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

That last point is where most confusion starts. People hear "repository" and picture a folder of diagrams. The distinction between a picture and a model is the whole game, so it is worth getting straight before anything else.

The diagram-versus-model distinction

This is the conceptual shift that trips up nearly everyone moving from drawing tools to a real repository — and it is the one that pays off the most once it lands.

A diagram tool — 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 now 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 — "Salesforce CRM realizes the Customer Management capability" — are model-level facts, not connector lines someone happened to draw.

Why it matters: change-impact analysis, portfolio reporting, AI querying, and governance enforcement 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 repository, modeled correctly, answers that in an instant.

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 just views drawn from the same underlying data.

What an EA repository contains

A well-structured Sparx EA repository holds several distinct kinds of content, and it helps to name them precisely.

Elements are the building blocks of the model. In ArchiMate these include Business Actors, Business Processes, Applications, 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 — a model-level fact, not a drawing convention.

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; it does not define 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.

Documentation is the textual content on elements — notes, descriptions, rationale. Architecture decision records can live as documentation on Decision elements; 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 to a shared repository 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 BI tools or AI assistants as a governed data source.
• They create "shadow repositories" where the real architecture lives in scattered, individual knowledge.

A shared repository dissolves all of that. 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 through Pro Cloud Server. One person models the business architecture while another models the application architecture in a different package — and relationships cross those boundaries cleanly, so an Application Component can link to a Business Process modeled by someone else.

Single source of truth. When an executive asks how many applications the Finance domain runs, there is one answer from the repository — not 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. Seconds from a governed repository; days from a pile of files.

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 cloud-hosted or server-hosted database is the right call.

Pro Cloud Server. PCS is the middleware that manages database connections, authentication, floating-license allocation, and remote access. It runs on a server or cloud VM in your environment, and the Sparx EA client connects through it.

Client. The Windows-native Sparx EA client provides the modeling environment. Architects work in the client and changes persist to the database in real time.

Downstream BI and AI. Reporting tools and AI assistants sit above the repository and read it as a data source — through a GraphQL API for BI dashboards and over the Model Context Protocol for AI assistants. These are read-only consumers: they query the model without modifying it, which means the repository's quality sets the ceiling on what they can return.

What good repository governance looks like

A repository is only as useful as its governance, and most 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 enforce.

Role-based access. Who administers, who has read/write on which packages, who reads only. Access control lets architects work safely in shared space without stepping on each other's domains.

Baseline policy. When baselines are taken — before governance meetings, at transition milestones — how long they are kept, and who owns the discipline of taking them.

Sparx Services works through all of these when helping you configure the solution, so the repository starts on solid foundations rather than accruing technical debt from day one.

The repository as the foundation for everything else

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

The connectivity layer that serves data to Power BI and AI assistants only ever reflects what is in the model. If the repository is inconsistently governed — missing owners, ad-hoc stereotypes, patchy capability coverage — that inconsistency flows straight through to every dashboard and every answer. Repository quality is the quality ceiling for everything downstream.

This is why we treat repository setup as a foundational step and MDG governance as a maturity step that comes before any BI or AI integration. The sequence is not optional: get the foundation right, then build on it. It is the same logic behind choosing Sparx EA as the platform in the first place — a governed model is what makes the rest possible.

Frequently asked questions