How to Build Power BI Dashboards from Your Sparx EA Repository

Published: 2026-04-18 Category: How To Offering relevance: Connect

Direct Answer

Building Power BI dashboards from Sparx EA requires EA GraphLink Interface A (GraphQL) to be deployed first: this is the prerequisite that exposes the repository as a queryable data source. Once EA GraphLink is in place, the process is: understand the GraphQL schema, connect Power BI Desktop to the GraphQL endpoint, write the queries for your key metrics, build the Power BI data model from the query results, create the visualisations that matter for your stakeholders, publish to Power BI Service, and optionally connect Copilot for natural-language querying. This guide is written for architects and BI architects who have EA GraphLink deployed and want to build meaningful dashboards. If EA GraphLink is not yet deployed, the starting point is the Connect engagement.

Key Takeaways

EA GraphLink Interface A (GraphQL) is the prerequisite: this guide assumes it is deployed and accessible.
The GraphQL schema is MDG-aware: element types, tagged value dimensions, and relationship types are first-class query objects.
Power BI connects via the GraphQL connector in Power Query: configure once, refresh on schedule.
Build a star schema data model in Power BI: element tables as fact tables; tagged value enumerations as dimension tables.
Core dashboards: Application Portfolio Heat Map, Technology Lifecycle Timeline, Capability Coverage, Governance Health.
Publish to Power BI Service for organization-wide access; Copilot integration enables natural-language queries on the dashboards.
MDG quality determines dashboard accuracy: poor governance produces misleading dashboards.

Step 1: Understand the EA GraphQL Schema

Before writing a single Power BI query, understand the data model that EA GraphLink exposes. This shapes every subsequent design decision.

Accessing the schema:

EA GraphLink Interface A includes a GraphQL introspection endpoint and (if configured) a GraphQL playground interface. Use either to explore the schema:

Navigate to the EA GraphLink GraphQL endpoint in a browser (or use a GraphQL client like Insomnia or Postman)
Run the introspection query: { __schema { types { name fields { name type { name } } } } }
Review the available types

What the schema typically includes:

Element types: Each ArchiMate element type (and custom MDG stereotype) is a distinct type in the GraphQL schema:

ApplicationComponent: with fields for name, notes, and all tagged values
Capability: with fields for name, notes, MaturityScore, StrategicImportance tagged values
BusinessProcess, TechnologyNode, DataObject, etc.

Tagged value fields: Each tagged value defined in the MDG appears as a field on its stereotype type in the schema:

ApplicationComponent.LifecycleStatus (string: the enumeration value)
ApplicationComponent.BusinessOwner (string)
ApplicationComponent.BusinessDomain (string)

Relationship types: Relationships are accessible as nested objects or as separate query types:

ApplicationComponent.realisedCapabilities: Capabilities linked to this Application Component via Realisation relationships
Capability.realisingApplications: Application Components that realize this Capability

Package structure: Elements can be queried with their package path, enabling package-scoped queries.

Write down the key query patterns you will need for each dashboard you plan to build. Having the query design on paper before opening Power BI saves significant iteration time.

Step 2: Connect Power BI Desktop to the GraphQL Endpoint

Required: Power BI Desktop (latest version). The GraphQL connector is available in Power Query as of early 2025.

Connection steps:

Open Power BI Desktop → Get Data → More → Other → GraphQL (Beta)
Enter the GraphQL endpoint URL: https://[your-pcs-host]/eagraphlink/graphql
Authentication: select API Key → enter the EA GraphLink Interface A API key
Click Connect

Power BI’s Query Editor (Power Query) opens with a GraphQL query editor. This is where you write queries for each data set you want in your Power BI model.

First test query:

Test with a simple query to confirm connectivity: “graphql query { applicationComponents { name lifeCycleStatus businessOwner businessDomain } } “

If the query returns a result set of Application Component elements with their tagged values, the connection is working. If it returns an error, check the endpoint URL, API key, and network access.

Step 3: Write GraphQL Queries for Your Key Metrics

Design one query per table in your Power BI data model. Each query should retrieve one element type with its relevant fields.

Query 1: Application Components (the portfolio fact table) “graphql query { applicationComponents { id name lifecycleStatus businessOwner technicalOwner businessDomain businessCriticality technicalHealth annualRunCost applicationTyp packagePath } } “

Query 2: Business Capabilities “graphql query { capabilities { id name businessDomain maturityScore strategicImportance applicationCoverage businessOwner packagePath } } “

