Architectural Change Cases: A Practical Tool for Evolutionary Architectures

One focus of software architecture is to improve the maintainability of a system over its lifespan. In many cases, this effort is largely speculative because it considers events that are by definition uncertain. It is easy to dismiss the impact of potential future change by asking, "How hard can it be to fix this if we need to?", but our experience has taught us that this is an invitation for retribution.

To focus this speculation and reduce the time a team spends in seemingly endless what-if discussions, we use what we call a change case. An architectural change case is a little like a crystal ball that lets you reason about possible outcomes of your architectural decisions.

While architectural decision records (ADRs) document decisions and, sometimes, trade-offs, they summarize a decision rather than serving as the starting point for an investigation of alternatives. Change cases articulate a possible need but not the means by which that need is satisfied.

Unlike architectural change cases, the goal of the Architecture Tradeoff Analysis Method (ATAM) is to evaluate how well an existing software architecture meets its current quality attribute requirements (QARs). In contrast, architectural change cases aim to assess how a system may need to evolve in the future.

What is an Architectural Change Case?

An architectural change case identifies a potential change to a solution's assumptions that may significantly impact its software architecture. A change case does not need to define the alternative solution; its purpose is mostly to articulate the possibility of a change at some point in the future and to outline possible alternatives. This approach supports contingency planning and may encourage design flexibility to mitigate the effects of the change. Its ultimate goal is to assess the resiliency of a software architecture.

An architectural change case may include the following information:

• A potential change in a QAR (higher or lower) or in the business case
• The likelihood of change (probability)
• The list of decisions that would need to change because their assumptions were violated
• Any potential options for resolving
• A forecast of the cost of change, which is the cost of reversing the decision. This cost can be roughly estimated using "t-shirt size" (S, M, L, XL, etc.) orders of magnitude.

An architectural change case is also a good way to analyze the impact of changing architectural decisions by articulating an alternative decision and the cost of reversing a current decision to implement the alternative, should the original decision prove to be incorrect.

Sources for identifying architectural change cases include "Chaos Monkey" -type tests to identify potential faults and system configuration changes that could lead to catastrophic failures. Another useful technique is to conduct pre-mortem reviews to consider how a system's architecture might fail. Architectural change cases can articulate these changes and help the team to formulate responses.

Architectural Change Cases Anticipate System Decay

Many software architectural decisions, in practice, seem to assume that either things won’t change or that change can be prevented. Neither of these assumptions is realistic. Change is inevitable in the technologies the system utilizes, in the skills of the people who will maintain it, and, most importantly, in the business context in which the system operates. Approaches like continuous architecture and evolutionary architecture recognize these challenges.

Architectural change cases help teams using these approaches express potential changes. This might include changes to AI models (e.g., concept drift), environment configurations, component and framework versions, security threats, bandwidth, and so on. Change cases also account for changes in the business environment, such as a minimum viable product (MVP) failing or becoming obsolete because of market shifts.

Architectural Change Cases in Practice

Consider the case of a large insurance company that creates a new subsidiary to compete against more nimble competitors by offering innovative products. They want to initially offer on-demand vacation home renter insurance, a short-term, flexible coverage that can be turned on or off via a mobile app. The availability of this product would be initially limited to one state. Their target customer base includes people who rent vacation homes for a few days to a few weeks, because their belongings are usually not covered by the homeowner’s insurance.

The company's management assumes that reusing the underwriting, accounting, and claims applications from the parent company will reduce its costs and time-to-market. They elect to use an AI coding agent to bring an MVP rapidly to market.

Their potential change cases include underestimating the adoption of their MVP. The actual number of users may turn out to be up to fifty percent higher than their highest estimates, because short-term renters appear to love the flexibility provided by this new product, based on initial usage statistics. As a result, the MVP may experience scalability and performance issues. The Minimum Viable Architecture (MVA) would need to be rapidly updated to handle the higher volumes, with a margin of safety.

What if their business stakeholders want to expand their target customer base to include recreational vehicles (RVs) and boat renters? It is doubtful that the parent company’s underwriting system would be able to handle these risk classes. What if their business stakeholders want to add an additional state with very different insurance regulations? This change case would test the solution's maintainability, as well as its performance and scalability.

These change cases imply that the team may no longer be able to reuse the underwriting system from their parent company. Table 1 summarizes the change case information collected by the team.

Table 1. Change case information for on-demand home renter insurance MVP.

Architectural change cases are a tool for thinking about the impact of your architectural decisions. Like considering the possible implications of a move in chess, they help teams to evaluate the strengths and weaknesses of a particular architectural decision.

Architectural change cases help to anticipate future architectural decisions.

A challenge in creating a Minimum Viable Architecture to enable the deployment of a minimum viable product is that architectural change cases need to be considered as part of the MVA success criteria, rather than just the solution of an immediate business problem.

Classes of Architectural Change Cases

While the example above focused mostly on functional changes, there are other classes of architectural change cases that teams need to consider, including:

