EA GraphLink vs Manual Data Export: The Case for Live Architecture Data

Every Excel sheet, CSV, generated report, and PowerPoint slide pulled out of Sparx EA is a snapshot — accurate at the instant it was made and drifting out of date from there. For anything consumed more than once, that drift is the whole problem. EA GraphLink takes the other route: a live, governed connection to the repository, so the data a dashboard or an AI assistant reads is the data as it stands right now.

This piece sets the two patterns side by side, explains where each genuinely belongs, and is honest about the cases where a frozen export is still the right answer.

How manual export works today

Most teams getting data out of Sparx EA lean on some mix of four mechanisms.

CSV and Excel export. The built-in matrix and spreadsheet exports produce files of elements, attributes, and tagged values. Those files land in email, SharePoint, or Confluence — where they sit and age.

Report generation. The built-in report generator turns the model into RTF or PDF documents. Excellent for formal deliverables — architecture definition documents, transition plans — and poor for anything that needs to stay current.

PowerPoint. Diagram images get embedded in decks and walked through at governance meetings. The deck is correct on the day it was assembled and frozen from then on.

Custom scripts. More mature teams write PowerShell or Python that queries the repository database or the automation API and pushes data elsewhere. These work until the schema shifts, at which point they break and need a maintainer.

The shared weakness runs through all four: the instant an export is generated, it begins to diverge from the actual repository. Change an element's lifecycle status the day after an export and every stakeholder downstream is working from the wrong picture until the next cycle runs.

The staleness problem

Architecture data goes off faster than most teams admit. A few patterns recur in practice.

Lifecycle changes. A vendor publishes an end-of-life date. The team updates the repository. The portfolio spreadsheet that went out last week still reads "Active," and the project planning next quarter's roadmap is building on the old status.

Ownership changes. A system changes hands in the repository. The org diagram handed to the new divisional head still names the previous owner, so questions get routed to the wrong person.

Decision changes. An Architecture Review Board moves a decision from "Proposed" to "Rejected." The decision register exported for the sponsor last month still says "Proposed," and the project proceeds on a false premise.

Capability changes. A new application joins the portfolio and its coverage is modeled. The capability gap analysis in the business case being written does not reflect it — because it was built from last month's export.

None of these are hypothetical; they are routine wherever export-and-distribute is the primary way data moves. And the effect compounds: decisions made on stale data create remediation work that consumes the capacity you needed for the next thing.

Live connection vs manual export, side by side

The two approaches solve the same problem — getting architecture data in front of people and tools — in opposite ways. Here is the contrast that matters.

How EA GraphLink changes the pattern

EA GraphLink exposes the Sparx EA repository as a read-only GraphQL schema. When Power BI, Tableau, or any GraphQL-capable tool queries that endpoint, it gets the current state of the repository at the moment of the query. The same schema is what AI assistants reach through the MCP server — one governed surface, two kinds of consumer.

EA GraphLink shipped in January 2026 as part of Kernaro AI Hub, so this is a new capability rather than a long-settled one — the teams putting it in front of stakeholders today are in their first months of live operation, and the early results are about removing the export cycle rather than years of accumulated practice.

No file to manage. There is nothing to generate, distribute, or version. The consuming tool reads the repository directly.

No bespoke export pipeline. The GraphQL schema is the interface contract. As the repository grows — new elements, new packages, new tagged values — the schema expands: existing queries keep working and new ones become available. There are no export scripts to babysit.

Currency is automatic. Whatever moment a tool queries, that is the state it sees. Stakeholders are never the ones holding the out-of-date copy.

The semantic layer comes with it. The schema is MDG-aware, so the semantic layer that MDG Technology governance establishes in the repository is preserved all the way out to the query.

The maintenance question, honestly

This is the part most business cases underweight. The maintenance work does not vanish with a live connection — it relocates.

With manual export you maintain export scripts when the schema changes, report templates when formats change, distribution lists when stakeholder groups change, the schedule itself (who runs it, when, and what happens when it fails), and version control of everything that went out (which copy did the project manager actually see?).

With EA GraphLink the schema needs governance when the metamodel changes materially — but that is an MDG governance task, not a separate export chore. Dashboard definitions in Power BI or Tableau still need updating when reporting requirements change, which is ordinary BI maintenance. Authentication and access are a one-time setup rather than a per-report concern.

So the work shifts from the export layer to the governance layer, where it actually belongs. Keeping your MDG meaningful is architecture work that pays off everywhere; maintaining a fleet of export scripts pays off nowhere else.

Where manual export still earns its place

Being straight about this matters — live connection is not always the answer. Manual export remains the right call in four situations.

Regulated reporting with an audit trail. Some frameworks — ISO 27001 audits, financial-services regulatory reporting — require a point-in-time snapshot that can be dated, signed off, and stored as evidence. A live dashboard cannot do that; you need a frozen artifact, and a generated report is exactly right.

Offline delivery. Presenting to a client who has no access to your BI environment? An exported document or diagram travels; a live dashboard needs connectivity.

One-off requests. "Can you send me a list of every application in the Finance domain?" — a bounded, one-time ask where a quick CSV is the pragmatic answer, not a persistent view.

Systems with no API. If a downstream system can only ingest files, export is the only mechanism available. That is a systems constraint, not a choice about how the EA team prefers to work.

A simple rule covers the rest: if the data will be consumed more than once, or its currency matters at each point of consumption, connect it live. If it is consumed once, for a bounded purpose, and the snapshot nature is fine, export it.

The business case for going live

The argument for EA GraphLink over manual export rests on three things.

Accuracy. Decisions made on current data are simply better decisions. The cost of a single decision made on a stale picture — investment aimed at a capability already covered, a project running on a superseded architecture decision — usually dwarfs the cost of putting a live connection in place.

Capacity. Time spent generating, formatting, and distributing exports is time not spent doing architecture. Where senior architects lose several hours a week to export and reporting upkeep, a live connection hands that time back.

AI integration. A file in a folder cannot be queried by an AI assistant. Serving the repository over MCP is what lets Copilot, Claude, or Gemini answer questions against your live architecture data — and that is only possible with a live connection. This is the same integration layer that AI Power Tools and the wider Sparx EA AI ecosystem build on.

Frequently asked questions

For the wider decision about which BI platform to put on top of the live connection, see Power BI vs Tableau for EA analytics. To shape the rollout itself, Configure the Solution stands up the integration layer and the first dashboards that replace your current export workflow.