Repository governance is the work that makes everything else possible. An ungoverned Sparx EA repository produces architecture data that can’t be trusted: by stakeholders, by AI tools, or by the architecture team itself. MDG Technology is the primary governance mechanism in Sparx EA, and the gap between a governed and an ungoverned repository is the difference between AI integration that works and AI integration that produces confidently wrong answers.
Key Takeaways
“Repository governance” is sometimes interpreted narrowly as naming conventions and access control. That’s a fraction of what it covers. Comprehensive repository governance in Sparx EA encompasses:
Metamodel governance: MDG Technology definition: what element types exist in this repository, what properties they require, what relationships between elements are valid, and what relationship types are prohibited. This is the architectural foundation of governance.
Naming conventions: defined and, critically, enforced. Enforcement through MDG scripts or Kernaro Assist event agents rather than style guides and hope.
Ownership and accountability: every element has an assigned owner who is accountable for its accuracy. Not the architect who created it: the business or technical owner who can validate whether it still reflects reality.
Access control: Pro Cloud Server role-based access defining who can read, create, modify, and approve changes. Access control isn’t just a security concern; it’s a governance control that prevents unauthorized changes to governed content.
Baseline management: capturing and preserving model states at defined milestones: program reviews, governance board meetings, major architecture decisions. Baselines enable comparison between what was decided and what was built.
Quality metrics: coverage of required tagged values, element age since last review, orphan elements with no relationships, relationship completeness ratios. Governance that can’t be measured can’t be managed.
Each of these requires deliberate design. None of them is the default state of a Sparx EA installation.
MDG Technology (Model Driven Generation Technology) is Sparx EA’s mechanism for extending and customizing the modeling environment. For governance purposes, it is the most important configuration in the tool.
Element stereotypes: MDG defines custom element types that extend base notation types. Instead of generic UML or ArchiMate elements, a governed repository uses organization-specific stereotypes: “Application Component (Certified)”, “Application Component (Proposed)”, “Data Entity (Critical)”, “Business Capability (Active)”. These distinctions matter for filtering, reporting, and AI queries.
Tagged value requirements: MDG defines which properties are required for each stereotype. An element cannot be saved without the required fields. This is the mechanism that moves governance from advisory to enforced. A “Data Entity (Critical)” element might require: data owner, classification level, GDPR relevance flag, and retention period. These fields cannot be skipped.
Relationship constraints: MDG can restrict which relationship types are valid between which element types. This prevents architecturally invalid connections: for example, preventing a direct dependency from a Business Capability to a Technology Component that bypasses the application layer. Clean relationship models are what enable meaningful cross-domain queries.
Profile templates: new elements created from MDG-governed templates inherit the correct stereotype and default property values. This accelerates correct modeling and reduces the likelihood of ungoverned elements being created inadvertently.
A rapid MDG maturity assessment uses one primary indicator: what percentage of elements in the repository have informal (no custom stereotype) typing? If more than 30% of elements use base UML or ArchiMate types without organizational stereotypes, governance work is needed before AI integration will produce reliable results.
Secondary indicators: what percentage of Application Component elements have all five required APM tagged values populated? What percentage of relationship elements have a rationale or owner annotation? What is the age distribution of elements: how many haven’t been reviewed in over 24 months?
The Discover service quantifies these metrics as part of its baseline assessment. The Deploy service remediates them.
Most governance problems in inherited Sparx EA repositories fall into three patterns. They’re worth naming directly because they require different remediation approaches.
The symptom: elements created with default UML or ArchiMate types rather than governed stereotypes. A repository that was built without MDG configuration: often because the team started modeling before governance was designed.
The consequence for AI integration: EA GraphLink cannot reliably distinguish element types when they are all expressed as generic UML Classes or ArchiMate Application Components without stereotypes. Queries that depend on element type distinctions return incorrect or incomplete results.
The remediation: MDG Technology definition followed by a bulk stereotyping exercise to apply correct stereotypes to existing elements. Scripted where possible; manual verification for ambiguous cases. Time-intensive for large repositories; essential before AI integration.
The symptom: required properties populated in some elements, absent in others. The portfolio has lifecycle tags on 40% of applications. The rest have none, or have free-text values that the dashboard can’t process: “active”, “Active”, “ACTIVE”, and “live” all meaning the same thing but appearing as four distinct values in a filter.
The consequence: portfolio dashboards show incomplete data. AI queries return partial answers that can’t be distinguished from complete answers. The Copilot query “which applications are approaching end of life?” returns only the applications where the lifecycle field was populated: the others are invisible to the query.
The remediation: MDG enforcement (to prevent recurrence), followed by a data quality campaign to populate missing tagged values. Ownership assignment is critical here: the architecture team can’t fix this alone; application owners need to provide the correct values for their applications.
The symptom: elements without assigned owners, or with owners who have left the organization or changed roles. The repository accumulates stale data because nobody has accountability for reviewing it.
The consequence: the repository fills with elements that were accurate when created and are now wrong. The architecture team can’t identify which elements are stale without knowing who to ask. The governance board can’t manage what it can’t assign.
The remediation: ownership assignment as a governance policy, with MDG enforcement (owner is a required tagged value), a governance cadence for ownership review, and an escalation process for elements whose owners are no longer reachable. This is as much an organizational design problem as a technical one.
Before AI integration, repository governance was primarily an internal quality concern. Architects cared about it because bad data made their work harder. Stakeholders didn’t see the data directly, so governance failures were mostly invisible outside the architecture team.
After AI integration, governance failure is visible at the executive level.
When Copilot or Kernaro AI Hub returns an incorrect answer about the application portfolio: because the underlying data is stale or inconsistently tagged: the stakeholder who receives that answer has no way to know it’s wrong. They act on it. When the error surfaces, the consequence isn’t “the architecture data was imperfect.” The consequence is “the architecture AI told us the wrong thing.” Trust in the architecture function erodes faster through AI-amplified errors than it ever did through imperfect PowerPoint reports.
Governance is no longer a quality-of-life improvement for architects. It’s the trust foundation for every AI-enabled interaction the organization has with architecture data.
The Deploy service establishes repository governance from the ground up, or remediates an inherited repository that has accumulated governance debt. A governance-focused Deploy engagement typically covers:
MDG Technology definition: designing and implementing the organization’s element stereotypes, tagged value requirements, relationship constraints, and profile templates. For organizations with an existing MDG configuration, this includes gap assessment and remediation.
Naming convention scripting: naming conventions documented in a style guide are aspirational. Naming conventions scripted as MDG validation rules or Kernaro Assist event agents are enforced. Deploy implements enforcement, not documentation.
Access control configuration: Pro Cloud Server role and permission design based on the organization’s governance model: who can create new elements, who can approve changes to certified content, who has read-only access.
Ownership assignment: process design for ownership tracking, including the MDG tagged value configuration, the governance review workflow, and the escalation path for unowned elements.
Quality metrics dashboard: typically a Power BI dashboard connected via EA GraphLink, showing current governance coverage across the repository: percentage of elements with required tags populated, age distribution, orphan element count, and ownership coverage.
Governance board setup: the organizational structure that owns repository governance: typically a small group with defined authority over MDG changes, element approval, and governance standard updates. Deploy includes governance board charter, operating cadence, and initial backlog.
Deploy establishes the foundation. Governance doesn’t end there. The Amplify service builds the capability for the architecture team to operate the governance practice independently: including Kernaro Assist automation for governance workflows, governance quality reporting, and the structured development of governance competency across the team.
What is MDG Technology and why does it matter for governance?
MDG Technology (Model Driven Generation Technology) is Sparx EA’s framework for customizing and extending the modeling environment. For governance, it is the mechanism that moves standards from advisory to enforced. MDG defines custom element types (stereotypes), required properties for each element type, valid relationship types, and profile templates for new elements. Without MDG configuration, governance relies entirely on architects following guidelines: which produces inconsistent results in practice. With MDG, governance is built into the tool behavior itself.
How do I enforce naming conventions in Sparx EA?
Three options, in increasing enforcement strength: a documented naming convention (weakest: aspirational only); MDG validation scripts that flag non-compliant names when elements are saved (moderate: visible but bypassable); Kernaro Assist event agents that automatically correct or reject non-compliant names at creation time (strongest: automated enforcement). Most mature EA practices implement MDG validation at minimum, with event agent automation for the highest-volume element types.
What access control options does Sparx EA support?
Sparx EA’s access control model, implemented through Pro Cloud Server, supports: package-level read/write permissions; role-based access profiles; element-level lock and approval workflows; user group definitions with inherited permissions; and integration with Active Directory for organization-wide identity management. The right access control design depends on the governance model: particularly the distinction between “anyone can create, specific roles can approve” workflows versus simpler read/write separation.
How do I assess the governance maturity of an inherited repository?
A rapid assessment focuses on four indicators: (1) percentage of elements with custom stereotypes versus default types: measures metamodel governance; (2) percentage of application-layer elements with all required tagged values populated: measures tagging consistency; (3) percentage of elements with an assigned owner: measures accountability; (4) age distribution of elements: measures governance cadence. These four indicators, combined with a sample review of relationship quality, give a reliable picture of remediation scope. The Discover service produces this assessment as a deliverable.
What should every element in a governed repository have?
At minimum: a governed stereotype (not a default UML or ArchiMate type); an assigned owner; a creation date and last-reviewed date; and the required tagged values for its stereotype. Elements in the application layer should additionally have business capability relationships and technology infrastructure relationships. Elements in the data layer should have data owner and classification tags. The exact requirements vary by element type and are defined in the MDG configuration: this is why MDG design precedes repository population.
How do I handle stale elements in a large repository?
A governance-driven approach: (1) Define “stale” in the governance policy: typically elements that have passed their review date, or elements that have not been modified in 18-24 months and have no review date set. (2) Use a governance quality dashboard (Power BI + EA GraphLink) to identify stale elements by owner and domain. (3) Run a quarterly governance campaign to review flagged elements: owners confirm currency or update. (4) Elements that cannot be verified move to an “Unverified” lifecycle status rather than being deleted, preserving the record while flagging unreliability. (5) Elements that are confirmed outdated are retired, not deleted: retirement preserves the historical record.
What is the difference between Deploy and Amplify for governance improvement?
Deploy establishes the governance foundation: MDG configuration, access control, naming convention enforcement, quality metrics, and governance board setup. Deploy is the technical and process setup phase. Amplify builds the practice capability to operate and expand governance independently: Kernaro Assist automation for governance workflows, architect training in governance tools and techniques, self-service governance reporting, and the development of governance as a team competency rather than a Sparx Services dependency. A typical progression is Deploy first, then Amplify once the foundation is stable.
How does repository governance quality affect AI integration results?
Directly and significantly. EA GraphLink translates repository content into AI-accessible data. When element types are consistently governed through MDG stereotypes, AI queries can filter accurately by element type. When tagged values are consistently populated, AI queries can use those values as filter criteria. When relationships are structurally sound, AI can traverse cross-domain relationships to answer multi-layer questions. Poor governance produces queries that return partial results, incorrect type filtering, and relationship traversals that miss dependencies. The MDG readiness assessment in the Discover service specifically evaluates AI integration readiness: not just internal governance quality.
Deploy: repository governance establishment from scratch or remediation of inherited repositories. $30K–$130K depending on repository size and governance scope.
Discover: governance maturity assessment, MDG readiness baseline, and prioritized roadmap. $25K–$75K. The right starting point if the current governance state is uncertain.
Amplify: once governance is established, Amplify builds the team’s capability to operate and expand it independently, including Kernaro Assist governance automation. $45K–$160K.
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.