Enterprise Architect, Is Your Jargon Scaring People Away?

Link: https://www.eatransformation.com/p/enterprise-architect-is-your-jargon-scaring-peiople-away

From Enterprise Architecture Transformation: A Practical Guide

Enterprise architects usually do not scare people away on purpose. It just happens.

First we talk about capabilities, target states, reference architectures, operating models, architecture principles, governance structures, transition roadmaps, and architecture repositories. Sometimes we even talk about metamodels, representations, and ontologies.

Then we notice that the other people in the meeting have become quiet. That can be interpreted in many ways. Maybe they are impressed. Maybe they are thinking deeply about structural dependencies across the organization. Or maybe they are counting how many minutes remain before lunch.

Jargon is not a small side issue in enterprise architecture (EA). Language affects whether people understand what we are trying to say, what they are expected to decide, and why architecture matters in the first place. If the EA function wants to be part of real organizational decision-making, it cannot sound like a closed professional club that accidentally invited a few business stakeholders to listen.

This is slightly inconvenient, because EA is a specialized field. Specialized fields tend to have specialized language. That is not automatically wrong. The problem starts when the language stops helping and starts protecting us from being understood.

Why We Use Jargon

There are several reasons why enterprise architects use jargon. Some are reasonable. Some are more human.

The reasonable reason is precision. Architecture deals with concepts that are not always easy to describe with everyday language. A capability is not exactly a process. An application portfolio is not just “a list of systems,” although sometimes it is close. A target architecture is not the same as a vision, a roadmap, or a solution design. If we use the wrong words, we may also start thinking in the wrong way.

This is especially true when architects talk to other architects. Shared terminology can make the conversation faster and more accurate. A familiar term can carry a lot of meaning inside a professional community. In that context, jargon is not automatically bad. Sometimes it is simply the vocabulary of the craft.

You can see this in people’s reactions when that vocabulary is missing. A simpler phrase may be easier to understand, but to another architect it may sound less precise, or even slightly wrong.

I have noticed that in my own writing. I have tried to reduce unnecessary jargon, and usually it is a good thing. But sometimes someone points out that I am not using the “right” term. For example, capability-based planning may be easier to explain as planning based on what the organization must be able to do. But someone may still prefer the formal term, because that is what the method, framework, or professional community uses.

That is true in all specialized fields. Scientific articles need precise terminology. Legal documents need exact language. Even in EA, some terms exist because they help people work more accurately.

But sometimes we use jargon simply because we are used to it. If you spend enough time talking about capability maps, governance models, and architecture principles, those words start to feel normal. After a while, “metamodel” sounds like something you might casually mention over coffee. That is a warning sign, but not necessarily a moral failure.

Sometimes jargon is also part of method enthusiasm. Enterprise architects can become quite fond of their methods, frameworks, viewpoints, layers, taxonomies, notations, and templates. That is closely related to the familiar architecture condition where the model starts to become more interesting than the problem it was meant to solve. There is probably no official diagnosis, but many of us have shown symptoms.

And sometimes, if we are honest, jargon is used to sound competent. Experts want to sound like experts. Consultants want to sound like consultants. Architects want to sound like people who should be invited before the project has already bought the wrong solution. There is nothing strange about that. But if the goal is impact, sounding impressive is a poor substitute for being understood.

Why Jargon Becomes a Problem

Jargon becomes a problem when it gets between architecture and its intended audience.

This is especially harmful in EA work because it depends on other people. Architects don’t implement the whole target architecture themselves, which is probably good for everyone involved. EA needs leaders, domain owners, project teams, process owners, data people, application owners, technology specialists, vendors, and sometimes finance people who ask difficult but useful questions.

If these people do not understand the architecture message, EA loses influence. The model may be correct. The principle may be elegant. The roadmap may show the right dependencies. But if the people who need to use it cannot connect it to their own decisions, the value remains mostly theoretical.

People may nod in the meeting because they do not want to look confused. They may agree that the topic is important. Then they continue making decisions in the language they actually use: budget, risk, customer impact, delivery schedule, regulatory pressure, operational pain, and what must be fixed before the next steering group.

Architecture language does not need to replace that language. It needs to connect to it.

This may matter even more outside English. Much of the terminology used in EA has travelled from English into other languages, including my native Finnish. Sometimes the borrowed term works. Sometimes it sounds even worse than the original. “Capability” is already a slightly abstract word in English, but its local equivalent may feel even more artificial if people do not use it naturally in everyday business conversation.

That does not mean every English term must be avoided. Some terms are widely understood, especially in international organizations. But when there is a clear local word that people actually use, it is often better to use that.

Speak So People Can Use It

A useful test is simple: who is the language for?

If the language is for architects, professional terminology may be appropriate. If the language is for a management team, the same content should connect to decisions, priorities, trade-offs, risks, and consequences. If the language is for a project team, it should explain scope, dependencies, constraints, and what must be done differently.

The same architecture insight can be expressed in different ways.

An architect might say:

“The current application landscape creates unnecessary coupling across business capabilities.”

That may be accurate. But in another setting, it may be better to say:

“Several business areas depend on the same systems in ways that make change slower and riskier. If one area changes something, others may be affected unexpectedly.”

Same point. Different language. More people stay mentally in the room.

A better approach is to translate architecture language into the listener’s world. Start with the problem before the concept. Instead of opening with “capability-based planning,” explain that the organization needs to plan development based on what it must be able to do, not only based on current applications or organization charts. After that, the term may actually make sense.

Use the formal term when it helps, but do not make it carry the whole explanation. Connect models to decisions. If you show an application map, explain what decision it supports: investment prioritization, modernization, risk reduction, sourcing, consolidation, or impact analysis. Use examples. If a dependency matters, show what breaks, slows down, costs more, or becomes harder to change.

And watch the room. If people stop asking questions, it does not always mean they understood everything. It may mean they gave up politely. Politeness is one of the more dangerous feedback mechanisms in architecture communication.

Before using an architecture term, it may be useful to ask three questions. Does this term make the point more accurate? Does the audience understand it? Does it help someone make a better decision or do better work?

If the answer is yes, use the term. If the answer is no, explain it differently. If the answer is “I am not sure, but it sounds professional,” maybe take a small pause.

The Point Is Not to Sound Less Like an Architect

The goal is not to make enterprise architects sound less like experts. The goal is to make expertise easier to use.

Anyone can avoid jargon by becoming vague. That is not an improvement. The real skill is to keep the meaning, preserve the nuance, and still make the message understandable to the people who need it. This is harder than using the professional term. It also usually creates more value.

Enterprise architects need precise concepts. We need models, principles, roadmaps, viewpoints, and sometimes even metamodels. I am not ready to give up all of them, and I suspect no one would believe me if I claimed otherwise.

But we also need impact. And impact happens through people who understand enough to make better decisions.

Jargon does not make an architect an expert. At best, it is a tool. At worst, it is a wall.

The real test is whether people can use what we say.

That is, of course, a bit unfair. First, we have to understand the complexity ourselves. Then we have to explain it in a way that does not make everyone else mentally leave the meeting. But that is the job.

🔗 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.

Web resources: Enterprise Architecture Info Package (FI)

📬 Want More Practical Enterprise Architecture Content?

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