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).
- Setup, not re-design: the four building blocks are live in 8 to 12 weeks in our projects — the phased approach below gives the sequence with effort and duration.
- DACH context: German mid-sized companies typically ship a lightweight governance — lead architect with decision rights, a monthly forum, five to eight principles — because a formal board pays off only beyond roughly 150–200 people.
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.
Setting up EA governance: the four-phase approach with effort and duration
The four building blocks above are the what. This is the sequence we run in Portamus client projects, typical for a mid-sized organisation (100–1,000 employees) that has a target state or is in the process of defining one:
| Phase | Activity and output | Effort | Duration |
|---|---|---|---|
| 1. Frame and principles | 5–8 architecture principles (statement, rationale, implications), ratified by the management board | 1–2 workshops | Weeks 1–3 |
| 2. Roles and mandate | Decide board or lightweight forum (see building block 2); RACI, decision rights, cadence, written counter-signature by IT management | 1 workshop + 1 week of documentation | Weeks 2–4 |
| 3. Gates and depth | Integrate review gates G1–G3 into the existing project process; impact classification; response-time commitment (≤ 10 working days) | 1 workshop | Weeks 4–8 |
| 4. Exception process and first cycle | Exception register with time limits and remediation plans; run the first three board cycles; calibrate depth and response times from actual lead times | 2–3 weeks of living operation | Weeks 6–12 |
Total: working governance with its first written decisions in 8–12 weeks. After that, the steady-state cost is a biweekly 90-minute session plus a few hours of decision preparation — and the board’s credibility comes from the response-time commitment more than from any process document. Organisations without a target state run an additional 2–3 weeks in advance: the first step of a lean EA start (see 90-day EA start) delivers the frame.
Setting up EA governance in Germany and the DACH region
Three structural features of the German mid-sized enterprise shape what a governance that actually gets used looks like:
- The decision path has to cross the management board (Geschäftsführung). German mid-sized companies decide faster than large enterprises, but the architecture must reach the same place where investment decisions reach. If the architecture forum or board is one step removed — below the management board — its decisions will be routinely bypassed in project reality. That is why the RACI and decision rights in Phase 2 are not formality but the core of the setup.
- ISO-driven documentation expectations. German companies are frequently audited (ISO/IEC 27001, and for listed or publicly tendering companies SOX-related controls). Architecture decision records and the exception register are exactly the documentation such audits ask for — a second, free reason to write decisions down. This shortens the setup: an EA governance that already records decisions systematically is cheaper for the audit than one built up retroactively.
- Lightweight beats formal below the size threshold. Up to about 150–200 people in the IT-facing organisation a formal architecture board is usually overkill. What works in Germany at this size: a named lead architect with decision rights, a monthly architecture forum, five to eight principles and a documented decision path (Phase 4 in the table above). The first real board comes only when there is a portfolio of 5–7 parallel initiatives.
What this means for DACH companies that plan EA governance with English-language sources: the principles transfer (TOGAF, gate concepts, exception registers are universal), but the institution usually doesn’t — the forum-first, board-later path is the DACH answer to “setting up an architecture board”.
Choosing an EA governance partner in Germany
Setting up governance is a change project as much as a method project. These are the criteria that separate a governance the organisation accepts from one that dies in the second quarter:
| Criterion | What to check | Why it matters |
|---|---|---|
| Mid-sized company references | EA governance setups at 100–1,000 employees, ideally in Germany or the DACH region | The right size is the difference between a forum and a bureaucracy |
| Principles, not process templates | Whether the partner can draft your 5–8 principles from your context — not install a process catalogue | Governance without organisation-specific principles is wall decoration |
| Embedded gates | Whether review gates fit into your existing project process — not a parallel review track | A second process is a bottleneck; an embedded gate is invisible |
| Response-time commitment | Whether the partner commits to a decision lead time (e.g. ≤ 10 working days) and measures it | The perceived speed decides acceptance more than the depth of process |
| Exception experience | Whether time limits and remediation plans for exceptions are standardised, not ad hoc | Silent deviations are the most common governance failure |
| Sponsor work | Whether the partner prepares the management board for the mandate and decision rights | A board without a signed management-board mandate loses in project reality |
Red flag: a partner who presents EA governance purely as an add-on to their EA tool — governance exists before and without the tool; that’s how it fails.
A typical setup engagement runs 8–12 weeks (the four phases above), the steady-state operation is the forum cadence, and the first measurable effect — a procurement request refused with reference to the target state — usually lands in month 3–4. Portamus operates from Oberhausen (North Rhine-Westphalia) and sets up EA governance for companies across Germany and the DACH region — as part of its EA programme development and enterprise architecture consulting.
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.
How long does it take to set up EA governance? In our projects: 8–12 weeks for a mid-sized organisation in four phases — frame and 5–8 principles, roles and mandate, embedded review gates with response-time commitment, and the exception process with first board cycles. Without a target state, add 2–3 weeks of lean EA start. Steady state: biweekly forum, a few hours of decision preparation.
Who can set up EA governance in Germany or the DACH region? Check mid-sized company references (100–1,000 employees), whether the partner drafts your principles rather than installing a template, whether the gates fit into your existing project process, and whether response times are committed and measured. Portamus sets up EA governance in Germany, for example as part of EA programme development in Germany.
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