Enterprise Architecture has a credibility problem. It is a discipline that commands significant investment in large organisations — EA teams, architecture review processes, framework licences, modelling tools — and produces, in many cases, outputs whose relationship to the actual technology decisions being made in delivery teams is tenuous at best. The architecture principles sit in a SharePoint site that nobody visits. The Architecture Review Board meets monthly to review decisions that have already been made. The roadmaps describe a target state that bears little resemblance to the direction the organisation is actually travelling. And when a major programme goes wrong — as they periodically do — the EA function was not involved early enough to prevent the problems that made it go wrong.
This is not a universal condition. There are EA programmes that work — that demonstrably influence the technology decisions of the organisation, prevent the expensive mistakes that EA governance is designed to prevent, and deliver the coherence of architecture that enables rather than constrains delivery. This article describes what those programmes have in common. It is written from the position of having established Enterprise Architecture governance at a BaFin-regulated bank from first principles — developing 183 architecture principles and 102 guidelines, elaborating on 21 overarching Enterprise Architecture principles, across seven architectural domains, building the review and approval processes through which those principles are applied, and aligning the entire framework with the concurrent obligations of DORA, BaFin supervisory requirements and the EU AI Act. The patterns that made that work — and the failure modes that had to be navigated along the way — are what this article addresses.
Why Most EA Governance Fails
The failure modes of EA governance are consistent across organisations and sectors. Understanding them is the starting point for designing something that works.
Architecture Principles That Actually Work
The distinction between an architecture principle that influences decisions and one that does not is almost entirely a matter of specificity. The test of a useful architecture principle is simple: could a delivery team make a significant architectural decision that violates it? If not — if the principle is worded so broadly that it cannot conceivably be violated — it is not a principle, it is a platitude.
Writing architecture principles with this level of specificity requires making choices — between technology options, between architectural patterns, between approaches that each have genuine advocates within the organisation. This is why most architecture principles are written as platitudes: genuine choices generate disagreement, and the path of least resistance is to write principles that everyone can support because they don't actually say anything. The EA function that is unwilling to take positions will produce principles that provide no guidance.
The Domain-Based Approach: From 21 Principles to 183
A common architecture principle set contains ten to twenty high-level statements that are intended to apply across all architectural decisions. The limitation of this approach is that the generality required to make principles apply everywhere means they inevitably end up vague enough to mean very little anywhere specific.
The approach taken at Aareal Bank was to organise principles by architectural domain, with each domain having its own principle set tailored to the specific decisions that arise within it. The result — 183 architecture principles and 102 guidelines across seven domains — sounds large but is, in practice, more usable than a small set of high-level statements, because the principles in each domain are specific enough to provide genuine guidance for the decisions that domain's architects and delivery teams actually face.
The domain-based structure has a further advantage: it makes the principle set maintainable. When a technology changes — when a new cloud service is adopted, when a regulatory requirement is updated — the affected domain's principles can be revised without touching the rest. A monolithic set of ten high-level principles is much harder to maintain with precision because any change has implications for every decision the principles are supposed to govern.
"183 domain-specific principles sounds like a lot. In practice, an architect working in the integration domain uses 25 of them. An architect making an AI deployment decision uses 18. Nobody needs to internalise all 183 at once — they need to know which domain they are working in and where to find the relevant guidance."
The Architecture Review Process: Fast, Focused and Helpful
The Architecture Review Board is the enforcement mechanism for architecture governance. How it is designed determines whether EA governance is a value-adding programme or a bureaucratic obstacle.
TOGAF: Toolkit, Not Straitjacket
TOGAF is the most widely adopted EA framework and, for that reason, worth addressing directly. It contains genuinely useful concepts — the Architecture Development Method, the content metamodel, the capability framework — and genuinely useful artefacts for structured thinking about architecture. It also, applied comprehensively, has the capacity to consume an architecture function's entire energy in producing artefacts that satisfy the framework's documentation requirements while failing to influence a single delivery decision.
The appropriate relationship with TOGAF — or any other EA framework — is to use it as a toolkit: to take the concepts and artefacts that are genuinely useful for the specific challenges the organisation faces, and to ignore the rest. An EA function that produces a comprehensive TOGAF-compliant architecture repository while delivery teams make decisions without reference to it has prioritised framework compliance over architectural influence. The two goals are not the same, and when they conflict, the practical goal of influencing real decisions should always win.
At Aareal Bank, the TOGAF framework informed the structure of the architecture governance programme — the domain organisation, the review process design, the principle format — without being applied comprehensively. The artefacts that were produced were those that genuinely supported decision-making. The artefacts that TOGAF prescribes but that would not have been used were not produced. This pragmatic approach is, in my experience, the right one for any regulated financial institution where the EA function's mandate is to support the organisation's technology strategy rather than to demonstrate framework adherence.
EA Governance in a Regulated Environment
In a BaFin-supervised institution, EA governance has a regulatory dimension that does not exist in unregulated industries. Architecture decisions — the choice of cloud platform, the data architecture, the integration patterns, the security controls — are subject to BaFin supervisory expectations expressed through BAIT, DORA and the broader regulatory framework. The EA governance process must be designed to ensure that these regulatory requirements are built into architecture decisions, not checked against them retrospectively.
The practical mechanism is to incorporate regulatory alignment explicitly into the principle set and the review process. In the Security & Compliance domain, for example, each principle is mapped to the regulatory requirement it addresses — whether BAIT Section 8, DORA Article 9, or GDPR Article 25. When a delivery team seeks architecture approval, the reviewer can confirm not only that the proposed solution meets the architectural standard but that it satisfies the regulatory requirement the standard is designed to implement. This makes the EA governance process a regulatory compliance mechanism as well as an architectural one — and is a significant practical argument for adequate investment in EA governance that can be made to senior leadership and the board.
The EU AI Act adds a further dimension. As financial institutions deploy AI systems, the architecture governance process becomes the mechanism through which AI Act compliance is built into AI deployments at the design stage rather than retrofitted. The AI & Emerging Technology domain principles — covering classification, explainability, human oversight, data lineage — are not separate from EA governance. They are EA governance, applied to a new class of technology that carries specific regulatory obligations.
Long before the formal title of Enterprise Architect existed in my career, I held a role in a large-scale software development programme at British Car Auctions that was described, informally, as "Keeper of the Vision." The responsibility was to maintain the coherence of the overall system architecture across a team of 17 developers working at pace in a RAD environment — to ensure that the individual decisions each developer was making in their workstream were consistent with the overall design, and to catch the divergences before they became integration problems. That role contained, in miniature, every element of effective EA governance: a clear architecture that was genuinely shared rather than held in one person's head; presence in the delivery context rather than governance from a distance; authority that was respected because it was exercised with judgment rather than bureaucracy; and the willingness to have direct, sometimes uncomfortable conversations with developers who were about to make a decision that would create problems downstream. The tools have changed. The role has not.
Measuring EA Governance Effectiveness
An EA governance programme that cannot demonstrate its value will not sustain senior leadership support through budget cycles and organisational changes. The metrics that matter are those that connect EA governance activity to outcomes that the organisation cares about — not the volume of principles produced or reviews conducted.
The most credible EA governance metrics are: architectural debt reduction — the number of documented deviations from approved patterns that have been remediated, expressed in terms of the risk and cost those deviations represented; decisions influenced — the number of significant architectural decisions that the governance process materially affected, with at least some cases where the original proposal was changed as a result of review; issues caught early — integration failures, security gaps, regulatory compliance problems that were identified at architecture review stage rather than at testing or in production; and delivery efficiency — the reduction in re-work attributable to teams following approved patterns rather than making inconsistent choices that create integration problems downstream.
None of these metrics is simple to collect. All of them require the architecture function to maintain visibility of delivery outcomes as well as architecture governance activities — which is itself an argument for the embedded architect model rather than the remote review model.
Questions for Architecture Leaders
- Could a delivery team make a significant architectural decision that violates your architecture principles — and if so, do they know it, and do they know what to do about it?
- Are your architecture principles organised by domain, with sufficient specificity in each domain to provide genuine guidance for the decisions that domain faces?
- Does your Architecture Review process operate at a cadence that delivery teams can work with — and is it positioned as early advisory engagement as well as formal review?
- Does the ARB have the authority to say no, and is that authority backed by senior leadership sponsorship that programme governance reflects?
- Is your exception management process well-calibrated — possible but requiring genuine justification, time-bounded, and systematically tracked?
- Are your architecture principles explicitly mapped to the regulatory requirements they implement — BAIT, DORA, EU AI Act — so that architecture review simultaneously confirms regulatory compliance?
- Are your architects embedded in delivery programmes, or are they reviewing from a distance? Is the distinction between those two operating models reflected in how your delivery programmes are governed?
- Can you demonstrate, in terms that senior leadership and the board find meaningful, the value that EA governance has delivered in the last twelve months?
Conclusion: The Purpose Is Influence, Not Compliance
The test of an EA governance programme is not whether it has produced a comprehensive architecture repository, a TOGAF-compliant content metamodel, or a principle set that covers every conceivable architectural decision. The test is whether it has influenced the technology decisions of the organisation — whether the architecture that is actually being built reflects the principles and standards that the programme exists to promote, and whether the problems that EA governance is designed to prevent are being prevented rather than accumulating as technical and regulatory debt.
That influence comes from principles with sufficient specificity to make real choices; from a review process that is fast, authoritative and genuinely helpful; from architects who are present in the delivery context rather than producing guidance from a distance; and from a mandate that is visibly supported by senior leadership and expressed in the governance arrangements of the programmes it is supposed to influence. These are not complicated requirements. They are, however, consistently underinvested in — because producing documentation is easier than building influence, and demonstrating framework compliance is more straightforward than demonstrating that decisions are better as a result of the governance process.
The EA function that builds genuine influence — that delivery teams engage because doing so produces better outcomes, not because governance requires them to — is the one worth having. Everything else, regardless of how comprehensive its documentation or how TOGAF-compliant its process, is an expensive distraction from that goal.