• External system interface changes that require your system to change in tandem.
• Replacing a major subsystem because of changing needs, vendor consolidation or failure, open source project cancellation, or other reasons that make the initial choice no longer viable.
• Infrastructure changes, including moving computing resources to another data center or to the cloud, network changes that affect latency, etc.
• Significant changes to the business model, including an unsuccessful MVP or market changes that invalidate business assumptions.
• Changes in the security vulnerabilities of the system due to external factors.

Considering example classes of change cases can help a team assess whether the system may need to change in the future by prompting them to question their assumptions.

When to Define an Architectural Change Case

Teams should consider creating architectural change cases when:

• Introducing a major dependency
• Adopting AI-generated code
• Hardcoding business rules
• Optimizing for rapid MVP delivery
• Coupling to external platforms
• Accepting scalability or maintainability trade-offs

Change cases are most valuable where reversing a decision later could become expensive or operationally risky.

Architectural Change Cases and Planning

Defining change cases fits well into iteration planning work (e.g., a Sprint in Scrum). As we have described in a prior article, each iteration produces a new or enhanced MVP and an associated MVA. While the team plans the work for the iteration, they need to consider the architectural trade-offs they are making and how these trade-offs might change over time if the business or markets change or if QARs change.

Merely identifying possible change cases may be sufficient, or the team may need to go a little further by experimenting to test their assumptions about the code's future adaptability to change. The results of these experiments will tell the team how much they need to invest in improving the modularity of their code to enable possible future replacement of parts of the system when the need arises.

AI and Architectural Change Cases

Given the interest in using AI coding agents to generate at least some part of an MVP, it is worth considering its potential impact on future changes by creating AI-specific change cases. Nearly all uses of AI agents to generate code carries the risk that the AI company goes out of business or is purchased by a competitor. An additional risk is that the AI model may change significantly, rendering the generated code unrepeatable in the future.

For an AI coding assistant to produce acceptable results, the team needs to spend time up-front defining their objectives and writing specifications, including code samples, and defining acceptance tests. These work products are more important than the AI-generated code itself. An effective strategy to mitigate the risk created by AI model changes is to create and maintain a repository of artifacts used to provide context to the AI assistant, including requirements, specifications, design documents, architectural/design models, prior architectural and design decisions, data, interface specifications, code snippets and acceptance tests. This repository can be maintained using existing tools, such as GitHub.

Teams working with an AI Coding Assistant should consider defining change cases that anticipate:

• Replacing some part of your existing system (e.g., a microservice) with code generated by an AI agent. In this case, you still guide and control the architecture but let the AI handle the details.
• Creating a new MVP with a different AI or with a newer version of your chosen AI. If you generated your whole MVP (and therefore your implicit MVA) with an AI coding agent, you should know whether those results are repeatable.
• Changes in an external system with which the AI-generated code needs to interface. Most new systems have to interface with other systems, and those other systems will change. The AI-generated code has to be able to handle this change.

Investing in creating a repository of AI-specific change cases and associated artifacts is an effective way to future-proof MVPs built with an AI coding assistant’s help.

Architectural Change Cases Need to Be Evaluated Empirically

It is not enough to merely identify architecture change cases. While understanding that you may have a problem is useful, you can’t understand the magnitude of the problem by just thinking about it. The challenge is to really understand the magnitude (i.e., the cost) of the problem; you don’t want to have to build the entire alternative. Using experiments helps to provide data for the estimates without having to build the entire alternative.

As we wrote in an earlier article, developing architectural experiments is an important skill for understanding the risk and complexity of a potential change and for validating hypotheses. In fact, the only way to really understand the impact of change is to try a small subset of the intended change, evaluate its effectiveness, measure the effort expended, and then extrapolate the results.

Fitness functions can be used to evaluate the effectiveness of the change. A fitness function provides a measuring device to establish a baseline for a QAR impacted by the change case, and check whether the experiment succeeded in providing the expected improvements, without negatively impacting the remaining portions of the system. For example, using the first change case in Table 1, "Underestimated Adoption of the Product," the performance and scalability fitness functions assess whether an experimental MVA could provide the expected QAR improvements without negatively impacting the usability and maintainability of the MVP.

Of course, there is a cost to running these experiments. Architectural change cases can be a useful tool, but they should be used in moderation because they can be expensive, both in time and money. But for some questions, the only way to get an answer is to build (or generate) and test some code.

Conclusion

It would be easy to assume that software architecture is a static thing, that once defined, it remains unchanging over time. If such a thing exists, we have never seen it. All architectures change. The question is whether that change is intentional or accidental. Architectural change cases help a team to be more thoughtful about their architectural decisions, where they represent change.

In fact, the architecture of a software system is never really finished because the world around it is always changing. Using AI coding agents exacerbates this problem by introducing changes that are often invisible. To counter these change pressures, teams need to consider creating architectures that continuously anticipate and mitigate change. Using architectural change cases can help.