As more organizations implement a shift-left approach to software development, architects are looking for ways to become part of a collaborative team. They can no longer deliver a design to development and walk away. With a continuous modernization approach, friction between what was planned and what was implemented disappears as teams work together to address architectural changes as early in the process as possible.
Originally, the shift-left movement focused on security. Its goal was to create systems where security was part of the design rather than added later in the development process. The shift required software architects to consider security measures in their initial design. It meant testing earlier and addressing design limitations while development was just beginning.
The changing mindset added pressure on engineers to maintain visibility into an application’s architecture. Evolving security requirements often demanded changes in design. That created a problem. How do you change a design if you don’t know what the design is doing in production? Even more critical is how you control design changes in a continuous integration/continuous development (CI/CD) environment. Can continuous modernization help?
What is Continuous Modernization?
Continuous modernization not only extends the CI/CD process, but more importantly, it enables organizations to incrementally modernize software to minimize technical debt and architectural drift. It gives companies a path for improving security as architectural vulnerabilities appear. Unlike waterfall approaches, architecture updates are provided throughout the SDLC process, not deferred to future releases or never.
However, all software suffers from growing technical debt. Changes are based on expediency rather than design integrity. If not controlled, an application can deviate from its original infrastructure, making it difficult to locate and fix flaws. Understanding architectural drift is imperative to help teams leverage continuous modernization to minimize architectural erosion.
What is Architectural Drift?
Software evolves—sometimes by design, but often in response to business demands. Users want a new feature. The application needs better performance. Of course, delivery schedules are tight, requiring trade-offs. These decisions often result in technical debt and architectural drift.
Architectural drift results from the unchecked evolution of runtime software that leads to a lack of coherence and clarity in the software’s design. Dead code, class entanglements, and deep dependencies contribute to Brian Marick’s “big ball of mud” that prevents architects from observing how systems work in live environments.
Related: Getting Leadership Buy-in on a Continuous Application Modernization Strategy
Unless engineers can see the architecture in operation, they cannot determine how far the software has drifted from its original design. They’ve lost control of the ship, and it’s drifting in open waters.
How Does Architectural Drift Become a Problem?
When ships drift, they go where the ocean takes them. Left unchecked, they go aground or succumb to the elements. The same can be said of architectural drift. Without correction, a system flounders. Its agility falters, and its viability fails. Like a ship, it succumbs to its environment.
Start with the Design
Architectural drift can begin before a developer writes a line of code. Designs that use tightly coupled structures with layered dependencies allow developers to rely on the infrastructure to maintain control. Function calls disappear into a maze that mysteriously delivers a result — almost like magic. If an error occurs, architects have few resources to help identify where the problem resides.
Even with distributed architectures, engineers can struggle. Microservices deployed across an application throw an error. How do architects determine if the error is isolated to a single instance? How do they determine what triggers the error? Without observability, resolution becomes time-consuming.
Add Changes Over Time
Not every software change adds to an application’s architectural technical debt. However, those that do pose a problem for engineers. During development, design changes may try to follow best practices for identifying deviations from the original architecture specification. But shift happens.Whether requirements change or expediency calls, architectural erosion is the result. Modifications are made that alter the original design. If left unchecked, these changes accumulate and increase the architectural drift of an application.
Mix in a Lack of Visibility
While visibility tools abound for applications, these same tools are not available at the architecture level. Without tools to analyze, track and correct architectural erosion, architects can’t adequately define how far the design has drifted. Even with better tools, engineers need observability capabilities.
Unlike monitoring, observability takes a proactive look at the internal state of the software during runtime. Its goal is to identify critical anomalies in a system’s architecture. To be effective, observability must be consistent, holistic, and automated. But what exactly is observability?
What is Observability?
Observability tries to describe the internal state of software through external outputs. Observability typically uses three data sources known as the three pillars of observability.
- Logs. Record what happens within an application, including its infrastructure.
- Metrics. Defined data points used to flag unusual behavior.
- Traces. Provide visibility of step-by-step code execution.
Events are often considered a fourth pillar. These customized records highlight potential problems through pattern identification,
While the data sources provide useful information, they have their limitations. Using observability tools that combine the information into comprehensive views delivers a realistic picture of system operations. Unfortunately, not every system component has the same level of visibility tools.
Why is Architectural Observability the Answer?
System architects have worked with “big balls of mud” for decades. They have struggled to untangle threads and assess problems through indirect means. The difficulty with architectural observability is poor tool creation.
Systems Are Complex
Monolithic structures have given way to distributed architectures that include microservices and containers. Sustained visibility across a distributed system often requires multiple tools that deliver data in varying formats. What’s missing is data consolidation that delivers a holistic view.
Data is Complex
Sorting through volumes of data recorded in real-time presents a challenge. Even with automated tools, data management can become time-consuming. If the data is not persisted, timely extraction may be needed for an accurate view over time. These factors complicate tool creation. Data consistency is crucial to identifying drift.
Related: Shift Left to Avoid Technical Debt Disasters: The Need for Continuous Modernization
A further complication to consistency is data separation. In collaborative environments, having access to all pertinent data may not be an issue; however, in situations where data silos exist, incomplete information makes a comprehensive evaluation impossible.
Business is Complex
Tying architectural events to business outcomes isn’t easy. Without an understanding of business complexities, architects may focus on the wrong metrics and fail to collect crucial data for analysis. For example, engineers may place a high priority on determining why CPU usage increases when a set of microservices runs. Executives may consider increasing page load times as more significant because slower load times can translate into lost revenue for an eCommerce site.
Observability allows engineers to see how released software deviates from its original design. It requires the right tools and a plan to address architectural drift.
How to Address Architectural Drift
Observability needs tools to establish a baseline and set thresholds. Best practices should proactively detect and correct abnormal behaviors that lead to architectural drift. The planned outcome should deliver a process that is consistent, holistic, and automated.
#1: Establish a Baseline
Baselines establish a starting point. They should include service topologies that itemize common and core business services. They should identify critical components that are routinely audited to detect deviations from the baseline. Automating the process allows architects to track those ad-hoc changes that impact an application’s infrastructure.
#2: Identify Service Exclusivity
As part of baselining, measure service exclusivity. Knowing how many independent classes and service resources are in use highlights dependencies that increase architectural debt. This baselining can help identify possible debt early before it becomes a paralyzing problem.
#3: Set Thresholds
Architects can establish thresholds for proactive observations of a system’s architecture. Automated systems enable engineers to schedule observations, configure measurements, and start analyses. Automating the collection of key metrics expedites the evaluation process for faster resolution of pending issues.
#4: Automate the Process
Automating data collection is only the first step in delivering comprehensive observability. Automation must turn that data into valuable insights that enable architects to minimize architectural erosion. The landscape is too complex and changes too rapidly for manual processing.
Continuous Modernization and Architectural Drift
Architects must be proactive in a continuous modernization environment. They must shift left to be more engaged in the initial design, whether refactoring, rearchitecting, or starting new. Their job persists through an application’s lifecycle because they have the tools needed to observe and correct architectural drift.
vFunction’s Continuous Modernization Manager provides architects with the tools needed to overcome observability challenges. Its automated modernization solution provides a holistic approach that delivers insights based on consistent data. The manager allows architects to:
- Shift left into the development cycle
- Monitor, detect and identify architecture drift
- Set baseline and thresholds
- Send alerts when critical
vFunction enables engineers to remain proactive through an application’s lifecycle. It helps maintain the architectural integrity of the software as it is continuously modernized. To see how we can help with your application modernization needs, request a demo.
