What Is an EA Repository? The Foundation of Enterprise Architecture Practice

It is also where AI does its work. When an architect asks AI to build a view, check the model against its rules or answer a question about the estate, AI reads and changes the repository. The architect decides what the repository should contain and what the rules are. AI is only as good as the person prompting it, and only as good as the repository it works in.

People often hear “repository” and picture a folder of diagrams. The distinction between a picture and a model matters more than anything else in this article, so start there.

The diagram-versus-model distinction

This is the conceptual shift that trips up most people moving from drawing tools to a repository, and it pays off most once it lands.

A diagram tool, such as Visio, draw.io, or Archi used a certain way, produces pictures. A rectangle labeled “CRM System” is a shape on a canvas. Copy it to another diagram and you have two shapes. Rename one and the other still reads “CRM System.” Shapes have no identity beyond the page they sit on.

An EA repository produces model elements. An element called “Salesforce CRM” exists exactly once. It carries an identifier, attributes, relationships, tagged values, documentation and an owner. When it shows up on five diagrams, those are five views of the same element. Change its lifecycle status once and every view reflects it. Its relationships, such as “Salesforce CRM realizes the Customer Management capability,” are model-level facts.

Why it matters: change-impact analysis, portfolio reporting, AI queries and governance checks all depend on elements being real records with real relationships. A diagram tool cannot answer which applications support the Supply Chain capability, because its shapes carry no semantic structure. A correctly modeled repository can.

How the pieces fit together

It helps to see the repository as a stack. The database holds the truth, Pro Cloud Server brokers shared access to it, the client is where architects work, and diagrams, dashboards and AI answers are all drawn from the same underlying data.

What an EA repository contains

A well-structured Sparx EA repository holds several distinct kinds of content.

Elements are the building blocks of the model. In ArchiMate these include Business Actors, Business Processes, Application Components, Technology Nodes, Capabilities and Data Objects. Each has a name, a type (its stereotype), documentation, tagged values and relationships.

Relationships are the connections that carry meaning. An ArchiMate Realization relationship from an Application Component to a Capability says the application implements that capability. It is a model-level fact.

Diagrams are named views onto subsets of the model. A Business Capability Map arranges capabilities in a hierarchy; an Application to Capability view links applications to what they realize. The diagram presents elements without defining them.

Tagged values are custom attributes attached to elements and defined by MDG Technology extensions. A value such as Lifecycle Status = Active on an Application Component drives portfolio reporting and executive dashboards. Values that another system owns, such as cost or risk, are best brought in from that system so they stay current.

Documentation is the textual content on elements: notes, descriptions, rationale. Architecture decision records can live as documentation on decision elements, and process descriptions accompany Business Process elements.

Baselines are snapshots of the repository at a moment in time, supporting version history, transition tracking and regulatory evidence.

Packages are the organizational hierarchy, folders with model significance. A Business Architecture package holds the business-layer elements and diagrams; an Application Portfolio package holds the Application Components.

Why a shared repository matters

The alternative is a scatter of individual files: Visio diagrams, slide decks, spreadsheets, local Archi files. Those files share a set of structural problems.

• They cannot be queried collectively without manual collation.
• They produce conflicting views when two architects model the same element independently.
• They cannot support change-impact analysis across domains.
• They are not available to reporting tools or AI as a governed data source.
• They create shadow repositories where the real architecture lives in scattered personal knowledge.

A shared repository removes those problems. One “Salesforce CRM” exists, every relationship from it is captured, every architect sees the same element, and every governance decision about it is recorded in one place.

Team collaboration. Architects work concurrently. One models the business architecture while another models the application architecture in a different package, and relationships cross those boundaries cleanly.

Single source of truth. When an executive asks how many applications the Finance domain runs, there is one answer from the repository instead of six answers from six spreadsheets.

Change-impact analysis. When a platform is scheduled for decommissioning, the repository surfaces every Application Component hosted on it, every Capability that depends on those applications and every Business Process that uses those capabilities. From a governed repository that answer comes quickly; from a pile of files it takes days of collation.

Sparx EA repository architecture

Database. The repository lives in SQL Server, MySQL or PostgreSQL, on a schema maintained by Sparx Systems. For team use, a server-hosted or cloud-hosted database is the right call.

Pro Cloud Server. PCS manages connections, authentication, floating-license allocation and remote access over HTTP or HTTPS, and it is required for WebEA and Prolaborate. It runs on a server or cloud VM in your environment.

Client. The Windows Sparx EA client provides the modeling environment. Changes persist to the database as architects work.

Reporting and AI. Several tools work from the repository, each suited to a different job. A reporting database built on top of the repository feeds Power BI dashboards, and Kernaro Connector for Power BI does the same where an organization has Kernaro AI Hub. Kernaro AI Hub, a Sparx Systems product, provides a read-only MCP server and a read-only GraphQL API for stakeholders and AI assistants asking questions. Kernaro Assist works inside the EA client. AI Power Tools for Sparx EA, free from NovoCircle, lets Claude or GitHub Copilot read and change the model on the architect’s machine. Sparx EA itself has no native MCP server. Whatever the tool, the repository’s quality sets the ceiling on what it returns.

What good repository governance looks like

A repository is only as useful as its governance, and much of that governance is decided at setup time.

Package structure. How the repository is organized into top-level domains and sub-domains. A structure that mirrors your EA framework makes navigation intuitive. A careless one becomes a filing problem that compounds as the model grows.

Naming conventions. Consistent patterns for application components, capabilities and technology nodes. Inconsistent naming produces a repository nobody can reliably query.

MDG Technology extensions. Which modeling extensions are active (ArchiMate, BPMN, SysML), which custom stereotypes exist, and which tagged values are mandatory on which element types. These choices define what the repository can express and what governance can check.

Role-based access. Who administers, who has read and write access on which packages, and who reads only. Access control lets architects work safely in shared space.

Baseline policy. When baselines are taken, such as before governance meetings, at transition milestones and before large AI-driven changes, how long they are kept, and who owns the discipline.

Written down clearly, these rules are also what AI builds and checks against. AI can apply them across the whole repository and report every exception. Deciding the rules, and judging the exceptions, is the architect’s work.

The repository as the foundation for everything else

Every advanced EA capability, including dashboards, automated governance checks, stakeholder reporting, change-impact analysis and AI-augmented modeling, rests on the repository being correctly structured and governed.

Reporting and AI only ever reflect what is in the model. If the repository is inconsistently governed, with missing owners, ad hoc stereotypes and patchy capability coverage, that inconsistency flows through to every dashboard and every answer. That is why governance comes first. With AI doing much of the building and checking, getting a repository into that state is far less work than it used to be, provided the architects have decided what it should contain. It is the same logic behind choosing Sparx EA as the platform: a governed model is what makes the rest possible.

Frequently asked questions