Direct Answer: EA maturity describes how systematically and effectively an organisation uses enterprise architecture to support decisions and governance. For Sparx EA teams, maturity is not just about modelling skill — it is about repository discipline, governance processes, stakeholder engagement, and the quality of the data that flows from the repository. The five levels described here progress from ad hoc diagramming (Level 1) through to AI-augmented continuous architecture intelligence (Level 5). Most organisations operate at Level 2 or 3. The gap between Level 3 and Level 4 — making the repository machine-readable and connecting it to BI and AI tools — is where EA GraphLink and MDG governance become decisive. Most teams do not reach Level 4 without deliberate investment in governance discipline.
Key Takeaways
- Most EA teams using Sparx EA operate at Level 2 (shared repository, basic MDG) or Level 3 (governed MDG, stakeholder reporting).
- The Level 3 to 4 transition is the critical inflection point: it requires MDG quality sufficient for machine-readable queries, EA GraphLink connectivity, and a team governance process that maintains that quality over time.
- Level 5 is not a destination — it is an operating model. AI-augmented architecture practice requires continuous governance discipline to function.
- Jumping levels does not work. Organisations that try to deploy AI tooling at Level 1 or 2 get poor results and eroded confidence in both the tooling and the EA programme.
- The Discover offering gives organisations a structured, evidence-based readiness assessment to identify their current level and the specific investments that would advance it.
Level 1: Ad Hoc
Characteristics
At Level 1, enterprise architecture exists in practice as a collection of diagrams. Visio files, PowerPoint slides, and the occasional Sparx EA diagram produced by an individual architect are the primary artefacts. There is no shared repository discipline — either because there is no shared repository, or because the shared Sparx EA instance is used as a file system (packages are project folders, elements are not shared or reused, naming is inconsistent).
Modelling notations are mixed: some diagrams use ArchiMate symbols, others use boxes and arrows with no defined meaning. The same application appears in ten places with slightly different names. The current state of the architecture lives in the architect’s head, not in the model.
Common Pain Points
- Architects spend significant time building presentations from scratch because no reliable source of truth exists.
- New team members have no way to understand the architecture 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 artefacts because they know they may be out of date.
What Needs to Change
Establish a shared Sparx EA repository with a structured package hierarchy and basic access controls. Define initial naming conventions. Introduce at least one consistently-used notation (ArchiMate for the application portfolio, BPMN for process models). The goal is a single authoritative location where architecture content is created and maintained.
Relevant Sparx Services offering: Discover — to assess the current state and design the repository structure and governance model for initial implementation.
Level 2: Managed
Characteristics
At Level 2, the EA team has a shared Sparx EA repository that is actively used. Architects create elements in the shared environment rather than private files. Basic MDG conventions exist — some stereotypes are defined, naming conventions are documented — but compliance is inconsistent. Different architects interpret conventions differently; the MDG profile may have been set up by one person and not everyone understands it fully.
Stakeholder deliverables (application landscape diagrams, capability maps, process models) are produced from the shared repository. Package structure is defined but may not be consistently maintained. Some projects request architecture involvement; others bypass the EA team.
Common Pain Points
- The repository is used, but data quality varies significantly by architect and by project vintage.
- Tagged values exist on the MDG profile but are sparsely populated — most elements have empty or inconsistent properties.
- Architecture governance is advisory rather than enforced — there is no formal mechanism for making compliance with architecture standards mandatory.
- BI or reporting attempts on the repository return inconsistent data because element types and property names are not consistently applied.
What Needs to Change
Strengthen MDG governance: define a canonical stereotype set, populate mandatory tagged values across the existing portfolio, introduce validation rules, and assign MDG ownership. Establish a lightweight architecture review process — not a full ARB at this stage, but a defined check that projects consult the EA team before technology decisions. Improve stakeholder reporting with a regular cadence.
Relevant Sparx Services offering: Amplify — MDG governance build and Kernaro Assist deployment to accelerate the governance quality improvement.
Level 3: Defined
Characteristics
At Level 3, the EA team has governed MDG, consistent element creation practices, and a defined stakeholder reporting model. The MDG profile is owned, maintained, and enforced through validation rules and team convention. New architects onboard to a clear governance model. The repository is the acknowledged source of truth for the application portfolio, the capability map, and key architectural decisions.
Stakeholder reporting is systematic: regular architecture briefings, published content via a portal (Prolaborate or equivalent), and architecture review involvement in significant technology decisions. The Architecture Review Board or equivalent governance forum is active.
Common Pain Points
- Reporting is still largely manual — architects compile reports from the repository rather than consuming automated dashboards.
- The repository contains high-quality governed data, but access to that data requires architect mediation. Stakeholders cannot self-serve.
- AI tooling is on the radar but the team is not sure whether the repository is ready for it.
- Architecture value is visible to EA-engaged stakeholders but invisible to the wider organisation.
What Needs to Change
Connect the repository to BI tooling via EA GraphLink Interface A (GraphQL → Power BI or Tableau). Introduce automated dashboard reporting that removes the manual compilation step. Assess and close any remaining MDG gaps that would prevent reliable machine-readable queries. Prepare for Kernaro AI Hub deployment with a readiness assessment.
Relevant Sparx Services offering: Connect — EA GraphLink deployment for BI dashboard connectivity and preparation for AI layer.
Level 4: Quantitatively Managed
Characteristics
At Level 4, the EA repository is machine-readable. EA GraphLink connects the repository to BI dashboards (Power BI, Tableau, Microsoft Fabric) that are consumed by stakeholders without architect mediation. Architecture metrics are visible: application portfolio health, MDG compliance rates, capability maturity scores, technology lifecycle status. Decision-makers can access architecture data on demand.
The MDG profile is mature and stable. Tagged value population rates are high (80%+ on mandatory properties). Validation runs regularly and exceptions are managed. The repository is a reliable data source, not just a modelling environment.
Common Pain Points
- BI dashboards are available, but natural language query — “what are the technology risks in our customer data platform?” — still requires an architect to compile the answer.
- AI tools are being adopted across the organisation but not yet connected to the EA repository.
- The EA team struggles to keep pace with the volume of architecture questions as visibility of the repository increases.
- Some stakeholders want conversational access to architecture data, not just structured dashboards.
What Needs to Change
Deploy EA GraphLink Interface B (MCP Server) and enable AI tools — Microsoft Copilot, Claude, or Kernaro AI Hub — to query the repository via natural language. Extend the MCP layer to Microsoft Fabric or other data platform integrations where EA serves as the semantic layer. Deploy Kernaro AI Hub to the stakeholder-facing environment.
Relevant Sparx Services offering: Connect (Kernaro AI Hub deployment) and Deploy (platform engineering and ongoing support).
Level 5: Optimising
Characteristics
At Level 5, architecture intelligence is continuous and embedded in how the organisation makes decisions. Kernaro AI Hub is active — business leaders and programme teams query the architecture directly. Kernaro Assist is embedded in the architect workflow, accelerating governance maintenance and model evolution. The EA team’s primary role has shifted from producing architecture artefacts to interpreting architecture intelligence and providing strategic guidance.
Architecture metrics are used for proactive management: technology debt is tracked and managed against targets, capability maturity trends are monitored, strategic alignment of the portfolio is measured and reported. The repository continues to evolve with the organisation — it is a live asset, not a project deliverable.
Common Pain Points
Level 5 is a continuous operating state, not a final destination. Common challenges at this level:
- Governance discipline must be maintained as the organisation grows and the team turns over. New architects need to onboard to the MDG governance model and maintain it under time pressure.
- Kernaro AI Hub creates demand for AI-readable architecture that can outpace the EA team’s ability to maintain and extend the repository scope.
- The value of live architecture intelligence creates pressure to expand the model scope — which can dilute focus if not managed deliberately.
What Needs to Change
Level 5 requires a sustained operating model, not a one-off investment. Architecture governance, MDG maintenance, AI model evolution, and stakeholder capability management are ongoing. The Deploy offering provides the platform engineering and ongoing support that sustains Level 5 operation.
Relevant Sparx Services offering: Deploy — ongoing platform support, governance maintenance, and EA GraphLink / Kernaro evolution management.
Applying the Model to Your Organisation
Most organisations overestimate their maturity level. The honest test is data quality rather than tooling presence. An organisation that has Sparx EA deployed on Pro Cloud Server, MDG profiles configured, and EA GraphLink installed — but with poor tagged value population rates and inconsistent MDG compliance — is operating at Level 2, not Level 4. The tooling sets a ceiling; governance discipline determines where you actually sit below that ceiling.
Maturity progression is not linear in time but it is sequential in logic. You cannot reliably skip Level 3 governance discipline and deploy Level 4 BI dashboards with trustworthy data. You cannot deploy Level 5 AI-augmented intelligence on a Level 2 repository without exposing its inconsistencies to the AI — which damages rather than builds stakeholder confidence.
The Discover assessment is designed to identify your current honest maturity level and design a realistic progression path. It does not assume higher maturity than the evidence supports.
FAQ
What is EA maturity and why does it matter? EA maturity describes how systematically an organisation uses enterprise architecture to support decisions and governance. It matters because EA value is not delivered by the presence of tools or models — it is delivered by the quality and reliability of architecture practice. A Level 5 EA practice generates continuous strategic intelligence. A Level 1 practice generates useful diagrams that may or may not be current. Maturity progression is the path from one to the other.
What level are most Sparx EA teams at? In our experience, most organisations with active Sparx EA deployments operate at Level 2 or Level 3 — they have a shared repository and some governance discipline, but not the MDG quality or the machine-readable data standard required for Level 4 BI or AI connectivity. Reaching Level 4 requires deliberate investment in MDG governance, which many teams have not completed.
Can we skip levels in the maturity model? In practice, no. You can deploy Level 4 tooling (EA GraphLink, Power BI dashboards) before achieving Level 3 governance discipline — but the output of those dashboards will reflect the data quality of a Level 2 or 3 repository, which means incomplete and inconsistent results. Stakeholders lose confidence in the dashboards before the governance has time to improve. The progression is sequential: governance discipline must precede machine-readable queries, which must precede AI intelligence layers.
How long does it take to move from Level 2 to Level 3? For an organisation with an active Sparx EA team and a populated repository, progressing from Level 2 to Level 3 typically takes three to six months: four to six weeks to strengthen the MDG profile, followed by eight to sixteen weeks to backfill existing content and establish the governance operating model (ownership, validation cadence, review process). The time depends on repository size, team capacity, and the extent of existing MDG inconsistency.
What does “machine-readable” mean in the context of Level 4? Machine-readable means the repository is structured consistently enough that automated systems — EA GraphLink, Power BI, AI tools — can traverse it and return reliable answers to structured queries. Specifically: element types are consistently stereotyped, tagged values are populated (not empty or free-text where enumerated values are needed), connector types are semantically correct, and naming conventions are consistent enough to avoid duplication confusion. Machine-readability is a governance discipline outcome, not a technology configuration.
What is the role of EA GraphLink in Level 4 and 5? EA GraphLink is the connectivity layer that makes Level 4 and 5 possible. Interface A (GraphQL API) connects the EA repository to BI tools — Power BI, Tableau, Microsoft Fabric — for structured dashboard reporting. Interface B (MCP Server) connects the repository to AI tools — Microsoft Copilot, Claude, Kernaro AI Hub — for natural language query. Without EA GraphLink, the repository can only be queried through the Sparx EA client, which requires architect mediation and prevents stakeholder self-service.
How do I assess our current maturity level? The most reliable assessment focuses on data quality rather than tooling presence. Questions to ask: What percentage of our application elements have their mandatory tagged values populated? How consistently are our MDG stereotypes applied versus base metaclasses? Can an external tool query our repository and return a reliable application list? Do stakeholders trust the data in our EA repository without verification? The Sparx Services Discover engagement provides a structured, evidence-based readiness assessment that identifies your honest current level and the specific investments required to advance it.
Can AI tooling help us improve maturity faster? At Level 2 and above, Kernaro Assist can accelerate maturity progression by automating governance conformance checking, accelerating MDG backfill work, and reducing the mechanical overhead of consistent element creation. However, Assist cannot substitute for the governance decisions that require business context, and its effectiveness is constrained by the current MDG quality. The most effective use of Assist for maturity progression is at Level 2 transitioning to Level 3 — using it to accelerate the governance improvement work that defines Level 3.
Find Out Where You Actually Are
Sparx Services’ Discover offering is a structured readiness assessment that gives you an honest, evidence-based view of your current EA maturity level and a clear progression plan.
The assessment covers repository structure, MDG governance quality, stakeholder engagement, and AI readiness — producing a findings report and a prioritised investment roadmap.
