Sparx EA Repository Governance Checklist: 20 Things Every Architecture Team Should Have
A well-governed Sparx EA repository has twenty governance elements in place. Most repositories have eight to twelve. The distance between those numbers rarely shows up as a documentation problem — it shows up as a structural one, and it is the difference between a model your team trusts and one they quietly work around. Treat the list below as a diagnostic: score what you have today, mark the gaps, and you will know exactly where the next quarter of governance effort should go.
The twenty items fall into four categories. They build on each other, so the order matters — start at the top.
MDG / Metamodel governance
Whether the metamodel is enforced in the tool, not just written down. This category governs everything below it.
Element quality
Whether names, descriptions, and diagram links are clean enough that someone other than the author can read the model.
Access and ownership
Whether the repository knows who owns what, who can change what, and how changes get reviewed.
Structure and queryability
Whether the model is organized and consistent enough to be queried, reported on, and reused with confidence.
Score each of the twenty items on a simple scale, then total them. A repository scoring above sixteen is genuinely well governed; one below ten needs structural work before anything else gets built on top of it.
Category 1: MDG / metamodel governance
This is the highest-leverage category. An MDG Technology profile is where type rules, mandatory fields, and relationship validity live — get these five right and most downstream quality problems never start.
1. Active MDG profiles for every framework in use. Each framework in the repository — ArchiMate, BPMN, SysML, DoDAF, TOGAF — has a correctly configured profile active. Custom element types appear only where the standard profile genuinely falls short.
2. Element type restrictions enforced. Profiles control which element types can be created in which packages, so ArchiMate elements never drift into UML design packages and BPMN elements never land in business-architecture packages. Type pollution is one of the most common quality problems in large repositories.
3. Mandatory tagged values enforced. Critical tagged values — lifecycle status, owner, domain, application health — are configured as mandatory in the profile. Not documented as required: technically enforced, so an element cannot be saved without them.
4. Enumeration constraints on controlled fields. Tagged values that should come from a fixed list (Lifecycle Status, Business Criticality, Review Status) use enumeration constraints rather than free text. Consistent values are what make a repository filterable and reportable.
5. Relationship validation rules active. Relationship constraints block invalid connections — for instance, stopping an Application Component from being wired to a Business Actor with a plain Association when the correct relationship is Serving. Relationship discipline is what separates a governed model from a governed-looking one.
Category 2: Element quality
The metamodel sets the rules; this category is about whether the content inside those rules is actually good. Clean elements are the difference between a model people use and a model people distrust.
6. Naming conventions documented and enforced. A naming convention exists for every element type in use, and names follow it consistently — held in place by Quick Linker rules or a validation script. Naming is the most human-visible quality signal in any repository.
7. Element descriptions populated. Every element with a public-facing purpose — capabilities, applications, business processes, data objects — carries a description a non-architect can read. Empty description fields are the most common reason a model technically captures something yet communicates nothing.
8. Diagram-to-element traceability maintained. Elements appear on at least one diagram, and diagrams are linked to the packages they represent. Orphan elements (on no diagram) and ghost diagrams (referencing deleted elements) get cleaned up on a regular cycle.
9. No duplicate elements. The repository does not hold multiple elements standing for the same real-world thing. Duplicates appear when architects create elements without checking what already exists; a disciplined model search habit prevents new ones, and periodic audits catch the old ones.
10. Baseline versions maintained. Approved architecture states are locked using Sparx EA's baseline capability, so current state and target state can be compared. Without baselines, gap analysis is informal and version history is guesswork.
Category 3: Access and ownership
A repository nobody owns degrades fastest. This category is about accountability — who is responsible for what, and how change is controlled.
11. Role-based access control configured. Sparx EA user security is set up to match the team: read-only for stakeholders, contributor for domain architects, administrator for leads and repository managers. The default "everyone is an admin" setup is the single largest integrity risk a repository carries.
12. Package ownership assigned. Every top-level package has a named owner — the architect answerable for its content, quality, and upkeep. Ownerless packages accumulate technical debt faster than any others.
13. Architecture review process documented and active. A formal route exists for reviewing and approving changes to baseline content, and new models pass through it before being baselined. The process is written down, not just understood by the people who happen to remember it.
14. Change log maintained. Significant changes are recorded — what changed, who changed it, why, and when. Sparx EA's audit log, or an equivalent process, supplies the record. Without one, past decisions cannot be reconstructed when someone inevitably asks.
15. External stakeholder access governed. Where stakeholders read the repository directly or through reports, that access is granted by role, reviewed on a cycle, and revoked when it is no longer needed. Ungoverned stakeholder access is both a security risk and a quality risk.
Category 4: Structure and queryability
The first three categories make the model correct. This one makes it usable at scale — consistent and well organized enough that reports, searches, and analytics return trustworthy answers instead of noise.
16. Element types consistent across the repository. Element types come from the standard profiles rather than a sprawl of one-off custom types. Consistent typing is what lets any reporting or analytics layer classify and roll up content reliably.
17. Relationship structure traversable. Relationships are correctly typed and connected end to end. A Serving relationship between an Application Component and a Business Service tells a different story than an informal Association — and only correctly typed relationships make traceability and impact analysis meaningful.
18. Package structure supports scoped queries. The top-level structure organizes content by domain (Business, Application, Technology, Data) and by phase (Baseline, Target) so that questions can be scoped cleanly. "Show me every application in the Finance domain" only works when Finance is a recognizable scope in the model.
19. Data freshness process active. A defined cycle keeps tagged values current — lifecycle status, health scores, and owners reviewed quarterly for the application portfolio and annually for capability models. Stale data is worse than missing data: it looks authoritative while being wrong.
20. Reporting and validation routines in place. Standard reports, queries, and model-validation checks are configured and run on a schedule, so the repository's state is observed rather than assumed. Validation that runs regularly catches drift before it compounds.
How to read your score
0–10 · Structural work needed
The repository lacks the governance to be relied on. Start with Category 1 — getting the first five items in place has the largest knock-on effect on everything after. Paralysis to a Plan is the right entry point.
11–15 · Targeted remediation
Governance functions, but with real gaps. Find the weakest categories and address those specifically rather than trying to fix everything at once.
A score of 16–20 means the foundation is sound: the metamodel is enforced, content is clean, ownership is clear, and the structure is consistent enough to query. From here, governance shifts from building the foundation to keeping it — which is a far easier job.
Frequently asked questions
What is the single most important governance item?
Active, correctly configured MDG profiles (item 1). The metamodel governs element types, relationship validity, mandatory tagged values, and enumeration constraints — every other control flows from it. A repository without effective MDG governance cannot be reliably governed by any other means.
How do I assess my current MDG maturity?
Open each active profile and check four things: are element type restrictions configured, are any tagged values marked mandatory, are enumeration lists set for controlled values, and are relationship constraints active? If all four are weak, MDG is where your governance effort will pay back fastest. A Sparx Services Paralysis to a Plan engagement includes a structured MDG maturity assessment as a core deliverable.
How often should I audit repository governance?
Quarterly for fast-changing content such as the application portfolio and technology standards, and annually for slower-moving content such as capability models and business architecture. A lightweight monthly check on MDG compliance — using Sparx EA's search and model-validation features — catches drift before it accumulates.
What score should prompt outside help?
A score below thirteen usually means the governance infrastructure needs deliberate attention rather than incremental self-improvement. Configure the Solution establishes MDG profiles, package structure, access controls, and review processes in a defined timeframe — the work that moves a repository out of the 8–12 range and into the high teens.
Close the gap
Governance is what makes a Sparx EA repository an asset the whole organization can lean on rather than a private modeling exercise. If you want a clear-eyed read on where your repository stands today, Paralysis to a Plan provides the scored assessment; Configure the Solution does the structural work to close the gaps. Both connect to how Sparx Services helps architecture leaders get more from the platform they already own.
Keep reading
You might also be interested in
How to Configure MDG Technology in Sparx EA
A governance setup guide for the metamodel layer that drives items 1 through 5.
Read → InsightWhat Is MDG Technology in Enterprise Architect?
The definition and governance role of MDG — the single highest-leverage control on this list.
Read → For leadersParalysis to a Plan
Turn this checklist into a scored, prioritized governance baseline.
See how → For leadersConfigure the Solution
The hands-on work that moves a repository from 8–12 into the high teens.
Explore →Know your real governance score.
Talk to a practitioner about assessing your Sparx EA repository against these twenty elements — and closing the gaps that matter most.
Book a call →