Evaluating and Evolving Architectures

Architecture Is Not a Milestone — It Is a Living Artifact

There is a dangerous assumption embedded in many development processes: that architecture is decided at a design review, documented, and then executed. Under this assumption, the architecture is static — a decision made once and defended thereafter. In practice, every architecture evolves. Requirements change. Technologies mature. Operational experience reveals performance characteristics that analysis could not predict. Threats emerge that the original threat model did not consider.

The question is not whether the architecture will change, but whether it will change through deliberate management or through uncontrolled drift. Deliberate evolution preserves architectural integrity — the system's structures remain coherent and the trade-offs remain understood. Uncontrolled drift accumulates technical debt — the architecture degrades incrementally until no one can explain why it is the way it is, and every change risks unintended consequences.

This lesson addresses both sides: how to evaluate whether an architecture is still fit for purpose, and how to evolve it when it is not.

Evaluating Architecture Fitness

An architecture is fit for purpose when it satisfies the system's current and foreseeable drivers (Lesson 1) within acceptable trade-off boundaries. Fitness is not a permanent state — an architecture that was optimal at initial deployment may become unfit as load grows, requirements change, or technology advances.

Fitness for Purpose

The most fundamental evaluation: does the architecture still enable what the system needs to do? Fitness for purpose is assessed by mapping current requirements and operational demands against the architecture's capabilities and constraints.

A software system designed for 1,000 concurrent users that now serves 50,000 may still function, but its centralized database architecture is no longer fit for that load. An aerospace avionics architecture designed for a single mission type that must now support three mission types may lack the modularity to accommodate the variation. A manufacturing line designed for one product family that must now produce four families may have hardcoded assumptions in its control architecture that prevent reconfiguration.

Fitness evaluation is not pass/fail. It identifies where the architecture is still adequate, where it is strained, and where it has failed. The strained areas are where intervention is most valuable — they have not yet failed, but they are trending toward failure.

How to assess. Revisit the architecture drivers from Lesson 1. For each driver, ask: has the demand changed since the architecture was established? Has the architecture's ability to satisfy the demand degraded? The gap between demand and capability is the fitness deficit.

Technical Debt

Technical debt is the accumulated cost of shortcuts, deferred maintenance, and architecture erosion. It is the gap between the architecture as designed and the architecture as built. Some technical debt is deliberate — a team knowingly takes a shortcut to meet a schedule constraint, with a plan to repay it later. Some is accidental — accumulated through years of changes made without understanding the architecture's intent.

Technical debt is not inherently bad. Like financial debt, it is a tool — taking on debt to meet a critical deadline can be rational, provided the debt is tracked and repaid. The danger is untracked debt: shortcuts that no one records, workarounds that become permanent, interface violations that accumulate until the architecture's integrity is compromised.

Common forms of technical debt across domains:

