EA governance
- 8–12 weeks typical duration of the build
- right-sized to the organisation's size and risk
Architecture governance has a bad reputation because in many organisations it works as a paper mill: templates, sign-offs, waiting. Meanwhile the real cost is generated by its absence: ad hoc decisions, solutions reinvented on every project, and wrong directions that no one turns down in time.
We build governance that works: only as many rules as the size and risk of the organisation justify. The direction comes from the approved target architecture, the principles, and the lifecycle-managed standards, but the essence is the embedding: the architecture gates attach to the demand and delivery processes already in place and measure change against that direction, the decision rights are tiered, and a deviation can be approved, but always with a deadline. Every significant decision goes into the decision log with its rationale, and the metrics also show whether the changes delivered the expected benefit. After the build we can also take over the operation: that is what EA as a service is for.
Governance as a steering loop
Governance is not gatekeeping: it sets a direction, measures change against it, then checks the outcome and adjusts the direction itself with what it learns.
When do you need us?
Every project builds something different
Architecture decisions are made ad hoc: a different technology, pattern and integration on every project. The result is a diverging system landscape and growing operating costs.
No one says no in time
A wrong direction only surfaces after go-live. There is no gate where an expensive decision could still be reversed cheaply.
The policy lives on paper
An architecture policy exists, but in practice no one follows it. Projects bypass it because it would slow them down rather than help.
Our process
Right-sizing
We assess where architecture decisions are made today, how much risk they carry, and where they connect to demand management and the implementations. We propose only as many rules as the size and risk of the organisation justify.
Principles and standards
Together with the leadership we formulate a small set of principles that can be enforced, each with a statement, a rationale, and implications. The technology standards get a register and a lifecycle: trial, active, phase-out, banned.
Building into the decision flow
We attach the architecture gates to the demand and delivery processes already in place: the yardstick is the approved target architecture, the principles, and the standards. We tier the decision rights: teams decide for themselves in line with the principles, high-risk decisions spanning several areas go to the review board, and the architects get a seat at the enterprise forums. A deviation can be approved, but always with a deadline.
Metrics and embedding
We introduce a decision log: every significant decision and deviation gets recorded with its rationale. The metrics measure value alongside control: did the changes deliver the expected benefit. In the first months we run the forums together with you, until the decision process sticks in daily work.
Let's see what this would give you.
Book a free 30-minute consultationWhat you get
- Assessment of where architecture decisions are made today, how much risk they carry, and where the architecture view never arrives
- A small set of enforceable architecture principles, each with a statement, a rationale, and implications
- A technology standards register with a lifecycle: trial, active, phase-out, banned
- Architecture gates built into the demand and delivery processes, measuring change against the approved target architecture, roadmap, and standards
- Time-boxed dispensations: an approved exception gets a deadline, not a permanent waiver
- Tiered decision rights and working forums: a review board, an architects' forum, and a seat at the enterprise decision forums
- A decision log: every significant architecture decision and deviation recorded with its rationale, retrievably
- Architecture metrics for control and value: they show whether the framework is working, and whether the changes delivered the expected benefit
What it gives you
- Prevention of expensive mistakes: a wrong direction is corrected while it is still on paper, not after go-live
- Faster projects, because teams know in advance what to align with
- Real guidance for daily decisions: teams decide for themselves, guided by the principles and standards
- Exceptions kept under control: every dispensation has a deadline and an owner
- A decision process embedded jointly in the first months, sticking in daily work
What it looks like in practice
Principles that decisions can be measured against
The challenge
The bank had to satisfy the standards of its international group and its own business environment at the same time. Architecture decisions lacked a single, enforceable benchmark: group-level principles could not simply be transplanted into local operations.
What we did
We developed a complete principle catalogue: common, business, data, application, infrastructure, and security principles. Each comes with a rationale, an example to follow and one to avoid, and its implications for decisions; the principles were aligned with group guidelines but tailored to local operations, with a forum procedure for handling deviations.
What came out of it
- A complete principle catalogue in six categories, aligned with group standards
- A rationale, examples, and explicit implications for every principle
- Local adaptation: what carries over from the group, and what reflects the local context
- A defined procedure for deciding deviations and questions of interpretation
Frequently asked questions
Will this not slow our projects down?
Right-sized governance actually speeds things up: projects know in advance what to align with, and a wrong direction gets corrected while it is still on paper, not after go-live. What people experience as slowdown is oversized governance. Right-sizing and tiered decision rights are how we avoid it.
We have a policy, but no one follows it. What can you do with that?
This is the most common starting point. First we look at why it gets bypassed: typically it is too long, too generic, or not tied to real decisions. We keep what works, drop the rest, or tie it to decision rights and metrics.
Does every decision have to go to the board?
No. We tier the decision rights: the review board deals with high-risk decisions that span several areas, while teams make the rest themselves, guided by the principles and standards. This keeps the board a decision-making body, not a bottleneck.
What happens when a project cannot comply with a standard?
A deviation can be approved, but always with a time limit: the exception gets a deadline and an owner, and at expiry the project returns to the standard, or the standard gets reviewed. When exception requests keep arriving against the same standard, that is not the projects' fault: the standard needs revisiting.
What exactly do you measure?
Both control and value indicators. On the control side: the compliance rate at the gates, the number and age of active dispensations (expired ones tracked separately), the number of systems running on phase-out or banned technology, and the board's decision lead time, which also shows whether the governance speeds things up or slows them down. On the value side: whether the changes delivered the benefit expected at the decision.
How is this different from business architecture governance?
EA governance spans the whole enterprise architecture: alongside the business layer, the application, data, and technology architecture, and in some cases security, too. Business architecture governance zooms into the business layer of this. Where both are being built, we fit them together: shared gates, aligned forums.
Who runs the governance after it is set up?
By default your own organisation, which is why embedding is part of the work: in the first months we run the forums together with you. If internal capacity is missing, we can also take over the operation on a lasting basis within our EA as a service offering.
How we can work together
Fix Scope
Scope and fee are agreed together at the start. For well-defined work this is the most predictable form; the business capability map, for example, typically runs this way.
Time & Material
Effort-based billing with a flexible scope. It works best when the task takes shape along the way and quick changes of direction matter.
Architect as a Service
An ongoing arrangement: architect capacity without hiring a full-time specialist. It can be fixed-price and predictable, or ad-hoc involvement; it scales up or down as needs change.
Book a free 30-minute consultation
Tell us briefly about your situation. We'll get back to you and start with a free, no-obligation 30-minute consultation.
Thank you for your message! We will get back to you shortly.
Something went wrong. Please try again or write to [email protected].
