New to Sparx EA? Here’s What the First 90 Days Actually Look Like

The first 90 days of a Sparx EA deployment are rarely smooth — and that is normal. Most teams underestimate three things: how long repository design decisions take, how unfamiliar MDG Technology feels to new users, and how slowly adoption spreads. With a clear sequence — get the repository working, establish governance, pick one domain to start, then deliver something visible — 90 days is enough to move from a fresh install to a functioning, stakeholder-facing practice. What follows maps the 12 weeks: what to prioritize at each stage, and the mistakes that quietly derail early deployments.

The 90-day arc at a glance

The first quarter is not one effort but four, in sequence. Each phase depends on the one before it, which is exactly why deployments that try to run them in parallel tend to stall.

The honest early experience

Before the structured advice, an honest account of what most teams actually live through in the first few weeks.

The tool is capable, and capability means options, and options mean decisions. The first time your team opens Sparx EA, they hit questions nobody scheduled: How should packages be structured? Which MDG Technology profiles do we need? Who owns the repository schema? Do we need Pro Cloud Server immediately, or can we start with file-based projects? What naming conventions will we use?

These are not obstacles. They are the real design work of architecture tooling. But teams that expected to install Sparx EA and start modeling on day one often find themselves weeks behind, because none of those decisions were made in advance.

The learning curve for MDG Technology is steep. MDG Technology governs element types, stereotypes, tagged values, and diagram types. For architects coming from Visio or informal modeling tools, it feels abstract and unfamiliar — yet it is exactly what turns Sparx EA from a drawing canvas into a governed repository. Skipping MDG in the early weeks to “keep it simple” reliably creates rework later.

Adoption is slow. Architects who took part in the evaluation tend to be enthusiastic; those who did not tend to be skeptical. Business stakeholders told “we have a new architecture tool” stay indifferent until they see something useful. Expect adoption to lag the technical setup by four to six weeks.

Weeks 1–4: get the repository working

The goal of the first four weeks is not to model architecture. It is to lay the foundation everything else depends on.

Repository setup. Choose your database (SQL Server, PostgreSQL, or MySQL), install and configure Pro Cloud Server, and verify multi-user connectivity. This is more involved than it looks — particularly PCS configuration, security settings, and certificate handling for HTTPS access. Do not skip or underestimate it.

Package structure. Design your top-level package hierarchy before anyone creates a model. A common starting structure separates Business Architecture, Application Architecture, Technology Architecture, and Shared Elements. Your MDG profiles should align to that structure from day one.

Naming conventions. Write down element naming conventions before the first model exists. Naming drift is very hard to correct after the fact and quietly erodes repository quality. Settle the capitalization rules, naming patterns per element type, version labeling, and diagram naming up front.

MDG profile selection. Identify the MDG Technology profiles you need for your starting domain — most often ArchiMate. Enable those, and only those. Do not switch on every available profile; restrict to what you will actually use.

One domain to start. Pick a single modeling domain — application portfolio, business capability map, or technology architecture — and commit to it through weeks 1–8. The most common early mistake is trying to model everything at once. Breadth before discipline produces a repository that looks populated but is structurally inconsistent.

Weeks 5–8: first real models

With the repository working and governance in place, weeks 5–8 are where architecture content actually begins.

Build in your chosen domain. Use the naming conventions, package structure, and MDG profiles you set in weeks 1–4. Resist importing legacy Visio diagrams wholesale — informal diagrams from other tools have no typed elements and will undermine your MDG governance.

Plan stakeholder communication. Architecture has no value if stakeholders cannot reach it. Weeks 5–8 should include at least one session where you show what exists in the repository and what it answers. It need not be polished — a live walkthrough of a capability map or application portfolio is enough to establish credibility.

Involve business stakeholders early. The most persistent failure mode in new deployments is treating architecture as an IT-internal activity until it is “ready.” Stakeholders involved from week 5 become advocates. Stakeholders invited to review finished architecture in month 6 become critics.

Upskill the team. By week 8, every architect who will use the repository should have covered the basics: navigation, element creation, diagram types, MDG profile usage, and package governance. This does not need to be formal training — structured self-study with review from a senior architect works — but it should be deliberate and tracked.

Weeks 9–12: first value delivery

“First value” is not a complete architecture. It is a specific, stakeholder-visible output that could not have existed without the repository.

Typical first-value deliverables include:

• An application portfolio map showing every application, the capabilities it serves, and its technology platform — something the business did not have before.
• A technology architecture view an infrastructure team uses to plan a migration.
• A capability heat map leadership uses in a strategy review.

What makes these valuable is not the notation — it is the structured, cross-referenced data underneath. When a stakeholder asks “which applications support capability X?” and you answer from the repository in two minutes instead of two weeks, that is first value.

The week 12 checkpoint. By the end of week 12 you should be able to answer three questions. Does the repository hold typed, MDG-governed elements? Can multiple architects work in it concurrently without conflict? Have at least two stakeholders seen repository output and found it useful? Three yeses mean the foundation is sound.

Common first-deployment mistakes

Modeling everything at once. The fastest route to an ungovernable repository is letting every architect model whatever seems relevant, with no defined starting domain and no element conventions.

Skipping MDG governance. MDG feels like overhead in week one. By month six, the repositories that skipped it are full of informal element types, inconsistent naming, and relationships nobody can query. The repositories that established MDG governance from the start are the ones whose data can be queried meaningfully and reused with confidence.

Leaving business stakeholders out early. Architecture no stakeholder has seen by week 8 is architecture no stakeholder will trust by week 24. Involve them in defining what the architecture should answer — not just in reviewing what it says.

Underestimating Pro Cloud Server setup. PCS is required for multi-user Sparx EA, and its configuration — database connection, authentication, HTTPS, port management — carries decisions that shape security, performance, and maintainability. Teams that rush it usually revisit it within three months.

Importing legacy diagrams. Legacy Visio diagrams, PowerPoint slides, and informal ArchiMate attempts carry untyped elements, inconsistent naming, and no MDG structure. Importing them populates the repository without adding governance. Start fresh with typed elements.

What a structured deployment does differently

Sparx Services’ Configure the Solution work imposes structure on exactly this sequence. Instead of leaving repository design to emerge organically — and inconsistently — it runs a defined setup, governance, and onboarding path:

1. Pre-deployment scoping — database, PCS configuration, and starting domain decided before installation.
2. Repository design — package structure, MDG profile configuration, and naming conventions established and documented.
3. PCS and security configuration — production-grade setup, not a placeholder.
4. Team onboarding — structured capability building for each architect role.
5. First model delivery — Sparx Services architects work alongside your team to produce the first governed models in your chosen domain.

The result is a repository ready for real architecture work — not one that needs rebuilding in month four. If your deeper goal is to put that data to work for the whole business, the same disciplined foundation is what later makes AI Augmented Architecture viable; without governed, typed elements, there is nothing dependable for AI to read.

Frequently asked questions