New to Sparx EA? What the First 90 Days Look Like

The first 90 days with Sparx EA are rarely smooth, and that is normal. Most teams underestimate how long repository design decisions take, how unfamiliar MDG Technology feels to new users, and how slowly adoption spreads. With a clear sequence, a team can move from a fresh install to a working practice that stakeholders use. Get the repository working, set the modeling rules, build one domain, then show stakeholders something useful.

Teams starting now have one advantage earlier teams did not. AI can do much of the mechanical work in the model: creating elements, drawing diagrams, converting old content and checking the result against the rules. The architect’s job in the first 90 days is to decide what the model should contain and to say it clearly. AI is only as good as the person prompting it, and a new repository with no rules gives it nothing to work to.

The 90-day arc at a glance

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

What the early weeks feel like

The tool is capable, which means options, which means 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? What naming conventions will we use?

These questions are the real design work of architecture tooling. Teams that expected to install Sparx EA and start modeling on day one often fall behind, because none of those decisions were made in advance. AI does not remove them. It makes them more important, because AI applies whatever rules you set, consistently and quickly, including bad ones.

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 tools, it feels abstract, yet it is what turns Sparx EA from a drawing canvas into a governed repository. Skipping MDG in the early weeks to keep things simple creates rework later.

Adoption is slow. Architects who took part in the evaluation tend to be enthusiastic, and those who did not tend to be skeptical. Business stakeholders told there is a new architecture tool stay indifferent until they see something useful. Expect adoption to trail the technical setup.

Weeks 1-4: get the repository working

The first four weeks 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. PCS configuration, security settings and certificates for HTTPS access take more effort than teams expect.

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. Align your MDG profiles to that structure from the start.

Naming conventions. Write down element naming conventions before the first model exists. Settle capitalization, naming patterns per element type, version labeling and diagram naming up front. Written conventions are also what you will hand to AI, so write them precisely enough that someone, or something, could follow them without asking.

MDG profile selection. Identify the MDG Technology profiles you need for your starting domain, most often ArchiMate. Enable those and only those.

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

Weeks 5-8: first real models

With the repository working and the rules in place, architecture content begins.

Build in your chosen domain. Today a new team builds its first models by hand, one element at a time, and learns the tool as it goes. Working AI-augmented, the architect states what the domain model should contain, the sources to draw from and the conventions to follow, and AI creates the elements, relationships and diagrams. The skill is knowing what belongs in the model and reviewing what was built. AI can check the content against your MDG and naming rules. Whether it is right about your estate is for the architect to judge. Automation checks completeness, people own correctness.

Bring existing content in on purpose. Do not import legacy Visio diagrams wholesale as drawings. Decide what the model should hold, then have AI read the old diagrams and spreadsheets and create typed elements from them, and review the result.

Design what stakeholders will see. Architecture has no value if stakeholders cannot reach it. Decide who will open the model, what question they come with and where they should land, and have AI build the navigation diagrams and views to match. Hold at least one session where you show what exists and what it answers. A live walkthrough of a capability map or application portfolio is enough to establish credibility.

Involve business stakeholders early. A persistent failure 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 months later tend to become critics.

Build the team’s skills. By week 8, every architect who will use the repository should know navigation, element creation, diagram types, MDG profile usage and package governance. They should also be practiced at stating a request to AI and checking what comes back. Structured practice with review from a senior architect works, as long as it is deliberate.

Weeks 9-12: first value delivery

First value 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, which 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.

The value sits in the structured, cross-referenced data underneath. When a stakeholder asks which applications support a capability and the answer comes from the repository the same day, from an architect or from AI working over the model, 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 several architects work in it at once without conflict? Have at least two stakeholders seen repository output and found it useful? If all three answers are yes, 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. AI only makes it happen faster.

Skipping MDG governance. MDG feels like overhead in week one. Repositories that skip it fill up with informal element types, inconsistent naming and relationships nobody can query. Repositories governed from the start are the ones whose data can be queried and reused with confidence, by people and by AI.

Leaving business stakeholders out early. Architecture no stakeholder has seen by week 8 is hard to get trusted later. Involve them in defining what the architecture should answer as well as in reviewing it.

Underestimating Pro Cloud Server setup. PCS configuration covers database connection, authentication, HTTPS and port management, and those choices shape security, performance and maintainability. Teams that rush it usually revisit it.

Accepting AI output unchecked. AI-built content looks finished. A new team that does not review it builds a repository nobody trusts.

How we help

Sparx Services’ Configure the Solution work puts structure on this sequence: database and PCS decisions made before installation, package structure and naming conventions documented, MDG profiles selected for the starting domain, and production-grade security. From there we can teach your architects to work AI-augmented in the new repository, stating what the model should contain and reviewing what AI builds, or we can build the first models for you and hand them over. Either way, the governed foundation is what makes AI-Augmented Architecture work, because AI needs typed elements and clear rules to work from.

Frequently asked questions