How Enterprise Architecture Descriptions Are Created in Practice

Why structure still matters, even when the work is iterative

Jan 12, 2026

Enterprise architecture (EA) descriptions are rarely created in a tidy, step-by-step manner. In practice, the work is iterative, assumptions change along the way, and information is always incomplete. Anyone who has done this kind of work knows that reality does not follow a clean sequence.

Still, there is value in describing a clear process for creating these descriptions. Structure does not simplify reality, but it helps navigate it. A shared process gives architects something to lean on when the work feels scattered and gives stakeholders a way to understand what is happening, even when the path forward is not linear.

The point is not to pretend that architecture work unfolds neatly. It is to recognize that, despite the messiness, the same high-level steps tend to repeat. What varies is not the process itself, but how clearly the starting point is defined and how much certainty exists at the beginning.

With that in mind, the following process is best read as a practical reference rather than a strict recipe. The steps do not always follow this order, some may overlap, and others may be revisited multiple times. Even so, they provide a useful structure for understanding how EA descriptions are typically created in real organizations.

The Process in Practice

The following steps describe a typical high-level process for creating an EA description.

Step 1: Clarify the Type of Description and Its Purpose

The first step is not modeling. It is understanding what kind of description is being created, and why.

In current state descriptions, the need is usually clear. The organization wants to understand what exists today: capabilities, applications, processes, technologies, dependencies, and so on. Typical drivers include rationalization, audits, risk management, compliance, documentation, or simply the need to update an outdated overview. The core question is straightforward: where are we now?

In target state descriptions and case-specific descriptions, the situation is different. There may be a strategic direction, a vision, or a pressing decision to be made, but no shared understanding of what that means structurally. The question is no longer about documenting reality, but about exploring possibilities, implications, and choices. In these cases, the purpose often becomes clear only during the work itself.

Despite this difference, the same discipline applies. Someone still needs to articulate why the description is needed, who it is for, and what kind of decisions or discussions it is supposed to support. That clarity may be strong at the start or emerge gradually, but it cannot be skipped.

Step 2: Assemble Source Material and Create an Initial Draft

Once the purpose is at least partially understood, the work moves forward with a first draft. This draft is usually created by architects, either individually or together, using whatever source material is available at the time.

This material typically includes process descriptions, organizational structures, IT documentation, earlier architecture models, various public documents, reference architectures, and example models from similar contexts. Today, AI tools are also commonly used to generate alternative structures or viewpoints, which can speed up early thinking but don’t replace judgment.

In some cases, there is very little material to work with. When the topic is new, the scope unclear, or previous documentation simply does not exist, the first source may be the people themselves. Short interviews, workshops, or informal conversations can then serve as the starting point, helping to establish a shared baseline before anything is modeled.

At this stage, completeness is neither realistic nor desirable. The initial draft is built on incomplete, inconsistent, and sometimes outdated information. That is expected. Its role is to make assumptions visible and give others something concrete to react to. A draft that triggers discussion is far more valuable than one that tries to be correct in isolation.

Step 3: Validate and Refine Through Expert and Management Input

The architecture description starts to become meaningful only when it is reviewed with people who know the organization and its constraints. This is where the process becomes visibly iterative.

Subject matter experts can point out inaccuracies, missing elements, and oversimplifications. They may also challenge the relevance, framing, and level of abstraction. New requirements emerge. Old assumptions are revised. Sometimes the scope changes altogether.

In current state descriptions, this phase is often about correction and completion. In target state and case-specific descriptions, it is more about sense-making. The description helps stakeholders articulate what they actually want, what trade-offs they are willing to accept, and what constraints are non-negotiable.

The model evolves through these conversations. The tool matters less than the dialogue it enables.

Step 4: Define Boundaries and Make Deliberate Omissions

As the description matures, one task becomes increasingly important: deciding what not to include.

Most architecture descriptions fail not because they are too simple, but because they try to show too much at once. Multiple perspectives are merged into a single view. Too much detail is added where only structure is needed. Exceptions multiply until the main point disappears.

This step requires conscious boundary-setting. The description must be aligned with its purpose and audience, even if that means leaving out information that might be interesting or accurate but not useful in this context. This applies equally to current state and target state work. A good architecture description is not comprehensive. It is selective.

Importantly, leaving something out of a particular view does not mean it is ignored altogether. The information may exist elsewhere, in another model, a different level of detail, or simply in the shared architecture repository.

Step 5: Approval

Eventually, the description reaches a point where it needs to be formally reviewed and approved. This step often sounds more final than it actually is, but it is still important. Approval usually means that the description is considered sufficient for its intended use at that moment. It does not mean that it is complete, stable, or finished for good.

In practice, approval means following the organization’s established governance practices. This may include a formal comment round and review or endorsement in a steering group, architecture board, or management team. These steps are less about perfecting the model and more about making the description legitimate and usable within the organization.

Step 6: Use and Maintenance

The real test of success is whether the description is actually used. If it supports decision-making, planning, or shared understanding, it has done its job.

Not all architecture descriptions are meant to be maintained. Some are created for a specific purpose, such as a procurement, a major decision, or the early phases of a project. Once that purpose has been fulfilled, the description may no longer be relevant, and there is no reason to keep it up to date.

Other descriptions, especially those capturing the current state, may need ongoing maintenance. In those cases, it should be clear who is responsible for updates, what triggers changes, and how the description fits into normal development and governance practices.

The important point is that this is a conscious choice. Architecture descriptions should not drift into obsolescence by accident, nor should everything be maintained by default. Deciding whether a description is disposable or long-lived is part of using architecture responsibly. A description that is used once and then retired can be just as successful as one that is maintained for years.

What This Process Actually Teaches You

This process highlights a few recurring realities of architecture work.

Current state descriptions usually start from a clear question, while target state and case-specific descriptions often help define the question as the work progresses. Early drafts are not documentation but thinking tools, meant to surface assumptions and trigger discussion rather than provide answers.

Validation is about both correctness and sense-making. It is where priorities, trade-offs, and constraints become explicit. Clear boundaries matter more than completeness, and usefulness almost always improves when detail is added selectively rather than by default.

Approval marks a description as usable, not final. Some descriptions are maintained, others serve a single purpose and are then left behind. Both outcomes can be entirely appropriate.

Although the process rarely unfolds in a straight line, having a clear structure still matters. It gives architects something to fall back on when the work feels fragmented and helps others understand why architecture descriptions take the form they do.

In the next piece, it is worth looking at why the work feels difficult even when the process itself is familiar. The hardest parts of modeling are usually not technical at all.

🎤 Upcoming Enterprise Architecture Webinar (in Finnish)

I’ll be a guest speaker at an Arter webinar titled Kokonaisarkkitehtuurin uudelleen käynnistäminen on January 27, 2026. The session will be held in Finnish and focuses on restarting enterprise architecture work in a lightweight, practical way when it has stalled or faded over time.

👉 Register for the webinar

🎥 CGI Webinar Recording Available (in Finnish, with an English Segment)

I recently took part in CGI’s Teknologian takana webinar series, discussing how enterprise architecture helps organizations manage complexity and drive change in practice. The main discussion is in Finnish, while the interview segment with Ardoq is in English (starting at 21:55) and brings an international perspective to the topic.

As a small curiosity, the webinar also features a rare occurrence: two different Eetu Niemis in the same session 😊

👉 Watch the recording