Ask an enterprise architecture team how mature it is, and you will usually get a number. Ask which model produced the number, and the conversation gets more interesting.
EA maturity models look alike from a distance. Most have five or so levels with names like "Initial" and "Managed". Most come with a questionnaire. Underneath, they disagree on four basic points: what is being measured, how a score is reached, what evidence the model rests on and what the result is for.
This article compares seven models on those four points: the IASA BTABoK model, Svyatoslav Kotusev's stages of EA practice, a modern TOGAF architecture maturity model, the US GAO's EA Management Maturity Framework, the US OMB's EA Assessment Framework, the MIT CISR stages of architecture maturity, and the model behind Useful EA's own assessment. The goal is not to crown a winner. It is to help you pick the model whose question matches yours.
The seven models at a glance
| Model | What it measures | How it scores | Best used for |
|---|---|---|---|
| Useful EA classic | The breadth of an EA practice across 12 domains, including modern ones such as cloud, data, security and AI | Levels 1–5 per domain, weighted average | Finding gaps and building a 90-day improvement plan |
| IASA BTABoK | An architecture practice as a team: competencies, engagement model, outcomes | Levels 0–5 across seven areas | Growing a practice within the BTABoK way of working |
| Kotusev | Which EA processes an organization actually runs | Stages 0–3, by which processes are present | Understanding where a practice stands and what usually comes next |
| TOGAF (Lambert) | How established architecture is across ten organizational domains | Levels 1–5 per domain | Organizations that frame their practice around TOGAF |
| GAO EAMMF 2.0 | How well an EA program is managed | Stages 0–6; a stage counts when its core elements are met | Audit and oversight of EA programs |
| OMB EAAF 3.1 | Whether an agency's EA is complete, used in investment decisions, and producing results | Levels 1–5 per KPI, averaged per area; no overall score | Accountability of US federal agencies |
| MIT CISR | The enterprise's own foundation for execution, not the EA team | Stages 1–4, taken in order | Setting the direction for business and IT architecture |
Distinction 1: what is being measured
The biggest difference is the thing under measurement. There are three quite different answers.
The architecture function. Most models measure the EA team or program: its processes, governance, people, artifacts and influence. The classic Useful EA model, the BTABoK model, the TOGAF model and GAO's EAMMF all sit here. They answer "how capable is our architecture practice?"
The practice as a set of processes. Kotusev's model is narrower and more concrete. It asks which EA processes the organization actually runs: architecting individual solutions, optimizing the technology landscape, and planning business and IT strategy together. It deliberately checks whether each element is present, not how good it is.
The enterprise itself. The MIT CISR model is different in kind. It measures the enterprise's architecture, not the architects: whether IT is a collection of local applications, a standardized technology base, a shared core of processes and data, or a set of reusable business modules. A small, skilled EA team can work inside an enterprise that is still at the first stage.
OMB's framework spans more than one of these. It measures the completeness of the EA and its use, but also results: mission performance and cost savings that the EA should have helped produce.
If your question is "is our EA team doing its job well?", you want a model from the first group. If it is "what kind of enterprise are we building?", CISR is the closer fit.
Distinction 2: levels or stages
Models reach a score in one of two ways, and the difference changes what the score means.
Levels rate each area on a scale, usually five levels inspired by the Capability Maturity Model, and then average. The classic, BTABoK, TOGAF and OMB models work this way. Levels give a detailed profile: strong in governance, weak in data, middling in strategy. Their weakness is that an average can hide shape. A practice that is excellent at project architecture and absent at strategy can average out at "Defined".
Stages place an organization on a path that is taken in order. Kotusev, GAO and CISR work this way. A stage is reached when its elements are in place, and the stages below it too. Stages say something an average cannot: what has to be true before the next step makes sense. Their weakness is coarseness. Two organizations at the same stage can be very different.
Stage models also differ in strictness. GAO has generally required every core element of a stage to be met. Kotusev expects real practices to mix elements from several stages and asks only whether most of a stage is present. CISR's authors argue that stages cannot be skipped at all.
Distinction 3: what the model rests on
Some models describe what has been observed; others describe what ought to be done.
Observed. Kotusev's stages come from interviews with architects in about a hundred companies, comparing how their practices looked before and after. The CISR stages come from MIT research into how companies build their foundation for execution. Both are descriptive: they report how organizations have tended to develop. Kotusev is explicit that his model is neither prescriptive nor predictive.
Prescribed. The GAO and OMB frameworks set out what government agencies are expected to do, tied to law and policy. The level-based models (classic, BTABoK, TOGAF) describe good practice as their authors see it. Kotusev is critical of maturity models that copy the five-level CMM pattern without empirical backing. That criticism is worth keeping in mind when reading any level-based score, including ours: it measures distance from a described good practice, not a proven path.
Distinction 4: what the result is for
Oversight. GAO's EAMMF and OMB's EAAF were built so that someone outside the program could hold it to account. GAO used the EAMMF to evaluate federal agencies' EA programs. OMB used the EAAF to rate agencies' architectures each year alongside their IT investment submissions. Both expect evidence: artifacts, documents, data.
Improvement. The classic, BTABoK and TOGAF models are meant to be used by the practice itself, to find its weak spots and plan what to fix. They work best as repeated self-assessments compared over time.
Orientation. Kotusev's and CISR's models are most useful for understanding where you are and what usually comes next. They are good conversation starters with executives, because the stages describe the business in plain terms rather than scoring the architects.
The models one by one
Useful EA classic model
12 domains, 48 capabilities, 144 questions. Levels 1–5, Initial to Optimizing.
Our own assessment is based on, and extended from, Sogeti's DYA (Dynamic Architecture) framework, described by Roel Wagter, Martin van den Berg, Joost Luijpers and Marlies van Steenbergen in Dynamic Enterprise Architecture: How to Make It Work (John Wiley & Sons, 2005). It keeps the core areas of EA practice (the practice itself, governance, strategic alignment, organizational capability, technology governance) and adds the domains that modern architecture work touches: cloud, integration, data and information, security, delivery and engineering, platforms and products, and AI and emerging technology. Each domain gets a level and a 30/60/90-day action plan. Use it for a broad health check and a concrete plan; read it with the caution from Distinction 3 in mind.
IASA BTABoK architecture maturity
Seven areas: Engagement, Ecosystem, Journey, Strategy, Agility, Capabilities, Business Model. Levels 0–5.
The Business Technology Architecture Body of Knowledge, from IASA Global, describes architecture as a profession that spans solution, software and enterprise work. Its maturity model judges an architecture practice through its team's competencies, its engagement model and its outcomes, and notes that the maturity of the wider company can cap the maturity of its architecture. The model is still a draft, and IASA does not yet publish assessment questions for it. It fits best where the BTABoK is already the practice's frame of reference.
Kotusev's stages of EA practice
Stages 0–3: No Architecture, Only Solution Architecture, Just IT Architecture, True Enterprise Architecture.
In "How Do Enterprise Architecture Practices Mature?" (2025), Svyatoslav Kotusev describes each stage as the arrival of one more EA process. Solution architecture comes first, with architects on projects producing solution options and designs. Technology optimization comes next, with standards, landscape documentation, review boards and funding for clean-up. Strategic planning comes last, with principles, target states and roadmaps agreed with senior business leaders. Each stage brings typical benefits and its own hard part: at the last stage, building trust with business leaders. The model is simple, empirical and honest about its limits: maturity varies by business unit, and a few organizations build their practice in a different order.
A modern TOGAF architecture maturity model
Ten domains. Levels 1–5: Initial, Under Development, Defined, Managed, Measured.
Daniel Lambert's model, published in Architecture & Governance Magazine in 2025, describes ten domains: architecture organizational structure, business strategy elaboration, business capabilities, senior management participation, business unit participation, architecture communication, security, initiative and project planning, solution delivery and execution, and governance and compliance. Each is described at each level in prose. Note that it is not The Open Group's own Architecture Capability Maturity Model, which is a separate, older model in the TOGAF library. It suits organizations that already organize their practice around TOGAF and want the levels described in those terms.
GAO EA Management Maturity Framework (EAMMF 2.0)
Seven stages (0–6), 59 core elements.
The US Government Accountability Office's framework (GAO-10-846G, 2010) grew out of audits of federal EA programs. Its stages run from creating EA awareness to continuously improving the EA for corporate optimization, and each stage holds core elements such as an approved EA policy, a governance committee, a documented methodology, or measured results. The elements are also grouped by management action (commitment, capability, demonstration, verification), functional area, OMB capability area and enabler. It is thorough and evidence-driven, and it is built for oversight. GAO itself later described it as a flexible frame of reference rather than the sole benchmark for an organization's journey.
OMB EA Assessment Framework (EAAF 3.1)
Three capability areas (Completion, Use, Results), 13 key performance indicators, levels 1–5.
The US Office of Management and Budget used the EAAF (version 3.1, June 2009) to rate federal agencies' architectures. Its KPIs are specific and often quantitative: the share of IT spending covered by completed segment architectures, the alignment between the transition plan and investment business cases, year-over-year reductions in steady-state IT spending. Levels are cumulative, so reaching level 4 means meeting levels 1 to 3 as well. Each capability area gets an average score; there is deliberately no overall score. The language is federal throughout (Exhibits 53 and 300, the Federal Transition Framework), so it fits government organizations far better than private companies. What every organization can borrow is its insistence that EA be judged by use and results, not by documents alone.
MIT CISR stages of architecture maturity
Four stages: Business Silos, Standardized Technology, Optimized Core, Business Modularity.
In Enterprise Architecture as Strategy (2006), Jeanne Ross, Peter Weill and David Robertson describe how companies build a foundation for execution. In Business Silos, IT serves local needs. In Standardized Technology, the company gains efficiency from shared infrastructure and standards. In Optimized Core, it standardizes the processes and data at the heart of its operating model. In Business Modularity, it builds reusable business components that allow fast, local variation on a shared core. Each stage changes what the company funds, who decides on applications, and what management practices it needs. The authors tie the right target to the company's operating model, and argue that stages cannot be skipped. Use it to talk with executives about the shape of the enterprise, rather than to grade the architecture team.
How to choose
- Grading the EA team, or understanding the enterprise? For the team, pick a level-based model or Kotusev. For the enterprise, CISR.
- Need a plan, or a position? Level-based models produce detailed gap lists. Stage models tell you where you are on the path and what usually comes next.
- Who will read the result? An auditor or oversight body will expect GAO- or OMB-style evidence. Executives tend to respond to stages described in business terms.
- What language does your practice already speak? If you work in the BTABoK or TOGAF, a model in that vocabulary will travel further inside your organization.
- Will you repeat it? Pick one model and stay with it. A change of score means little if the model changed in between.
Nothing stops you from using two. A level-based assessment of the practice and a stage-based view of the enterprise answer different questions, and the contrast between them is often the most useful finding: a mature EA team in an enterprise that has not yet standardized its core is a very different situation from the reverse.
Using these models in Useful EA
The Useful EA EA Maturity Assessment is built to support all of the models described here, scoring each one the way it was designed to be scored: levels averaged where the model uses levels, stages in order where it uses stages, and no overall score for OMB's framework. Each assessment uses one model, so results stay comparable over time. Where a model publishes no questions of its own, our questions are written from the model's published descriptions, and the tool says so.
The tool will not make maturity evaluations available for any copyrighted framework until we receive approval from its copyright holders. Those maturity models will be released into the tool when permission is provided. The GAO and OMB frameworks are works of the US government and are not subject to copyright.
The models described here belong to their authors and publishers. Useful EA is not affiliated with or endorsed by IASA Global, The Open Group, the US GAO, the US OMB, MIT CISR or the individual authors. TOGAF is a registered trademark of The Open Group.