How to build a business case for getting your EA repository’s answers into Copilot

You don’t need to invent a business case for getting your EA repository’s answers to the people who ask, because you are already paying the cost of not doing it. Name that cost, in hours and in missed decisions, and put a number on it.

Every time a delivery lead emails the architecture team to ask “do we already integrate with Salesforce anywhere?”, that’s a 15-second question. In practice it takes three weeks, because the answer lives in a specialist tool that requires a specialist to open it. Multiply that by the questions your architects field each week, by the stakeholders who ask variations of the same thing, and by the delivery teams that blow past decision deadlines while they wait.

Then count the people who have stopped asking. They proceed without the architecture context they needed, and the consequences surface months later as rework. That is what the current state costs. A business case for getting your Sparx EA repository’s answers into a tool like Microsoft 365 Copilot is a case for paying less to get more.

Quantify what the current state costs

Start with architect time, because it’s the number you can defend.

Pull a sample week from your EA team’s calendar and count the hours spent answering questions that could be answered by querying the repository directly. By hand, an architect opens EA, finds the elements, assembles the answer and explains it to whoever asked. That time goes to retrieval and explanation, and it comes out of design, governance policy and strategy. Many teams are surprised by how large that share is, so measure it rather than assume it.

Take that fraction, multiply by your loaded cost per architect (salary, benefits, and overhead), and annualize it across the team. That figure, the cost of being slow at answering questions you already hold the data for, is your baseline.

Then layer on two costs that are harder to price but no less real:

• Decisions made without architecture context. When a team skips a dependency check, integrates in a way that adds technical debt, or rebuilds something that already exists, the rework typically runs several times the original build cost. Even one such decision per team per quarter adds up.
• The cost of waiting. Decisions stall while context is assembled. Market windows close. Quarterly planning slips into the next quarter. Strategy sessions stall because half the room is still gathering data.

Most architecture leaders can put a firm number on the first cost and a credible estimate on the second. Together they give you a defensible annual figure that scales with the size and complexity of the organization.

Frame the ROI as redistributed cost, not new spend

Getting repository answers to the people who ask moves the cost somewhere more valuable. The time architects spend answering lookups becomes time for design, governance, and strategy. The architects don’t go away; their work gets harder to replace.

The AI-augmented way changes what the architect does in the loop. The architect decides which questions the business should be able to ask, what counts as a trustworthy answer, and how complete the repository has to be before the answers are exposed. AI builds and maintains the reporting layer that serves those answers. That is a different job from answering each question by hand, and it is the one your most senior architects should be doing.

Build the lever as a loaded-cost calculation rather than a headline dollar figure. Take the hours per week each architect currently spends on repository lookups, estimate how far self-service answers pull that down, and multiply the recovered hours by your loaded hourly cost across the team. For a five-architect team, recovering even a handful of hours each per week compounds into a substantial annual capacity gain, capacity you redeploy into work that moves the strategy.

The question is whether to use the tool we already bought more effectively.

Recovered capacity is the first lever. Add two more:

• Decision quality. When architecture context is instant instead of three weeks late, risk surfaces earlier, redundancy gets caught, and integration points are discovered before they become surprises. Over a year, better-informed decisions compound, and the value is usually conservative to estimate.
• Decision velocity. Decisions that take four weeks with assembled context take one when the context is already there. Faster cycles show up directly in delivery speed and market responsiveness.

Add the three together and you have the shape of the return; your own numbers decide whether it clears the bar inside the first year. By year two, with set-up behind you, the recovered capacity keeps paying out against a near-flat cost base.

Name the risks explicitly

A business case should name its risks, because one that ignores them reads like a sales pitch. Three are worth stating.

Data governance. Once anyone can query the repository, accuracy matters more. Your current state tolerates some staleness because only specialists ask. Open the repository to a broad audience and stale data produces confident, wrong decisions at speed. The fix is a governance model that keeps repository data current before you widen access. It is solvable, but it takes discipline and investment.

Query accuracy. AI systems hallucinate. Factual lookups (“what systems integrate with this one?”) are reliable; reasoning questions (“how should we integrate with this one?”) need an architect. The real risk is that stakeholders ask the wrong kind of question and trust an answer they shouldn’t. A clear policy on what the AI may and may not be relied on for handles this.

MDG dependency. This is the hidden one. Whichever route you take, the answers are only as good as your MDG Technology, the definition that gives the physical Sparx schema its business meaning. With Kernaro AI Hub, the MDG translates the schema into the GraphQL schema the AI sees. With a Power BI model, it decides which tables and columns exist at all. If your metamodel is patchy or leans on implicit knowledge, the answers will be too. Check whether your MDG is ready before you invest, and budget for remediation first if it isn’t.

None of these are reasons to skip the work. They’re the difference between a case that looks like fantasy and one that looks like you know exactly what you’re implementing.

Choose the route before you cost it

“Copilot” covers more than one route, and the route sets the cost. For Microsoft 365 Copilot, which is read-only, there are two. If you have Kernaro AI Hub, Copilot can reach your EA data through Hub’s read-only API, via Copilot Studio or a Microsoft 365 connector, and the Kernaro Connector for Power BI, an extension to Hub, is the preferred route to Power BI. Without Hub, Copilot answers from a published Power BI semantic model built on a reporting database, which we can build for you or teach your architects to build. For GitHub Copilot in VS Code, AI Power Tools for Sparx EA gives full read/write through its VS Code extension. AI Power Tools is free, so its cost is people and setup, not licenses. The mechanics are in the NovoCircle documentation (opens in a new tab), and AI tools for Sparx EA compares all the routes.

Lead with the comparison point

The framing that lands with leadership starts from what you already own. You’ve already paid for the Sparx EA repository. You’ve already spent the time and money to model the architecture. The data already exists. The integration cost is the cost of letting more people reach that investment without a specialist in the middle.

Framed that way, the ask reads as infrastructure optimization, with cost redistributed toward work that generates value, and it stops reading as discretionary software spend.

A business case structure you can adapt

Use this five-part structure to assemble the internal case. Each step turns one of the arguments above into a line your finance partner can sign off on.

In most organizations where the repository is mature and the MDG is reasonably clean, the answer is yes, and the case describes what the numbers already show. For the bigger picture of how this reshapes the architect’s role, see AI-Augmented Architecture. When you’re ready to turn the case into a scored, fundable plan, Paralysis to a Plan is the next step.

How we help

We can teach your architects to do this work on your own repository and mentor them until it sticks, and we can get your EA data into Power BI, Microsoft 365 Copilot, Microsoft Fabric or your data warehouse for you. If the repository is not complete enough yet to put in front of Copilot, we can build and update the model for you.