Questions to ask before you invest in EA AI augmentation

An architecture leader who wants AI working on the architecture is usually right to want it. The goal is architects who decide what should be done while AI does the mechanics in the tool and the model. Wanting that and being ready to fund it are different conversations, though, and the gap between them is where budget disappears.

Before you fund AI augmentation for your enterprise architecture practice, you should be able to answer seven questions, though not necessarily perfectly. If three or more leave you guessing, start with an assessment before you spend on anything else. Each question below comes with what a confident answer sounds like and what a shaky one tells you.

1. Is your Sparx EA repository actively maintained and trusted by the team?

Why it matters. AI scales whatever it is given. A clean repository gets more useful with AI on top of it. A neglected one gets worse, because the AI repeats every inconsistency and every stale element it finds.

What a good answer sounds like:

• “We run regular model reviews; elements get updated when decisions change.”
• “Teams check the model before a new project starts.”
• “We can see what is current and what is obsolete.”
• “Architects argue about whether something belongs in the model, not about whether the model is accurate.”

If the answer is ‘we don’t really know’: your EA repository is probably fragmented, with different teams keeping different standards and element definitions drifting. You need a clear picture of what you are working with. AI can help produce that picture, by counting what is missing and inconsistent across the model, but an architect has to decide what the counts mean.

2. Is your MDG Technology defined and documented, or implicit and fragmented?

Why it matters. Your MDG Technology is the contract between your model and any tool that reads it. If the metamodel lives only in people’s heads (“we all know what a Capability is; it’s just never written down”), AI will make confident, wrong assumptions. If each team defines Capability its own way, the output comes back incoherent.

What a good answer sounds like:

• “Our MDG Technology is defined, versioned and reviewed.”
• “Element types, relationships and tagged values are documented.”
• “We have governance rules, for example, every Capability must have an owner.”
• “New joiners learn the metamodel in their first week.”

If the answer is ‘our metamodel is in people’s heads’: that is the biggest single blocker to useful AI output, so making the metamodel explicit comes first. The AI-augmented way to do it is for the architect to design the governance intent, the stereotypes, required tags and rules, and to have AI apply and check it across the model.

3. Do you know how AI will reach the repository?

Why it matters. Sparx EA core has no built-in AI assistant and no native MCP server, so every route is something added alongside it, and each has its own prerequisites. Shared, read-only answers for many people come through Kernaro AI Hub, a Sparx Systems product that has to reach your repository from a server. An architect directing AI to build and change the model works from their own machine, through Kernaro Assist inside EA or through Claude or GitHub Copilot with the free AI Power Tools for Sparx EA, which need EA on a Windows machine and an organization that permits that AI.

What a good answer sounds like:

• “We know where the repository is hosted and who administers it.”
• “We know which AI platforms IT and security have approved.”
• “We know which jobs need shared read-only access and which need an architect changing the model.”
• “The repository server is documented, supported and patched on a normal schedule.”

If the answer is ‘we’re not sure’: this is a prerequisite. Find out how and where the repository is hosted and which AI your organization permits, then match the route to the job. The AI tools for Sparx EA comparison sets the options side by side.

4. Which jobs would gain most from architecture context?

Why it matters. The payoff comes from putting architecture context into work people already do: an architect drafting a solution design, a delivery team checking dependencies, a portfolio owner asking what supports a capability. If you cannot name the jobs, you do not yet have a use case.

What a good answer sounds like:

• “Our proposal teams use [AI platform]; they would benefit from our capability definitions.”
• “Our workflow designers need to know which systems exist.”
• “Our architects spend their week keeping the model current by hand; we want AI doing that work while they review it.”
• “Our technical writers need architecture context for their documentation.”

If the answer is ‘we just want an AI assistant on the model’: a single assistant is a worthwhile start. Ask next where architecture context would change a workflow you already run, because that is where most of the value sits.

5. What specific use cases are you targeting first?

Why it matters. Use cases force specificity. They scope the work and give you success criteria you can hold the program to.

What a good answer sounds like:

• “Stakeholders spend hours every month documenting capability status; we want that drafted for them.”
• “Architects spend too much of their time writing element descriptions; we want AI drafting them for review.”
• “We answer ‘what apps support capability X?’ many times a year, and each answer takes days.”
• “Compliance needs to know which applications run deprecated technologies, and today that is a long manual review.”

If the answer is ‘we’ll figure it out after we deploy’: that is how budget gets spent without value landing. Pick two or three use cases you can measure, record the current effort for each, and you have your baseline.

6. What does success look like, and how will you measure it?

Why it matters. Success reads differently to different people. An architect measures time saved, a CIO measures inventory accuracy, and a business stakeholder measures faster decisions on application spend. Agree on what you are measuring before anything is switched on.

What a good answer sounds like:

• “We will track architect time on documentation against the baseline we measured.”
• “We will track how many AI-drafted descriptions need edits before they are accepted.”
• “We will measure how long a stakeholder waits for an answer to a portfolio question.”
• “We will track the share of applications with known standards alignment.”

If the answer is ‘we’ll just see how it goes’: that leads to spending the money and never proving the value. Define the measures now. They become your criteria for each next step.

7. Who owns this internally, and do they have the authority to unblock it?

Why it matters. This decides whether you are adding a tool or changing how architecture gets done. A mid-level architect cannot mandate how teams work or require metamodel updates, and someone working on this part-time cannot sustain it.

What a good answer sounds like:

• “The CTO owns it; she has authority over architecture standards and team budgets.”
• “It reports to the Chief Architect, who can mandate MDG Technology updates and model governance.”
• “The VP of Technology sponsors it and can fund the model work and the team’s skills.”
• “Ownership is shared between EA and the PMO, coordinating on governance and standards.”

If the answer is ‘the EA team will own it’: treat that as a warning. EA teams are usually stretched already, and an initiative parked solely with them competes with the day job and loses. It needs a sponsor with authority over governance and standards, or it stalls the moment a metamodel or model-quality decision is required.

Reading your score

Tally your answers. The result points at your next move.

The assessment path

If you can answer all seven clearly, you are ready to configure the solution. You know your current state, your use cases are specific, and you have the organizational backing to make it stick.

If you land at five or six, you are close. Name the blind spots and close them before you commit.

If you can answer four or fewer, start with an assessment. Paralysis to a Plan works through four questions with you: the problem you are trying to solve; the pieces of the puzzle, including your Sparx EA deployment, repository structure, metamodel governance, data quality, AI platforms and policies, and your team’s skills; what success looks like; and the plan that gets you there. It answers these seven questions for your environment and produces the plan for what comes next.

You could skip all of this. You would stand up the tooling, architects would use it for the safe tasks, you would see some incremental value, and you would wonder why it never changed how the practice works. Answering these questions first lets you invest with a clear view of what you are building toward. For the wider picture of how this changes the practice, see AI-Augmented Architecture, or start from where your architects spend their day.