There is a version of this scenario in almost every organization that has adopted ArchiMate seriously: the notation is consistent, the team is trained, the modeling platform supports the language — and the repository still cannot be used reliably for reporting without significant manual reconciliation.
NovoCircle’s The Long Arc: A Practitioner’s Guide to the Six Stages of EA (Enterprise Architecture) Evolution maps how enterprise architecture practices mature through six stages, and identifies the move from common language to governed model as one specific — and frequently underestimated — transition along that arc. This post is an applied view of that transition.
Two business units produce application layers that cannot be merged because element types were applied with different assumptions. The same system appears in the repository under different names in different domains. A capability mapping that makes sense in one part of the enterprise maps to a completely different structure in another. The architecture is using a common language. The architectural decisions made within that language are not common at all.
This is the Stage 4 to Stage 5 transition — and it is one of the most underestimated challenges in EA practice development.
What Stage 4 Actually Delivers
Stage 4 — what the NovoCircle Long Arc framework calls “A Common Language” — is a genuine and significant achievement. It means that architecture is portable across people and organizations: a new architect joining from a different company can read existing models and contribute new ones without a guided tour, because the language, the methods, and the standards exist independently of any single team.
This is valuable. The work of Stage 4 — getting a team aligned on a shared modeling language, training consistently, establishing the element type library that gives everyone the same vocabulary — is hard work, and it eliminates a real class of coordination problems.
But Stage 4 still has a ceiling. The notation is consistent. The structural choices are not.
Every new architecture program built on ArchiMate starts from scratch on the same fundamental questions: what does “capability” mean in this organization? What is the correct top-level taxonomy for the application portfolio? How should location elements be structured — by country, by data center, by region, by legal entity? How granular should application elements be — should a platform with ten modules be one element or ten? None of these questions are answered by the ArchiMate specification. They are answered by your organization’s modeling standards — or, if those standards don’t exist, by each architect’s individual judgment.
When each architect answers those questions independently, the outputs look consistent at the level of notation and are not consistent at the level of structure. Two business units can both be using ArchiMate correctly and produce models that cannot be combined, compared, or reported on together — because the underlying structural assumptions are different.
The Difference Between Notation and Semantics
One of the subtler distinctions in the Stage 4 to Stage 5 transition is the difference between using ArchiMate as a notation and using it as a semantics.
ArchiMate as a notation means that the visual symbols are available: the boxes, the connectors, the color conventions, the element shapes that distinguish a business process from an application component from an infrastructure node. Most EA platforms that claim ArchiMate support give you this.
ArchiMate as a semantics means that the underlying repository enforces the type rules and relationship constraints that ArchiMate specifies: that an ArchiMate application element is typed as an application, that an ArchiMate serving relationship between a business process and an application has the directional and semantic meaning that the specification defines, that the metamodel enforces what elements can relate to what other elements in what ways. Fewer platforms implement this fully, and even fewer organizations configure what their platform supports.
A repository built with ArchiMate symbols but without ArchiMate semantics is a Stage 2 diagram with better icons. The visual consistency is Stage 4. The underlying model is not.
This distinction becomes consequential at Stage 5, where the repository needs to be trustworthy as a data source — machine-readable, semantically consistent, reliably queryable. A repository with ArchiMate notation but without ArchiMate semantics cannot be trusted as data. The same query run against two parts of the repository may return incomparable results because the element types were applied without consistent meaning.
What Stage 5 Actually Requires
The governance that makes a repository trustworthy operates at two levels that most practices conflate.
Process governance is what most EA teams already have by Stage 4: the Architecture Review Board, the governance calendar, the submission requirements, the review cadence. Process governance ensures that architecture decisions go through the right review. It does not ensure that the models produced by those decisions are structured consistently.
Model governance is what Stage 5 requires: the controls, enforced in the repository itself, that ensure every element is typed correctly, named consistently, related to other elements in semantically valid ways, and maintained at a completeness level that makes it trustworthy as a data source. Model governance catches inconsistencies at the point of creation rather than at the point of reporting.
The diagnostic for whether an organization has model governance is direct: can you pull a dataset from the repository and use it for a leadership report without manual reconciliation? If the answer is no — if the process of generating a portfolio report requires checking, correcting, and supplementing repository data with information from other sources — model governance is missing.
The Three Changes That Move From Stage 4 to Stage 5
1. Reference framework adoption — operational, not decorative. TOGAF (The Open Group Architecture Framework), BIAN, TMForum, DoDAF: these reference frameworks change the economics of an architecture practice by providing structural starting points for the decisions that Stage 4 leaves open. What is the standard taxonomy for capabilities? BIAN provides one for banking. What is the standard classification for applications? TOGAF’s application portfolio view provides a starting point. Adopting a reference framework operationally — meaning the framework structures the repository configuration, not just the governance documentation — closes the structural inconsistency that Stage 4 leaves behind.
2. Modeling standards embedded in the platform, not just documented. The modeling standards that exist only in a governance document are not enforced. An architect who hasn’t read the governance document recently, or who makes a judgment call under time pressure, produces elements that deviate from the standard. The standard says it was violated. The repository doesn’t know.
Modeling standards embedded in the platform — through element type libraries that enforce allowed properties, through relationship type constraints that enforce allowed connections, through naming convention validators that catch inconsistencies at creation time — are enforced by default. An architect cannot easily violate them without the platform flagging the deviation. This is the difference between standards that are aspirational and standards that are operational.
3. Data quality metrics that are tracked and acted on. Repository trustworthiness is not a state that is achieved and maintained automatically. It is a metric that has to be measured and managed. What percentage of application elements have all required properties populated? What is the completeness rate for capability mappings across business units? What is the rate of naming convention violations detected in the last quarter and how many have been resolved?
Organizations that track these metrics and treat them as governance outputs — not just as technical debt to be addressed eventually — produce repositories that are genuinely trustworthy. Organizations that don’t track them discover the problem when they try to use the repository for something that depends on it being reliable.
The AI Readiness Signal
The practical significance of the Stage 4 to Stage 5 transition goes beyond the quality of the current reporting. Stage 5, fully achieved, is the readiness state for AI (Artificial Intelligence) augmentation of the most valuable EA workflows.
AI-powered architecture analysis, governance automation, and stakeholder engagement tools all depend on a repository that is trustworthy as a data source. An AI agent querying a Stage 4 repository — notation consistent, structure not — produces outputs that reflect the structural inconsistencies of the underlying data. The outputs can be worse than no AI augmentation at all, because they look authoritative and are not.
A Stage 5 repository — model governed, semantically consistent, completeness-tracked — is the substrate that makes meaningful AI augmentation possible. The organizations that build Stage 5 rigorously, even when the immediate benefit seems incremental, are the organizations that will be able to move into Stage 6 (Architecture Without Amnesia) with a foundation that actually supports it.
Where NovoCircle Can Help
The Stage 4 to Stage 5 transition is detailed, specific work. It requires platform configuration, modeling standards development, reference framework adaptation, and governance process redesign — not in isolation, but in the right sequence and with the right dependencies between them.
NovoCircle’s EA advisory work is particularly focused on this transition: practitioners who have worked in repository-based EA environments, who understand the platform configuration choices that embed standards versus document them, and who have designed governance processes that produce model quality rather than just review volume.
If your practice is at Stage 4 — using a common language, running a governance process — and the repository still can’t be trusted for reporting, book a discovery call.
The Long Arc: A Practitioner’s Guide to the Six Stages of EA Evolution covers the full framework including detailed descriptions of Stages 4 and 5 and what the transition between them requires.
Ryan Schmierer is the founder of NovoCircle, a technology advisory practice specializing in Modern Enterprise Architecture and Intelligent Automation.