Enterprise Architecture maturity models have been around for decades. Most organisations with a functioning EA practice can tell you roughly where they sit on a five-level scale. What fewer can explain is why so many practices seem to reach level 2 — producing artefacts, maintaining an architecture repository, running occasional review boards — and then stop progressing.
In our experience working with EA practices across sectors, the stall at level 2 is not random. It happens for specific, consistent reasons — and once you understand them, breaking through becomes achievable.
What Level 2 Looks Like
A level 2 EA practice typically has most of the following characteristics:
- A small team of architects (often 2-5 people) producing documentation
- An architecture repository that is partially populated and inconsistently maintained
- An Architecture Review Board that meets periodically but whose outputs are advisory rather than binding
- A collection of standards documents that projects are aware of but not systematically following
- Relationships with senior technology leadership, but limited traction with business stakeholders
The practice is functional. Architecture is happening. But it is not yet genuinely influencing outcomes — and the team knows it.
The Three Blockers
The stall at level 2 is almost always caused by one or more of three blockers.
Blocker 1: Architecture Without Mandate
The most common blocker is simply that the EA function does not have sufficient organisational authority to make its outputs stick. Review board recommendations are ignored. Standards are bypassed. Projects proceed with architectures that the EA team flagged as problematic, because the project sponsor had more organisational weight than the Chief Architect.
This is a governance problem, not an architecture problem — and it cannot be solved by producing better architecture documents. It requires an explicit decision at CIO or CTO level about the authority of the EA function: are architecture decisions binding, or are they advisory? If advisory, what happens when the advice is ignored?
Breaking through requires a governance conversation, not more architecture work. Often the trigger is a visible failure — a project that went wrong in exactly the way the EA team predicted — that creates the organisational will to strengthen the mandate.
Blocker 2: Architecture Disconnected from Delivery
The second blocker is the gap between architecture outputs and delivery reality. The EA team produces target-state architectures and roadmaps, but the delivery teams building things are working to different constraints, timescales, and incentives. Architecture becomes something that happens before and after delivery — not during it.
The result is architecture drift: the as-built state diverges progressively from the designed state, the repository becomes inaccurate, and the EA team spends increasing time trying to understand what was actually built rather than designing what should be built next.
Breaking through requires embedding architects in delivery. Not as reviewers at the end of a project, but as active participants — shaping technical decisions as they are made, not documenting them after the fact. This requires a change in operating model for the EA function, and often requires negotiation with delivery managers who are not accustomed to architectural involvement.
Blocker 3: Architecture Without Business Relevance
The third blocker is perhaps the most subtle, and the most damaging. The EA team is excellent at producing technically rigorous architecture — capability maps, domain models, integration diagrams — but cannot articulate why any of it matters to the business problems that the organisation is actually trying to solve.
Business stakeholders disengage. Technology leaders value the team but cannot justify expanding its influence. The practice becomes technically competent but organisationally isolated.
Breaking through requires a genuine shift in how the EA team approaches its work — starting from business problems rather than technology frameworks. Every architecture artefact should answer the question: what business decision does this enable, and what would be worse without it?
How to Break Through
Most practices stall because of a combination of all three blockers, not just one. The breakthrough rarely comes from a single initiative. It comes from a sustained effort on three fronts:
- Secure the mandate. Work with CIO/CTO leadership to establish a clear governance model — which decisions require architecture review, what happens when recommendations are not followed, and how exceptions are managed. This does not need to be prescriptive or bureaucratic; it needs to be clear and consistently enforced.
- Embed in delivery. Assign architects to the highest-priority delivery programmes — not as reviewers, but as participants. Demonstrate that architectural involvement improves outcomes, then use those outcomes as evidence to expand the model.
- Connect to business outcomes. Reframe every architecture initiative in terms of the business capability it enables or the risk it reduces. Stop presenting architecture diagrams to business stakeholders; present outcomes, options, and recommendations in language they can evaluate.
The practices that break through level 2 are not necessarily the ones with the most technically capable architects. They are the ones that have solved the organisational problem as well as the technical one — and that requires leadership as much as architecture expertise.