In software: duplicated code, outdated dependencies, bypassed architectural boundaries (a service calling another service's database directly instead of through its API), missing tests for critical paths.

In mechanical and civil systems: deferred maintenance, components operating beyond their design envelope, modifications that were not reflected in the as-built documentation, material degradation that changes structural behavior.

In electrical systems: wiring modifications that bypass the original routing plan, firmware patches applied without updating the configuration baseline, sensor calibrations that have drifted beyond their specified accuracy.

How to assess. Technical debt is measured by the cost to bring the architecture back to its intended state. If the answer is "we cannot determine the intended state because the documentation is out of date," that is itself a form of debt — documentation debt — and it is often the most expensive kind because it makes all other debt invisible.

Scalability Headroom

Scalability headroom is the margin between current demand and the architecture's capacity limits. An architecture with high headroom can absorb growth without structural change. An architecture with low headroom requires structural modification to accommodate even modest growth.

Headroom is assessed for each relevant dimension: computational throughput, data volume, user concurrency, geographic distribution, product variant count, production rate. The architecture may have ample headroom in some dimensions and none in others. A system that scales well with user count but not with data volume has a specific scalability constraint that will drive evolution.

How to assess. Identify the architecture's bottlenecks — the points where capacity is consumed first as demand grows. In a centralized architecture, the bottleneck is typically the central node. In a pipe-and-filter architecture (Lesson 4), the bottleneck is the slowest filter. In a pub-sub architecture, the bottleneck may be the broker. Measure current utilization at each bottleneck. The gap between current utilization and maximum capacity is the headroom.

Headroom matters because the cost of adding capacity depends on whether the growth is within the architecture's design range or beyond it. Adding a server to a distributed system is incremental. Redesigning a centralized system to be distributed is structural. Knowing where the architecture's growth limits lie enables proactive investment before a capacity crisis forces reactive redesign.

Architecture Evolution Strategies

When evaluation reveals that the architecture is no longer fit — or is approaching unfitness — evolution is necessary. The question is how to evolve without disrupting the system's ongoing operation or introducing unacceptable risk.

Planned Upgrades

Planned upgrades are scheduled modifications to specific components or subsystems within the existing architecture framework. The architecture's overall structure remains unchanged; individual elements are improved or replaced.

Characteristics. The upgrade is scoped to a component or interface. The component's interfaces are preserved or changed through formal interface change management (Lesson 2). The rest of the system is unaffected — or affected only through the managed interface changes. Testing focuses on the upgraded component and its immediate interfaces.

Where it works. Planned upgrades work when the architecture's fundamental structure is still sound and the issue is in a specific component's capability. Upgrading a sensor to a higher-accuracy model. Replacing a database engine with a faster one that supports the same query interface. Swapping a controller for one with more processing capacity that accepts the same I/O connections.

Where it fails. Planned upgrades fail when the problem is structural — when the architecture's topology or partitioning is the constraint, not a single component's capability. Upgrading the central node in a centralized architecture buys time, but if the fundamental issue is that centralization cannot scale, the upgrade defers the structural problem without solving it.

Technology Insertion

Technology insertion replaces an existing technology with a newer one that offers improved capability, reduced cost, or extended life. It is more disruptive than a planned upgrade because the new technology may have different interfaces, different failure modes, or different operating characteristics.

Characteristics. The replacement technology does not have a one-to-one interface match with the existing technology. Adaptation layers, interface converters, or partial redesign are required. The benefit must justify the integration cost, the requalification cost, and the risk of introducing new failure modes.

Where it works. Technology insertion works when the new technology provides a step change in a critical architecture driver (performance, cost, reliability) and the integration cost is manageable. Replacing analog instrumentation with digital sensors in a nuclear plant. Migrating from on-premise servers to cloud infrastructure in software systems. Transitioning from hydraulic actuation to electromechanical actuation in aerospace systems.

Where it fails. Technology insertion fails when the integration cost is underestimated — which happens frequently because new technologies are evaluated on their standalone capability, not on the cost of adapting the surrounding system to use them. A digital sensor that is individually superior may require changes to wiring, controller software, data processing, calibration procedures, and maintenance training — the total cost may exceed the benefit.

Migration Strategies

Migration strategies address structural evolution — changing the architecture's topology, partitioning, or fundamental organization. This is the most disruptive form of evolution because it affects the system's overall structure, not just individual components.

Strangler pattern. New capability is built alongside the old system. Traffic is gradually routed from old to new. The old system is "strangled" over time as the new system absorbs its responsibilities. This avoids a high-risk cutover and allows incremental validation. Common in software (migrating from monolith to microservices) and applicable to physical systems (building a new processing line while the old one continues to operate, then decommissioning the old line).

Parallel operation. The old and new architectures run simultaneously for a validation period. Outputs are compared. Discrepancies are investigated before the old system is retired. This is standard practice in safety-critical domains — a new nuclear reactor protection system runs in parallel with the existing system for months, with automatic comparison of trip decisions, before the new system takes authority.

Phased migration. The system is divided into segments that are migrated sequentially. Each phase has a defined scope, entry criteria, and rollback plan. The interface between migrated and non-migrated segments must be explicitly managed — this often requires temporary adapter interfaces that are removed when migration is complete.

All three strategies share a principle: never bet the system on a single cutover. Incremental migration with validation at each step is slower but dramatically safer than a flag-day replacement where the old system is turned off and the new system is turned on simultaneously.

The System Model's Role in Architecture Evolution

Architecture evolution is where MBSE (DGTLENG 201) provides its highest leverage. Without a maintained system model, architecture evolution is guided by institutional memory — which is incomplete, inconsistent, and walks out the door when people change roles.

Baseline Comparison

The system model captures the architecture baseline: the as-designed structure, interfaces, behaviors, and requirements allocation. When a change is proposed, the model enables comparison between the baseline and the proposed state. What components change? What interfaces are affected? What requirements are at risk? These questions are answered by model traversal rather than by meetings.

Impact Analysis

When a technology insertion or migration changes a component's interface, the model's traceability relationships identify every other component that depends on that interface. Every requirement allocated to the changing component. Every test that verifies the interface. Every behavioral model that assumes the current interface specification. This impact analysis is the difference between a controlled change and a surprise.

Configuration Management Over Time

As the architecture evolves through multiple upgrade cycles, the model maintains a history of configurations. The model can answer questions that human memory cannot: "What was the interface specification between subsystem A and subsystem B before the 2024 upgrade?" "Which requirements were satisfied by the component that was replaced in Phase 2?" "What drove the decision to change the data bus protocol in version 3?"

These questions become critical when a problem surfaces years after a change was made. Without the model, the investigation starts from scratch. With the model, the investigation starts from the recorded configuration history and decision rationale.

Architecture Decision Records

Architecture Decision Records (ADRs) document the context, decision, and consequences of each significant architecture change. An ADR captures: the problem or driver that motivated the change, the alternatives considered, the alternative selected, and the trade-offs accepted. ADRs are lightweight — typically a single page — but their value compounds over time because they preserve the "why" behind the architecture.

In an MBSE environment, ADRs link to the model elements they affect. The decision to migrate from a centralized to a distributed topology links to the structural elements that changed, the interface specifications that were modified, and the requirements that were re-allocated. This linkage means that anyone examining the model can trace from the structure to the decision that created it.

Without ADRs, architecture knowledge exists only in the minds of the people who made the decisions. When those people leave, the organization inherits an architecture it cannot explain — and an architecture you cannot explain is an architecture you cannot safely evolve.

Slide through the three maturity levels above. Most organizations operate at the static baseline or early managed evolution stage. Notice what changes at each level: not just the process, but the role of the system model and the relationship to technical debt. The progression is from reactive (fix it when it breaks) to proactive (monitor and maintain fitness continuously).

Assessment