Resources
A practical guide for architects and architecture managers preparing their Sparx EA repository for AI augmentation.
The single biggest factor in the success of an AI augmentation program for enterprise architecture is not the AI tool you choose. It is the quality of the repository you connect it to.
This guide walks through six concrete steps for bringing a Sparx EA repository to the standard required for AI tools: including EA GraphLink, Microsoft Copilot, and Kernaro AI Hub: to produce reliable, trustworthy, and genuinely useful outputs. Each step is practical and actionable. The guide is structured for architecture teams doing the work, not executives approving it.
By the end of the guide, you will have a clear checklist of what needs to be in place before AI augmentation will deliver value: and a sequence for getting there.
When an AI tool queries your Sparx EA repository through EA GraphLink’s MCP or GraphQL interface, it reads what is there. It does not interpret what you intended to model. It does not infer missing relationships, guess at unnamed elements, or reconstruct context from diagrams. It reads the data as it exists in the repository’s underlying structure: element names, tagged values, descriptions, relationship types, stereotype classifications, and package hierarchy.
This has a direct consequence: the quality of AI output is bounded by the quality of repository data. If your Application elements have no descriptions, an AI assistant asked “what does this application do?” will either return nothing or return incorrect inferences. If your relationships are ambiguous: because the same logical connector type has been used for ten different semantic purposes: AI queries that traverse relationships will return noise. If your elements are not stereotyped, the AI cannot distinguish an Application from a Data Object from a Business Service without additional context it may not have.
The problem is sometimes described as “garbage in, garbage out,” but that framing underestimates how specific the issue is. The repository does not need to be perfect to be useful. But it does need to be consistent, complete enough for the questions being asked, and governed by a metamodel (MDG) that gives AI tools the semantic context they need to interpret what they are reading.
Well-governed MDG is, in practice, the primary quality signal for AI tools. When your MDG stereotypes are consistently applied, each element carries a type classification that tells the AI tool not just what the element is called but what kind of thing it is, what properties it is expected to have, and what relationship types are semantically valid in its context. That context is the difference between an AI assistant that gives confident, accurate answers and one that hedges every response with uncertainty.
The six steps in this guide move from audit through governance through structure through integration. Each step builds on the previous one. The sequence matters.
Before you can improve your repository, you need an honest picture of where it stands. A structured audit is not optional: it is the first step, because the most common mistake in AI readiness programs is treating symptoms rather than root causes.
What to look for in a repository health audit:
Element completeness. Every element in the repository should have, at minimum, a name, a type (ideally a stereotype), and a description. Tagged values should be populated to the standard defined by your MDG. An audit should measure what percentage of elements in each domain meet the minimum property standard. In most repositories, this number is lower than architects expect: typically between 40% and 70% in the first honest audit.
Naming consistency. Pull a sample of 50–100 elements from each major domain and review the naming patterns. Are application names consistent? Do they follow a convention (e.g., [Vendor]-[ProductName] or [BusinessDomain]-[Function])? Are there duplicates: the same real-world thing appearing under multiple names in different packages? Naming inconsistency is one of the most common failure modes for AI queries, because the AI cannot reliably aggregate information about a concept that appears in 12 different spellings.
Orphan elements. An orphan element is one with no meaningful relationships: it exists in the repository but connects to nothing. Orphan elements are invisible to most AI traversal queries. They represent modeling debt and inflate element counts without contributing usable information. Most repositories have more orphan elements than the team realizes; they accumulate when projects end without cleanup.
Relationship coverage. For the core architecture domains: Business, Application, Technology: assess whether the expected relationship types are present. Application elements should have realisation links to business capabilities, deployment links to technology nodes, and interface/integration links to connected systems. Missing relationships mean AI tools cannot answer cross-domain questions correctly.
The 20-item governance checklist (summary): At the end of your audit, score the repository against 20 governance criteria covering naming conventions, description completeness, stereotype use, relationship coverage, orphan rate, MDG compliance, package structure, tagged value population, owner assignment, status tagging, version baselines, duplicate element rate, cross-domain traceability, relationship type discipline, security classification, diagram naming, technology tagging, lifecycle status, integration point modeling, and capability-to-application traceability.
This audit provides the input to Steps 2 through 5. Everything after this point is targeted improvement rather than guesswork.
MDG Technology: Sparx EA’s metamodel definition framework: is where you define what kinds of things exist in your repository and what properties and relationships are valid for each. It is the semantic layer that gives your repository meaning beyond a collection of boxes and lines.
What MDG governance means in practice:
MDG governance is not a one-time configuration. It is an ongoing practice of maintaining the stereotypes, tagged value definitions, relationship rules, and validation checks that govern your repository. Most organizations set up MDG once: typically at deployment: and then let it drift as the architecture practice evolves. By the time AI augmentation becomes a priority, the MDG is partially out of date, partially inconsistently applied, and partially undocumented.
The first governance action is to audit your current MDG configuration against your actual architecture practice. Document every stereotype in use, its intended purpose, the tagged values it carries, and the relationship types it should participate in. Then compare that documentation to what is actually in the repository. The gaps between the two are your MDG debt.
Building a stereotype discipline:
A stereotype discipline means every architecture element has an agreed stereotype applied at creation and maintained through its lifecycle. This requires three things: (1) the MDG profiles are complete enough to cover your architecture domains, (2) architects know which stereotype to use and why, and (3) there is a process for adding new stereotypes when genuine new types are needed rather than creating ad-hoc elements.
The MDG Pattern Library (a companion document from Sparx Services) provides 12 reusable governance patterns: including the Lifecycle Status Pattern, the Ownership Assignment Pattern, and the Automated Validation Pattern: that give architects a concrete starting point for each governance domain.
Tagged value standards:
Tagged values are the primary mechanism for capturing structured metadata on elements. For AI tools, tagged values are first-class query targets: they are how you express properties like technology vendor, application lifecycle status, business owner, cloud-native status, and regulatory classification in a form that is machine-readable and queryable.
Defining tagged value standards means specifying: which tagged values are mandatory for each stereotype, what the valid values are for enumerated tags, who is responsible for populating them, and how compliance is measured.
Using AI Assist for MDG validation:
Kernaro Assist (in-EA, currently in Beta) and Sparx EA’s built-in validation framework both support automated checking of MDG compliance: flagging elements that violate stereotype rules, missing mandatory tagged values, or relationship types that fall outside the permitted set. Configuring these validation rules is the enforcement mechanism that makes MDG governance sustainable rather than dependent entirely on architect discipline.
Your package hierarchy is the organisational spine of your repository. It determines how architecture content is grouped, who owns it, and how it can be navigated by both humans and AI tools. A well-structured package hierarchy makes AI queries faster, more accurate, and more granular. A poorly structured one makes them unreliable.
What a well-structured package architecture looks like:
The key principles are domain ownership, layer separation, and clear naming conventions.
Domain ownership means each major architecture domain: Business Architecture, Application Architecture, Technology Architecture, Data Architecture, Security Architecture: has its own top-level package or package subtree, with a clear owner responsible for that domain’s content. Cross-domain content (such as integration points or capabilities that span domains) belongs in explicitly defined cross-cutting packages, not scattered across domain packages.
Layer separation means the repository mirrors the layering of your architecture framework: typically motivation, business, application, technology: and content is placed in the appropriate layer rather than in project-based or ad-hoc packages. When AI tools traverse the repository looking for capability-to-application traceability, they follow package and relationship paths. If an application element lives in a “Q3 Project” package rather than the Application Architecture domain, it may not be found by domain-scoped queries.
Naming conventions for packages matter as much as naming conventions for elements. Package names should be consistent, unambiguous, and aligned with how the organization talks about its domains.
Common anti-patterns to avoid:
Restructuring an existing repository:
Package restructuring in a mature repository is significant work that requires careful sequencing: content moves must preserve relationships, baselines, and access controls. In most cases, the right approach is to define the target structure, migrate content domain by domain, and retire legacy packages progressively rather than attempting a big-bang migration.
EA GraphLink is the connectivity layer that makes your Sparx EA repository accessible to AI tools, BI platforms, and data integration systems in real time. It is a product from Sparx Systems, not a feature of the base Sparx EA product: it is deployed as a separate layer that exposes your repository through two interfaces.
Interface A: GraphQL for BI and data integration:
Interface A exposes your repository through a GraphQL API. This enables Power BI, Tableau, and other BI and data integration tools to query your architecture data directly: retrieving application portfolios, technology inventories, capability maps, and relationship data in structured form that can be visualized, filtered, and aggregated in live dashboards. The data refresh can be automated, so BI reports always reflect the current state of the repository rather than a point-in-time export.
Interface B: MCP for AI tools:
Interface B exposes your repository through the Model Context Protocol (MCP): the emerging standard for giving AI assistants access to structured context. This means AI tools such as Microsoft Copilot, Claude, and other MCP-compatible assistants can query your architecture repository as part of a conversation. An architect (or an executive) can ask “which applications support the Order Management capability?” and receive an answer drawn from live repository data rather than from the AI’s training data.
Prerequisites for EA GraphLink deployment:
EA GraphLink requires Sparx Enterprise Architect to be running with a shared repository (DBMS-backed: SQL Server, Oracle, or PostgreSQL). It does not work with file-based (.eapx) repositories. The deployment process covers server-side EA GraphLink configuration, connection to the shared repository, API configuration, and network/security setup appropriate to your environment.
Repository quality matters significantly here: the queries that EA GraphLink exposes are only as useful as the data they return. Steps 1 through 3 of this guide are the prerequisite work that makes EA GraphLink deployment valuable rather than merely functional.
Software licensing note:
EA GraphLink licenses are purchased directly from Sparx Systems. Sparx Services does not resell software. Our role is to scope the license requirement as part of the Connect engagement, provide the bill of materials, and deliver the implementation. Contact Sparx Systems or your Sparx EA reseller for current licensing terms and pricing.
With EA GraphLink deployed and your repository quality in good shape, you are ready to connect the AI and BI tools that put architecture insight in front of the people who need it.
Connecting Power BI and Tableau:
The EA GraphLink GraphQL interface connects directly to Power BI and Tableau as a data source. The connection is configured in your BI tool using the GraphQL endpoint, and queries are defined using the EA GraphLink schema to pull the specific architecture data you want in dashboards: application portfolios, technology lifecycle views, capability coverage maps, dependency matrices, and more. Once the data source is connected, Power BI and Tableau reports can be refreshed on a schedule, giving stakeholders a live view of the architecture rather than a static export.
Connecting Microsoft Copilot and MCP-compatible AI tools:
The MCP interface enables any MCP-compatible AI assistant to query your repository. For Microsoft 365 environments, this means Copilot can answer architecture questions as part of everyday work: in Teams, in SharePoint, or in the dedicated Copilot experience. The configuration process involves registering the EA GraphLink MCP endpoint, defining the context scope (which packages and element types the AI can access), and testing the query patterns that match the questions your users will actually ask.
Connecting Kernaro AI Hub:
Kernaro AI Hub is a stakeholder-facing platform (GA 2026) built specifically for EA data, requiring EA GraphLink as its connectivity layer. It provides a purpose-designed interface for business and technology leaders to explore architecture insights, ask questions about the portfolio, and access current-state and target-state views without needing to open Sparx EA. The Kernaro AI Hub deployment is scoped within a Connect engagement.
Measuring the before/after:
The impact of AI augmentation is real and measurable. Before tracking it, establish a baseline: how long does it take to produce an application portfolio report? How many requests come to the EA team from executives asking for architecture data? What is the typical lead time for an architecture impact assessment?
After deployment, track the same metrics. In practice, organizations connecting AI tools to well-governed EA repositories typically see: a reduction in time spent on data extraction and reporting tasks (often 30–50% of senior architect time redirected to analysis rather than reporting); a significant increase in architecture-informed decisions as executives can now access data directly; and a measurable improvement in architecture influence on investment decisions.
Sustaining the improvement:
AI augmentation is not a one-time deployment. The value compounds as the repository stays current, MDG governance is maintained, and new integration surfaces are added as AI tools evolve. Sustaining the improvement means: keeping EA GraphLink and its downstream integrations current, continuing MDG governance as the architecture practice evolves, running regular repository health checks, and treating the AI integration layer as a maintained component of the platform rather than a project that ends at go-live.
The Connect offering from Sparx Services delivers Steps 4 and 5 end-to-end: EA GraphLink deployment, GraphQL and MCP configuration, BI and AI tool integration, and stakeholder enablement. Steps 1 through 3 can be addressed through an Amplify engagement (governance uplift) or a Discover engagement (assessment and roadmap) if you are not yet confident in your repository foundation.
Book a conversation: sparxservices.com/contact
Sparx Services: Enterprise Architecture Platform Specialists
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.