Direct Answer
An EA repository is a governed, shared database containing all architectural models, elements, relationships, decisions, and documentation for an organisation. It is not a diagram store — this is the most important misconception to correct. A diagram is a view of the model; the model is the repository. In Sparx EA, the repository is a relational database (SQL Server, MySQL, or PostgreSQL) where every element (application, capability, process, technology component) exists as a record, every relationship between elements is a record, and diagrams are simply configured views of those records. Multiple architects work in the same repository concurrently. Stakeholders query the same data. Governance decisions, naming conventions, and architectural standards are enforced in the repository, not in individual files. The shared repository is the single source of truth — and everything valuable about EA practice depends on it being governed correctly.
Key Takeaways
- An EA repository is a model store, not a diagram store. Diagrams are views of the model; the model is the data.
- Sparx EA repositories are relational databases: SQL Server, MySQL, or PostgreSQL.
- Multi-user concurrent access is enabled by the Pro Cloud Server (PCS).
- Every element, relationship, tagged value, and diagram is a record in the database.
- The repository is the single source of truth for all architecture decisions, models, and governance.
- Repository governance (package structure, naming conventions, MDG Technology extensions) determines whether the repository is useful or chaotic.
- Without governance, a repository is a shared Visio store. With governance, it is a strategic organisational asset.
- EA GraphLink reads the repository to serve BI dashboards and AI assistants — repository quality determines output quality.
The Diagram vs Model Distinction
This distinction is the most important conceptual shift for architects transitioning from drawing tools to EA repositories — and it is misunderstood with near-universal frequency.
A diagram tool (Visio, draw.io, even Archi in some uses) creates pictures. A rectangle labeled “CRM System” is a shape on a canvas. If you copy that rectangle to another diagram, you have two shapes. If you rename the shape on one diagram, the other diagram still says “CRM System.” Shapes have no identity beyond the diagram they appear in.
An EA repository (Sparx EA) creates model elements. An element called “Salesforce CRM” exists once in the repository — it has an identifier, attributes, relationships to other elements, tagged values, documentation, and an owner. When it appears on multiple diagrams, those diagrams are views of the same underlying element. If an architect updates the element’s name or lifecycle status, every diagram showing that element reflects the change. The element’s relationships — “Salesforce CRM realises the Customer Management capability” — are model-level facts, not visual connector lines.
Why this matters: Change impact analysis, portfolio reporting, AI querying, and governance enforcement all depend on elements existing as actual records with relationships. A diagram tool cannot answer “which applications support the Supply Chain capability?” — because diagrams do not have this semantic structure. An EA repository, modeled correctly, answers this query instantly.
What an EA Repository Contains
A well-structured Sparx EA repository contains:
Elements: The fundamental building blocks of the model. In ArchiMate: Business Actors, Business Processes, Applications, Application Components, Technology Nodes, Capabilities, Data Objects, and more. Each element has a name, type (stereotype), documentation, tagged values, and relationships.
Relationships: The connections between elements that carry semantic meaning. An ArchiMate Realisation relationship between an Application Component and a Capability means the application implements that capability — this is a model-level fact, not a drawing convention.
Diagrams: Named views that display subsets of the model. A “Business Capability Map” diagram shows capabilities arranged in a hierarchy. A “Application to Capability” diagram shows applications linked to the capabilities they realise. The diagram organises and presents elements; it does not define them.
Tagged values: Custom attributes attached to elements, defined by MDG Technology extensions. A tagged value of Lifecycle Status = Active on an Application Component is a governance attribute used for portfolio reporting, AI querying, and executive dashboards.
Documentation: Textual content attached to elements — notes, descriptions, rationale. Architecture Decision Records can be stored as documentation on Decision elements. Business process descriptions accompany Business Process elements.
Baselines: Snapshots of the repository at a point in time. Baselines support version history, transition architecture tracking, and regulatory compliance.
Diagrams and packages: Packages are the organisational hierarchy of the repository — equivalent to folders, but with model significance. A package called “Business Architecture” contains the elements and diagrams for the business layer. A package called “Application Portfolio” contains all Application Component elements.
Why a Shared Repository Matters
The alternative to a shared repository is individual architect files — Visio diagrams, PowerPoint slides, Excel spreadsheets, local Archi files. Individual files:
- Cannot be queried collectively without manual collation
- Produce conflicting views when two architects model the same element independently
- Cannot support change impact analysis across domains
- Are not accessible to AI assistants or BI tools as a governed data source
- Create “shadow repositories” where the actual architecture is scattered across individual knowledge
A shared repository solves all of these. One instance of “Salesforce CRM” exists. All relationships from it are captured. All architects see the same element. Governance decisions about it are recorded in the same place. AI assistants and BI tools query one data source.
Team collaboration. Multiple architects work concurrently in the same Sparx EA repository via Pro Cloud Server. Architect A models the Business Architecture; Architect B models the Application Architecture in a different package. Both see each other’s work. Relationships cross package boundaries — an Application Component modeled by Architect B can be linked to a Business Process modeled by Architect A.
Single source of truth. When an executive asks “how many applications do we have in the Finance domain?”, there is one answer — from the repository — not six different answers from six different spreadsheets.
Change impact analysis. When a technology platform is scheduled for decommissioning, the repository identifies all Application Components hosted on it, all Business Capabilities dependent on those applications, and all Business Processes that use those capabilities. This analysis takes seconds from a governed repository; it takes days from a collection of individual files.
Sparx EA Repository Architecture
Database. Sparx EA repositories are stored in SQL Server, MySQL, or PostgreSQL. The database schema is maintained by Sparx Systems. For team use, a cloud-hosted or server-hosted database is appropriate.
Pro Cloud Server (PCS). The Pro Cloud Server is the middleware layer that manages database connections, authentication, floating license management, and remote access. PCS runs on a server (or cloud VM) in the organisation’s environment. Architects connect to the Sparx EA repository through PCS via the Sparx EA client.
Client. The Sparx EA client application (Windows native) connects to PCS and provides the modeling environment. Architects work in the client; changes are persisted to the database in real time.
EA GraphLink. EA GraphLink sits above PCS and exposes the repository data as a GraphQL API (Interface A, for BI tools) and as an MCP Server (Interface B, for AI assistants). EA GraphLink reads the repository without modifying it — it is a read-only intelligence layer above the modeling environment.
What Good Repository Governance Looks Like
A repository is only as useful as its governance. The key governance decisions made at repository setup time include:
Package structure. How the repository is organised into top-level domains and sub-domains. A well-designed package structure mirrors the organisation’s EA framework and makes navigation intuitive. A poorly-designed package structure becomes a filing problem that gets worse as the repository grows.
Naming conventions. How elements are named consistently — naming patterns for application components, business capabilities, technology nodes. Inconsistent naming produces a repository that cannot be reliably queried.
MDG Technology extensions. Which modeling extensions are active (ArchiMate, BPMN, SysML), which custom stereotypes are defined, which tagged values are mandatory on which element types. These decisions define what the repository can express and what governance can be enforced.
Role-based access. Which users have admin access, which have read/write access to which packages, which have read-only access. Access control enables multiple architects to work safely in the same repository without inadvertently modifying each other’s domains.
Baseline policy. When baselines are taken (before major governance meetings, at architecture transition milestones), how long they are retained, and who is responsible for taking them.
Sparx Services addresses all of these governance decisions in the Deploy engagement, ensuring the repository starts with the right foundations rather than accumulating technical debt from day one.
The Repository as the Foundation for Everything Else
Every advanced EA capability — AI querying, BI dashboards, automated governance checking, stakeholder reporting, change impact analysis — depends on the repository being correctly structured and governed.
EA GraphLink (the AI and BI connectivity layer) serves data from the repository. If the repository data is inconsistently governed — missing owners, ad-hoc stereotypes, incomplete capability coverage — EA GraphLink serves that inconsistency to Power BI dashboards and AI assistants. The repository quality is the quality ceiling for all downstream outputs.
This is why Sparx Services treats repository setup (Deploy) as a foundational engagement, and MDG governance (Amplify) as a necessary maturity step before Connect (AI and BI integration). The sequence matters: get the foundation right before building on it.
Frequently Asked Questions
Q: Can the EA repository be hosted in the cloud? Yes. The Sparx EA database (SQL Server, MySQL, or PostgreSQL) can be hosted on any cloud platform — Azure SQL, Amazon RDS, Google Cloud SQL. The Pro Cloud Server can be deployed on a cloud VM in the same environment. Sparx Services configures cloud-hosted repositories as part of the Deploy engagement, including appropriate security groups, backup policies, and connection configuration.
Q: What is the difference between a Sparx EA project file (.qea) and a shared repository? A .qea file is a single-user SQLite database — it is a portable, file-based repository suitable for individual use or offline work. For team use, the repository moves to a shared SQL Server/MySQL/PostgreSQL database accessed via Pro Cloud Server. The data model is the same; the storage and access mechanism differs. Most EA teams start with .qea files and graduate to a shared database as team size and governance requirements grow.
Q: How do you set up role-based access in a Sparx EA repository? Pro Cloud Server provides the authentication framework for Sparx EA repositories. User accounts are configured in PCS (or integrated with Active Directory/Azure AD). Within the Sparx EA client, package-level security can be applied — specific packages can be locked to specific users or groups. The Repository Security feature in Sparx EA allows fine-grained control over who can read, write, or administer each package. Sparx Services configures role-based access as part of the Deploy engagement.
Q: How many users can work in a Sparx EA repository simultaneously? Sparx EA supports concurrent multi-user access limited by the floating license count (how many Sparx EA licenses your organisation has purchased). In practice, teams of 5–50 concurrent architects are common. At higher concurrency, performance is managed through PCS configuration and database optimisation. Element-level locking in Sparx EA prevents conflicts when multiple users work in overlapping areas.
Q: What happens to the repository when Sparx EA is upgraded? Sparx EA upgrades occasionally include database schema changes. When upgrading Sparx EA and Pro Cloud Server, the repository database is migrated automatically on first connection by the new version. Sparx Services recommends taking a baseline (snapshot) of the repository before major upgrades, so a rollback point is available if needed. Sparx Systems publishes migration notes with each major release.
Q: How do baselines work in Sparx EA? A baseline is a snapshot of a package (or the entire repository) at a specific point in time. Baselines are stored in the repository database and can be compared against the current model state — Sparx EA highlights elements that have been added, modified, or deleted since the baseline was taken. Baselines are used for transition architecture tracking (comparing As-Is vs To-Be), ARB governance (reviewing what changed since the last review), and regulatory compliance (providing evidence of architecture state at a specific date).
Q: Can the EA repository integrate with enterprise directories like Active Directory? Yes. Pro Cloud Server supports Windows Authentication and Active Directory integration, allowing Sparx EA repository access to be controlled through existing enterprise identity management. Azure Active Directory integration is also supported for cloud-hosted environments. This means user provisioning and access management can be handled through the same identity systems used for other enterprise applications.
Q: How is the repository backed up? Because the Sparx EA repository is a standard relational database (SQL Server, MySQL, or PostgreSQL), it is backed up using the same database backup tools used for any other enterprise database. Automated backup policies (daily full backup, transaction log backup for SQL Server) are appropriate. In cloud-hosted configurations, cloud-native backup services (Azure Backup, AWS RDS automated backups) are used. Sparx Services recommends and configures backup policies as part of the Deploy engagement.
Ready to Set Up Your EA Repository?
Sparx Services’ Deploy engagement covers everything from database selection and Pro Cloud Server installation through package structure design, MDG configuration, role-based access setup, and team onboarding.
We set up the repository foundation that every other EA capability is built on — correctly from day one.
