Questions to ask before you invest in EA AI augmentation

Most CIOs and transformation directors we meet already know they want AI working against their architecture. That instinct is right. But wanting to plug AI into your repository and being ready to do it are two different conversations, and the gap between them is where budget quietly disappears.

The short version: before you fund an AI augmentation program for your enterprise architecture practice, you should be able to answer seven questions honestly. Not perfectly. If three or more leave you guessing, your first move is an assessment, not a deployment. 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 is multiplicative. A clean repository gets sharper with AI on top of it. A neglected one gets worse, because the AI faithfully amplifies every inconsistency and every stale element it finds. You are not patching a data-quality problem by adding AI — you are automating it.

What a good answer sounds like:

• “We run monthly 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. Different teams keep different standards; element definitions drift. You need a clear picture of what you are working with before AI touches it. That picture is an assessment.

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 it is fragmented, with each team defining Capability its own way, the output comes back incoherent.

What a good answer sounds like:

• “MDG Technology is defined; here is the version and last review date.”
• “Element types, relationships, and tagged values are documented.”
• “We have governance rules — for example, every Capability must have an owner.”
• “New joiners are trained on the metamodel in their first week.”

If the answer is ‘our metamodel is in people’s heads’: this is the most common reply, and it is the single biggest blocker to useful AI output. You need explicit metamodel definition first. Metamodel remediation is one of the things an assessment is built to deliver.

3. Is your cloud-server tier deployed and current?

Why it matters. The connectivity layer that surfaces repository data to AI runs against a shared server deployment, not single-user copies of Sparx EA scattered across laptops. If everyone is working in local files, there is nothing for an integration to connect to. And a server that is several versions behind is carrying security and performance gaps that will surface at the worst time.

What a good answer sounds like:

• “Our cloud-server tier is deployed in [environment]; we are on version X.Y.”
• “It rides our normal patch schedule.”
• “It is documented and supported.”
• “Teams reach the repository through the shared server, not local files.”

If the answer is ‘we’re not sure’ or ‘we haven’t set that up’: this is a prerequisite, not a detail. You need to know your deployment topology. If the organization is still running single-user EA everywhere, that is a migration conversation that comes before any AI discussion. An assessment maps your topology and names what has to change.

4. Which AI tools does your organization use, and which would gain most from architecture context?

Why it matters. A connectivity layer is a platform, not an application. Its payoff comes from feeding architecture context into the tools your teams already live in. If you cannot name which tools matter, you do not yet have a use case — you have an aspiration.

What a good answer sounds like:

• “We use [GenAI platform] for proposals; it would benefit from our capability definitions.”
• “We use [automation platform] for workflow design; it needs to know which systems exist.”
• “We are evaluating [platform] and need to understand how it connects to the repository.”
• “Our technical writers use [content platform]; architecture context would speed up their documentation.”

If the answer is ‘we just want an AI assistant on the model’: a single assistant is one endpoint, and a worthwhile one. But if you are not routing architecture context into the rest of your stack, you are leaving most of the connectivity layer’s value on the table. Start by asking where architecture context would change a workflow you already run.

5. What specific use cases are you targeting in the first six months?

Why it matters. Deployment without use cases is capability theater. Use cases force specificity: they scope the work, and they hand you success criteria you can hold the program to.

What a good answer sounds like:

• “Stakeholders spend roughly 20 hours a month documenting capability status; we want that auto-drafted.”
• “Architects spend about 15% of their time writing element descriptions; we want that carried for them.”
• “We answer ‘what apps support capability X?’ 50 times a year; we want that in seconds, not days.”
• “Compliance needs to know which applications run deprecated technologies; today that is a two-week manual review.”

If the answer is ‘we’ll figure it out after we deploy’: that is exactly how budget gets spent without value landing. Pick two or three measurable use cases, estimate the current effort and cost of each, and you have your ROI 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; a business stakeholder measures faster decisions on application spend. You need to agree on what you are measuring before anything is switched on.

What a good answer sounds like:

• “We will track architect time on documentation — baseline 120 hours/month, target 80 within six months.”
• “We will track the accuracy of generated descriptions — target above 90% needing no edits.”
• “We will measure self-service query turnaround — baseline two weeks, target under two minutes.”
• “We will assess compliance coverage — baseline 60% of apps with known standards alignment, target 100%.”

If the answer is ‘we’ll just see how it goes’: that is the setup for “we spent the money and never proved the value.” Define the metrics now. They become your deployment criteria, not an afterthought.

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

Why it matters. This decides whether you are deploying a tool or changing how architecture gets done. A mid-level architect cannot mandate how teams use a new capability or require metamodel updates. Someone working on this part-time cannot sustain it. This is a question about organizational alignment, not technology.

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 both the build and the capability work.”
• “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 red flag. EA teams are usually stretched already, and an initiative parked solely with them competes with the day job and loses. This needs cross-organizational sponsorship and someone with real authority over governance and standards — otherwise it stalls the moment a metamodel or model-quality decision is required.

Reading your score

Tally your honest answers. The picture is simple, and it points straight 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. You have a handful of blind spots — name them and close them before you commit.

If you can answer three or four, or fewer, an assessment is your first step. Paralysis to a Plan covers:

• A read on your Sparx EA repository and deployment topology
• An MDG Technology audit — explicit definition, documentation, governance rules
• A cloud-server readiness check
• AI tool landscape mapping — what is in use, what is planned
• Use case identification and prioritization
• Success-metric definition
• An organizational readiness read

It is scoped to your environment. It answers these seven questions and produces a roadmap 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 book some incremental value — and you would quietly wonder why it never changed how the practice actually works. The alternative is to spend the time upfront, answer these questions honestly, and invest with a clear view of what you are building toward.

The gap between buying a tool and building a capability usually comes down to exactly that: understanding where you are before you decide where you are going. For the wider picture of how this reshapes the practice, see AI Augmented Architecture, or start from where your architects spend their day.