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’s normal. Most organisations underestimate three things: how long repository design decisions take, how unfamiliar MDG Technology feels to new users, and how slowly team adoption moves. The good news is that with a clear sequence — get the repository working, establish governance, pick one domain to start, then deliver visible value — 90 days is enough to move from installation to a functioning, stakeholder-facing architecture practice. This article maps what the first 12 weeks actually look like, what to prioritise at each stage, and the most common mistakes that derail early deployments.
Key Takeaways
- Repository design decisions feel overwhelming early — this is normal, and you do not need to decide everything on day one
- MDG Technology is unfamiliar to most new users but is non-negotiable for a governable, AI-ready repository
- Start with one modelling domain; breadth comes after discipline
- Team adoption is the slowest variable — budget time for it deliberately
- Weeks 9–12 should produce something stakeholders can see and respond to
The Honest Early Experience
Before the structured advice: an honest account of what most organisations actually experience in the first few weeks of a Sparx EA deployment.
The tool is capable. That capability means there are many options, and options create decisions. When your team first opens Sparx EA, they are likely to face questions they did not anticipate: 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 EAP files? What naming conventions will we use?
These are not obstacles — they are the real design work of enterprise architecture tooling. But organisations that expected to install Sparx EA and start modelling on day one often find themselves weeks behind because these decisions were not made in advance.
The learning curve for MDG Technology is steep. MDG (Model Driven Generation) governs element types, stereotypes, tagged values, and diagram types in Sparx EA. For architects coming from Visio or informal modelling tools, MDG feels abstract and unfamiliar. But it is what turns Sparx EA from a drawing tool into a governed repository. Skipping MDG in early weeks to “keep it simple” consistently creates rework later.
Team adoption is slow. Architects who participated in the evaluation are often enthusiastic. Architects who did not are often sceptical. Business stakeholders who are told “we have a new architecture tool” are usually 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 weeks 1–4 is not to model architecture. It is to establish the foundation that everything else depends on.
Repository setup. Decide on your database (SQL Server, PostgreSQL, or MySQL), install and configure Pro Cloud Server, and verify multi-user connectivity. These steps are more involved than they appear, particularly PCS configuration, security settings, and certificate handling for HTTPS access. Do not skip this phase or underestimate it.
Package structure. Design your top-level package hierarchy before anyone creates a model. A common starting structure: separate packages for Business Architecture, Application Architecture, Technology Architecture, and Shared Elements. Your MDG profiles should align to this structure from day one.
Naming conventions. Establish element naming conventions in writing before the first model is created. Naming drift is very difficult to correct after the fact, and it undermines repository quality significantly. Decide: capitalisation rules, naming patterns for each element type, version labelling, diagram naming.
MDG profile selection. Identify which MDG Technology profiles you need for your starting domain — most likely ArchiMate 3.0. Enable those profiles in your project. Do not enable every available profile; restrict to what you will actually use.
One domain to start. Pick one modelling domain — application portfolio, business capability map, or technology architecture — and commit to it for weeks 1–8. The most common early mistake is attempting 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 begins.
Build in your chosen domain. Use the naming conventions, package structure, and MDG profiles established in weeks 1–4. Resist the urge to import legacy Visio diagrams wholesale — informal diagrams from other tools do not have typed elements and will undermine your MDG governance.
Stakeholder communication plan. Architecture has no value if stakeholders cannot access it. Weeks 5–8 should include at least one stakeholder session in which you show what exists in the repository and what it answers. This does not need to be a polished presentation. A live walkthrough of a business capability map or application portfolio in Sparx EA is enough to establish credibility.
Involve business stakeholders early. The most persistent failure mode in new EA deployments is treating architecture as an IT-internal activity until it is “ready.” Business stakeholders who are involved from week 5 become advocates. Stakeholders who are invited to review finished architecture in month 6 become critics.
Team upskilling. By week 8, every architect who will use the repository should have completed basic Sparx EA training covering: 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” in a Sparx EA deployment is not a complete architecture. It is a specific, stakeholder-visible output that could not have been produced without the repository.
Common first-value deliverables:
- An application portfolio map showing all applications, their business capabilities served, and their technology platform — something the business did not have before
- A technology architecture view that an infrastructure team uses to plan a migration
- A business capability heat map that leadership uses in a strategy review
What makes these valuable is not the ArchiMate notation — it is the structured, cross-referenced data underneath them. When a stakeholder asks “which applications support capability X?” and you can answer from the repository in two minutes rather than two weeks, that is first value.
Week 12 checkpoint. By the end of week 12, you should be able to answer: Does the repository have typed, MDG-governed elements? Can multiple architects access it concurrently without conflict? Have at least two stakeholders seen repository output and found it useful? If the answer to all three is yes, the foundation is sound.
Common First-Deployment Mistakes
Trying to model everything at once. The fastest way to produce an ungovernable repository is to let every architect model whatever they think is relevant without a defined starting domain and element conventions.
Skipping MDG governance. MDG feels like overhead in week one. By month six, the repositories that skipped MDG are full of informal element types, inconsistent naming, and relationships that cannot be queried meaningfully. Repositories that established MDG governance from the start are the ones that can connect to EA GraphLink and deliver AI-assisted insight.
Not involving business stakeholders early. Architecture that no stakeholder has seen by week 8 is architecture that no stakeholder will trust by week 24. Involve stakeholders in defining what the architecture should answer — not just in reviewing what it says.
Underestimating Pro Cloud Server setup complexity. PCS is required for multi-user Sparx EA. Its configuration — database connection, authentication, HTTPS, port management — involves decisions that affect security, performance, and maintainability. Teams that rush PCS setup typically revisit it within three months.
Importing legacy diagrams. Legacy Visio diagrams, PowerPoint slides, and informal ArchiMate attempts from other tools carry informal elements, inconsistent naming, and no MDG typing. Importing them populates the repository without adding governance. Start fresh with typed elements.
What Sparx Services Deploy Does Differently
The Sparx Services Deploy engagement imposes structure on exactly this sequence. Instead of leaving repository design decisions to emerge organically — often inconsistently — Deploy works through a defined setup, governance, and onboarding sequence:
- Pre-deployment scoping — decisions on database, PCS configuration, and starting domain made before installation
- Repository design — package structure, MDG profile configuration, and naming conventions established and documented
- PCS and security configuration — production-grade setup, not a placeholder
- Team onboarding — structured capability building for each architect role
- 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 that is ready for real architecture work — not one that needs to be rebuilt in month four.
FAQ
How long does a Sparx EA deployment take before it is useful? With a structured setup, a Sparx EA repository can be producing useful stakeholder-facing output within 90 days. The key is sequencing: repository infrastructure first, governance second, modelling third, stakeholder engagement throughout. Teams that skip governance or start modelling before the repository is properly configured typically take longer to reach useful output, not less.
Do we need Pro Cloud Server from day one? Yes, if you have more than one architect who will access the repository. Pro Cloud Server is required for multi-user Sparx EA — without it, architects need direct database access, which is impractical and insecure in most enterprise environments. PCS setup should happen in week 1–2, not as an afterthought.
What is MDG Technology and why does it matter for new deployments? MDG Technology (Model Driven Generation) is Sparx EA’s mechanism for defining element types, stereotypes, tagged values, and diagram constraints. It is what turns Sparx EA from a flexible drawing tool into a governed repository. For new deployments, configuring MDG correctly from the start is the most important technical decision — it determines whether the repository can support AI integration, meaningful querying, and long-term governance.
How many architects do we need to start a Sparx EA practice? A functioning EA practice can start with one architect, but it benefits significantly from two — one focused on the technical repository configuration and one focused on stakeholder engagement and modelling. For enterprise-scale deployments, a minimum team of three (one repository owner, two domain architects) is more realistic.
Should we import our existing Visio diagrams into Sparx EA? Generally no — not as a starting approach. Legacy Visio diagrams contain informal elements without MDG typing, inconsistent naming, and relationships that Sparx EA cannot govern. The better approach is to use existing diagrams as reference material while rebuilding key architecture content as typed, MDG-governed elements. This takes longer in week one but produces a repository that is actually queryable and governable.
What does Sparx Services Deploy cost and what does it include? Deploy is a structured platform setup engagement ranging from $30K to $130K depending on environment complexity, team size, and starting scope. It covers repository design, PCS configuration, MDG profile setup, naming convention development, team onboarding, and delivery of first governed models. Licensing is purchased separately direct from Sparx Systems — Deploy includes a licence bill of materials as part of the scoping.
Ready to Start Your Sparx EA Deployment With a Clear Structure?
Sparx Services Deploy gives your organisation a production-ready Sparx EA environment — database, Pro Cloud Server, MDG governance, team onboarding, and first model delivery — in a defined engagement sequence. No guesswork on repository design. No surprises on PCS configuration. A working repository at the end.
