AI Integrations
Microsoft Fabric is not a BI tool. It is not the same as Power BI.
Fabric is the Microsoft data integration control plane: the enterprise platform that makes all organizational data (finance, operations, HR, supply chain, and now architecture) first-class citizens in a unified governance framework. Power BI is the BI/dashboard layer that sits on top of that data.
EA GraphLink’s MCP Server connects your Sparx EA repository to Microsoft Fabric’s data integration layer. This makes architecture data a governed data asset in the same way financial data, operational data, and HR data are. The same organization who manages finance data pipelines can now manage architecture data pipelines. The same governance layer that controls access to financial information controls access to architecture information.
The result: architecture becomes part of the enterprise data estate, not a silo.
Architecture data enters the enterprise data governance layer.
Your current state: Architecture data lives in EA. It’s modeled beautifully, governed carefully, but it’s isolated. It doesn’t flow to the data platforms where your organization makes data-driven decisions. Finance has a data platform. Operations has a data platform. HR has a data platform. Architecture is separate.
Your future state: Architecture data flows through Fabric alongside all other enterprise data. It’s subject to the same data quality standards. It’s governed by the same policies. It’s available for combination with other data assets to answer cross-domain questions. “What is the relationship between our technology debt and our customer experience outcomes?” isn’t a theoretical question: it’s a Fabric query that combines architecture data with operational metrics.
This is profound. Architecture stops being a specialist discipline with specialist data and becomes part of how the enterprise understands itself.
Fabric’s MCP interface (same one Copilot uses, but different purpose) allows external systems to contribute data to Fabric pipelines. EA GraphLink can be a data source in Fabric workflows. When an architect updates application metadata in EA, that change can flow through Fabric to any downstream system that depends on architecture data.
Conversely, data from Fabric can be pulled into your EA models for context. A Fabric query that combines architecture data with financial data can loop back to EA as a calculated field or metric.
This is your integration path. You already manage Fabric. You already govern data pipelines. EA integration becomes another data source that you manage using familiar Fabric patterns. Architecture data governance becomes part of enterprise data governance, not a separate function.
Architecture data is now visible in the same governance layer as other enterprise data. Portfolio investment decisions can be made with full data context. Cross-domain impact analysis becomes native: you can see architecture implications of financial decisions and financial implications of architecture decisions.
Your repository becomes a strategic asset. It’s not just used for architecture reviews. It’s a data source that feeds enterprise analytics and decision support. The value of your architecture modeling work multiplies.
Cross-Domain Analytics: Architecture + Finance
Combine your application portfolio data from EA with cost data from your financial systems via Fabric. Analyze: “Which applications have the highest cost-per-transaction? Which are approaching end-of-life?” These questions require joining architecture and financial data. Fabric makes this native.
Enterprise AI Agents Spanning Architecture and Business Data
With architecture data in Fabric, enterprise AI agents (Copilot or custom agents) can answer questions that span architecture and business domains simultaneously. “Show me high-cost applications that are on deprecated technologies and prioritize remediation by business impact.” This query joins cost data, technology data, and business criticality: only possible if all three data sources are in a unified data estate.
Architecture Data Governance Within Enterprise Data Governance
Rather than maintaining separate governance frameworks for architecture data and operational data, unify everything in Fabric’s governance layer. One data dictionary. One lineage tracking. One access control framework. One quality framework. This reduces governance overhead and ensures architecture data quality is maintained to the same standard as other data assets.
Automated Architecture Data Pipelines
Replace manual exports and scheduled reporting with automated Fabric pipelines. When data in your EA repository changes, trigger a Fabric pipeline that propagates those changes to downstream systems: data warehouses, analytics platforms, other enterprise applications. Architecture data becomes a living stream, not a periodic export.
Architecture as an Input to Enterprise Risk and Compliance
Combine architecture data (compliance coverage, standards adherence) with risk and compliance data from your risk management platform. Analyze: “Which applications have high compliance gaps? What’s the architectural remediation path?” This integrated view is only possible in a unified data estate.
Technology Roadmap Correlation with Financial Planning
Combine technology investment roadmap data from EA with financial planning and forecasting data from your ERP. Ensure that architecture investment plans align with financial capacity. Identify conflicts and gaps early.
| Role | Primary Benefit | Secondary Benefit |
|---|---|---|
| Data Architect | EA integration within familiar Fabric patterns | One governance layer for all enterprise data |
| IT Executive | Architecture visible in cross-domain analytics | Data-driven portfolio decisions with full context |
| Architecture Manager | Repository recognized as strategic data asset | Architecture investment justified by data value |
| Chief Data Officer | Complete enterprise data estate including architecture | Unified governance and quality standards |
| Finance/Business Intelligence | Architecture data available for cross-domain analytics | Better informed financial planning |
| Risk/Compliance Officer | Architecture compliance data integrated with compliance data | Holistic risk and compliance view |
| Business Analyst | Architecture context available in business analytics | Better informed business decision making |
Organizations invested in Fabric need to include architecture in the data estate.
If Fabric is your enterprise data platform, it should include all significant business data: and architecture is significant. Finance is in there. Operations is in there. HR is in there. Architecture should be there too. The value of Fabric increases as more of your data is integrated. Including architecture makes the data estate more complete.
Unified governance is more efficient than federated governance.
Maintaining separate governance frameworks for architecture and operational data is overhead. If Fabric is already your governance standard, extending it to architecture is simpler than maintaining a separate architecture governance layer.
Cross-domain analytics unlock insights that siloed data cannot.
The highest-value analytics questions often span multiple domains. “Which modernization projects have the highest ROI?” requires combining architecture data with financial data. “How does our technology debt affect our operational efficiency?” requires joining architecture and operational data. These questions are impossible if your data is siloed. Fabric makes them native.
Architecture investment becomes visible and justifiable.
When architecture data is isolated, stakeholders often don’t see the full business impact of architecture work. When architecture is part of the unified data estate and feeds cross-domain analytics, the business impact becomes visible. This justifies architecture investment.
Fabric investment is significant and must be justified by data integration needs.
Fabric capacity, licensing, and operations have costs. If your primary need is dashboards and reporting (which Power BI handles), Fabric is overkill. Fabric makes sense when you have multiple significant data sources that need to be unified for analytics and AI. If you don’t have that case, start with Power BI.
Only makes sense if Fabric is genuinely your enterprise data platform.
Some organizations buy Fabric and then don’t use it extensively. They use Power BI for dashboards. They keep operational data in separate systems. If that’s your situation, Fabric integration isn’t the right path. Validate that Fabric is genuinely central to your data strategy before pursuing integration.
Requires data integration expertise.
Power BI integration is largely self-service for Power BI developers. Fabric integration involves data pipelines, data governance, and integration patterns. It typically requires a data architect or data engineer to implement and maintain. Ensure you have the capability before committing.
Data quality demands are higher in a unified data estate.
When architecture data is isolated in EA, data quality issues are contained. When architecture data is in Fabric alongside critical business data, data quality issues become organizational problems. Before integrating into Fabric, ensure your architecture data governance is mature enough to sustain the scrutiny.
Governance decisions must be made before integration.
Who can access architecture data through Fabric? What data is too sensitive to integrate? How do you handle changes to data schema? These governance questions must be answered before you start building Fabric pipelines. Governance work takes time. Factor it into your planning.
EA GraphLink with MCP Server enabled. The MCP interface is part of standard EA GraphLink deployment. Your Sparx Systems account manager confirms it’s active.
Microsoft Fabric license and capacity. Fabric requires Fabric Capacity license (not included with standard Power BI licenses). Capacity costs depend on your scale and performance requirements. This is a licensing conversation with your Microsoft account team.
Data integration expertise. Unlike Power BI, which can be self-service, Fabric integration requires data engineers or data architects who understand Fabric pipelines, data governance, and integration patterns. Ensure you have the capability before starting.
MDG Technology assessed for data estate readiness. Your MDG Technology defines how EA data maps to external systems. Before integrating with Fabric, ensure your MDG is clean, well-documented, and aligned with enterprise data standards. This is part of Discover: have your MDG assessed before committing to Fabric integration.
Data Governance Framework. How does architecture data governance interact with enterprise data governance? Who approves schema changes? How do you handle data quality issues? These governance questions must be answered before Fabric pipelines are live. Allocate time for governance design.
Security and Access Control Design. How do you enforce row-level security in Fabric for architecture data? How do business units access only their relevant architecture data? Design the access control framework before integration.
Start with cross-domain analytics you want to enable.
What questions require combining architecture data with other enterprise data? How often are these questions asked? How long does it take to answer them manually? What’s the business value of faster answers?
Estimate analytics acceleration.
Queries that currently take 2-4 weeks (manual data combination, custom reporting) can be answered in minutes once architecture data is in Fabric. Estimate how many such queries you run annually and the time saved.
Calculate analyst and engineer time freed.
Analysts spend time building custom reports combining architecture and operational data. Engineers maintain custom ETL jobs to move architecture data to analytics platforms. Fabric pipelines automate both.
Formula:
(Analyst hours/month on architecture reporting × 12 months × hourly rate) +
(Engineer hours/month maintaining architecture data pipelines × 12 months × hourly rate) +
(Business value from faster cross-domain analytics)
Example:
20 analyst hours/month × 12 months × $100/hour = $24,000
8 engineer hours/month × 12 months × $150/hour = $14,400
Business value from improved cross-domain decisions (time to insight + decision quality) = $50,000+ conservatively
Total annual value: $88,400+
Factor in Fabric licensing and maintenance:
Fabric capacity: $2,000-5,000/month depending on scale = $24K-60K/year
Data integration engineering support: 20-30% of one engineer = $20K-30K/year
Total annual cost: $44K-90K
Net ROI varies by scale, but for organizations with significant cross-domain analytics needs, integration typically pays for itself within 12-18 months.
Power BI (For Dashboards and Reporting)
Power BI handles dashboards and reporting. If your primary need is executive dashboards and self-service reporting, Power BI is more cost-effective than Fabric. Fabric is for data integration and unified data governance. Power BI sits on top of that if needed. These are complementary, not competitive. Many organizations use both: Fabric for data integration and governance, Power BI for dashboards and reporting.
Dedicated Data Warehouse (Synapse, Snowflake, BigQuery)
Organizations with mature data warehouses often use those as their data integration layer. EA data can be integrated into an existing data warehouse. Pros: you keep your current platform. Cons: you don’t get Fabric’s integrated experience or unified governance. If you already have a mature data warehouse, extending it might be more efficient than adopting Fabric.
Kernaro Intelligence Layer
Kernaro provides conversational access to EA data without Fabric dependency. Pros: lower cost, architecture-specific design. Cons: doesn’t integrate architecture data into enterprise data governance. If your need is conversational AI access without data estate integration, Kernaro is a simpler alternative.
Manual Data Integration
Architects manually prepare architecture data summaries for inclusion in data warehouse exports. Pros: no new systems to adopt. Cons: labor-intensive, error-prone, doesn’t scale. This is the status quo for many organizations. It works until you need real-time data or frequent updates.
Q: Do we need both Fabric and Power BI?
A: They serve different purposes. Fabric is the data integration and governance layer. Power BI is the dashboarding and reporting layer. Many organizations use both: Fabric handles data integration, Power BI handles user-facing dashboards. You could use Fabric with Tableau or other BI tools. But if Power BI is your BI standard, it pairs naturally with Fabric.
Q: How much of our EA repository needs to integrate with Fabric?
A: Start with application portfolio data (applications, technology components, business capabilities). This is usually the highest-value dataset. You can add more (architecture decisions, roadmaps, standards) as governance matures and usage patterns establish. Integration is progressive, not all-or-nothing.
Q: What about sensitive architecture data?
A: Fabric supports row-level security and data masking. Sensitive data (infrastructure details, security patterns, threat models) can be excluded from Fabric integration or masked for specific user groups. Design your data governance framework to handle this. This is a conversation with your data governance team, not a technical blocker.
Q: How do we handle schema changes in EA?
A: Your MDG Technology defines the schema EA exposes to Fabric. Changes to the MDG can affect Fabric pipelines. Establish a change control process: MDG changes go through architecture and data governance review. Major structural changes may require Fabric pipeline adjustments. This is one reason governance design upfront is important.
Q: Can Fabric access real-time EA data?
A: Refresh frequency is configurable. Real-time (minute-level or second-level) updates are possible but typically unnecessary. Most organizations use 4-24 hour refresh cycles. Discuss frequency requirements as part of Fabric integration planning.
Q: How does this work if EA is on-premises?
A: EA GraphLink can connect to on-premises EA repositories and expose MCP interfaces accessible to Fabric. Network and firewall configuration must allow traffic from Fabric to your EA GraphLink instance. This is a security and infrastructure conversation, but it’s fully supported.
Q: What if we don’t have a CDO or data governance function?
A: Fabric integration requires someone who understands data governance to own the architecture data governance aspects. If you don’t have this function, you may need to establish it before pursuing Fabric integration. Alternatively, engage a consultant to design and bootstrap governance. This isn’t a blocker: many organizations add governance functions as part of data platform maturation.
Q: Can we use Fabric without Copilot?
A: Yes. Fabric is primarily a data integration and governance platform. Copilot integration (enterprise AI agents accessing Fabric data) is an optional feature. You can integrate architecture data into Fabric for analytics and pipeline purposes without deploying Copilot.
Q: What’s the difference between Fabric MCP and Power BI GraphQL?
A: Power BI uses GraphQL (BI dashboard interface). Fabric uses MCP (data integration control plane interface). Same EA GraphLink instance serves both. Different downstream use cases: GraphQL feeds dashboards, MCP feeds data pipelines and AI agents. Both can be deployed from a single Connect engagement.
Fabric integration positions architecture as a first-class citizen in your enterprise data estate. Architecture data enters the same governance, quality, and integration frameworks as financial and operational data.
This is not a first step. If you haven’t deployed EA GraphLink and assessed your repository readiness, start with Discover. If you’re not already invested in Fabric, start with Power BI for dashboards.
But if Fabric is genuinely your enterprise data platform and you need to include architecture data in your unified governance layer:
[Start Your Fabric Integration Planning]
Or, if you want to understand how Fabric fits alongside Power BI and Copilot:
[Talk to Us About Your Data Strategy]
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.