Enabling Evolutionary Architecture Through Change Locality

What is Change Locality?

Change locality is a critical property in evolutionary architecture, asserting that a business capability has locality when the responsible team can make changes without needing to reconstruct the entire system. It means the understanding required for a change should be proportional to the change's scope. For example, updating address UI should not require understanding the entire delivery model, but changing address policy might appropriately involve coordination with fulfillment and fraud teams, provided that coordination is explicit.

Understanding Boundary Drift

Boundary drift occurs when the initial hypotheses about system boundaries—which decisions or components should change together—no longer align with the actual paths of change required by the business. This misalignment often stems from product expansion, team reorganizations, platform responsibilities shifting, or supporting capabilities becoming core. The result is that a team, like a checkout team for an e-commerce system, might still "own" a request (e.g., changing an address) but no longer owns all the decisions determining its safety (e.g., warehouse cutoffs, fraud rules, delivery partner instructions).

This drift leads to disproportionate cognitive load, where a local-looking request requires understanding complex, non-local context. Signals include features touching many systems with unclear ownership, incidents relying on tacit knowledge from specific engineers, lengthy onboarding due to uncodified knowledge, or extensive code review threads on small changes due to disagreement on correct behavior.

Sociotechnical Causes of Drift

• Technology: Shared platforms abstracting decisions, shared databases spanning domains, implicit runtime dependencies, opaque platform abstractions, and missing observability can all contribute to technological drift.
• Team Ownership: Ambiguity or misalignment between team ownership and the capabilities they are expected to evolve, especially when organizational structures change but system topology does not, leads to gaps in end-to-end policy ownership.
• Process: Outdated review steps, support scripts becoming de facto policy, or rigid governance processes that preserve an older operating model despite product evolution can cause process-related drift.
• People: Over-reliance on individual memory and relationships as the primary integration layer, creating tight coupling through tacit knowledge rather than explicit system design.

Restoring Locality: Strategies for Architects

Architects can restore change locality through deliberate trade-offs and structural interventions. The core idea is to make decisions clear and keep them with the teams that understand them. This involves:

• Redistribute Repeated Mechanics: Identify common, low-level mechanics that are being duplicated or managed inconsistently across teams. Centralize or standardize these operations (e.g., a shared shipping platform for carrier rules) to reduce cognitive load on individual teams, but ensure necessary decisions remain explicit and visible.
• Expose Essential Policy: Rather than hiding critical business decisions behind abstractions, expose them explicitly via APIs or well-defined contracts. For instance, a fulfillment service should provide clear responses (e.g., "too late to change - fraud locked") instead of just a generic error, allowing the checkout team to react appropriately without deep internal knowledge.
• Rehearse Real Exception Paths: Systematically identify and codify how exceptions are handled. This reduces reliance on tribal knowledge and ensures that the system's design accounts for deviations from the happy path, making change safer and more predictable. This also involves periodically re-evaluating whether chosen boundaries still match the current path of change.