Enabling Evolutionary Architecture Through the Preservation of Change Locality

When Change Stops Being Local

A software engineering team was responsible for maintaining and evolving their internal e-commerce checkout process. This most recent request looked small: let customers change a delivery address after placing an order. Checkout owned the screen, the confirmation flow, and the customer journey, so the work appeared to belong inside the checkout boundary.

Discovery showed a different decision path. Whether the address could change depended on warehouse cutoff times, fraud rules, delivery partner instructions, support scripts, notification templates, and refund policy. The implementation might still be small, but checkout could not make the change safely without understanding decisions owned elsewhere.

This is boundary drift. The address-change request still starts in checkout, but checkout no longer owns all the decisions that determine whether the change is safe. Preserving change locality means making those decisions clear and keeping them with the teams that understand them: fulfillment owns cutoff timing, fraud owns risk rules, support owns customer promises, and checkout can use those decisions without rediscovering them for every request.

Figure 1: Restoring locality makes the required context visible and keeps local changes local. Source: AI-generated with ChatGPT

Evolution Depends on Change Locality

Evolutionary architecture starts from a simple premise: change is constant, not exceptional. The architectural question is not only, "Can the system change?" It is, "Can the right team make the change with the right amount of context?"

Modern systems face change from several directions at once: new regulations, customer workflows, product experiments, AI-enabled capabilities, operating constraints, and market shifts. At sufficient scale, almost any system can be made to change. The harder question is whether change remains coherent, so a team can evolve a capability without reconstructing the whole system every time.

That property is change locality. A business capability has locality when the team responsible for it can answer three questions without reconstructing the whole system:

• What can change here?
• What contract protects neighboring work?
• What evidence proves the change is safe?

Clear domain boundaries, explicit contracts, observable dependencies, and platform support all serve this test.

Locality does not mean isolation. The point is proportionality: the understanding required to make a change should be proportional to the scope of the change. If changing the address copy requires checkout to understand the whole delivery model, locality is weak. If changing address policy requires coordination with fulfillment and fraud, that coordination may be appropriate, but it should be explicit.

Boundary Drift Breaks Change Locality

Boundaries are hypotheses about which decisions or components should change together. They are also provisional agreements about where change should be contained, drawn to reflect how the business looked at a particular moment.

Common ways boundaries may drift:

• Products can expand into adjacent capabilities.
• Teams may split, merge, or reorganize.
• Platforms absorb responsibilities that used to live close to product teams.
• Supporting or outsourced capabilities become core to the business.

Thus, the boundaries that once made change safe can begin to misalign with the path of change the business now requires.

At first, the address-change boundary may fit checkout well. Customers can edit the address until the order is packed. Checkout owns the screen, the rule, the confirmation email, and the dashboard. A change like "allow edits for 30 minutes after purchase" involves one team, one test suite, and one release.

Then the business learns. Some items leave the warehouse quickly. Some addresses trigger fraud checks. Some delivery partners need instructions earlier than others. Premium customers get more flexible service. Support starts handling exceptions over the phone. Each change is reasonable. Together, they change what an address update means at different stages of order fulfillment.

The gap between the boundaries that the system still expresses and the boundaries required by the pending change is the boundary drift. In other words, the decisions have moved/changed; the structure has not. The checkout team still owns the address-change request and backlog, while fulfillment, fraud, support, and delivery now own decisions that determine whether the change is safe.

We can also consider a software engineering team at a digital retail bank that is responsible for the account opening flow. At launch, the bank offered one simple savings account with that development team owning the application form, identity checks, and welcome communications; the boundary fit.

The bank then grew by adding loan accounts, while building its own underwriting process which pulls and scores credit histories automatically, with edge cases going to a human underwriter. Fully supporting checking accounts meant printing, mailing, and activating debit cards. Inadvertently, growing and evolving compliance rules to underpin the new financial products led to more applications being flagged for review, requiring document requests and intake, potentially pushing decision-time into days and no longer minutes.

The onboarding team still owns the account opening process and receives direct requests to modify the form; requiring the onboarding team to hold non-local context owned by Underwriting, Card Fulfillment and Compliance in order to make a safe change. The boundary never moved on paper. The path of change did.

Figure 2: Boundary drift can create a reinforcing loop unless architects intervene. Source: AI-generated with ChatGPT

Cognitive Load is the Signal

Cognitive load in this context means the amount of business, technical, operational, and organizational context a team must hold in balance to accurately make changes to the system.

For the address-change capability, the signal is not "five teams are involved." The signal is that checkout cannot tell which decisions matter, who owns them, or what evidence proves the change is safe. A local-looking request now requires the team to reconstruct warehouse timing, delivery partner rules, fraud exceptions, support promises, and refund behavior.

The same signal appears outside this example. A team estimates a modest feature and then discovers during implementation that it touches three systems with unclear ownership. An incident post-mortem shows that recovery depended on one engineer who remembered a non-obvious dependency from a previous role. Onboarding takes months because the knowledge required to reason safely does not live in the code, tests, documentation, or dashboards. A 10-line pull request generates a fifty-comment review thread because reviewers cannot agree which behavior is correct.

These may be signs that the current boundary model may no longer match the structure of change.

The drift is easier to see when decision authority is separated from the user-facing structure:

Sociotechnical Design Explains the Drift

Boundary drift is sociotechnical because the same symptom rarely has a single technical cause. Team ownership, operating processes, platform design, and institutional knowledge can also shift the boundaries. These are illustrated below using the address-change example.

