AI Integrations
EA GraphLink’s MCP Server connects your Sparx EA repository to Microsoft Copilot inside M365. When a business stakeholder in a Teams call asks “What’s the architecture impact of this proposed change?” they get an answer from live repository data, surfaced directly in the Teams window. Same with Outlook, Word, PowerPoint. The stakeholder never logs into EA. They never visit a separate dashboard. Architecture data flows directly into the platforms where M365 users already work.
This is possible because Microsoft Copilot uses the MCP (Model Context Protocol) interface as its integration layer. EA GraphLink exposes an MCP Server. The MCP connector bridges the two. Copilot gains the ability to query your repository. Your business stakeholders gain the ability to ask architecture questions in the tools where they spend their time.
The key insight: business decisions happen in M365, not in EA. Making architecture data available where decisions happen removes the friction that prevents stakeholders from seeking architecture context.
The architectural information barrier disappears.
Your current state: A project manager has a question about application architecture. She opens a Teams chat and messages an architect. The architect is in meetings. Reply comes two hours later. The project manager reads it, has more questions, asks in chat. Another round trip. By the time architecture context is available, the stakeholder has moved on or made the decision without full information.
Your future state: The same project manager is in a Teams call with stakeholders. A question about architecture comes up. She types into Copilot right there in Teams: “What’s our strategy for sunsetting that application?” Copilot queries your EA repository and replies with current architecture information. The decision-maker has context in real time. No email. No delays. No friction.
This changes the decision environment fundamentally. Stakeholders can seek architecture input at the moment they need it, in the platform they’re already using. Architects are no longer gatekeepers of information: they’re advisors providing expertise on top of accessible data.
Traditional model: Stakeholder → email/message → architect → email/message → stakeholder (delay, asynchrony, information loss)
New model: Stakeholder → Copilot in M365 → EA repository → Copilot → stakeholder (synchronous, contextual, authoritative)
Architects move from being information distributors to being insight developers. The data is available. The question is what to do with it.
No new tools. No logins. No specialized EA training. Architecture data surfaces in the platforms you already use: Teams, Outlook, Word. Ask your question in natural language. Get an answer from your authoritative architecture repository. The barrier to accessing architecture context drops to nearly zero.
Better architectural visibility in business decisions. Stakeholders who would normally skip architecture input because it was too friction-heavy can now access it easily. This lifts the quality of decisions. It also surfaces architectural issues that would otherwise remain hidden until they became operational problems.
Architecture insight reaches further. Your team doesn’t have to wait for formal requests or scheduled reviews. Architecture data is available on demand across the organization. This means architecture can influence more decisions at an earlier stage.
Real-Time Architecture Impact Assessment in Project Teams
A project team in Teams is discussing a technology change for a critical business system. Someone asks: “What applications does this technology support? What’s the timeline to deprecate it across our portfolio?” A project member types the question into Copilot. Copilot queries the repository. The answer surfaces in the Teams window: a summary of affected applications, their criticality, and timeline recommendations. The discussion moves forward informed.
Executive Decision Support in Natural Language
A VP is reviewing a proposal to outsource an entire application suite. She’s in Outlook reviewing the proposal document. A question surfaces: “What’s our application modernization roadmap for this domain?” She opens Copilot in Outlook, asks the question. Copilot provides current information from the repository about planned modernization work, existing technical debt, and alignment with business capability priorities. She has context for her decision without scheduling an architecture review.
Architecture Context in Word Documents
A business analyst is writing a business case for a new initiative. She needs to understand the current architecture of the domain she’s proposing changes to. Rather than email-requesting a summary, she opens Copilot in Word and asks: “What’s the current technology landscape for our customer-facing applications?” Copilot provides a summary of applications, their technology stacks, maturity levels, and architectural concerns. She incorporates this context into her business case.
Architecture-Aware PowerPoint Content Generation
A presenter is preparing an executive briefing on digital transformation. She opens PowerPoint, uses Copilot to generate slides based on her notes. She can ask: “Based on our current application portfolio and architecture strategy, what are our modernization priorities?” Copilot synthesizes information from the repository and generates talking points and visualizations. She reviews, edits, and presents with architecture backing behind the narrative.
Portfolio Compliance Questions During Planning
During quarterly planning, a business unit leader asks: “Which of our applications are compliant with our current architecture standards? Where are our gaps?” A team member asks Copilot the question in Teams. Copilot queries the repository and provides a compliance summary for that business unit, including applications that need work and their remediation status. The planning conversation has data.
Architectural Trade-Off Exploration
A technology selection meeting is underway. There’s debate about which database approach makes sense for a new system. Someone asks: “What’s our current database strategy? What precedents do we have?” Copilot in Teams provides information about existing database technologies, their usage patterns, and any architectural preferences from your repository. The team can make a more informed choice.
| Role | Primary Benefit | Secondary Benefit |
|---|---|---|
| Business Stakeholder | Architecture context on-demand in familiar platforms | No special training, no tool learning curve |
| IT Executive | Architecture visibility in real-time business decisions | Data-driven decision quality improvement |
| Architecture Manager | Architects freed from ad-hoc information requests | Architecture influence reaches more decisions |
| Project Manager | Real-time architecture context during project work | No delays waiting for architect responses |
| Product Owner | Technology and capability alignment information available | Better informed product roadmap decisions |
| Finance/Budget Owner | Architecture context during investment discussions | Rationale for architecture spending visible |
| Risk/Compliance Officer | Compliance and standards coverage available on demand | Risk visibility across portfolio |
Decision quality improves when decisions have architectural context.
Most business decisions have architecture implications. When stakeholders can access architecture information at the moment they need it, they make better decisions. This doesn’t require them to understand architecture deeply: it just requires the information to be available. Copilot makes it available.
M365 is already the decision platform.
Business stakeholders already spend significant time in Teams, Outlook, and Word. They don’t check a separate architecture tool. They don’t attend formal architecture reviews for every decision. They make decisions in the platforms they use for work. Making architecture data available in those platforms aligns the information supply to where decisions happen.
The adoption barrier drops to zero.
Power BI requires Power BI literacy. Prolaborate requires portal navigation. Separate AI tools require logins and training. Copilot in Teams requires nothing. If you use Teams (which you do), you can ask Copilot a question. There’s no training, no new tools, no adoption challenge. Your entire M365 user base is immediately capable of accessing architecture information.
Asynchronous communication improves with context.
Email and chat don’t work well for architecture questions. You need synchronous conversation to explore nuances, question assumptions, and refine understanding. By putting architecture data directly in the decision-making platforms, you make it possible for synchronous conversation to happen in context. The question and answer can be in the same thread, with data available to both parties.
Your repository becomes a business asset, not a specialist tool.
Right now, most of your organization doesn’t know what’s in your EA repository. They don’t have access. They don’t understand how to use it. Copilot integration makes the repository a business asset that serves anyone who works in M365. The downstream value of your architecture modeling work increases dramatically.
M365 Copilot licensing cost is significant.
M365 Copilot costs $30/user/month on top of your existing M365 licenses. For a 1,000-person organization where 200 people would regularly use Copilot for architecture questions, that’s $72,000 annually just for licensing (200 users × $30/month × 12 months). This is a real cost. For some organizations, it’s justified by the decision improvement and efficiency gains. For others, it’s not. Calculate your expected user base and validate the ROI before committing.
Data governance complexity increases.
Your EA repository data leaves your on-premises environment and flows through Microsoft’s cloud infrastructure to Copilot. For regulated industries (healthcare, finance, government), this creates data residency and compliance questions that may require legal or compliance review. This isn’t a blocker: many regulated organizations use Copilot successfully: but it’s a governance conversation you need to have upfront.
Data quality becomes highly visible.
Power BI dashboards are consumed by people who expect dashboards to be well-designed. EA dashboards in Power BI typically look polished. Copilot responses are conversational. Bad data becomes obviously bad when an AI assistant surfaces it. If your repository contains outdated, incomplete, or conflicting information, Copilot will expose that relentlessly. You’ll immediately know where your data quality is weak.
This isn’t a reason to avoid the integration: it’s actually valuable feedback. But you need to be prepared to invest in repository governance to maintain quality as Copilot usage scales. It’s easier to ignore data quality issues when they’re hidden in EA. Harder when they’re surfaced conversationally to business stakeholders.
Stakeholder expectations shift rapidly.
Once Copilot access is available, business stakeholders expect answers immediately. If Copilot says something your architects think is wrong, stakeholders believe Copilot. This creates pressure to ensure the repository is consistently accurate and trustworthy. It’s the right pressure: it drives better architecture practices: but it’s pressure nonetheless.
You’re dependent on M365 uptime.
If Microsoft Copilot is down, stakeholders can’t access architecture data through that channel. This is Microsoft’s problem to solve (and they typically solve it well), but it’s a dependency. For mission-critical architecture questions, you might want a backup channel (dashboard, browser-based tool, human architect).
EA GraphLink with MCP Server enabled. The MCP interface is part of standard EA GraphLink deployment. Your Sparx Systems account manager confirms the MCP Server is active and accessible.
M365 Copilot license. This is $30/user/month per Copilot user. Factor this into your budget. Determine how many users will actively use Copilot for architecture questions. Start with pilot pricing (e.g., 20 users during pilot) and expand based on adoption and ROI.
MCP Connector Configuration. The connector links Copilot to your EA GraphLink MCP Server. Configuration requires specifying your EA GraphLink endpoint and authentication credentials. Your Sparx Services team handles this as part of Connect.
MDG Technology Strong Enough to Trust at Scale. Copilot answers are only as good as your repository data. Before deploying Copilot, your MDG Technology and repository governance must be assessed for quality. Discover evaluates this. If gaps exist, address them before Copilot goes live. You don’t want business stakeholders receiving bad information from an AI assistant.
Data Governance Aligned to Copilot Usage. Who can access what? Does an application owner see only their applications’ data? Does a business unit leader see their business unit’s portfolio? Establish this governance upfront. This is an organizational decision, but it affects how the MCP connector is configured.
Stakeholder Adoption and Change Management. This integration changes how people access architecture information. Some architects may worry about losing gatekeeping authority. Some business stakeholders may not know how to phrase questions for an AI assistant. Plan for adoption, training, and change management. This isn’t a technical deployment: it’s a practice shift.
Start with stakeholder time spent on architecture communication.
Survey your organization. How much time do stakeholders spend waiting for architecture answers? How many emails request architecture context? How many meetings happen partly to get architectural alignment?
Estimate self-service adoption.
If architecture data is available on-demand in Copilot, what percentage of routine architecture requests could be answered by stakeholders themselves rather than requiring architect involvement? Estimate this conservatively: 30-50% is typical.
Calculate avoided coordination costs.
Formula:
(Stakeholder communication cycles per week × stakeholder hours per cycle × number of stakeholders × 52 weeks × adoption rate × stakeholder hourly rate) +
(Architect hours freed from answering requests × hourly rate × 12 months)
Example:
15 architecture requests/week × 2 hours/request × 200 potential requesters × 50 weeks × 40% self-service adoption × $100/hour = $1.2M annual value
Plus:
Architects freed from request handling = 5 hours/week × 50 weeks × $150/hour = $37,500
Total annual value: ~$1.24M
Factor in M365 Copilot licensing cost:
200 concurrent users × $30/month × 12 months = $72,000
Net ROI:
$1.24M - $72,000 = $1.17M annual net benefit (after licensing cost)
Payback period: <1 month
This is conservative: it doesn’t account for decision quality improvement or faster time-to-decision. For organizations where business decisions involve significant capital allocation, improved decision quality can dwarf the other ROI components.
Kernaro AI Hub
Kernaro is Sparx Systems’ purpose-built architecture intelligence platform. It provides conversational access to your repository without requiring M365 Copilot licensing. Pros: lower licensing cost, architecture-specific design, no Microsoft dependency. Cons: requires navigation to a separate tool (less frictionless than Copilot in Teams), smaller installed base means less integration ecosystem. Kernaro is an excellent choice if you want dedicated architecture intelligence without M365 dependency.
Salesforce Agentforce
For Salesforce-centric organizations, Agentforce is the Copilot equivalent. It uses the same EA GraphLink MCP interface. Same benefits, different platform. Evaluate Agentforce if Salesforce is your primary business platform.
Prolaborate (Browser-Based EA Reporting)
Prolaborate provides self-service dashboards and reporting without enterprise BI platform dependency. Pros: lower cost, no licensing per user, browser-based access. Cons: less conversational than Copilot, requires portal navigation, not integrated into M365. Prolaborate is a good option if you need dashboards without Copilot dependency.
Manual Copilot Use Without EA Integration
Business stakeholders can ask Copilot architecture questions using general knowledge. Pros: no integration required. Cons: responses lack your specific context and data, potentially misleading. Not a real alternative: the value of Copilot integration is connecting it to your authoritative data.
Trained Human Architects in Lean Response Mode
Staff dedicated architects to respond quickly to ad-hoc requests. Pros: high-quality, nuanced responses. Cons: expensive, doesn’t scale, limits what architects can contribute strategically. This is the status quo for many organizations. Copilot doesn’t replace architects: it makes them more effective by handling routine questions and freeing time for deep work.
Q: Can Copilot access sensitive architecture data?
A: Yes, but you need to control it. Your data governance defines what data flows to Copilot. You can restrict sensitive information (e.g., infrastructure details, security patterns) from being exposed to Copilot. Organizational boundaries can be enforced: a business unit leader’s Copilot queries only see their business unit’s data. This requires coordination between your EA governance and Microsoft Copilot configuration, but it’s fully supported.
Q: What training do business stakeholders need?
A: Very little. If they use Teams and Outlook, they already know how to use Copilot. The main training is architecture-domain-specific: “Here’s what you can ask, here’s what kinds of answers to expect, here’s how to interpret the results.” Budget a 30-minute overview session, not a full training program.
Q: How accurate are Copilot’s answers?
A: Only as accurate as your repository. Copilot returns information from your EA data exactly as it exists. If your data is current and well-governed, Copilot answers are reliable. If your data contains errors or is outdated, Copilot will surface those errors. This is actually a feature: it keeps pressure on data quality. But you need strong governance before scaling Copilot usage.
Q: Can we control what Copilot is allowed to answer?
A: Partially. You can exclude certain data from flowing to Copilot. You can set governance rules about who can ask what questions. You can’t tell Copilot “don’t answer questions about infrastructure”: that’s a system-level constraint that would require different tooling. But you can prevent sensitive data from reaching Copilot through data governance.
Q: What happens if the MCP connector goes down?
A: Copilot reverts to general knowledge. Business stakeholders can still use Copilot, but they won’t have access to your specific repository data. The connector going down is rare (it’s just a network link), but it’s a dependency to understand. Most organizations consider this acceptable risk.
Q: Can we use Copilot for architecture documentation generation?
A: Yes. A stakeholder can ask Copilot to “Generate a summary of our application modernization strategy.” Copilot synthesizes your repository data into narrative documentation. This can seed business case documents, strategy presentations, and policy statements. The output requires architect review, but it accelerates documentation from scratch.
Q: Will this work with our current EA installation, or do we need upgrades?
A: You need EA GraphLink with MCP Server enabled. This is a standard component of modern EA GraphLink deployments. If your EA GraphLink is recent (last 2-3 years), MCP Server is already available. If it’s older, you may need an upgrade. Your Sparx Systems account manager can confirm your version status.
Q: How much repository data flows to Microsoft’s cloud?
A: Only what Copilot needs to answer the question asked. If a stakeholder asks “What applications support this business capability?” Copilot queries the repository via the MCP connector, receives the relevant data, and generates a response. The data flows from your repository through Microsoft’s infrastructure and back. No data is stored in Microsoft’s cloud: it’s in-flight queries only. For organizations with data residency concerns, confirm this model meets your requirements before deploying.
Q: Can we audit who asked what questions?
A: Yes. Microsoft Copilot activity is logged. You can audit who asked what questions and what Copilot returned. This is useful for governance and understanding usage patterns. Configure audit logging as part of deployment.
Copilot integration removes the friction that prevents business stakeholders from seeking architecture context. Architecture information flows to where decisions happen.
The journey starts with assessing your readiness: repository quality, governance structure, M365 licensing. If you haven’t completed a Discover assessment, that’s the first step.
If you’ve assessed your foundation and you’re ready to deploy Copilot integration:
[Start Your Connect Engagement]
Questions about whether Copilot is right for your organization?
[Let’s Discuss Your AI Strategy]
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.