How to Set Up a Sparx EA Repository from Scratch: Step-by-Step Guide

Setting up a Sparx EA repository from scratch is seven sequential steps. Each one has consequences for long-term repository health, and decisions made at setup time are difficult and disruptive to reverse later. The most consequential are naming conventions and package structure, in steps 6 and 7 — get those right up front. This guide walks each step with the decision criteria you need.

Step 1: Choose your database

For team use (multi-user, server-hosted), you choose from three platforms.

SQL Server (Microsoft). Best for organizations with existing SQL Server infrastructure and Windows environments. Mature enterprise support, Azure SQL compatibility for cloud hosting, Windows Authentication integration. Adds license cost if not already present; needs DBA familiarity.

MySQL. Best for Linux-hosted environments and lower-cost setups. Open source, widely deployed, good performance at EA repository sizes. Less native Windows integration than SQL Server.

PostgreSQL. Best for cloud-native environments (AWS RDS, Azure Database for PostgreSQL). Open source, strong JSON/JSONB support, excellent performance, broad cloud support. Less common in traditional Windows enterprises.

Decision criterion: match your existing DBA capabilities and infrastructure. The repository is a standard relational database — it needs no special features. If your team already runs SQL Server, use SQL Server; if you are on AWS and know PostgreSQL, use that. Do not introduce a new database platform for the EA repository alone.

Cloud vs on-premises: cloud-hosted databases (Azure SQL, Amazon RDS, Google Cloud SQL) are recommended for new installations — managed backup, high availability, and scaling without DBA overhead. On-premises suits data-sovereignty or air-gap requirements.

Step 2: Install Pro Cloud Server

Pro Cloud Server (PCS) is Sparx Systems’ middleware layer for multi-user access. Without it, Sparx EA can only open a repository from a local file or direct database connection — neither is appropriate for a team.

What PCS provides:

• Managed database connections — architects connect through PCS, not directly to the database
• Floating license management — the license pool is managed through PCS
• Authentication and security — user access managed through PCS, with optional Active Directory integration
• Remote access — teams can reach the repository over HTTPS
• The integration endpoint for BI and AI connectivity to the repository

Installation, at a high level: install PCS on a server (Windows Server recommended; Linux supported), point it at your chosen database, create the initial repository through PCS, configure authentication, and test the connection from a Sparx EA client. For cloud-hosted repositories, run PCS on a VM in the same region as the database — Azure VM + Azure SQL, or AWS EC2 + RDS PostgreSQL, are common patterns.

Step 3: Create the initial repository

With PCS running and connected:

1. Open Sparx EA and connect to PCS.
2. Create a new project (the repository) in PCS — this creates the Sparx EA schema in the database.
3. Apply the initial model structure; at this stage the repository is empty.
4. Set up the initial package hierarchy (see Step 6).
5. Take a baseline of the empty, correctly-structured repository — your clean starting point.

One repository vs multiple: most organizations run a single production repository. One repository enables cross-domain analysis and single-source-of-truth governance; multiple repositories require federation for enterprise-level analysis. Start with one unless data sovereignty or organizational independence compels separation.

Step 4: Configure MDG extensions

MDG Technology extensions determine which element, relationship, and diagram types are available. This is set at the repository level.

For a standard EA program:

• ArchiMate 3.x (mandatory) — the full ArchiMate notation across all layers.
• BPMN 2.0 — if process modeling is in scope.
• TOGAF Content Metamodel — if you produce TOGAF deliverables.
• SysML — only if systems engineering is in scope; do not activate it for a standard IT architecture program.
• Custom organizational MDG — design and activate early. Retrofitting governance tagged values to an existing repository is painful.

Every extension adds to the toolbox and diagram-type list. Activate only what your program needs; add more as scope expands.

Step 5: Set up user security

With PCS managing access, configure role-based security before any modeling begins.

Repository Administrator — full access: manage packages, change MDG configuration, reset locks, manage users. One or two people only.

Domain Architect (read/write) — read/write to their assigned domain package; read-only elsewhere. The standard architect role.

Read-Only Stakeholder — read access for project managers, analysts, or executives who view but do not modify.

Automated Account — for scripts and integrations: read-only access, separate credentials from human users.

Active Directory integration: if you use AD, configure PCS to authenticate against it, so repository access is managed through existing identity management with no separate passwords. Beyond PCS roles, Sparx EA’s model security allows package-level locking for sensitive content.

Step 6: Establish naming conventions and package structure

This is the most important governance decision in the setup. Decisions here are very hard to change after content is loaded — renaming conventions mid-flight produces inconsistency; restructuring package hierarchies breaks relationships and diagram references.

Top-level packages should mirror your EA framework. For a TOGAF/ArchiMate-aligned program, a typical structure:

[Repository Root]
├── Architecture Vision
│   ├── Principles
│   └── Requirements
├── Business Architecture
│   ├── Business Capabilities
│   ├── Business Processes
│   └── Business Information
├── Application Architecture
│   ├── Application Portfolio
│   └── Integration Architecture
├── Technology Architecture
│   ├── Technology Standards
│   └── Infrastructure
├── Decision Register
└── Working / In Progress

Adapt to your framework and domain model. Do not over-engineer — three levels is usually sufficient; deep hierarchies become hard to navigate.

Naming conventions:

• Applications — canonical names matching procurement and contracts. “Salesforce CRM,” not “SFDC.” Prefer “Vendor Product” for commercial software, “Business Function” for custom apps.
• Capabilities — noun + qualifier (“Customer Onboarding”). Never verb-form.
• Processes — verb + noun (“Process Insurance Claim”). Name them as activities.
• Generally — Title Case, no abbreviations unless universally understood, consistent vocabulary (don’t alternate Application / System / Solution).

Document the conventions in a Principles package so they are a first-class architecture artifact, not a separate document that gets lost.

Step 7: Run a domain pilot before full rollout

Do not populate the entire repository simultaneously. A domain pilot — building out one domain fully before extending — de-risks the rollout and validates governance decisions before they apply broadly.

Choose a pilot domain that has an engaged, available architect; well-understood content; representativeness of your broader scope; and enough importance to demonstrate value. Application Portfolio is often a good choice — tangible, executive-relevant, and it tests the key MDG tagged values without complex relationship modeling.

Validate at the end: run MDG validation against the pilot package and resolve all violations; demonstrate the content to a stakeholder audience to test whether structure and naming communicate; and review the modeling experience with the pilot architect. The pilot will reveal gaps in MDG design, naming decisions that need adjustment, and structure issues. Fix them before rolling out — the cost of fixing governance decisions in a one-domain pilot is a fraction of fixing them across a fully-populated repository.

What Sparx Services does in Configure the Solution

The Configure the Solution engagement covers all seven steps: database advisory, PCS installation (cloud or on-premises), repository creation, MDG selection and activation, user-security design (including AD integration), naming-convention and package-structure design, domain-pilot execution, and team onboarding. We typically complete it in 4–8 weeks depending on environment complexity, leaving the team with a production-ready repository and governance foundations in place.

Frequently asked questions

Set up your repository with Sparx Services

Configure the Solution covers every step in this guide — from database selection through pilot completion and onboarding — leaving you a production-ready repository with the governance foundation that makes every subsequent EA investment worthwhile. It is the groundwork that an AI Augmented Architecture practice depends on, and it starts where your architects work day to day.