Everyone Knows How to Model. So Why Doesn’t Anything Get Modeled?

A practical look at why enterprise architecture content stays thin despite familiar tools and methods

Jan 20, 2026

It is a surprisingly common situation. An organization has acquired an architecture tool, architects have attended trainings, and perhaps a few pilot models have been produced. On paper, everything looks fine. In principle, the architects know how to model core enterprise architecture (EA) content: capabilities, processes, applications, information, and technologies. The methods are familiar, the notation is not new, and the tool no longer feels intimidating.

And yet, modeling still feels heavy. So what, exactly, is getting in the way?

After the initial push, very little happens. Descriptions remain partial, outdated, or stuck in draft form. Whatever content does exist is rarely used for anything concrete: not in planning, not in decision-making, not in guiding change. Architecture work continues, but modeling the organization as a whole quietly fades into the background.

This is odd, because modeling is not an optional extra in EA work—it is the core of the practice. Without content, there is nothing to use: no shared picture, no structure to reason about, no handhold for discussions or decisions. Architecture without models is just talk, and talk does not scale very well.

When the situation is discussed (if it is discussed), the first suspect is often the tool. It is too complex, too heavy, or sometimes too simple. Close behind comes another familiar explanation: there is no time. Architects are pulled into projects, workshops, and constant firefighting, and modeling is something to be done “properly” later, when things calm down.

Sometimes these diagnoses are correct. Tools can be genuinely cumbersome, and time pressure is very real. But more often, they are symptoms rather than root causes: convenient labels for something deeper that makes modeling feel like extra work instead of an essential part of the job.

The Problem Is Rarely Lack of Skills—It’s Lack of Direction

One of the main reasons modeling feels difficult is not lack of competence, but lack of shared direction. There is no common understanding of what should be modeled, how it should be modeled, or for what purpose. In other words, there is no shared content framework or clear work plan. When it is missing, everyone defaults to their own perspective and experience.

One person models detailed processes, another focuses on data, a third maps applications, and a fourth worries about fixing the metamodel first. All of this may make sense in isolation, but without an agreed level of abstraction and shared priorities, the pieces never come together.

From the outside, it looks like architecture work is happening. In reality, there is discussion, theorizing, and a growing set of scattered diagrams, but little that forms a coherent, usable whole. At that point, modeling starts to feel heavy—not because it is technically difficult, but because the work lacks direction, a shared way of describing things, and clear boundaries.

Too Much Detail, Too Early

Another very typical trap is diving into details right from the start. The intention is usually good: let’s do this properly once, so we don’t have to redo it later. Model everything thoroughly, and we’re set. Every process gets its own swimlane diagram, every API service is carefully modeled.

In practice, the opposite happens. Detailed modeling takes time, requires a lot of source information, and quickly turns into a coordination effort of its own. The descriptions become heavy, slow to produce, and difficult to maintain. Few people have the patience—or the need—to read them. The big picture fades into the background, and modeling turns into a self-referential exercise. Architecture for the sake of architecture.

Once modeling feels slow and exhausting, interest fades. Modeling gets postponed, then quietly dropped. And later, people wonder why “architecture never really took off.”

Theoretical, Generic Models

There is also the opposite problem. Instead of getting stuck in details, modeling is pushed forward with the idea that something is better than nothing. Time is limited, substance knowledge is thin, and the result is often a set of generic, theoretically correct models that could describe almost any organization.

A typical example is “a party that has a contract with another party.” Which is true, of course. And also fairly pointless. It tells nothing about what actually matters, what is specific to this organization, or why anyone should care.

This happens when modeling drifts too far away from real substance. EA is meant to be coarse-grained, but still concrete. Abstract enough to manage complexity, yet specific enough to say something meaningful about this organization. When models remain purely generic, modeling does not feel heavy—it feels pointless.

Point Solutions Do Not Create a Whole

Modeling can also be done in a very point-like manner. Usually something easy and familiar is chosen as a starting point—often some support function or a single application landscape. It feels reasonable: at least something concrete gets done quickly.

The problem is that without an overall plan, these point descriptions remain isolated. They do not connect to each other and do not form a coherent view that could actually support decision-making or development planning. What you end up with is a collection of diagrams, each perfectly fine on its own, but lacking a meaningful whole.

At this stage, modeling starts to feel pointless. Not because people don’t know how to do it, but because the value of the work remains unclear.

Don’t Tools Matter at All?

To be fair, tools do matter. A bad or poorly introduced tool can make modeling unnecessarily painful. An overly heavy tool kills motivation; one that is too lightweight does not support managing complexity. And if the tool rollout was left half-done, it is no surprise the work feels clumsy.

At the same time, a good tool only enables better modeling—it does not automatically create it. The right tool can lower the threshold for producing and maintaining content, make relationships easier to see, and support reuse. It can also support utilization: making architecture content easier to access, navigate, visualize, and apply in planning and decision-making. But it does not decide what should be modeled, nor does it make the results useful by default.

Still, the tool is rarely the root cause. More often, it merely amplifies existing problems. If no one has decided what is being modeled, at what level of detail, and for what purpose, no tool will save the situation. Even the best tool can be used to produce confusing and useless descriptions.

When Modeling Problems Are Leadership Problems

Most architecture initiatives don’t fail because modeling is hard. They fail because no one has clearly decided what the modeling is for.

Although I have focused mainly on issues related to the descriptions themselves, modeling difficulties are very often rooted in leadership and organizational challenges. There is no shared answer to what EA is expected to achieve, no clear owner for EA, too few people are involved, or no time is explicitly allocated for architecture. There is no agreed plan for how modeling should progress, and, quite often, no real demand for the outcomes.

These are not technical modeling problems. They are leadership and operating-model problems. And sooner or later, they surface in the architecture content itself—or in the fact that there is hardly any content to speak of.

Modeling Is Not a Mystical Skill

When modeling feels hard, it is tempting to assume it requires some rare expert skill or special talent. In most cases, that is not the problem. Architects generally know how to model. What is missing is clarity about what the modeling is supposed to achieve.

This is why getting the operating model basics right matters more than mastering yet another notation. Define and actually roll out a shared content framework. Agree on what gets modeled, at what level of abstraction, and how the models are meant to be used. Establish a few common ways of working that make modeling part of everyday architecture work, not a separate side activity.

Before opening the tool, it helps to pause and ask a simple question: what decision should this model support? If the answer is unclear, the model will almost certainly struggle to justify its existence. Another useful test is more uncomfortable: if no one uses the model in six months, what would that tell us about why it was created in the first place?

Modeling feels especially heavy when it is forced to compensate for missing decisions. When goals are unclear, priorities undefined, and ownership fuzzy, modeling tries to fill the gap—and inevitably fails. Clear decisions upstream make modeling lighter downstream.

When the purpose, scope, and progression are clear enough, modeling becomes what it was meant to be all along: a tool for thinking, discussion, and alignment. Not a heavy obligation postponed to the next quarter. And at that point, the tools also start to feel surprisingly reasonable. Sometimes even genuinely useful.