Direct Answer: MDG Technology (Model Driven Generation) is Sparx EA’s metamodel framework — the set of rules that defines what element types exist, what properties they carry, and how they connect. For AI, MDG is not optional plumbing: it is the semantic contract between your repository and every downstream system that queries it. EA GraphLink translates your EA repository into structured data for Power BI, Microsoft Fabric, and AI tools via MCP. If your MDG is inconsistent — undefined stereotypes, missing tagged values, ad hoc element types — EA GraphLink surfaces that inconsistency to every AI query and every BI dashboard. The rule is simple: garbage MDG, garbage AI output. Strong MDG governance is the single highest-leverage investment an EA team can make before connecting AI tooling.
Key Takeaways
- MDG Technology defines the semantic layer that EA GraphLink exposes to AI and BI systems — poor governance propagates directly into AI output quality.
- Inconsistent stereotypes and missing tagged values are the most common causes of broken AI queries on EA repositories.
- MDG governance is not a one-time configuration task; it requires discipline, ownership, and a change management process.
- The Amplify offering is specifically designed to build MDG governance discipline, not just configure MDG profiles.
- AI cannot repair bad MDG. It can only expose it more clearly and at greater scale.
What MDG Technology Is and Does
MDG Technology is Sparx EA’s built-in metamodel extension mechanism. Out of the box, Sparx EA supports ArchiMate, TOGAF, BPMN, UML, SysML, and others. MDG lets you extend those notations — or create proprietary ones — by defining:
- Custom stereotypes on existing metaclasses (e.g., a
«CriticalCapability»stereotype on an ArchiMate Business Capability) - Tagged values that carry structured properties on those stereotypes (e.g.,
CapabilityMaturityLevel,BusinessOwner,InvestmentCategory) - Shape scripts for visual rendering
- Validation rules that enforce structural constraints
The result is a controlled vocabulary for your repository. Every element created under a governed MDG profile is typed, named, and annotated consistently. That consistency is what makes the repository machine-readable.
Without MDG governance, architects create elements using whatever types seem close enough, add notes in free-text fields, and use different naming conventions across packages. The repository looks like architecture to a human scanning it. To a machine parsing it for structure, it looks like noise.
MDG as the Semantic Layer for EA GraphLink
EA GraphLink operates in two modes. Interface A exposes a GraphQL API that BI tools — Power BI, Tableau, Microsoft Fabric — query to retrieve architecture data. Interface B runs an MCP Server that AI tools such as Microsoft Copilot Studio, Claude, or custom agents connect to for natural language queries.
Both interfaces rely on the same underlying mechanism: they traverse the EA repository’s element graph, reading element types, stereotype names, tagged values, and connector types to build meaningful responses.
Consider a simple query: “Which applications support the Customer Onboarding capability, and what is their decommission status?”
For EA GraphLink to answer this, it needs:
- A
«Application»stereotype (or equivalent) with a tagged value calledDecommissionStatuscarrying a controlled vocabulary (Active, Under Review, Scheduled for Decommission). - A defined connector type — Realization or Serving — linking Application elements to Capability elements.
- Consistent population of those tagged values across the application portfolio.
If DecommissionStatus exists on 40% of applications, uses three different value formats (yes/no, true/false, Active/Inactive), and is missing on the remaining 60%, the AI query returns an unreliable partial answer. The AI will not hallucinate a value — it will report what is there, which is incomplete and inconsistent. That is not an AI failure. That is an MDG governance failure surfaced by AI.
Five Signs Your MDG Is Hurting Your AI Readiness
1. Architects use base metaclasses instead of stereotyped elements. You have Application Components and Business Functions in the repository, but no consistent stereotypes applied. EA GraphLink cannot distinguish a critical ERP from a departmental spreadsheet tool.
2. Tagged values are populated inconsistently. Key properties — owner, lifecycle status, business criticality — exist on the MDG profile but are empty or free-text on most elements. BI dashboards show null-heavy tables.
3. Naming conventions vary by team or project. The same application appears as “SAP ECC,” “SAP ECC 6.0,” and “ECC Core” across packages. Deduplication is a manual exercise before any meaningful query.
4. MDG profiles are undefined or unlocked. Architects can create any element type in any package with no enforcement. The repository is technically valid Sparx EA but has no consistent semantic structure.
5. Connector types are not enforced. Realisation, Association, Dependency, and Serving connectors are used interchangeably. The relationship graph cannot be traversed meaningfully for impact analysis or AI queries.
If you recognise three or more of these patterns, your AI investment will underperform until MDG governance is addressed. This is not a technology problem. It is a governance and discipline problem.
What Well-Governed MDG Looks Like
A mature MDG implementation has the following characteristics:
Controlled vocabulary at the stereotype level. Every significant element type in the repository has a defined stereotype with a clear purpose. «Capability», «ApplicationService», «DataEntity», «BusinessProcess» — each one is explicitly defined and documented.
Tagged value schemas with controlled values. Where freeform text is acceptable, it is intentional. Where structured data is needed — lifecycle status, maturity score, regulatory classification — the tagged value uses an enumeration with a defined list.
Validation profiles that run on save or commit. Sparx EA’s built-in model validation can enforce MDG rules. A validation profile that checks for missing mandatory tagged values before a package is baselined catches governance drift early.
MDG ownership. One named individual or a small team owns the MDG master profile and manages changes through a lightweight RFC (request for change) process. Ad hoc stereotype additions go through that owner.
Documentation in the repository itself. The MDG pattern library — descriptions of each stereotype, tagging guidance, usage examples — lives as a governed package in the EA repository, not in a Word document on SharePoint.
How Long Does It Take to Fix MDG Governance?
This is the honest answer: it depends on how long the repository has been running without governance, and whether you are correcting existing elements or only governing new ones.
For a repository with two to five years of ungoverned content, a realistic remediation programme runs twelve to eighteen weeks for the MDG definition phase, followed by a three to six month backfill and enforcement period. The MDG definition work is fast — typically two to four weeks of focused design. The hard part is retrospective population of tagged values on existing elements, which requires architect time and sometimes stakeholder interviews.
For greenfield or near-greenfield repositories, governed MDG can be established in four to six weeks and enforced from day one. This is the ideal scenario.
The Amplify engagement is sized around this reality. It does not pretend that MDG governance is a configuration task. It builds the operating model — ownership, change process, validation cadence — alongside the technical profile.
Can AI Assist Repair Bad MDG?
Kernaro Assist, Sparx Services’ in-EA AI tool, can accelerate MDG governance work. It can suggest stereotype assignments, flag elements that appear to be missing tagged values, and help architects apply consistent naming. But it cannot substitute for governance decisions that require business context.
Specifically: Assist cannot determine the correct value for BusinessCriticality on an application it has no context for. It cannot decide whether two differently-named elements represent the same real-world asset or two distinct ones. Those are judgment calls that require an architect with domain knowledge.
What Assist does well in an MDG governance programme is the mechanical work: identifying elements that do not conform to the defined profiles, suggesting corrections, and reducing the time it takes to backfill tagged values once the governance decisions have been made.
Is MDG Governance the Same as Naming Conventions?
No, though naming conventions are a component of good MDG governance. Naming conventions address how elements are labelled — a valuable discipline that significantly improves search and query results. MDG governance addresses the deeper question of what types of elements exist, what properties they carry, and how they relate.
You can have perfect naming conventions and still have a repository that EA GraphLink cannot traverse meaningfully, because the connector types are wrong, the stereotypes are undefined, or the tagged value schema is missing.
Think of naming conventions as the surface of governance and MDG as the structure underneath it. Both matter. MDG matters more for AI readiness.
FAQ
What is MDG Technology in Sparx EA? MDG Technology (Model Driven Generation) is Sparx EA’s metamodel extension framework. It lets you define custom element types (stereotypes), structured properties (tagged values), visual rendering rules, and validation constraints on top of any base notation — ArchiMate, UML, BPMN, or a proprietary language. MDG profiles are what give your repository a controlled, machine-readable semantic structure.
Why does MDG quality affect AI output? AI tools query the EA repository through EA GraphLink, which traverses element types, connector types, and tagged values to answer questions. If those structures are inconsistently applied — missing stereotypes, empty tagged values, mixed naming — the query returns incomplete or contradictory results. The AI reports what is in the repository. If the repository is poorly governed, the AI output reflects that. Improving MDG governance is the most direct way to improve AI output quality.
What does a well-governed MDG look like? A well-governed MDG has: defined stereotypes for every significant element type, tagged value schemas with controlled vocabularies, a named MDG owner who manages the profile through a lightweight change process, validation rules that are enforced on save or at baselined milestones, and governance documentation that lives in the repository itself rather than in external files.
How long does it take to fix MDG governance? For established repositories with ungoverned content: four to six weeks to define the MDG profile, followed by three to six months to backfill existing elements and enforce the new standards. For greenfield repositories, governed MDG can be established and enforced within four to six weeks. The definition phase is fast. The remediation of existing content is where time is spent.
Can AI Assist fix bad MDG? Kernaro Assist can accelerate MDG governance work — it can flag non-conforming elements, suggest stereotype assignments, and help with mechanical backfill of tagged values. But it cannot make governance decisions that require business context: which applications are critical, whether two elements represent the same asset, or what the correct lifecycle status is. Assist is a productivity multiplier for MDG governance work, not a replacement for it.
Is MDG governance the same as element naming conventions? No. Naming conventions govern how elements are labelled, which matters for search and human readability. MDG governance governs the deeper structure: what element types exist, what properties they carry, and how they connect. Both disciplines matter for AI readiness, but MDG structure has more impact on whether EA GraphLink can traverse and query the repository meaningfully.
Build MDG Governance That Makes AI Work
Sparx Services’ Amplify offering is designed for EA teams who want to connect AI tooling but know their repository governance is not ready. Amplify builds the MDG profile, the validation rules, the ownership model, and the change process — alongside deploying and configuring Kernaro Assist.
The result is a repository that AI tools can actually use, and a team that knows how to keep it that way.
