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

Configuring MDG Technology is seven steps. The most common mistake is opening the MDG editor before completing Steps 1–3 — the design decisions made there determine whether the MDG delivers governed intelligence or just adds technical complexity. The vocabulary you define here is what makes the repository precise, reportable, and AI-ready. It is worth doing carefully.

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, subscription, 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.

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, SubscriptionModel, VendorSLA)
    ├── Custom-Built Application (custom — adds DevelopmentLanguage, CodeRepository)
    └── Legacy System         (custom — adds TechnicalDebtScore, MigrationPriority)

For most organizations, 3–8 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.

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.

Pro Cloud Server deployment (recommended for team repositories): copy the MDG XML to the PCS shared MDG folder, configure PCS to serve it, and all clients connecting via PCS receive it automatically. Method 2 is required for team repositories — it ensures everyone uses the same MDG version and removes individual import steps.

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 via PCS.

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) — scripted on-save validation alerts architects to violations immediately. The tightest feedback loop, but it requires scripting effort.

Frequently asked questions

Build your MDG governance framework with Sparx Services

Sparx Services helps your team build a custom MDG Technology extension end to end — requirements analysis, stereotype design, build, validation-rule configuration, and deployment — transferring the knowledge as we go so you can extend and maintain it independently. It is the heart of Configure the Solution, and the governance foundation that an AI Augmented Architecture practice is built on.