Governance
In this section
| Page | What it covers | Code | Cowork | Desktop chat | VS Code |
|---|---|---|---|---|---|
| Validate a model against a ruleset | Run a conformance ruleset (the ArchiMate 3.1 set, your own file, or one hosted at a web address) against the whole model or one package, then interpret and fix the findings. | Yes | Yes | With you | With you |
| Author a ruleset | Write a complete ruleset for a modeling language (required tags, allowed values, connector counts, endpoint stereotypes) and prove it against known-good and deliberately bad content. | Yes | Yes | With you | With you |
| Catch a non-conforming change | Catch what does not conform to your modeling standard at the moment of change: an architect adds a component to a project, and validation flags it before it is promoted. | Yes | Yes | With you | With you |
| Clean up model decay | Find orphan elements, composite-diagram links that have fallen out of sync, and inconsistent stereotype or tag use, then fix them without deleting anything that is still load-bearing. | Yes | Yes | With you | With you |
| Find ungoverned elements | Before a reporting build, list the elements no report will show because they carry no stereotype, and fix them where the evidence supports it. | Yes | No | No | With you |
| Protect a change with a baseline | Take a snapshot of a package before a bulk or destructive change, compare afterward, and either keep the change or roll the package back. | Yes | Yes | With you | With you |
| Assess the language situation | Find out what state the repository's modeling language is in, and whether a technology is really installed, loaded and enabled, before you change it. | Yes | Partly | With you | With you |
| Hand-author an MDG Technology | Write the MDG Technology XML for a modeling language, with stereotypes, tagged values, toolbox pages and diagram types, then deploy and test it. | Yes | Yes | With you | With you |
| Build an MDG Technology from a source model | Build a technology from profile packages that live in the repository, through to the XML file, a version stamp and a verified deployment. | Yes | Yes | With you | With you |
| Generate an MDG Technology from current usage | Turn the stereotypes, metaclasses and tagged values that a repository actually uses into a formal technology. | Yes | No | No | With you |
| Deploy an MDG Technology and prove it works | Put a technology into a model, or onto a machine, and prove with runtime checks that it works, then retire the builds it replaces. | Yes | Yes | With you | With you |
Where it runs: Yes = runs fully · With you = runs, and you do the steps in EA’s window · Partly = one part needs a capability the client lacks · No = not available · TBC = to be confirmed
Governance is keeping the model conformant and under control: checking it against your modeling standard, catching a non-conforming change before it is promoted, cleaning up decay, making changes reversible, and owning the modeling language the repository uses. AI Power Tools confirms completeness and conformance to the rules you set. Whether the architecture is right is a judgment that stays with you.
How to read these scenarios: How to read a scenario. Examples use Westbrook Bank as an illustration. Substitute your own model, technology and paths. Run the start-of-session check (Start a session safely) before any write.
Conventions in these scenarios. Westbrook Bank is a fictitious reference organization. Its technology id is WBA and its stereotypes look like WBABusinessApplication. They appear as an illustration; substitute your own technology, stereotypes and tag names. Nothing in these scenarios assumes you have the Westbrook model.
Modeling languages. In Sparx EA, a modeling language is delivered as an MDG Technology: stereotypes, tagged values, toolbox pages and diagram types, packaged as an XML file. The scenarios here use Westbrook Bank's WBA technology as the illustration. You use your own technology id and your own stereotypes, and you do not need the Westbrook model.
Where a technology lives. A technology can reach EA in three ways, and Manage Technology (Specialize, Technologies) shows where each copy is stored in its Location column. Two of the places are inside the model.
| Where | Location in Manage Technology | What it keeps | Reaches |
|---|---|---|---|
| In the model, whole technology | Model | Everything, toolbox pages included | Everyone who opens the model |
| In the model, profiles only | Project | The profiles and the diagram types. No designed toolbox pages: EA shows one automatic page built from the stereotypes | Everyone who opens the model |
| On one machine | The file name | Everything | That machine only |
Prefer Location: Model. Location: Project is for a technology that has no toolbox pages. AI Power Tools reads both in-model Locations. For a technology it reports where each copy is stored and its version, and when the model holds the same id at both Locations it says so: EA answers from the Project copy, so a Project copy shadows the Model copy. A technology disabled in Manage Technology is reported as registered but not enabled, and not as available for modeling.
Deploying at Location: Model builds the technology from an «mdg technology» package in the open model, toolbox pages included, and reads back what was stored. A Project copy of the same id can be replaced at the same time. If EA keeps it, reopen the project and run the step again. A technology file reaches Location: Model only through EA's own Import MDG Technology, with Import to Model, which exists only in EA's interface. Restart EA before judging the toolbox.
Choosing a modeling-language scenario. The first question is whether the technology has a source model.
| Situation | Scenario |
|---|---|
| You do not know what state the repository is in | Assess the language situation, first |
| No source model. A small technology, or a one-off | Hand-author an MDG Technology (direct XML) |
| The stereotypes already exist as a profile package in a repository, or the technology has versions, several authors or a reviewed metamodel | Build an MDG Technology from a source model (model-driven) |
| The language exists only as habits: stereotypes in use, with no technology behind them | Generate an MDG Technology from current usage |
| You have a technology XML file or an «mdg technology» package and need it in a model or on a machine, or need to prove that it works | Deploy an MDG Technology and prove it works |