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

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

The setup decisions matter more now that AI does much of the modeling. AI builds and checks content according to the rules the repository gives it: the MDG, the package structure and the written conventions. A repository set up with clear rules gets consistent content. One set up loosely gets inconsistent content faster.

The seven steps at a glance

Step 1: Choose your database

For team use, you choose from three server platforms.

SQL Server (Microsoft). Best for organizations with existing SQL Server infrastructure and Windows environments. Mature enterprise support, Azure SQL for cloud hosting, Windows Authentication integration. Adds license cost if not already present, and 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 (Amazon RDS, Azure Database for PostgreSQL). Open source, strong performance, broad cloud support. Less common in traditional Windows enterprises.

Decision criterion: match your existing DBA skills and infrastructure. The repository is a standard relational database and 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 or on-premises: cloud-hosted databases (Azure SQL, Amazon RDS, Google Cloud SQL) suit most new installations, with 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’ server for shared access. Sparx EA clients can also connect straight to the database, but that gives every client direct database access, which many organizations will not allow. For most enterprise teams, PCS is the right choice.

What PCS provides:

• Managed connections, so architects connect through PCS instead of directly to the database
• Floating license management for the license pool
• Remote access over HTTP or HTTPS
• The connection point for WebEA, Prolaborate and other web-based tools that read the repository

Installation, at a high level: install PCS on a server, configure it to reach your database, set up its security and certificates, 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, for example an Azure VM with Azure SQL, or AWS EC2 with RDS PostgreSQL. Check the Sparx Systems documentation for the supported platforms for your version.

Step 3: Create the initial repository

With the database and PCS ready:

1. Create an empty database and run the Sparx EA schema script for your database platform, which Sparx Systems provides.
2. Transfer a base project into it using Sparx EA’s project transfer, then register the database in PCS and connect to it from the client.
3. Set up the initial package hierarchy (see Step 6).
4. Take a baseline of the empty, correctly structured repository as your clean starting point.

One repository or several: most organizations run a single production repository. One repository supports cross-domain analysis and single-source-of-truth governance, while several need federation for enterprise-level analysis. Start with one unless data sovereignty or organizational independence requires separation.

Step 4: Configure MDG extensions

MDG Technology extensions determine which element, relationship and diagram types are available.

For a standard EA program:

• ArchiMate 3.x: the full ArchiMate notation across all layers.
• BPMN 2.0, if process modeling is in scope.
• TOGAF support, if you produce TOGAF deliverables.
• SysML, only if systems engineering is in scope.
• A custom organizational MDG, designed and activated early. Retrofitting governance tagged values to an existing repository is painful.

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

Step 5: Set up user security

Configure role-based security before any modeling begins.

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

Domain Architect: read and write access 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 change content.

Service account: for scripts and integrations, with only the access each one needs and credentials separate from human users.

Directory integration: configure Sparx EA security to use Windows authentication or directory-based sign-in, so repository access is managed through your existing identity management with no separate passwords. Package-level locking protects sensitive content.

Step 6: Establish naming conventions and package structure

This is the most important governance decision in the setup. It is very hard to change after content is loaded. Renaming conventions mid-flight produces inconsistency, and restructuring package hierarchies breaks relationships and diagram references.

Top-level packages should mirror your EA framework. For a TOGAF and 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 it to your framework and domain model. Do not over-engineer it: three levels is usually enough, and deep hierarchies become hard to navigate.

Naming conventions:

• Applications: canonical names matching procurement and contracts, such as “Salesforce CRM” instead of “SFDC.” Prefer “Vendor Product” for commercial software and “Business Function” for custom applications.
• Capabilities: noun plus qualifier (“Customer Onboarding”), never verb form.
• Processes: verb plus noun (“Process Insurance Claim”), named as activities.
• Generally: Title Case, no abbreviations unless universally understood, and consistent vocabulary (do not alternate Application, System and Solution).

Document the conventions in the Principles package so they are a first-class architecture artifact. Write them precisely enough that someone new, or AI, could follow them without asking.

Step 7: Run a domain pilot before full rollout

Do not populate the whole repository at once. A domain pilot, building out one domain fully before extending, validates the governance decisions before they apply broadly.

Choose a pilot domain with an engaged, available architect, well-understood content, representativeness of your broader scope, and enough importance to show value. Application Portfolio is often a good choice: tangible, relevant to executives, and a good test of the key MDG tagged values.

Build it AI-augmented. Today a pilot architect builds the domain by hand and the validation happens at the end. Working AI-augmented, the architect states what the domain should contain, the sources to draw from (an application inventory, the ITSM configuration data, the PPM and ITFM systems) and the conventions from Step 6, and AI builds the content and checks it against the MDG and naming rules as it goes. Automation checks completeness, people own correctness. The pilot architect reviews whether the content is right about the estate and whether the conventions held up in practice. The skill is stating the intent clearly and noticing where the rules were ambiguous, because those are the gaps to fix before rollout. Tools that help include Claude or GitHub Copilot with AI Power Tools for Sparx EA, and Kernaro Assist in the EA client.

Validate at the end: run MDG validation against the pilot package and resolve all violations, show the content to stakeholders to test whether structure and naming communicate, and review the experience with the pilot architect. The pilot will reveal gaps in MDG design, naming decisions that need adjustment and structure issues. Fixing them in a one-domain pilot costs a fraction of fixing them across a fully populated repository.

Frequently asked questions

How we help

Our Configure the Solution work covers the platform steps in this guide: database advice, Pro Cloud Server installation, repository creation, security design including directory integration, and the package structure and naming conventions. For the MDG, the pilot domain and the model beyond it, we can teach your architects to build them AI-augmented, or build them for you. It is the groundwork an AI-Augmented Architecture practice depends on.