Sparx EA Repository Governance Checklist: 20 Things Every Architecture Team Should Have

A well-governed Sparx EA repository has twenty governance elements in place. Missing ones rarely show up as a documentation problem. They show up as a structural one, and they decide whether your team trusts the model or works around it. Use the list below as a diagnostic: score what you have today, mark the gaps, and you will know where the next quarter of governance effort should go.

Governance matters more now that AI does much of the work in the model. AI builds and changes content according to the rules it is given, quickly and consistently. A repository with clear, enforced rules gets content that follows them. A repository without them gets more inconsistency, faster.

The twenty items fall into four categories. They build on each other, so start at the top.

The four categories at a glance

Score each of the twenty items on the scale below, then count how many score 3 or 4. That count, out of twenty, is your governance score. A repository with more than sixteen is well governed. One with ten or fewer needs structural work before anything else is built on top of it.

Category 1: MDG / metamodel governance

This is the highest-impact 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, such as ArchiMate, BPMN, SysML, DoDAF or TOGAF, has a correctly configured profile active. Custom element types appear only where the standard profile falls short.

2. Element type restrictions enforced. Profiles control which element types can be created in which packages, so ArchiMate elements do not drift into UML design packages and BPMN elements do not 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, such as lifecycle status, owner, domain and application health, are configured as mandatory in the profile and checked, so missing values are caught instead of merely documented as required.

4. Enumeration constraints on controlled fields. Tagged values that should come from a fixed list (Lifecycle Status, Business Criticality, Review Status) use enumeration constraints instead of 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 separates a governed model from one that only looks governed.

Category 2: Element quality

The metamodel sets the rules. This category is about whether the content inside those rules is good.

6. Naming conventions documented and enforced. A naming convention exists for every element type in use, names follow it consistently, and a validation check catches exceptions. Naming is the most visible quality signal in any repository.

7. Element descriptions populated. Every element with a public-facing purpose, such as capabilities, applications, business processes and data objects, carries a description a non-architect can read. Empty description fields are the most common reason a model captures something and 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 elements are created 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 captured using Sparx EA’s baseline capability, so current and target states can be compared, and so there is a recovery point before large changes. 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 and how change is controlled.

11. Role-based access control configured. Sparx EA user security matches the team: read-only for stakeholders, contributor for domain architects, administrator for leads and repository managers. A default setup where everyone is an administrator is the 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, so it survives the people who 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 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 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, dashboards and AI return trustworthy answers.

16. Element types consistent across the repository. Element types come from the standard profiles instead of a sprawl of one-off custom types. Consistent typing is what lets reporting and AI 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 questions can be scoped cleanly. Asking for every application in the Finance domain only works when Finance is a recognizable scope in the model.

19. Data kept current at the source. Values such as lifecycle status, cost, ownership and risk are not typed in once and left to go stale. They come from the PPM, ITSM, eGRC and ITFM systems that own them, brought into the model on a defined cycle, with an owner for each value. Stale data is worse than missing data, because it looks authoritative while being wrong.

20. Reporting and validation routines in place. Standard reports, queries and model-validation checks run on a schedule, so the repository’s state is observed instead of assumed. Validation that runs regularly catches drift before it compounds.

How to read your score

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.

Running the checklist AI-augmented

Today an architect works through a list like this by hand: opening profiles, running searches, sampling packages and counting orphans, usually once a year if at all. Working AI-augmented, the architect states the rules, such as the profiles, the naming conventions, the mandatory values and which system owns each one, and AI runs the checks across the whole repository, lists every exception with where it sits, and proposes fixes where the evidence supports one. It can run as often as the model changes. Automation checks completeness, people own correctness. Whether an orphan is dead or simply not yet connected, whether two similar elements are duplicates, and whether a missing stereotype was an accident or a decision are for the architect and the package owner to decide. The skill is writing the rules precisely enough to check against, and judging the exceptions. Tools that help include Claude or GitHub Copilot with AI Power Tools for Sparx EA, and Kernaro Assist in the EA client.

Frequently asked questions

Close the gap

Governance is what makes a Sparx EA repository an asset the whole organization can rely on. Paralysis to a Plan gives you a scored assessment of where your repository stands. Configure the Solution sets up access, structure and review processes, and we can build the MDG, rulesets and model that close the remaining gaps. See how we help architecture leaders.