Are You an Architect—or a Management Consultant?

Link: https://www.eatransformation.com/p/are-you-an-enterprise-architect-or-management-consultant

From Enterprise Architecture Transformation: A Practical Guide

In the previous article, I looked at why producing enterprise architecture (EA) descriptions often feels difficult—even when tools, methods, and skills are already in place. The conclusion was fairly simple: modeling rarely fails because it is technically hard. It fails because direction, purpose, and shared ways of working are missing.

But there is another, slightly more uncomfortable angle to the same problem.

I have met a surprising number of enterprise architects who do very little modeling. They attend meetings, facilitate discussions, comment on plans, challenge assumptions, and act as sparring partners for development leads and management. They are clearly intelligent, experienced, and articulate. From a consulting perspective, they add real value.

But when it comes to EA descriptions—actual models of the organization—there is very little. Maybe a few case-specific diagrams for individual initiatives. Some PowerPoint sketches. Occasionally a high-level picture that explains one decision or a small domain. But no coherent set of descriptions. Not even a reasonably complete high-level view of the current state.

And this raises an uncomfortable question: what does it mean to be an architect if you don’t really produce architecture content?

Common Ways Architecture Drifts Away from Descriptions

When architects do not produce architecture descriptions, it is rarely accidental. The reasons are usually well intentioned, sometimes even reasonable on their own. But over time, they shape a role where architecture exists mostly as conversation, advice, and presence in meetings—rather than as shared, reusable understanding.

Below are a few recurring patterns I have seen in different organizations.

The “Advisor-Only” Architect

In many cases, the role has quietly shifted toward what could be described as a management consultant with an architecture background. The architect helps others think, frames problems, and translates between business and IT. This is not inherently bad—quite the opposite. Organizations often need exactly this kind of support.

The problem arises when this becomes the only mode of working. EA is supposed to create a shared foundation that reduces the need for constant alignment meetings. When that foundation is missing, alignment happens again and again in workshops, steering groups, and one-to-one conversations.

When architecture exists primarily as conversations and verbal advice, it becomes highly person-dependent. The value lives in meetings, not in artifacts. Once the architect is not present, the shared understanding starts to fade. New people join, projects move on, and the same discussions need to be repeated—often with slightly different conclusions.

At that point, architecture no longer scales. Instead of fewer meetings, you end up needing more of them just to keep everyone on roughly the same page.

“We Don’t Have Time to Model”

One common explanation is lack of time. Architects are pulled into projects and endless meetings. Modeling is something that would require focus and continuity, and there never seems to be a good moment for that.

This explanation is understandable, but also revealing. If there is no time to produce even a coarse, shared view of the organization, what does that say about how architecture is positioned? Modeling is not a side activity. It is how architectural thinking becomes reusable and scalable. Without descriptions, architecture cannot really outlive individual conversations.

“Modeling Is Too Operational”

Another explanation I hear is more subtle: real architects shouldn’t be drawing boxes. Modeling is sometimes seen as too operational, too technical, or even junior-level work. The “real” value is supposedly in “strategic” work, not in documenting.

This creates an artificial divide. Good architecture descriptions are not documentation in the clerical sense. They are condensed thinking. A good current-state view, even if incomplete, forces prioritization: what actually matters enough to be shown? What relationships are worth making explicit? What complexity can be ignored?

Avoiding modeling in the name of “strategic” thinking often means avoiding the discipline that strategy actually requires.

“We Have Plenty of Architects”

There is also a fourth explanation that comes up, usually implicitly rather than out loud: we already have a lot of architects.

On the surface, it sounds reassuring. Architecture capacity should not be the problem. Yet this is often where things start to drift. When there are many architects but no shared direction, no common plan, and no clearly defined scope for EA, everyone ends up doing their own thing.

Each architect focuses on their own domain, initiative, or stakeholder group. None of this is necessarily wrong in isolation. But without a shared understanding of what EA is meant to produce at the organizational level, the pieces do not add up.

Paradoxically, having many architects can make modeling harder, not easier. Agreeing on a common content framework, level of abstraction, and priorities takes effort. If no one owns that coordination, modeling becomes fragmented or quietly disappears altogether.

From the outside, the situation looks busy. There are meetings, comments, and opinions. What is missing is a shared architectural foundation. And without that, EA does not scale—no matter how many architects you have.

Between No Models and Too Many Models

EA work tends to drift toward two extremes. At one end, nothing is really modeled. Architecture lives in conversations and verbal advice. At the other end, everything is modeled. Repositories grow, details accumulate, and keeping things up to date becomes a job of its own. Neither extreme works particularly well.

When architecture exists mostly as conversations, the question is simple: what actually remains when the architect is not in the room? What can be reused, challenged, or scaled? In many cases, very little. Decisions rely on memory, architecture becomes person-dependent, and shared understanding fades surprisingly fast.

Over-modeling has a different failure mode. The content exists, but it is too heavy, too detailed, or too detached from actual decisions to be used. The effort goes into maintaining the model rather than using it. Architecture becomes hard to approach, and people quietly work around it.

To be clear, this is not a call to model everything or to build exhaustive repositories. EA descriptions should be coarse-grained. They should focus on what is relevant, not on adding detail for its own sake. But some shared, maintained descriptions are non-negotiable if EA is meant to be more than personal expertise. Even a partial current state is better than none—provided it is intentional, aligned with real needs, and actually used. Without that middle ground, architecture either evaporates into talk or collapses under its own weight.

So What Is the Architect’s Role, Then?

An architect does not have to choose between being a thinker and being a modeler. The two reinforce each other. Modeling without thinking produces noise. Thinking without modeling produces insights that do not stick.

If you recognize yourself—or your organization—in this description, the question is not “should we start modeling everything?” A better question is simpler and more uncomfortable:

What architectural understanding would still exist if no architect attended the meetings for the next six months?

If the answer is “very little,” the problem is probably not a lack of tools or skills. It is that architecture has drifted too far away from its own foundations.

And those foundations are, still, the descriptions.

🔗 You May Also Like

Looking to dive deeper? Here are more enterprise architecture insights you might find useful:

👨‍💻 About the Author

Eetu Niemi is an enterprise architect, consultant, and author.

📬 Want More Practical Enterprise Architecture Content?

Subscribe to Enterprise Architecture Transformation for real-world advice on architecture that supports change, strategy, and delivery.