Figure 3: Boundary drift is rarely only technical; it emerges across technology, teams, process, and people. Source: AI-generated with ChatGPT

Technology

When shared platforms remove duplication but hide decisions, this can be a symptom of technology drift. A shipping platform may centralize carrier rules, warehouse cutoff times, and delivery promises. That may be the right trade-off, but checkout still needs to understand what a "too late to change" response means: packed, dispatched, fraud-locked, partner-notified, or refund-sensitive. Drift also hides in shared databases that span domains, runtime dependencies added without explicit contracts, platform abstractions that obscure important behavior, and missing observability that forces teams to reason about effects they cannot directly see.

Team Ownership

Ambiguity or confusion over team ownership can play a role. Checkout may own the customer experience, warehouse operations may own physical fulfillment, fraud may own risk, and support may own exception handling. Each ownership line can make sense locally. The gap appears when ownership no longer aligns with the capability teams are expected to evolve, or when the organization changes but the system topology does not. In this example, no team clearly owns the end-to-end policy.

Process

Evolution of process, or the lack of it, along with the evolution of capability, can be a source of drift. A review step may have been added after a delivery incident. Support scripts may have become the practical source of exception policy. Refund approvals may sit in a separate workflow. Release governance, architecture review, incident escalation, and decision-making processes encode past learning, but they can also preserve an older operating model after the product has changed.

People

Experienced engineers, operations leads, and support managers often remember why certain promises are unsafe. That memory is valuable. The risk is that relationships and recollection become the only reliable integration layer. The system may look decoupled in its deployment topology while remaining tightly coupled through the tacit knowledge required to reason about it safely.

No structural style or modeling practice guarantees locality indefinitely. It is important to periodically re-evaluate whether the chosen boundary still matches the current path of change.

Restoring Locality: Redistribute, Expose, Rehearse

Restoring locality starts with a practical question: where should this kind of change land? We strive to have each decision land where its context lives, while making the evidence required to make changes safely, visible across boundaries.

Figure 4: Architectural intervention starts with diagnosis, then uses trade-offs to restore locality. Source: AI-generated with ChatGPT

Redistribute Repeated Mechanics

Redistribution changes who owns mechanics. If several teams repeatedly implement the same mechanics (cutoff calculations, partner status checks, notification delivery, deployment pipelines, infrastructure setup, compliance scaffolding, or observability wiring), a platform or shared service may help. This should not move business policy into the platform by default. The platform can own mechanics and toil; product and domain teams still need clear authority over customer promises.

Expose Essential Policy

Exposure determines what teams need to see. Some constraints must be visible to the teams making changes: when an order is packed, when fraud can block an address, when a partner needs final instructions, and what support can promise. Exposure can mean explicit ownership, API contracts, contract tests, architecture decision records, service catalogs, meaningful events, dashboards, or escalation paths. The goal is to make the decisions that govern safe change legible to the teams responsible for evolving the capability.

Rehearse Exception Paths

Rehearsal tests whether the new arrangement keeps the change local under realistic conditions. After a redesign, test the cases that previously required expert coordination. Can support resolve a known address-change exception from the visible policy? Can checkout adjust a premium-customer window within approved guardrails? Can the team see when a partner handoff makes the change unsafe? Incidents, onboarding, architecture reviews, and capability walkthroughs all reveal whether the boundary works in practice. If every realistic exception still depends on the same experts, locality has not been restored.

Trade-Offs and Limits

Preserving change locality is achieved with a balance of team autonomy and coordination. Autonomy without coherent contracts can create duplicated rules, incompatible data semantics, and operational surprises.

Standardization can improve flow, but it can move too much decision-making away from the teams closest to the domain. Low cognitive load is not valuable if the wrong complexity has been hidden. Some changes are genuinely cross-cutting: shipping promises, fraud controls, refunds, safety, financial reporting, and customer communication may require broad agreement because the business consequence is shared. Do not optimize for locality when consistency or risk control matters more than local speed.

The architect's job is not to force every change back into one team. It is to preserve enough locality that the system can keep changing coherently, resiliently, and sustainably as the business evolves.

Boundaries Are Living Hypotheses

Architects help by treating boundaries as living hypotheses: these decisions should change together, and these teams should be able to reason about them with this level of context. Delivery friction, incidents, support escalations, review queues, and expert dependency test whether that hypothesis still holds.

The practical discipline is to keep asking three questions:

• Which changes now require teams to reason beyond the boundary that receives the request?
• Which team or boundary should own the decision that makes the change safe?
• What policy, evidence, or mechanics must be redistributed, exposed, or rehearsed so the change can remain local?

A more evolvable architecture keeps small changes small. Teams can act with confidence because they understand the part of the system they are responsible for, and because the boundaries around that responsibility hold under pressure.

When teams can make local changes with local understanding, the system can evolve without losing coherence. When even simple changes become negotiations with the entire system, boundary drift has become the dominant cost of changing that capability.

References

• Ford, N., Richards, R., & Sadalage, P. (2022). Building evolutionary architectures: Automated software governance (2nd ed.). O'Reilly Media.
• Skelton, M., & Pais, M. (2019). Team topologies: Organizing business and technology teams for fast flow. IT Revolution Press.
• Evans, E. (2003). Domain-driven design: Tackling complexity in the heart of software. Addison-Wesley.