Query 3: Application-to-Capability Relationships “graphql query { realisationRelationships( sourceType: "ApplicationComponent", targetType: "Capability" ) { sourceId sourceName targetId targetName } } “

Query 4: Technology Nodes “graphql query { technologyNodes { id name vendor lifecycleStatus endOfLifeDate technologyTier businessDomain } } “

Query 5: Architecture Decisions “graphql query { architectureDecisions { id adrId name status decisionDate decisionAuthority businessDomain } } “

Name each query clearly in Power Query: the query name becomes the table name in the Power BI data model.

Step 4: Build the Power BI Data Model

With the query results loaded into Power BI, build a star schema data model connecting the tables:

Relationships to create in Power BI Model View:

ApplicationComponents to AppToCapability (Relationships table):

From: ApplicationComponents[id]
To: AppToCapability[sourceId]
Cardinality: One-to-many (one application, many relationship rows)

AppToCapability to Capabilities:

From: AppToCapability[targetId]
To: Capabilities[id]
Cardinality: Many-to-one (many relationship rows, one capability)

TechnologyNodes to ApplicationComponents (if hosting relationships are included):

Via a deployment relationship table if available from GraphQL

Calculated measures (DAX) to create:

“`dax // Count of applications by lifecycle status EndofLife_Count = CALCULATE( COUNT(ApplicationComponents[id]), ApplicationComponents[lifecycleStatus] = “End-of-Life” )

// Average capability maturity score AvgCapabilityMaturity = AVERAGE(Capabilities[maturityScore])

// Percentage of applications with documented business owner OwnerCoveragePct = DIVIDE( CALCULATE( COUNT(ApplicationComponents[id]), ApplicationComponents[businessOwner] <> “” ), COUNT(ApplicationComponents[id]) )

// Application count per capability (for coverage analysis) AppsPerCapability = CALCULATE(COUNTROWS(AppToCapability), RELATEDTABLE(AppToCapability)) “`

Step 5: Create Key Visualisations

Dashboard 1: Application Portfolio Heat Map

Visual type: Matrix (cross-tab)

Rows: Business Domain (from BusinessDomain field)
Columns: Lifecycle Status (from LifecycleStatus field)
Values: Count of Applications
Conditional formatting: apply color scale (red for high counts in End-of-Life; green for high counts in Active)

This creates the classic portfolio heat map showing how applications are distributed across domains and lifecycle stages.

Dashboard 2: Technology Lifecycle Timeline

Visual type: Gantt chart (use a custom visual from AppSource) or Bar chart

Y-axis: Technology node name
X-axis: End-of-Life date
Color by: Lifecycle Status
Filter: Show only nodes with EndOfLifeDate within 24 months

This shows which technology components are reaching vendor support end dates, enabling proactive remediation planning.

Dashboard 3: Capability Coverage Analysis

Visual type: Matrix or heatmap

Rows: Business Capability name (from Capabilities table)
Values: Application Coverage (tagged value from Capabilities), Count of Supporting Applications (from relationship data)
Conditional formatting: Red = ApplicationCoverage = “None”; Yellow = “Partial”; Green = “Full”

Filters: by Business Domain, Strategic Importance

Dashboard 4: Architecture Governance Health

Visual type: Card visuals + Bar charts

Owner Coverage %: percentage of Application Components with BusinessOwner populated
Lifecycle Status Coverage %: percentage with LifecycleStatus populated
Average Capability Maturity by Domain: bar chart with Domain on x-axis, average maturity on y-axis
Decision Register Status: pie/donut chart of ADRs by status (Proposed/Accepted/Deprecated/Superseded)

This dashboard is primarily for the EA team’s internal governance visibility: it shows where the repository data quality is strong and where remediation is needed.

Step 6: Publish to Power BI Service and Set Refresh

From Power BI Desktop: Home → Publish → Select your workspace in Power BI Service
In Power BI Service, navigate to the published dataset
Dataset Settings → Scheduled Refresh → configure refresh schedule (daily, or multiple times daily)
Set gateway connection: if EA GraphLink is on-premises (not cloud), a Power BI Gateway must be installed and configured to allow the Power BI Service to reach the on-premises GraphQL endpoint
Apply Row-Level Security (RLS) if different stakeholder groups should see only their domain’s data

