Why We Chose These Patterns — And What That Choice Actually Means
Four architectural patterns, four reasoning decisions. Understanding the logic behind the design is what separates strategic architecture from technical preference.
Series: Build to Change — Part 2 of 3
"Choosing an architectural pattern is not a technology preference. It is a reasoning decision — a response to a specific problem in a specific context. A question of how strategic architecture actually thinks."
In Part 1 of this series, we examined the strategic case for moving from Build to Last to Build to Change — the shift from monolithic, tightly coupled enterprise systems toward composable architectures that can respond to the business rather than constrain it.
That argument is the why. This article is the how — specifically, the reasoning behind the four architectural patterns selected to govern the procurement modernization. Not why they are technically sound, but why they were the right choice for this particular problem, in this particular context, at this particular moment.
That distinction matters. A pattern that is correct in principle but misapplied to the wrong problem produces a result that is technically elegant and operationally useless. Fit-for-Purpose architectural thinking demands that every design decision be traceable to the specific concern it is resolving. These four patterns were each chosen because they resolved a specific concern — and for no other reason.
PATTERN ONE: THE STRANGLER FIG
Reasoning: Evolution Over Revolution
THE STRANGLER FIG PATTERN
The Strangler Fig Pattern takes its name from a tree that grows around an existing structure, gradually replacing it while the original continues to function. The host tree does not need to be cut down first. It is displaced incrementally as the new growth takes over, until the original is no longer needed.
In enterprise architecture, the pattern works the same way. A new capability is built alongside the legacy system. Traffic is incrementally routed to the new system as each capability is proven. The legacy system continues to handle what has not yet been migrated. Over time, the legacy system's scope shrinks until it can be decommissioned without a disruptive cutover event.
The pattern is most valuable when: the legacy system cannot be taken offline, the full scope of the migration is not yet known, or the organization needs to build confidence incrementally before committing to a complete replacement.
Ref: Strangler Fig Pattern: A legacy modernization strategy popularized by Martin Fowler (2004) to enables a phased migration from monolithic architectures to modern, modular systems.
The procurement system could not be shut down. It was running live transactions every day — purchase orders being raised, approvals being processed, vendor payments being triggered. Any modernization strategy that required a full cutover carried a risk profile that no organization could accept.
The Strangler Fig Pattern resolved this concern directly. Rather than replacing the legacy system, we built a facade — an intermediary layer that sat in front of both systems and directed traffic based on a simple rule: if the requested function had been modernized, route to the new system; if not, route to the legacy system. The user experience remained consistent throughout. The migration happened behind the interface, invisible to the people whose work depended on it.
The sequencing followed a deliberate risk logic. The first capability migrated was the approval workflow — chosen because it was high-value to the business, relatively self-contained, and carried the lowest dependency risk. Once that migration was stable, the vendor portal followed. The purchase order generation — the most deeply integrated function — was retained in the legacy system until the surrounding capabilities were proven.
This incremental approach did something beyond managing technical risk. It built organizational confidence. Each successful migration demonstrated that the new architecture worked, reduced the scope of what remained in the legacy system, and gave the team real operational experience with the new environment before the most complex migration began.
The goal was not to be bold. It was to be right — incrementally, in sequence, without disrupting the business that depended on the system throughout.
PATTERN TWO: THE ANTI-CORRUPTION LAYER
Reasoning: Data Sovereignty
THE ANTI-CORRUPTION LAYER
An Anti-Corruption Layer (ACL) is an architectural boundary placed between two systems with different data models and conceptual structures. Its sole function is translation — converting the data and language of the old system into the data and language of the new one, and vice versa, without allowing either system's internal logic to contaminate the other.
The name reflects the core concern it addresses: in a direct integration between a legacy system and a modern one, the complexity and idiosyncrasy of the legacy system's data model tends to "corrupt" the design of the new system. The new system is built around old constraints it should have been free to leave behind.The ACL prevents this by acting as a dedicated translation layer. Neither system needs to understand the other's internal structure. Each speaks its own language. The ACL handles the conversion between them.
Ref:The Anti-Corruption Layer (ACL) pattern was introduced by Eric Evans (Domain-Driven Design: Tackling Complexity in the Heart of Software, 2023). It acts as a mediating interface that prevents legacy system complexities from polluting the integrity of a new, modern architecture.
Legacy enterprise systems accumulate decades of data model decisions, many of which reflected the technical constraints of the era in which they were made rather than the actual structure of the business processes they supported. Table names that reflect historical organizational structures. Field definitions that combine logically separate concepts. Relationships that exist for technical reasons with no direct business meaning.
If the new procurement system were built to integrate directly with the legacy system's data model, it would inherit all of those constraints. The new architecture would be shaped by the old one. The technical debt being eliminated from the core would simply reappear in the new system, in a different form.
The Anti-Corruption Layer resolved this by establishing a clean boundary. The new system was designed on its own terms — using a data model that reflected the actual procurement process as it needed to work, not as the legacy system had encoded it. The ACL handled all translation between the two worlds. When the new system needed vendor data, it requested it in its own language. The ACL converted that request into whatever the legacy system required, retrieved the data, and returned it in the format the new system expected.
The cost of building and maintaining the ACL was real. The decision to absorb that cost was justified by a single consideration: the new system needed to be free to evolve. An architecture that begins life constrained by the legacy it was designed to replace will eventually require its own replacement for the same reason.
Data sovereignty — the principle that a new system owns its own data model and is not governed by the legacy it coexists with — is not a technical nicety. It is the condition that makes long-term architectural flexibility possible.
PATTERN THREE: THE SIDECAR
Reasoning: Separation of Concerns
THE SIDECAR PATTERN
The Sidecar Pattern separates supporting functions — logging, security, authentication, monitoring — from the core business logic of a service, by running them as a separate process attached to the main service rather than embedded within it.
The metaphor is a motorcycle sidecar: a separate compartment that travels with the vehicle, shares its lifecycle, but is structurally independent. The sidecar can be upgraded, replaced, or reconfigured without modifying the main vehicle.
In enterprise architecture, the pattern is most valuable when supporting functions need to evolve independently of business logic — when, for example, security requirements change more frequently than procurement logic, or when observability standards need to be updated across multiple services without touching each service's core code.
As the procurement capabilities were extracted from the legacy core and rebuilt as independent services, a recurring design question emerged: where does the security logic live?
The naive answer is inside the service — each capability manages its own authentication, its own access controls, its own audit logging. The problem with this approach is that security requirements change more frequently and more uniformly than business logic. When the organization updates its authentication standards, every service that has embedded security logic requires a coordinated update. Each update carries deployment risk. The more services involved, the higher the coordination cost.
The Sidecar Pattern resolved this by separating the concerns entirely. Security logic, audit logging, and monitoring were placed in dedicated sidecar processes that ran alongside each business service but were maintained and updated independently. The procurement approval service handled procurement approval logic. The sidecar handled everything else.
When security requirements changed, the sidecar was updated. The business service was untouched. The deployment was smaller, faster, and lower risk. The business logic remained focused on its purpose. The supporting functions remained focused on theirs.
This is the architectural principle of separation of concerns applied at the service level. It is not a pattern chosen for technical elegance. It is a pattern chosen because it makes the architecture cheaper to maintain and safer to change — which, over the lifetime of a live enterprise system, is the more important property.
PATTERN FOUR: EVENT-DRIVEN ARCHITECTURE
Reasoning: Resilience Through Decoupling
EVENT-DRIVEN ARCHITECTURE
In a traditional integrated system, services communicate through direct calls — Service A requests data from Service B, waits for the response, and proceeds based on what it receives. This is synchronous, predictable, and fragile: if Service B is slow or unavailable, Service A waits or fails.
Event-Driven Architecture replaces direct calls with events. When something significant happens — a purchase order is approved, a vendor record is updated, a payment is processed — the system publishes an event describing what occurred. Any other service that needs to respond to that event subscribes to it and processes it independently, at its own pace.The result is a loosely coupled system: services are aware of events but not dependent on each other's availability. A slowdown in one service does not cascade to others. New capabilities can be added by subscribing to existing events, without modifying the services that produce them.
In a tightly coupled monolithic system, the failure modes are symmetrical with the integration. When one component slows, the services that depend on it slow. When one component fails, the services waiting for its response fail. The procurement approval process waiting on a finance validation is only as fast as the slowest step in the chain.
Event-Driven Architecture resolved this by changing the fundamental communication model. Rather than services calling each other and waiting for responses, services publish events and continue. When a purchase order is approved, the system publishes an event that says, in effect, "this approval occurred." The finance system, the inventory system, the vendor notification service — each subscribes to that event and processes it independently. No service waits for another. No failure cascades.
The business value of this choice extends beyond resilience. It changes how new capabilities are added. In the legacy system, extending the procurement process — adding an automated vendor risk check, for example, or a real-time budget validation — required modifying the existing process code. In an event-driven model, a new capability simply subscribes to the relevant event and processes it. The existing services are untouched. The new capability is independent.
This is the architectural foundation that makes the Composable Enterprise possible in practice. Each service can evolve independently. New capabilities can be added without modifying what already works. And the system as a whole becomes more resilient precisely because its components are less dependent on each other.
THE PATTERN DECISION AS A FIT-FOR-PURPOSE EXERCISE
Looking across these four patterns, a common reasoning structure is visible. Each was chosen not because it was architecturally fashionable or technically sophisticated, but because it resolved a specific, named concern in the most direct way available.
The Strangler Fig resolved the concern that a live system could not be taken offline. The Anti-Corruption Layer resolved the concern that a new system would inherit the constraints of the one it was replacing. The Sidecar resolved the concern that supporting functions would constrain the evolution of business logic. Event-Driven Architecture resolved the concern that tight coupling would propagate failures and limit extensibility.
Each decision was traceable to a concern. Each concern was named before the pattern was selected. And each pattern was evaluated against the question of whether the investment it required — in development time, governance overhead, and operational complexity — was proportionate to the value it generated.
This is Fit-for-Purpose architectural thinking applied at the design level. The patterns are not the architecture. The reasoning behind their selection is.
A technically sophisticated pattern applied to the wrong problem is not a strategic decision. It is an expensive one.
Next in this series — Part 3: Tools Are Many. Perspective Is the Point. How EA governs a modernizing landscape without becoming the obstacle it was designed to prevent — and why the people inside the architecture ultimately determine whether it delivers value.
Ref: Building Microservices: Designing Fine-Grained Systems, Sam Newman.
Raschada Nootjarat is an Enterprise Architect with a focus on AI strategy, architecture governance, and the intersection of human and machine systems in organizational transformation. She starts this website together with her "Fit-for-Purpose Enterprise Architecture" book in April, 2026.