The case is already there. You just need to name it.
You don’t need to invent a business case for connecting your EA repository to conversational AI. The case exists. You’re living the cost right now.
Every time a delivery lead emails the architecture team asking “do we have any existing integrations to Salesforce?” they’re asking a question that should take 15 seconds to answer. Instead it takes three weeks, because the answer lives in a specialized tool that requires a specialist intermediary.
Multiply that by the number of questions your architects answer every week. By the number of stakeholders who ask variations of the same question. By the number of times delivery teams miss decision deadlines while waiting for architecture context.
Then add the people who stop asking altogether, because the turnaround is too slow. They make decisions without the architecture information they needed, and you discover the consequences months later.
That’s what you’re paying for today. The business case for Connect is the case for paying less to get more.
Quantifying the cost of the current state
Start with architect time.
Pull a sample week from your EA team’s calendar. Count how many hours are spent answering questions that could be answered by querying the repository directly. Not designing new architectures. Not writing governance policies. Not leading strategy conversations. Just pulling information and explaining it to people.
In most organizations, it’s between 30 and 50 percent of an architect’s time.
Multiply that by your average loaded cost per architect (salary + benefits + overhead). Then multiply that by 52 weeks.
That’s the cost you’re paying today just to be slow at answering questions you already have data about.
Add a second number: the cost of bad decisions made without architecture context. This is harder to quantify precisely, but it’s real. When a delivery team proceeds without checking dependencies, integrates systems in ways that create technical debt, or duplicates functionality that already exists elsewhere, the rework costs are typically 3-5 times the original development cost. Even one bad decision per quarter per team makes this number substantial.
Add a third: the cost of waiting. Decisions get delayed while architecture context is assembled. Market windows close. Quarterly planning extends into the next quarter. Strategy conversations stall because half the room is still gathering data.
Most architecture leaders can put real numbers on at least the first two. When you add them up, you typically get a number that looks like $500K to $2M annually, depending on organization size and complexity.
That’s your baseline. That’s what the current state costs you.
Framing the ROI
Connect doesn’t eliminate the cost. It redistributes it.
The time your architects currently spend answering questions becomes available for design work, governance development, and strategic architecture. The architects don’t disappear. Their work gets more valuable.
This is a loaded cost calculation. If an architect currently spends 40 hours a week and 50% of that time is answering questions, then 20 hours a week is discretionary architecture work. If Connect brings the question-answering time down to 10 hours a week, you’ve recovered 10 hours of capacity.
At a $150K loaded cost, that’s roughly $150 per hour per architect. Recover 10 hours per week across a team of five architects, and you’re looking at $39,000 per month in recovered capacity, or roughly $470,000 annually. That’s a real number. That’s architect time you can redeploy to work that drives strategy.
Add a second ROI lever: stakeholder decision quality. When architecture context is instantly available instead of three-week-delayed, stakeholders make better decisions. Risk is surfaced earlier. Redundancy is avoided. Integration points are discovered before they become surprises. The compounding value of better-informed decision-making over a year is substantial and typically conservative to measure.
Then add the third: velocity. Decisions that currently take four weeks to make with architecture context take one week when that context is instantly available. Over a year, accelerating decision cycles has measurable impact on delivery speed and market responsiveness.
When you add these up, recovered architect capacity, decision quality improvement, and decision velocity, most organizations see a 2.5-4x return on the implementation cost within the first year. By year two, when the running costs are minimal, the return is essentially unlimited.
What risks to name explicitly
An honest business case includes risk.
The first risk is data governance. If anyone can ask questions of your EA repository, then accuracy matters more. Your current state tolerates some level of staleness because only specialists ask the questions. If business stakeholders are asking directly, bad data produces bad decisions at speed. Before implementing Connect, you need a governance model that ensures repository data stays current and accurate. This is solvable but requires investment and discipline.
The second risk is query accuracy. AI systems hallucinate. They can generate confident-sounding answers that are wrong. You need a clear governance model for what kinds of questions Connect can answer reliably (pure factual queries: “what systems integrate with this one?” usually work) versus what kinds require architect judgment (“how should we integrate with this one?” needs human reasoning). The risk isn’t that Connect fails. It’s that stakeholders ask it the wrong questions and trust answers they shouldn’t.
The third risk is MDG dependency. This is the hidden one. EA GraphLink’s ability to answer questions depends on the quality of your Meta Data Group (MDG) definition. If your technology metamodel is incomplete, inconsistent, or relies on implicit knowledge rather than explicit data, then Connect will produce incomplete or unreliable answers. Before you invest in Connect, you need to be honest about whether your MDG is clean enough to support automated querying. If it isn’t, you need to budget for MDG work first.
These aren’t reasons to skip Connect. They’re reasons to name what you’re actually implementing. A business case that ignores risks looks like fantasy. A business case that names risks looks like you know what you’re doing.
The comparison point
Here’s what to emphasize to leadership: this isn’t a new tool purchase.
You’ve already invested in a Sparx EA repository. You’ve already spent the time and money to model your architecture. You already have the data. The cost of Connect is the cost of unlocking that investment so more people can access it without specialist intermediaries.
The comparison isn’t “should we buy a new tool?” It’s “should we use the tool we already bought more effectively?”
When you frame it that way, the business case looks less like discretionary software spending and more like infrastructure optimization. You’re not adding cost. You’re redistributing cost toward value-generating work.
A business case structure you can adapt
Use this structure to build your internal case:
Current state cost. Architect time spent answering questions (express as annual loaded cost). Bad decisions made without architecture context (express as estimated annual rework cost). Decision delays and their business impact.
Future state benefit. Recovered architect capacity (express as annual hours or loaded cost). Improved decision quality (express as reduced rework or faster time-to-value). Improved decision velocity (express as reduced decision cycle time and its business impact).
Implementation investment. License and implementation costs for Connect. MDG remediation if needed. Governance model development.
Risks and mitigations. Data governance (mitigation: establish a governance model). Query accuracy (mitigation: define appropriate use cases). MDG quality (mitigation: audit current MDG, budget for cleanup if needed).
Timeline. Year one: implement Connect, capture immediate architect capacity benefits. Year two and beyond: realize decision velocity benefits and compounding value from better-informed stakeholders.
Decision. Does the recovered capacity and decision quality improvement justify the implementation investment?
In most organizations where the repository is mature and the MDG is reasonably clean, the answer is yes. The case you’re building isn’t aspirational. It’s just describing what the numbers already show.
