Insight · Assessment

Enterprise Architecture Maturity: A 5-Level Model for Sparx EA Teams

By Sparx Services · October 4, 2025 · 7 min read

EA maturity rests on repository discipline, governance, stakeholder engagement and the quality of the data that comes out of the model. The five levels below run from ad hoc diagramming to continuous architecture intelligence. The hard jump is from Level 3 to Level 4, where the repository becomes reliably machine-readable.

That jump used to depend on how much manual effort a team could put into backfilling tagged values, fixing stereotypes and compiling reports. Working AI-augmented changes the effort. Architects decide the rules and what the model should contain, and AI does the mechanics: populating values from the systems that already hold them, checking content against the profile and keeping views and dashboards current. The decisions about rules and exceptions are still the architects’, and so is judging whether the result is right.

Maturity is easy to overestimate. The test is data quality, and tooling presence tells you little. A team running Sparx EA on a server with profiles configured but sparse tagged values is operating at Level 2, whatever is installed. Use the levels below to find where you are.

The five levels

Ad Hoc

Architecture lives as a scatter of diagrams: Visio files, slides, the occasional Sparx EA diagram from one architect. There is no shared repository discipline, and the current state lives in people’s heads. Notations are mixed and the same application appears in ten places under slightly different names.

Managed

A shared repository is actively used. Architects create elements in the shared environment instead of private files. Basic MDG Technology conventions exist but compliance is uneven: stereotypes are partially defined, tagged values sparsely populated, and reporting returns inconsistent data.

Defined

Governed MDG, consistent element creation and a defined stakeholder reporting model. The profile is owned and enforced through validation rules. The repository is the acknowledged source of truth, an Architecture Review Board is active, and reporting runs on a regular cadence. Reporting is still largely manual, and stakeholders cannot serve themselves.

Quantitatively Managed

The repository is machine-readable. Architecture metrics are on dashboards people use without an architect in the middle: portfolio health, MDG compliance, capability maturity, lifecycle status. Mandatory properties are populated, much of it from the systems that own the data, and validation runs regularly. The model is a reliable data source as well as a drawing environment.

Optimizing

Architecture intelligence is continuous and built into how the organization decides. The model is finished and stays current, with AI doing much of the upkeep. The team’s main work shifts from producing artifacts to deciding what the model should answer and interpreting it. Level 5 is an operating state that holds only with sustained governance discipline.

1 Ad Hoc2 Managed3 Defined4 Quantitative5 Optimizing

Level 1: Ad Hoc: the symptoms

At Level 1, EA exists as a collection of diagrams. Either there is no shared repository, or the shared Sparx EA instance is used as a file system, with packages as project folders and no reuse. The current state of the architecture is in the architect’s head. The common pain points:

Architects rebuild presentations from scratch because no reliable source of truth exists.
New team members cannot understand the estate without interviewing existing architects.
Project teams make technology decisions without architecture input because the EA team cannot respond quickly enough.
Stakeholders do not trust architecture artifacts because they know they may be out of date.

What needs to change: establish a shared repository with a structured package hierarchy and basic access controls, define naming conventions, and adopt at least one consistently used notation. AI can help consolidate the scattered diagrams into typed elements once the architects have decided what the model should contain. Paralysis to a Plan assesses the current state and designs that structure.

Level 2: Managed: the data-quality wall

The repository is used, but data quality varies by architect and by project vintage. Tagged values exist on the profile but are sparsely populated. Architecture governance is advisory, and any report returns inconsistent data because element types and property names are applied inconsistently.

What needs to change: define a canonical stereotype set, introduce validation rules and assign profile ownership. Then fill the gaps. Today teams backfill tagged values by hand, and the values go stale as soon as they are typed. The modern way is to connect the model to the PPM, ITSM, eGRC and ITFM systems that already hold cost, ownership, lifecycle and risk data, and let AI bring it in and check it against the profile. The architect decides which source owns which value and reviews the exceptions. Configure the Solution sets up the governance this depends on.

Level 3: Defined: reliable but manual