Power BI Gateway: Required for on-premises EA GraphLink endpoints. The gateway is a Windows service installed in the corporate network that provides a secure tunnel between Power BI Service (cloud) and the on-premises data source. Configure the gateway to use the same API key authentication as Direct Desktop connections.

Step 7: Connect to Copilot (Optional)

For organizations with Microsoft 365 Copilot licenses, connecting Copilot to the published Power BI dataset enables natural-language querying of dashboard data:

In Power BI Service → workspace settings → Enable Copilot
Publish the dataset with Copilot access enabled
Users with Copilot access in Power BI Service can open the dashboard and use the Copilot pane to ask questions: “What is the percentage of End-of-Life applications in the Finance domain?” or “Which domain has the lowest average capability maturity score?”

Copilot’s answers are based on the Power BI data model (not the EA MCP Server directly): it queries the loaded and modeled data, not the live repository. This means the answers reflect the last refresh of the data, not the live repository state. For live EA repository queries via Copilot, use EA GraphLink Interface B (MCP Server) separately.

Frequently Asked Questions

Q: Can we use DirectQuery from Power BI to EA GraphLink instead of scheduled refresh? Power BI’s DirectQuery mode for GraphQL connectors queries the GraphQL endpoint on each report interaction rather than loading data into Power BI’s in-memory model. This provides real-time data currency at the cost of query performance (each visual queries the GraphQL endpoint, which may produce perceptible lag for complex dashboards). For EA analytics dashboards where daily currency is sufficient, scheduled refresh (imported data) is recommended for better performance. DirectQuery is appropriate for operational dashboards where real-time currency is critical.

Q: How many rows can EA GraphLink return to Power BI in a single query? EA GraphLink supports pagination for large result sets. For typical EA repositories (a few thousand to tens of thousands of elements), a single query returns all elements of a given type without pagination issues. For large repositories (100,000+ elements), pagination parameters in the GraphQL query ensure all elements are retrieved across multiple requests. Power BI’s Power Query handles pagination via a custom function: Sparx Services configures this as part of the Connect engagement.

Q: Do we need a Power BI Premium or Fabric capacity for EA dashboards? Power BI Pro (per-user licensing) is sufficient for most EA analytics use cases: sharing dashboards within the organization, scheduled refresh, and basic Copilot access. Power BI Premium Per User (PPU) or Fabric capacity is required for advanced features: large dataset storage, very frequent refresh (more than 8 times per day), XMLA endpoint access, and full Copilot capabilities. For most EA programs, Power BI Pro is the right starting point.

Q: How do we handle elements in the repository with incomplete tagged values (empty fields)? Incomplete tagged values appear as blank values in Power BI queries. In DAX measures, handle blank values explicitly: use IF(ISBLANK([LifecycleStatus]), "Unknown", [LifecycleStatus]) to categorize elements with no lifecycle status into an “Unknown” bucket rather than dropping them from visualisations. The Governance Health dashboard specifically tracks the prevalence of incomplete values: this is a feature, not a bug. Showing the EA team where data gaps exist drives the governance improvement that improves dashboard accuracy over time.

Q: Can non-technical business stakeholders use these dashboards without training? Well-designed EA dashboards should be self-explanatory for business stakeholders. Avoid architecture jargon in visualisation labels: “Application End-of-Life Risk” is clearer than “ApplicationComponent.LifecycleStatus = EOL Distribution”. Include a brief “How to read this dashboard” text visual on the first page. Use consistent colors across all dashboards (red = risk, green = healthy, gray = unknown). Provide tooltips on visual elements that explain what they show. The Copilot integration further reduces the need for stakeholders to navigate the dashboard: they can ask questions and get answers without interpreting charts.

Q: How do we track dashboard accuracy over time as the repository is updated? Dashboard accuracy is a function of repository data quality. Track two metrics over time in the Governance Health dashboard: overall tagged value completeness (% of elements with key fields populated) and review a sample of the underlying data manually each quarter to validate that what Power BI shows matches the actual repository state. As the governance culture matures and MDG validation is enforced, data quality improves and dashboard accuracy increases correspondingly.

Ready to Build Your EA Analytics Dashboards?

Sparx Services’ Connect engagement deploys EA GraphLink Interface A, configures the Power BI connector, and delivers the initial dashboard set: Application Portfolio Heat Map, Technology Lifecycle Timeline, Capability Coverage, and Governance Health: ready to publish to your organization.

Talk to Sparx Services about EA analytics →