How to build a business case for connecting your EA repository to Copilot

You don’t need to invent a business case for connecting your EA repository to conversational AI — you’re already paying the cost of not doing it. The job isn’t to manufacture a justification. It’s to name a cost your organization is already absorbing, 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 — and a business case for connecting your Sparx EA repository to a tool like Microsoft Copilot is really 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. Not designing architectures. Not writing governance policy. Not leading strategy. Just retrieving information and explaining it to whoever asked. In most organizations that’s 30 to 50 percent of an architect’s week.

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

Connecting the repository to AI doesn’t erase the cost — it moves it 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.

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 conversational access pulls 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 actually moves the strategy.

The comparison isn’t “should we buy a new tool?” It’s “should we 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 most organizations see a multiple-of-investment return inside the first year. By year two, when running costs are minimal, the recovered capacity keeps paying out against a near-flat cost base.

Name the risks explicitly

An honest business case names its risks — a case that ignores them reads like a sales pitch. There are three worth stating plainly.

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 — 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 isn’t that the integration fails — it’s 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. A read-only MCP server such as EA GraphLink can only answer well if your MDG Technology — the definition that translates the physical Sparx schema into the queryable GraphQL schema the AI sees — is clean and complete. If your metamodel is patchy or leans on implicit knowledge, the answers will be too. Be honest about 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 integration. They’re the difference between a case that looks like fantasy and one that looks like you know exactly what you’re implementing.

Lead with the comparison point

Here’s the framing that lands with leadership: this is not a new tool purchase. 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 unlocking that investment so more people can reach it without a specialist in the middle.

Framed that way, the ask stops looking like discretionary software spend and starts looking like infrastructure optimization — not added cost, but cost redistributed toward work that generates value.

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 isn’t aspirational. It just 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.