Published: 2026-04-18 Category: What Is Offering relevance: Amplify
Direct Answer
MDG Technology (Managed Domain Groups) is Sparx EA’s metamodel extension mechanism. It is the system that defines custom element types, stereotypes, tagged values, diagram types, and validation rules within the Sparx EA modeling environment. UML alone does not have the semantic vocabulary for every architectural domain — ArchiMate, SysML, BPMN, DoDAF, and every industry framework that Sparx EA supports is implemented as an MDG extension, either built-in (shipped with Sparx EA) or custom (built by an organisation for its own modeling standards). MDG Technology is also the AI quality gate: EA GraphLink’s semantic query layer is MDG-aware, meaning the stereotypes, tagged value enumerations, and element type names defined in MDG directly shape what AI assistants and BI tools can query and how precisely they can answer. An organisation with no custom MDG relies on generic UML semantics for AI querying. An organisation with a well-designed custom MDG has a governed, queryable architectural vocabulary that AI can reason about precisely.
Key Takeaways
- MDG Technology = Managed Domain Groups — Sparx EA’s system for extending and customising the metamodel.
- MDG defines: custom element types (stereotypes), tagged value definitions, diagram types, and validation rules.
- Built-in MDGs: ArchiMate, SysML, BPMN, TOGAF, DoDAF — shipped with Sparx EA or available from Sparx Systems.
- Custom MDGs: built by organisations to govern their own modeling standards and vocabulary.
- UML alone lacks the semantic precision for EA domains — MDG is what adds that precision.
- EA GraphLink is MDG-aware: well-governed MDG stereotypes become first-class queryable dimensions for AI and BI.
- The custom MDG is the “source of truth” for an organisation’s architectural vocabulary.
- MDG design and governance is the core deliverable of the Sparx Services Amplify engagement.
What MDG Technology Does
MDG Technology is the mechanism that allows Sparx EA to model in ArchiMate, SysML, BPMN, DoDAF, TOGAF content, and any other domain-specific notation — including custom notations invented by an organisation for its own governance purposes.
Without MDG: Sparx EA models in base UML. A rectangle is a Class. A connection is a Dependency or Association. The semantic meaning of a “Customer Management Capability” or a “Cloud Infrastructure Service” is not captured in the tool — it is just a Class with a text label.
With ArchiMate MDG: Sparx EA knows that a Capability is a specific ArchiMate Strategy layer element with specific allowed relationships. A Realisation relationship between an Application Component and a Capability has precise semantic meaning. Diagram validation can check that elements are used in architecturally valid ways.
With a custom organisational MDG: Sparx EA knows that a SaaS Application is a specific organisational stereotype extending ArchiMate’s Application Component, with mandatory tagged values for Cloud Provider, Subscription Cost, Vendor SLA, and Data Classification. Validation rules enforce that these fields are populated before the element can be saved.
MDG Technology is what transforms Sparx EA from a general-purpose UML modeler into a governed enterprise architecture management tool.
Components of an MDG Extension
An MDG Technology extension package contains:
Stereotype Profiles: Stereotypes extend base UML metaclasses (Class, Component, Node, Interface, Dependency, etc.) with additional metadata and semantic meaning. ArchiMate’s Business Process extends the UML Activity; the ArchiMate MDG applies the stereotype with appropriate icon, compartment settings, and relationship constraints. A custom Managed Application stereotype extends Component with the organisation’s specific attribute requirements.
Tagged Value Definitions: Each stereotype can define a set of tagged values — custom attributes attached to elements of that stereotype. A tagged value definition specifies:
- The attribute name (e.g.,
Lifecycle Status) - The data type (text, integer, date, boolean, enumeration)
- The allowed values for enumerations (Active, Tolerate, Migrate, Eliminate, End-of-Life)
- Whether the value is mandatory
- Default value (if any)
Tagged value enumerations are particularly important for AI and BI integration — they define the controlled vocabulary that AI assistants use when filtering, grouping, and answering questions.
Diagram Types: MDG extensions can define custom diagram types — specific diagram templates that constrain which element types and relationship types can appear in that diagram. An ArchiMate Application Layer diagram allows Application Components and Application Services; it does not allow Business Process elements (which belong in the Business Layer diagram). Custom diagram types enforce modeling discipline.
Validation Rules: MDG validation rules define constraints that are checked when a model is validated. Rules can enforce:
- Mandatory relationships (every Application Component must have at least one Realisation to a Capability)
- Attribute constraints (Lifecycle Status must be populated; Application Owner must be a non-empty string)
- Naming conventions (Application Components must follow the pattern “Vendor Product” or similar)
- Structural constraints (Capabilities cannot directly realise Technology Nodes without an Application Component in between)
Validation rules are the automated enforcement mechanism for governance standards. Running a validation check on the repository surfaces all elements that violate governance rules — without relying on individual architects to self-enforce.
Built-In MDG Extensions
Sparx EA ships with MDG extensions for major standards. The primary ones:
ArchiMate 3.x: The Open Group’s enterprise architecture notation. Implements all ArchiMate layers (Strategy, Business, Application, Technology, Physical, Implementation & Migration), element types, relationship types, and viewpoints. This is the primary MDG for EA programs using Sparx EA.
BPMN 2.0: Business Process Model and Notation. Implements BPMN 2.0 flow elements (Tasks, Events, Gateways, Pools, Lanes) for business process modeling.
SysML 1.x: Systems Modeling Language. Used for systems engineering — requirements, block definition diagrams, internal block diagrams, activity diagrams for system behavior.
TOGAF Content Metamodel: Implements TOGAF work product types — Principles, Requirements, Gaps, Work Packages, Plateaus. Used alongside ArchiMate for TOGAF-aligned EA programs.
UML 2.5: The base UML package — class diagrams, sequence diagrams, use case diagrams, state machines, and more.
DoDAF / MODAF / NAF: Defence architecture frameworks with specific viewpoint types and element stereotypes.
Custom MDG Extensions: The Organisational Standard
Beyond the built-in frameworks, organisations build custom MDG extensions to govern their own modeling standards. This is where the Sparx Services Amplify engagement delivers its most distinctive value.
A custom organisational MDG typically includes:
Organisation-specific stereotypes: A custom Cloud Service stereotype (extending ArchiMate Application Component) with tagged values for cloud provider (AWS/Azure/GCP), subscription model, and data classification. A custom SaaS Platform stereotype with vendor and contractual metadata. A custom Legacy System stereotype with migration priority and technical debt scoring.
Governance vocabulary: Tagged value enumerations that define the organisation’s classification vocabulary — lifecycle stages, investment bands, criticality ratings, business domain taxonomy. These enumerations are the controlled vocabulary for BI and AI querying.
Validation rules: Enforcing that new elements cannot be committed to the repository without mandatory governance data. Without validation rules, the repository fills with elements that lack owners, lifecycle status, and capability linkage — the data quality degradation that undermines AI and BI usefulness.
Custom diagram types: Tailored diagram templates for the organisation’s standard architectural views — “Current State Application Landscape” with specific element types and layout guidelines, “Capability Heat Map” with appropriate capability element types and colouring.
Custom toolbox: Configuring the Sparx EA modeling toolbox to surface the organisation’s stereotypes prominently — so architects reach for the right element types without navigating the full MDG tree.
MDG Technology as the AI Quality Gate
The EA GraphLink semantic query layer is MDG-aware. When Power BI or Tableau connects via Interface A (GraphQL), or when Copilot or Claude connects via Interface B (MCP Server), they receive data structured according to the MDG schema.
An element with stereotype Application Component (ArchiMate MDG) is queryable as “type = Application Component.”
An element with a custom stereotype SaaS Application (custom MDG extending Application Component) is queryable as “type = SaaS Application” — a more specific, meaningful dimension.
A tagged value Lifecycle Status with MDG-governed enumeration values is queryable as a structured filter: Lifecycle Status = End-of-Life returns all elements where the lifecycle status tagged value matches “End-of-Life” precisely.
A free-text note in an element’s documentation field that says “This app is end of life” is not queryable as a structured filter — the AI would need to parse unstructured text.
The implication: Every investment in MDG governance — defining more precise stereotypes, governing more tagged value enumerations, enforcing validation rules — directly improves the precision and reliability of AI and BI outputs from the repository. MDG is not a technical implementation detail; it is the foundation of intelligence quality.
Building vs Consuming MDG Extensions
Consuming built-in MDGs: Most Sparx EA users start by consuming built-in MDG extensions (ArchiMate, BPMN). This requires activating the extension in the Sparx EA project and using the appropriate element types from the toolbox. Sparx Services includes MDG activation and configuration in the Deploy engagement.
Building custom MDG extensions: Custom MDG development uses the MDG Technology editor in Sparx EA — a profile-based approach where stereotypes are defined by creating UML profile packages, tagged value definitions, and constraint specifications. The MDG Technology wizard packages these into a deployable .xml file that can be imported into any Sparx EA installation.
Custom MDG development is a specialist skill that requires understanding both the UML metamodel and the Sparx EA MDG implementation. Sparx Services delivers custom MDG design and implementation as the core of the Amplify engagement — building the governance framework that fits the organisation’s specific modeling needs and BI/AI integration requirements.
Deploying and Maintaining MDG Extensions
Deployment: Custom MDG extensions are deployed to the Sparx EA repository through the Project/Model Options > MDG Technologies menu. They can also be pre-deployed via Pro Cloud Server configuration, so all connecting Sparx EA clients automatically receive the MDG when they connect to the repository.
Version control: MDG extensions are XML files. They should be version-controlled in the organisation’s source control system (Git or equivalent). MDG version numbers allow compatibility tracking as extensions evolve.
Updates: When the MDG is updated (new tagged values added, new stereotypes defined, validation rules updated), the updated MDG is deployed to the repository and all clients. Existing elements are not automatically re-validated — a model validation run surfaces elements that no longer meet updated rules.
AI Assist validation: Sparx EA’s AI Assist feature can use MDG validation rules as part of AI-assisted modeling — suggesting correct stereotypes and flagging governance violations as architects model. This is a complementary AI capability (within the Sparx EA client) to the external AI query capability provided by EA GraphLink.
Frequently Asked Questions
Q: What is the difference between a stereotype and a tagged value? A stereotype defines a new element type — it extends a UML metaclass with a specific identity, icon, and relationship rules. An Application Component is a stereotype of UML Component. A tagged value is an attribute on an element of that stereotype — it is data attached to the element instance. Lifecycle Status, Business Owner, and Annual Run Cost are tagged values on Application Component elements. The stereotype defines “what type of thing this is”; tagged values define “what data this instance carries.” Both are MDG-governed.
Q: Do I need to build a custom MDG if I just use ArchiMate? You do not need a custom MDG to use ArchiMate — the built-in ArchiMate MDG provides the element types and relationships. However, you will likely want a custom MDG extension to add governance-specific tagged values to ArchiMate elements — lifecycle status, business owner, investment band, and so on. The ArchiMate MDG does not define these governance attributes; they are organisation-specific. A custom MDG extension that adds tagged value definitions to existing ArchiMate stereotypes (without redefining the stereotypes themselves) is the standard approach.
Q: How long does it take to build a custom MDG for an EA program? A focused MDG design and build for an EA program — covering the core stereotypes, tagged value definitions, validation rules, and diagram types — typically takes 4–8 weeks in the Amplify engagement. This includes discovery (what needs to be governed), design (the stereotype structure and tagged value vocabulary), build (the MDG XML implementation), testing (validation in a staging repository), and deployment. More complex MDGs (multiple domains, extensive validation rules) take longer.
Q: Can MDG validation rules automatically block elements from being saved without mandatory data? Yes. Sparx EA’s MDG validation can be configured to flag or block elements that violate rules. Blocking validation (enforced on save) requires integration with Sparx EA’s model validation framework and can be implemented via scripts triggered on element save events. Flagging validation (run on demand) surfaces violations across the repository but does not prevent saving. The appropriate enforcement level is a governance decision — stricter enforcement improves data quality but can slow modeling workflows. Sparx Services advises on enforcement strategy during the Amplify engagement.
Q: Is it possible to use multiple MDG extensions simultaneously? Yes. Multiple MDG extensions can be active in a single Sparx EA repository simultaneously — a common configuration is ArchiMate + BPMN + TOGAF Content Metamodel + custom organisational MDG. Element types from different MDGs coexist in the repository and can be linked by relationships. Diagram types from each MDG remain distinct. The main governance consideration is avoiding naming conflicts between stereotypes from different MDGs — a design discipline addressed in the Amplify engagement.
Q: What happens to MDG-governed data in the repository if the MDG is updated? Existing element instances retain their tagged values when an MDG is updated. If a tagged value is renamed in the MDG, existing data under the old name is retained but no longer recognised by the new schema — a migration step is needed. If new tagged values are added, existing elements will have empty values for the new attributes until populated. If validation rules are tightened, existing elements may now fail validation. MDG updates require a migration plan to manage the impact on existing repository data. Sparx Services includes migration planning in MDG update work.
Q: Can MDG Technology govern elements across multiple Sparx EA repositories? An MDG extension file can be deployed to any number of Sparx EA repositories — a single custom MDG can govern modeling standards across multiple repositories (e.g., a primary EA repository and project-specific repositories). The MDG provides consistent stereotypes and validation rules wherever it is deployed. Cross-repository element references (elements in one repository linked to elements in another) are supported in Sparx EA via the Remote Package feature.
Q: How does MDG Technology relate to Sparx EA’s Pattern (template) feature? MDG Technology defines the vocabulary (what element types exist and what attributes they have). Sparx EA Patterns (also called Model Templates or Model Patterns) define reusable structure — a pre-built package containing elements arranged in a standard way. A Pattern might provide a “Business Domain” template that creates a package with the standard sub-packages, diagram templates, and placeholder elements for a new business domain. Patterns and MDG work together: the MDG defines the element types; Patterns provide quick-start structures using those types. Both are part of the governance toolkit in the Amplify engagement.
Q: Is MDG Technology documentation available from Sparx Systems? Yes. Sparx Systems publishes extensive MDG Technology documentation in the Enterprise Architect online user guide. The documentation covers the MDG wizard, profile-based MDG development, tagged value definition, diagram extension, and validation rule implementation. Sparx Services recommends reviewing this documentation alongside the Amplify engagement — we build your organisation’s MDG while transferring knowledge to your team so you can maintain and extend it after the engagement.
Ready to Build Your MDG Governance Framework?
Sparx Services’ Amplify engagement delivers a custom MDG Technology extension designed for your organisation’s modeling standards and AI/BI integration requirements — including stereotype design, tagged value governance, validation rules, diagram templates, and deployment configuration.
The MDG is the foundation that makes your EA repository an intelligence asset rather than a diagram store.