Governed MDG, consistent practices, a defined reporting model, an active review board. The repository is the source of truth for the portfolio, the capability map and key decisions. The friction now is effort: reporting is still mostly compiled by hand, stakeholders need an architect to get answers, and the team is unsure whether the repository is ready for automated querying.

What needs to change: close the remaining MDG gaps that would block reliable queries, then put a reporting database on top of the repository so dashboards in Prolaborate or Power BI replace manual compilation. AI can find the gaps and build the reporting layer. Deciding what each dashboard should answer, and for whom, is the architect’s work. See reporting and Power BI.

Level 4: Quantitatively Managed: the model becomes data

The repository is machine-readable and feeds dashboards people use without an architect in the middle. Metrics are visible on demand, the profile is stable, and validation runs regularly with exceptions managed. The remaining gap is conversational: stakeholders want to ask questions in plain language instead of reading a dashboard, and the team struggles to keep up with the volume of questions.

What needs to change: let business and IT stakeholders ask questions of the model directly, with the repository as the governed source the tools read from. That can be Microsoft 365 Copilot answering from a published Power BI semantic model, Kernaro AI Hub, or Prolaborate 6 with AI. AI tools for Sparx EA compares which helper fits which job.

Level 5: Optimizing: an operating state

Architecture intelligence is continuous. Business leaders and program teams ask the architecture questions directly, and the team’s role has shifted to deciding what the model should answer, interpreting it and guiding strategy. The model is a live asset kept current from project delivery and the source systems. The challenges are about sustaining it: governance discipline must survive team turnover, demand for answers can outpace the team’s capacity to maintain the rules, and the value of live intelligence creates pressure to expand scope.

What needs to change: governance, profile maintenance and stakeholder enablement become ongoing work. The skills that keep Level 5 running are stating intent clearly to AI, reviewing what it changes, and designing what stakeholders see as their questions change.

Applying the model

Organizations tend to overestimate their level because they count tools instead of measuring data. The tooling sets a ceiling and governance discipline sets where you sit below it. Progression is sequential in logic, even when it is fast in time. You cannot reliably skip Level 3 governance and stand up trustworthy Level 4 dashboards, and running Level 5 conversational access on a Level 2 repository exposes its inconsistencies to the people you most need to trust it.

A structured readiness assessment is the quickest way to find your level and a realistic path to the next one. It is the same discipline we bring to architecture leaders who need to turn pressure into a fundable plan.

FAQ

What is EA maturity and why does it matter?

EA maturity describes how systematically an organization uses enterprise architecture to support decisions and governance. It matters because EA value comes from the quality and reliability of the practice and its model. A Level 5 practice keeps a finished, current model that people use to decide. A Level 1 practice has diagrams that may or may not be current.

Can we skip levels?

Not reliably. You can deploy dashboards or AI before the governance is in place, but they will reflect the data quality underneath: incomplete and inconsistent. Stakeholders lose confidence before governance has time to improve. AI can make the climb faster by doing the mechanics, but governance still comes before machine-readable queries, and those come before stakeholders asking questions directly.

How long does it take to move from Level 2 to Level 3?

It depends on repository size, how inconsistent the existing content is, and the team’s capacity. The work is the same either way: strengthen the profile, bring existing content up to it, and set up the operating model of ownership, validation and review. With AI doing the backfill and the checking, the slowest part is usually the decisions people have to make about the rules and the exceptions.

What does machine-readable mean at Level 4?

The repository is structured consistently enough that automated systems, including AI, can traverse it and return reliable answers: element types are consistently stereotyped, mandatory tagged values are populated, connector types are semantically correct, and naming is consistent enough to avoid duplicates. Machine-readability is a governance outcome, and no configuration switch produces it.

How do I assess our current level?

Measure data quality, not tooling. What share of application elements have their mandatory tagged values populated? How consistently are stereotypes applied? Can an external tool query the repository and return a reliable application list? Do stakeholders trust the data without checking it? AI can gather much of this evidence from the repository quickly. Deciding what it means for your practice is the assessment.

Find out where you are, and what the next level takes.

We can assess your practice and build the plan with you, then do the modeling work and hand it over. Or we can teach your architects to climb the levels AI-augmented on your own repository and mentor them until it sticks.

Book a call

Keep reading