Summary: EA governance is the mechanism that turns a target architecture into a lived one. It rests on four building blocks: architecture principles (what we hold to), an architecture board (who decides), review gates (when decisions are checked) and an exception process (how justified deviations are permitted and time-boxed). Without them, enterprise architecture stays documentation; with them it becomes steering capability. This article shows how we set up EA governance in Portamus client projects — lean enough that the organisation accepts it.
Key takeaways
- EA governance answers four questions: who decides, against which principles, when is it reviewed, how are exceptions handled?
- 10–15 principles are enough. Each needs a statement, a rationale and implications — otherwise it is wall decoration.
- An architecture board only works with real decision rights, a small membership and a fixed cadence.
- Risk-based review depth is the single biggest lever against the perception that governance slows things down.
- The exception process is not an admission of defeat; it is the precondition for rules being followed at all.
- Measure effect (lead time, reuse, technical debt), not effort (documents produced).
What is EA governance?
EA governance is the set of roles, decision rights, principles and processes an organisation uses to ensure that changes to its architecture fit the target state. It is the difference between an architecture that exists on slides and one that actually shapes project decisions.
The reference frame is TOGAF: the Preliminary Phase establishes the governance framework, and Phase G (Implementation Governance) ensures delivery follows the agreed architecture. Governance is therefore not a discipline alongside architecture work but its transmission mechanism — and a core part of enterprise architecture management.
EA governance vs. IT governance
| IT governance (e.g. COBIT 2019) | EA governance | |
|---|---|---|
| Object of control | The IT organisation as a whole | Substantive consistency of the architecture |
| Core questions | Investment, risk, resources, compliance | Does this solution fit the target state? |
| Typical bodies | IT steering committee, investment board | Architecture board, design authority |
| Output | Budget and risk decisions | Approvals, conditions, time-boxed exceptions |
In practice EA governance is embedded in IT governance: the architecture board provides the substantive assessment, the investment board decides the money. Where that coupling is missing, architecture is routinely overruled.
Building block 1: architecture principles
Principles are the cheapest governance instrument available — they decide hundreds of individual cases in advance. TOGAF defines four components of a good principle:
| Component | Purpose |
|---|---|
| Name | Short, memorable, quotable |
| Statement | What applies — unambiguously worded |
| Rationale | Why it applies (link to a business goal) |
| Implications | What follows from it — including the uncomfortable parts |
Examples from our engagements (abridged):
- “Buy before build.” Standard software over custom development where it covers ≥ 80 % of the requirement. Implication: in case of doubt, processes adapt to the software, not the other way round.
- “One system of record per data object.” Every business object has exactly one leading system. Implication: secondary copies are read-only, synchronisation is one-way.
- “Integration through the platform.” No point-to-point interfaces between core systems. Implication: projects budget integration effort via the integration architecture.
Rule of thumb: if a principle never leads to an uncomfortable consequence, it is not a principle — it is a statement of intent.
Ten to fifteen principles is the practical ceiling. The limiting factor is not drafting effort but the organisation’s ability to remember them.
Building block 2: the architecture board
The architecture board ratifies principles, approves target states, decides on deviations and prioritises technical debt.
What works in practice:
- Five to seven voting members — lead architecture, IT operations, information security, one business representative, application development. Larger groups discuss rather than decide.
- A fixed cadence, typically every two weeks, with submissions closing 48 hours in advance.
- Real decision rights — documented in a RACI and countersigned by IT leadership. A board whose decisions can be bypassed only costs time.
- Written decisions as architecture decision records: context, decision, consequences, date. They later become the most valuable answer to “why did we do it this way?”.
What does not work: a board without preparation, without quorum, with rotating membership — or one that redesigns solutions in detail instead of deciding.
Building block 3: review gates
Governance needs defined checkpoints along the delivery path. Three have proven themselves:
| Gate | Timing | Question asked |
|---|---|---|
| G1 – architecture assessment | Before budget approval | Does the initiative fit the target state? Do reusable services exist? |
| G2 – solution approval | After high-level design | Does the design satisfy the principles? Which conditions apply? |
| G3 – delivery check | Before go-live | Was what was approved actually built? Which deviations emerged? |
The decisive element is risk-based review depth. We use a short classification (architectural impact high / medium / low) based on a few criteria: new system, new interface to a core system, personal data, cloud relocation, deviation from a principle. Only “high” passes all three gates; “medium” is reviewed in writing; “low” runs on self-assessment. In our projects this typically puts 15 to 25 % of initiatives into full review — and that concentration is what makes governance tolerable.
Building block 4: the exception process
Every architecture rule is eventually broken for good reason — an acquisition, a regulatory deadline, a legacy constraint. The relevant question is not whether but how visibly.
A workable exception process has four features:
- A request path with a rationale and a named accountable person.
- A time limit — every exception expires, typically after 6 to 18 months.
- A remediation plan, or explicit acceptance into the technical debt backlog.
- Visibility — an exception register reviewed regularly in the board.
Without this process you get silent deviations: never requested, never documented, and resurfacing years later in an IT landscape analysis as an expensive surprise.
Measuring effectiveness
Governance that cannot be measured is cut at the first cost pressure. Useful metrics:
- Lead time of an architecture decision (target: ≤ 10 working days).
- Coverage: share of high-impact initiatives actually reviewed.
- Open and expired exceptions — a growing stock of expired exceptions is the earliest warning signal.
- Reuse rate of existing services instead of new builds.
- Technical debt trend, ideally coupled to application portfolio management.
Do not measure documents produced or meetings held: that is effort, not effect.
Common mistakes
- Governance before a target state. Without an agreed target architecture the board reviews against taste rather than substance.
- Too many principles. Forty principles are effectively none.
- A board without a mandate. Recommendations without decision rights are ignored in day-to-day delivery.
- Uniform review depth for everything. Creates queues, and queues create workarounds.
- Allowing no exceptions. Produces not more compliance but invisible non-compliance.
- Governance without architects. A body can make decisions; it cannot produce an architecture.
Frequently asked questions about EA governance
What is EA governance? The set of roles, decision rights, principles and processes ensuring that changes to business and IT architecture stay aligned with the target architecture.
What does an architecture board do? It ratifies principles and target states, decides on deviations, approves initiatives at review gates and prioritises technical debt — effective when small, regular and genuinely empowered.
What are architecture principles? Binding, justified guidelines for architecture decisions. TOGAF defines them as name, statement, rationale and implications; ten to fifteen are enough.
How is EA governance different from IT governance? IT governance (COBIT) steers the IT organisation as a whole; EA governance steers the substantive consistency of the architecture and sits embedded within it.
At what size does an architecture board make sense? From roughly 150–200 people in the IT-facing organisation, or five to seven parallel initiatives. Below that, a named lead architect with decision rights suffices.
How do you keep EA governance from becoming a bottleneck? Risk-based review depth, committed response times and a clean exception process.
What role does TOGAF play? It establishes governance in the Preliminary Phase and enforces it in Phase G (Implementation Governance); architecture contracts and compliance reviews underpin review gates.
How do you measure whether EA governance works? Decision lead time, review coverage of high-impact initiatives, open and expired exceptions, reuse rate and technical debt trend.
Conclusion
EA governance is not a control apparatus but a decision system. Four building blocks are enough: a few robust principles, a small body with a real mandate, risk-based review gates and a transparent exception process. Our consistent experience from Portamus projects: resistance to governance is almost never aimed at the rules themselves but at waiting time and arbitrariness. Deliver fast, explainable, documented decisions and you earn acceptance — and with it an architecture that actually steers.
Want to set up EA governance, or make an existing architecture board effective? We shape principles, bodies and review processes into a form your organisation can carry. → Explore Portamus EA programme development
Sources
- The Open Group: TOGAF Standard, 10th Edition — Architecture Governance, Phase G (2022)
- ISACA: COBIT 2019 Framework: Governance and Management Objectives (2018)
- ISO/IEC/IEEE 42010:2022 — Software, systems and enterprise — Architecture description