How to Configure MDG Technology in Sparx EA: A Governance Setup Guide

A custom MDG Technology is part of building the model in Sparx EA. It sets the stereotypes, controlled tagged-value enumerations and validation rules that every element is held to. In AI-augmented work the architect designs that governance intent, and AI does much of the build, applies the profile to model content and checks the model against the rules. The design steps stay with the architect.

Configuring MDG Technology takes seven steps. The most common mistake is opening the MDG editor before completing Steps 1 to 3, because the design decisions made there determine whether the MDG gives you a governed model or only adds technical complexity. The vocabulary you define here is what makes the repository precise and reportable, and what lets an AI work on it reliably.

The seven steps at a glance

Step 1: Understand what you need to govern

Before opening the MDG editor, complete a governance requirements analysis, a documentation and workshop step, not a tool step.

What modeling domains does your team use? ArchiMate almost certainly; BPMN if process modeling is in scope; SysML if systems engineering is; and any custom elements your team models that don’t fit those vocabularies.

What element types do you need that built-in MDGs lack? Common custom stereotypes: SaaS Application (Application Component with cloud provider, pricing model, vendor SLA), Legacy System (with technical-debt rating and migration priority), External Partner System, Regulatory Requirement.

What governance attributes do you need on each type? For Application Component, for example: Lifecycle Status (Active/Tolerate/Migrate/Eliminate/End-of-Life/Decommissioned), Business Owner, Technical Owner, Business Domain, Annual Run Cost, Business Criticality, Technical Health, Cloud Provider. Where a value such as run cost or lifecycle status already lives in another system (your ITFM, ITSM, PPM or eGRC system), plan to connect to it with AI rather than retype it, and use the tagged value to define where that fact lands in the model.

What validation rules must be enforced? Which tagged values are mandatory; whether naming conventions need enforcing; and any relationship constraints (e.g. Application Components must have at least one Realization to a Capability).

Document all of this before proceeding. The MDG build is the implementation of this design, not the place to make design decisions.

Step 2: Review existing MDGs

Before building new stereotypes, review what already exists in your installation. Many teams build stereotypes that duplicate built-in ArchiMate or TOGAF types they weren’t aware of.

In Sparx EA: Settings › MDG Technologies › view all active MDG packages. Review every ArchiMate element type by layer, the TOGAF Content Metamodel types if activated, and any previously installed custom MDGs.

Common discoveries: ArchiMate’s Capability (Strategy layer) already exists, teams sometimes create a redundant custom one; Principle exists in both ArchiMate and TOGAF MDGs; a previous architect already created a partial custom MDG that needs extension rather than replacement.

For each requirement from Step 1, decide: does an existing type cover it (use it, extend with tagged values only)? Does an existing type need extension (create a custom stereotype extending it)? Or does an entirely new type need creating? Most requirements are satisfied by extending existing ArchiMate types, not by creating new types from scratch.

Step 3: Design your stereotype structure

With requirements analyzed and existing MDGs reviewed, design the stereotype hierarchy, on paper first, not in Sparx EA. A typical example:

UML Component (base)
└── ArchiMate Application Component (built-in MDG)
    ├── SaaS Application       (custom: adds CloudProvider, PricingModel, VendorSLA)
    ├── Custom-Built Application (custom: adds DevelopmentLanguage, CodeRepository)
    └── Legacy System         (custom: adds TechnicalDebtScore, MigrationPriority)

For most organizations, a small set of custom stereotypes covering the key element types is the right initial scope. Avoid stereotype proliferation, more stereotypes mean more modeling discipline required and more to maintain.

Tagged-value enumeration design. For every enumeration, define the complete list of allowed values. This is the controlled vocabulary used for filtering, grouping, and reporting. Example Lifecycle Status values: Active, Invest, Tolerate, Migrate, Eliminate, End-of-Life, Decommissioned. Do not use free text where an enumeration is possible. Every field used for filtering, grouping, or counting should be a controlled enumeration.

Step 4: Build with the MDG Technology editor

With the design documented, build the MDG using profile-based construction:

1. Create a dedicated “MDG Development” package at the root, separate from operational content and protected from general access.
2. Within it, create a UML Profile package per stereotype domain (Application Architecture, Business Architecture, Decision Register).
3. In each Profile, add Stereotype elements, set the Base (the UML metaclass or ArchiMate element it extends).
4. Add tagged-value definitions to each stereotype: name, type, allowed values, default, notes.
5. Add Constraint elements for validation rules. OCL for complex rules, simple property constraints for mandatory-field checks.
6. Set display settings: icon, shape, default colors.

Then use the MDG Technology wizard (Settings › MDG Technology › Generate MDG Technology File) to package the profiles into a deployable XML file, supplying the MDG name and ID, version number, author, and the profile packages to include.

Step 5: Define validation rules

Validation rules surface governance violations when architects validate the model. Configure them two ways.

Constraint-based (within the MDG). Add OCL constraints to stereotypes for mandatory fields, for example a constraint that BusinessOwner must be populated, and for relationship requirements, such as an Application Component needing at least one Realization to a Capability.

Script-based (more flexible). For complex rules, write Sparx EA scripts (JavaScript) run on demand or triggered on changes. Scripts can check all elements in a package for mandatory completeness, generate a violations report by package and element, and auto-fix simple issues such as setting defaults on empty fields. Configure the script to output to the Results window so architects can run validation before an ARB submission.

AI-run rules. AI-augmented, the architect writes the rules once and an AI with access to the live repository checks the model against them, reports violations by package and element, and proposes fixes that the architect approves. Changing a rule is an edit to the rule set rather than a script change. Automation checks completeness, people own correctness.

Step 6: Deploy to the repository

With the MDG XML generated, deploy it so every connecting client receives it.

Per-project deployment: in a Sparx EA client, Settings › MDG Technologies › Import, then browse to the XML and import. Active for that client session.

Repository-level deployment (recommended for team repositories): import the MDG into the repository itself, so every user who opens that repository, including through Pro Cloud Server, works with it. This keeps everyone on the same MDG version and removes individual import steps. Check the exact procedure for your EA version in the Sparx Systems documentation.

Version control. Store the MDG XML in Git and tag each version. When the MDG changes, commit the new version, increment the version number in the metadata, and redeploy to the repository.

Step 7: Train the team and enforce via validation

An MDG without adoption is wasted. Training covers which stereotypes exist and when to use each, how to add tagged values, how to run validation and read results, what the rules enforce and why, and where the MDG reference documentation lives (publish the Step 1 design in the repository as architecture principles).

Three enforcement levels, in order of maturity:

• Advisory (start here), run validation as a team review before ARB submissions. Low-friction; builds the governance habit.
• Gated, configure the ARB workflow so content with outstanding violations cannot be submitted until validation passes.
• Automated (advanced), validation runs routinely, through on-save scripts or an AI checking the model against the rules, and architects hear about violations straight away.

Frequently asked questions

Build your MDG governance framework

The MDG is the governance foundation an AI-Augmented Architecture practice is built on. We can help your architects design it and have AI build, apply and check it, or build the MDG and rulesets for you as part of building the model and hand them over.