THE FOUR GOVERNANCE PRINCIPLES

As the procurement capabilities were decoupled from the legacy core and rebuilt as independent services, the architectural landscape became more complex. More systems. More interfaces. More teams making more independent design decisions. The patterns selected in Part 2 created flexibility. Flexibility, without governance, creates a different kind of problem. 

Four principles governed how that complexity was managed.

PRINCIPLE ONE: SINGLE SOURCE OF TRUTH

As services migrated from the legacy core to the cloud platform, a predictable problem emerged: knowledge about the system's structure began to fragment. The team responsible for the ERP understood one part of the landscape. The cloud platform team understood another. The integration team understood the connections between them. No single person or team could answer the question, "what is actually connected to what, and what would change if we modified this?"

That fragmentation is the precondition for the kind of cascading failure documented in the case discussed in Why Strategic Enterprise Architecture Is the Secret to Real Business Value. Decisions made without visibility of dependencies produce unintended consequences. Those consequences compound.

The governance response was to maintain a centralized architecture map — a live inventory of every service, every interface, every dependency, and every migration status. Not as a documentation exercise, but as an operational tool. Before any change was approved, the map was consulted. Before any new capability was built, its dependencies were registered. The map was not owned by the architecture team alone — it was the shared reference for every team working in the landscape.

The goal was not comprehensiveness for its own sake. It was decision confidence: the ability to make a change knowing what else would be affected by it.  

PRINCIPLE TWO: STANDARDIZATION AND INNOVATION IN BALANCE

In a modernizing enterprise, the instinct of every development team is to choose the best tool for their specific problem. Left unchecked, this instinct produces a polyglot landscape — dozens of different frameworks, patterns, and platforms, each locally optimal and collectively unmanageable.

The governance response was a service catalog: a curated set of approved patterns, platforms, and integration standards, maintained by the EA function and available to every team. If a team needed to implement the Strangler Fig Pattern, the catalog provided the standard approach — the approved facade configuration, the routing logic, the testing requirements. If a team needed to integrate with the ERP, the catalog defined the approved interface through the Anti-Corruption Layer.

This is not the same as prohibiting innovation. The catalog itself was a living document, updated as new patterns were proven in practice. Teams could propose additions. Patterns that worked were standardized. Patterns that did not were removed.

The distinction the EA function had to maintain clearly was between standardizing the how — the patterns and platforms through which capabilities were built — and constraining the what — the business capabilities teams were building. The first reduces maintenance cost and cognitive load. The second kills the innovation the modernization was designed to enable. 

PRINCIPLE THREE: CONTINUOUS OBSERVABILITY

In a monolithic system, failure is visible in a specific way: one system is either running or it is not. In a distributed, event-driven landscape with dozens of independent services, failure is visible in a much more nuanced way — and much harder to diagnose without the right instruments.

The governance response was observability designed from the beginning as an architectural requirement, not an operational afterthought. Every service was instrumented to publish health and performance data. Every event flow was traceable from origin to destination. And critically, the observability data was connected to the business capability map — so that when a service showed degraded performance, the impact on the business processes it supported was immediately visible.

This is the difference between knowing that a service is slow and knowing that the vendor approval workflow is taking three times longer than normal, affecting fourteen purchase orders currently in the queue. The first is an IT alert. The second is a business concern. Governance that can translate between the two is governance that the business will trust and use.

PRINCIPLE FOUR: LIFECYCLE MANAGEMENT

Every system modernized today is a legacy system in waiting. The technical debt the Strangler Fig Pattern was designed to eliminate will re-accumulate unless the organization maintains the discipline to decommission what it has replaced.

The governance response was to treat lifecycle management as an architectural commitment, not an operational decision. At the point of design, every capability migrated from the legacy system was given a corresponding decommission plan: when the migration was stable, what legacy code would be eliminated, and who was accountable for executing that elimination.

This sounds straightforward. In practice, it is the discipline most often deferred — because decommissioning old code does not add new features, does not satisfy business stakeholders in the short term, and carries risk without immediate reward. The governance requirement to execute lifecycle plans was not popular. It was necessary. The alternative is an architecture that is simultaneously modern and legacy — carrying the cost of both without the full benefit of either. 

MINDSET, CONTEXT, AND PEOPLE

The four governance principles above describe structure. What they cannot fully describe is the human condition that determines whether that structure works.

In every enterprise modernization I have been part of, the tools were eventually adequate. The patterns were generally sound. The governance frameworks were designed with care. What varied — and what ultimately determined the difference between programs that delivered value and programs that delivered artifacts — was the quality of the thinking behind the decisions, and the quality of the relationships within which those decisions were made. 

Three things consistently separated the programs that worked.

The first was target before tool.

The technology platforms available for enterprise modernization are genuinely powerful. They are also genuinely capable of consuming years of investment while producing systems that are technically impressive and strategically irrelevant. Every tool decision in the programs that delivered value was preceded by a clear answer to the question: what specific business concern does this resolve, and how will we know when it has been resolved? When that question did not have a clear answer, the tool decision was deferred until it did.

The second was contextual judgment over methodological compliance.

The Fit-for-Purpose concept is not a prescription for how architecture should always be done. It is a discipline for determining how it should be done in a specific context, for a specific purpose. Some engagements require speed above all else. Others require compliance and auditability. Others require the kind of careful incremental migration described in this series. The patterns we used here were right for this context. The governance principles described above were calibrated to this landscape. Neither should be applied wholesale to a different program without the diagnostic work of understanding what that program actually needs.

The third — and the most important — was the treatment of stakeholders as co-creators rather than recipients.

The target architecture developed in this modernization was not produced by the EA team and delivered to the business. It was developed with the business — through structured conversations about what was currently blocked, what the business needed to be able to do, and what it was willing to accept in terms of transition risk and operational change. The procurement managers who processed approvals every day understood the workflow in ways no architect could replicate from documentation. The vendor relationship managers understood the external integration requirements in ways no system map could fully capture.

Architecture that is technically correct but organizationally disconnected will be tolerated at best and bypassed at worst. The most expensive architectural decision is often the one that was made without the people who would have to live with it.

Stakeholders are not the audience for the architecture. They are its co-authors.