How to know if your Sparx EA repository is ready for AI augmentation (and what to do if it isn’t)

Ask an EA leader whether their repository is ready for AI augmentation and the reflex answer is some version of “probably not.” They picture a readiness assessment as a verdict: a long list of problems to fix before they are allowed to begin. A more useful picture is a profile. Readiness for a Sparx EA repository breaks down into six dimensions. A team is usually strong on some and weaker on others, and a gap in one or two of them tells you where to start. You can begin AI-Augmented Architecture work in the domains that are already strong and close the gaps in parallel, with AI doing much of that work under an architect’s direction.

The six dimensions that determine readiness

Readiness is the combined state of six things about your EA repository: what is modeled, how consistently, and how reachable it is.

1. Model completeness

Whether the elements in your repository represent your organization’s architecture, or whether large areas are missing, stale or half-modeled. Solid coverage in two or three domains and thin coverage elsewhere is a workable position. You start where the coverage is good.

2. Tag and attribute coverage

How consistently architects have filled in the properties that carry your organization’s metadata. Stereotypes, tagged values and structured attributes are what make Sparx EA data queryable rather than a flat list of names.

3. Relationship density

Whether the connections between elements are modeled as well as the elements themselves. Relationships turn a repository from a list into a map. Impact analysis, dependency tracing and capability-to-system linkage all depend on relationships being present and correctly typed.

4. Metamodel consistency

Whether your team models the same concepts the same way across packages, domains and time. An MDG Technology defines the types, stereotypes and structural rules that hold the metamodel together, and validation rules check the model against it.

5. Description quality

Whether elements carry meaningful descriptions that an AI can reason over. An AI can traverse relationships and retrieve elements without descriptions. It cannot answer a plain-language question about what those elements mean or do, so stakeholder self-service and AI answers both depend on this dimension.

6. Connection readiness

Whether AI can reach the repository in the way you need. Sparx EA core has no built-in AI assistant and no native MCP server. Shared, read-only access for many people comes from Kernaro AI Hub, a Sparx Systems product whose read-only MCP server serves the whole enterprise. An architect who wants AI to read and write the model can use Kernaro Assist inside the EA client, or AI Power Tools for Sparx EA, free from NovoCircle, which gives Claude or GitHub Copilot access from the architect’s own Windows machine. AI tools for Sparx EA sets the options side by side. This dimension is mostly a conversation with IT and security about which tools are permitted and where the repository is hosted.

A lower readiness score is a map of what to fix first, and in what order.

Score your own repository in four passes

You do not need a formal engagement to get a usable read. For each dimension, decide whether the current state is strong (solid across the domains you would prioritize), partial (real but with identifiable gaps) or inconsistent (would mislead AI until it is fixed).

Closing the gaps, today and AI-augmented

The order matters more than the effort. Metamodel consistency and connection readiness come first, because they affect every later step, and enriching content that an inconsistent metamodel then misrepresents wastes the work. Tag and attribute coverage comes next, aimed at the domains and element types that will carry the most value. Description quality follows, prioritized the same way.

Today, by hand. Architects open element after element, fill in missing tags, retype descriptions and add relationships from memory. On a large repository that stalls long before it finishes.

AI-augmented. The architect designs the governance intent: the stereotypes, the mandatory tags, the allowed relationships and what a good description says. That goes into the MDG and a set of validation rules. The AI checks every element against them, reports the gaps, drafts descriptions and proposes fixes where the evidence supports one, and makes the changes the architect approves. Automation checks completeness, people own correctness.

The skill it asks. Stating what good looks like precisely enough for an AI to check it, and reviewing the AI’s proposals with knowledge of the estate. A drafted description that reads well and says the wrong thing is worse than none.

If you would rather have the scoring done with you, Paralysis to a Plan runs it as a structured assessment: repository quality, MDG consistency and automation opportunity, scored across the six dimensions, with a sequenced plan at the end. For the wider picture of what augmentation changes once you are ready, see AI-Augmented Architecture.