NovoCircle’s The Long Arc: A Practitioner’s Guide to the Six Stages of EA (Enterprise Architecture) Evolution maps enterprise architecture evolution across six stages, from the most informal practice to the most AI (Artificial Intelligence)-augmented. What follows is a practical guide to identifying where your practice sits and what that diagnosis means for your next investment.
One of the most useful things you can do for an enterprise architecture function is locate it honestly on a maturity arc. Not to generate a score for a slide deck — but because where you are determines what the next step requires, and the most common mistake in EA practice development is trying to build Stage 4 capability on a Stage 2 foundation.
The Six Stages at a Glance
| Stage | Name | The Organizing Idea |
|---|---|---|
| 1 | The Carried Map | Architecture exists only inside one person |
| 2 | The Age of Diagrams | Architecture survives the meeting, but not the year |
| 3 | The Connected Repository | Elements have identity; the model has memory |
| 4 | A Common Language | Architecture becomes portable across people and organizations |
| 5 | The Governed Model | The repository earns the right to be trusted as data |
| 6 | Architecture Without Amnesia | AI ends the era of conclusions without reasoning |
The stages are developmental. You cannot skip one without paying the cost later. An organization that jumps from Stage 1 to Stage 4 because a consultant configured a tool for them will find that the Stage 2 and Stage 3 work still needs to be done — it has just been deferred, and now it needs to happen inside an already-configured environment, which is harder.
Stage 1: The Carried Map
Architecture exists only inside one person.
What it looks like from the inside:
There is an architect in almost every organization at this stage, even if nobody calls them that. They may be a senior infrastructure engineer who has been there for twelve years. The IT (Information Technology) director who personally reviewed every system implementation since the company outgrew its first server. The solutions architect who built the integration layer and is the only person who understands how it behaves under load.
These people carry an extraordinarily detailed map of the organization’s technology landscape. They know which systems interact, which integrations are fragile, which decommissioned component is still silently receiving traffic from something that was supposed to be updated two years ago. They are the organization’s institutional memory.
Signs you might be here:
– When a new initiative requires understanding the current technology landscape, one specific person gets pulled into the conversation
– You have no formal architecture documentation, or the documentation that exists is so out of date it isn’t consulted
– Technology decisions happen without reference to an architecture function
– A departure or retirement would leave significant organizational knowledge gaps
What triggers the transition:
The carried map has a fatal vulnerability: it leaves when the person leaves. A retirement, a resignation, or an acquisition can remove the map from the organization overnight. The knowledge didn’t leave gradually — it left the day the email account was deactivated. Other triggers: a major initiative that requires integrating systems nobody has mapped, a security audit that reveals nobody can answer basic questions about data flows, or new leadership that won’t operate without documented rationale.
What has to change:
The first change is cultural, not technical. The organization has to accept that architecture is a shared function, not an individual attribute. The tool is secondary at this stage. A SharePoint wiki, a shared notebook, a simple diagramming file — any of these can hold Stage 1’s first external record. The commitment to maintaining something is more important than what that something is built in.
Stage 2: The Age of Diagrams
Architecture survives the meeting, but not the year.
What it looks like from the inside:
The most common Stage 2 tool is not Visio. It is PowerPoint.
When an organization commits to capturing its architecture for the first time, it reaches for the tools it already knows how to use. Architects build system landscape slides. They create data flow diagrams in Word documents. They maintain Visio files on SharePoint. Some teams use draw.io or Lucidchart for collaborative sessions.
All of these tools share a fundamental limitation: a box is a shape. It has no identity, no type, no properties, and no persistent relationships. The “Payments Application” box on the system landscape slide and the “Payments Application” box on the integration diagram are two independent rectangles with the same label. Change one and the other stays wrong.
The result is a pathology that every Stage 2 practitioner recognizes: diagrams age into fiction.
Signs you might be here:
– You have architecture documentation, but you describe it as “not fully current” or “directionally correct”
– When you present architecture to stakeholders, you add verbal caveats about which parts are accurate
– Different teams maintain their own versions of overlapping diagrams with no mechanism for reconciliation
– A diagram is posted to SharePoint after an architecture review and nobody touches it again
– You hear the phrase: “We have documentation, but we can’t trust it”
What triggers the transition:
The diagnosis is almost always the same sentence: “We have documentation but we can’t trust it.” The underlying problem is not that the diagrams are out of date. It is that the format provides no mechanism for keeping them current. When a system changes, nothing in a PowerPoint file automatically changes with it. Maintenance requires human memory and discipline. At scale, both run out.
What has to change:
The shift from a presentation tool to a modeling tool is the most significant transition in the EA evolution. It requires accepting a fundamentally different mental model of what an architecture artifact is. The tool doesn’t change first — the understanding of what a repository is, and why an element is different from a shape, has to come first. This is often the stage at which organizations seek outside help, because the conceptual shift is harder than the technical one.
Stage 3: The Connected Repository
Elements have identity; the model has memory.
What it looks like from the inside:
In Stage 3, a box is no longer a shape. It is an element: an object with a unique identity, a defined type, properties that describe it, and relationships that connect it to other elements. That element exists once in the repository and can appear on any number of diagrams. Change its name once and it changes everywhere. The diagram is no longer the artifact — it is a view of the underlying model.
The value of this shift becomes clear in a crisis. When COVID-19 forced organizations to shift to remote work overnight, IT leadership asked: what applications does the helpdesk team depend on to support customers, and can all of it run remotely? For most organizations, answering that question took more than a week. For a team with a connected repository, it was a 30-second query. The repository didn’t make the crisis smaller. It made the organization capable of seeing itself clearly enough to respond.
Signs you might be here:
– You use a dedicated EA modeling platform (not diagramming tools)
– Elements have persistent identities — changing a name in one place changes it everywhere
– Impact analysis is possible: you can query “what depends on this system?”
– Architecture review boards evaluate proposals against a model, not against individual diagrams
– The repository is growing, but trust in it is mixed — “it’s valuable, but only we can navigate it”
What triggers the transition:
Stage 3’s limitation is human, not technical. The repository has been built by multiple people with different modeling habits. An application modeled by the infrastructure architect is named differently from the same application modeled by the application architect. Relationship types are used inconsistently. The repository is growing, but it is becoming harder to trust as it grows. The diagnosis: “Our repository is valuable but only we can navigate it.”
Stage 4: A Common Language
Architecture becomes portable across people and organizations.
What it looks like from the inside:
The EA profession settled on shared modeling languages that define the standard vocabulary of the practice. ArchiMate provides a shared notation for the business, application, and technology layers of enterprise architecture and the relationships between them. BPMN (Business Process Model and Notation) gives process architects a language that business analysts and developers can both read. UML (Unified Modeling Language) gives software architects a standard notation for systems and behavior.
The shift from Stage 3 to Stage 4 is a shift from private vocabulary to shared vocabulary. What makes this work in practice is not training certifications — it is the combination of a common language, a consistent set of methods applied across the team, and clearly defined modeling standards that give every architect the same starting point.
A new architect joining from a different organization can review existing models and contribute new ones within days: not because they have credentials, but because the language, the methods, and the standards exist independently of any single team.
Signs you might be here:
– Your team uses a recognized modeling language (ArchiMate, BPMN, UML) with consistent application
– A new architect can orient themselves in the repository without a guided tour
– Model elements are typed correctly and consistently across domains
– The repository is readable by architects who didn’t build it
What triggers the transition:
The team has the language but not the scaffold. Every new architecture program starts from scratch on the same structural decisions: what does “capability” mean in this organization? What is the correct top-level taxonomy for the application portfolio? The notation is consistent but the structural choices are not. Two business units using ArchiMate produce application layers that cannot be merged because the element types were applied with different assumptions.
Stage 5: The Governed Model
The repository earns the right to be trusted as data.
What it looks like from the inside:
Stage 5 encompasses two meaningfully different internal positions. An organization at the entry of this stage has adopted reference frameworks (TOGAF (The Open Group Architecture Framework), BIAN, TMForum, DoDAF), established governance processes, and built architecture practices that look mature from the outside. An organization at the far end of this stage has something more specific: a repository whose contents are semantically consistent, machine-readable, and trustworthy as a data source.
The gap between those two positions is invisible until you try to do something automated with the repository — and then it becomes the only thing that matters.
Here is what the gap looks like in practice. An EA team prepares the quarterly portfolio report for the CIO. They pull the data directly from the repository. The numbers don’t add up. Application counts differ between domains. The same system appears twice under different names. Capability mappings are incomplete in three business units. The team spends two days manually reconciling the data before the report can go out. This happens every quarter.
The modeling standards existed in a governance document. Nothing in the repository itself prevented an architect from doing it differently. The process was governed. The model was not.
Signs you might be here:
– You have adopted a reference framework (TOGAF, BIAN, or similar) and it is operational, not decorative
– Architecture review processes exist and run
– The repository is the system of record for technology decisions
– Pulling data directly from the repository for reporting requires significant manual reconciliation
What triggers the transition:
The repository is clean, governance is automated enough to maintain it, and AI tools are ready to work with it as a trustworthy data source. The opportunity signal is visible: the constraint on augmentation is no longer data quality — it is workflow design.
Stage 6: Architecture Without Amnesia
AI ends the era of conclusions without reasoning.
What it looks like from the inside:
Every architecture repository in existence today records what was decided. The best ones record when it was decided and by whom. But none of them reliably record why — the reasoning behind the decision, the alternatives that were considered and rejected, the constraints that made one choice inevitable.
This is not a failure of discipline. It is a failure of mechanism. The architecture review session where reasoning was surfaced and debated happened in a meeting room, captured imperfectly in meeting notes, and lost to the repository entirely. What remained was the conclusion — the element in the model — stripped of the thinking that produced it.
Stage 6 is the stage at which AI makes it possible to capture reasoning alongside conclusions. AI agents can sit in architecture review discussions, process the reasoning that was articulated, and associate it with the model elements that were affected. Future architects can query not just what exists in the architecture but why it exists — which alternatives were considered, which constraints drove the decision, which assumptions were made that may no longer hold.
This is the architectural equivalent of the double-entry bookkeeping system: not just recording the transaction, but recording the reasoning that makes the transaction legible. Organizations that build this capability early will create architecture practices that serve as genuine organizational memory rather than periodic snapshots.
Signs the transition is possible:
– Your repository is at the governed end of Stage 5 — data quality is trustworthy
– AI adoption is underway in your organization, creating both a governance challenge and a toolset opportunity
– Your senior architects are spending significant time on work that does not require senior architect judgment
– You have begun asking what it would mean for your EA practice to actually scale
Using This Assessment
Most EA practices sit somewhere between Stage 2 and Stage 5. Knowing which stage you are at — and what the next stage actually requires — is where every NovoCircle engagement begins.
A few honest notes on this framework:
The stages do not progress uniformly across an organization. A Stage 5 corporate EA function can coexist with Stage 2 PowerPoint diagrams in a business unit’s SharePoint. The framework is most usefully applied to a specific EA practice and its immediate organizational context, not to an enterprise as a whole.
The transitions require the work of the stage you are leaving, not just the tools of the stage you are entering. An organization that skips the modeling discipline of Stage 3 in favor of a Stage 4 governance framework will find that the governance framework sits on top of a repository it cannot trust — and the fix requires going back to do Stage 3 properly inside an already-configured environment.
And the most common misdiagnosis is Stage 4 when the practice is actually at Stage 3: the team is using ArchiMate notation, but the repository does not enforce ArchiMate semantics. The symbols are Stage 4. The underlying model is Stage 2 with better icons.
If you want an external read on where your practice sits — or where the actual constraint on the next transition is — book a discovery call. Every NovoCircle EA engagement begins with exactly that conversation.
Read the full framework in The Long Arc: A Practitioner’s Guide to the Six Stages of EA Evolution.
Ryan Schmierer is the founder of NovoCircle, a technology advisory practice specializing in Modern Enterprise Architecture and Intelligent Automation.