EA functions tend to collect unfinished decisions, open questions, architecture tasks, and half-finished descriptions. That is normal. Architecture work sits between strategy, development, IT, operations, and governance, so it naturally attracts topics that are important enough to matter and unclear enough to need attention.

That is exactly why the state of the EA function is worth checking before a longer break. And this is best done together, not as a private evening exercise by the person who already has too much on their plate. A short discussion within the EA team usually reveals quickly whether responsibilities are clear, decisions are documented, and someone else can continue the work when needed.

This is a practical check rather than a maturity assessment, an architecture review, or a three-day governance exercise. The idea is to make sure that the most important architecture topics, responsibilities, deliverables, and decisions are in a good enough state. Enterprise architects should be able to close the laptop, leave for holiday, and let their thoughts move to more urgent seasonal matters, such as grilling something that is delicious but probably too expensive.

Everything rarely becomes finished before the holidays. That is fine. The more useful goal is to leave the EA function in a state where work can continue, decisions can be made, and people know what they are supposed to do next.

In other words, architecture work should rely on clear responsibilities and shared understanding rather than one person remembering everything.

1. Are the Open Architecture Issues Clear?

Most EA functions have open issues. That is normal. If there are no open issues, the organization is either very small, very calm, or not telling the architects everything.

The important question is whether the open issues are visible and understandable.

Which architecture questions are still unresolved? Which assumptions need to be validated? Which dependencies are still unclear? Which topics are waiting for a decision, and which are simply waiting because nobody has had the energy to touch them?

Before the holidays, open issues should be either closed, assigned, or made explicit. Leaving a few things open is fine. Leaving them floating around in meeting notes, chat messages, and someone’s memory is less fine. Especially if that someone is about to spend three weeks somewhere with poor mobile coverage.

2. Are All Relevant Initiatives Supported?

The EA function should also check whether all relevant development initiatives have the architecture support they need.

This does not mean that every project needs a full architecture review, a complete target architecture, and a ceremonial blessing from the architecture board. Some projects need only light guidance. Some need a few good questions at the right time. Some need more serious attention because they affect core capabilities, critical applications, data flows, integrations, security, or long-term technology choices.

The health check is about coverage. Are there important initiatives that the EA function is not aware of? Are there projects making architecture-relevant decisions without support? Are some architects overloaded while other topics receive no attention at all?

A project that does not ask for architecture support may be doing perfectly well. Or it may be quietly creating a problem for August. Both options exist. Only one of them is pleasant.

3. Are Architecture Decisions Clear?

Architecture decisions have a habit of becoming blurry.

A direction is discussed. Someone agrees “in principle.” A slide is updated. A steering group nods. The architect makes notes. Later, everyone remembers the decision slightly differently.

Before the holiday season, it is worth checking whether the important architecture decisions are clear. What has been decided? Who made the decision? What alternatives were considered? What assumptions does the decision depend on? What still needs to be confirmed?

This does not require a heavy decision log with more fields than actual decisions. But the important decisions should be documented well enough that someone else can understand them later.

A decision that only exists in the chief architect’s head is fragile. It may feel clear at the time, but after a few weeks of holiday, it can become just another item in the long list of things someone meant to write down.

4. Does Every Architecture Task Have an Owner?

Architecture work often fails between meetings.

A topic is discussed, everyone agrees it is important, and then it quietly waits for someone to do something. Usually this someone has no name, no time, and no idea that they have been selected.

Before the holidays, every important architecture task should have an owner and a clear next step.

Who will update the application landscape? Who will prepare the recommendation for the integration approach? Who will clarify the data ownership issue? Who will support the CRM project while the lead architect is away? Who will follow up on the security architecture concern?

The owner does not need to solve everything alone. But someone needs to hold the ball. Otherwise the ball will still be there in August, only slightly dustier.

5. Are Escalation Paths Clear?

Some things can wait until after the holidays. Some things should not.

The EA function should be clear about what needs escalation, who can make decisions during absences, and which topics can safely wait. This is especially important if architecture governance depends heavily on a few senior people.

Who can approve exceptions? Who can give direction if a project needs an architecture decision? Who should be contacted if a critical need appears? Which decisions must wait for the chief architect, and which can be handled by others?

It is not about creating drama but about reducing unnecessary drama.

A good holiday setup makes it clear when people can move forward and when they should stop and ask for help. Without this, organizations tend to do both at the wrong time.

6. Are Architecture Descriptions Usable Without Their Author?

Architecture descriptions should be understandable without the person who created them standing next to the screen.

That is a painfully useful test. Can someone understand the current state, target state, dependencies, and key open questions from the available material? Are the most important descriptions up to date? Do they support the decisions and projects that are active now? Is it clear where the latest official version can be found?

The goal is to make the critical descriptions usable enough before the holidays. This does not mean perfecting the architecture repository before July. That way lies sadness. It means making sure that people can find the right material, trust that it is current enough, and use it without a private guided tour from the original author.

If a diagram needs a 45-minute explanation before it means anything, it may still have some value. But if nobody knows whether it is the latest version, it becomes less of an architecture description and more of an organizational rumor with boxes and arrows.

7. Is the Autumn Pipeline Visible?

Before the holidays, it is also useful to look slightly ahead.

What architecture topics are likely to become important in August and September? Which initiatives are starting? Which decisions are coming? Which strategy, portfolio, sourcing, or technology discussions will need architecture input? Which architecture descriptions should be started, updated, or prepared when people return?

The EA function should have enough visibility to avoid starting from zero after the holidays. It should be clear which topics need architecture support, which descriptions will be needed first, and who will take the first steps.

Autumn usually arrives faster than expected. Much like architecture debt, but with more calendar invitations.

Leave the Architecture Function in a Usable State

The purpose of this health check is not to make the EA function perfect before the holidays.

The purpose is more practical. Open issues are clear. Relevant projects have support. Architecture decisions are documented. Tasks have owners. Escalation paths are known. Critical descriptions are usable. The autumn pipeline is visible enough.

That is already a lot.

And if these things are in place, even the chief architect can probably leave for holiday with a reasonably clear conscience.

Not completely, of course. That would be unrealistic. But clear enough.

🏖️ A Short Summer Break

I will also take a short summer break from publishing.

The next post will come in mid-August. Until then, I hope your architecture decisions are documented, your open issues have owners, and your holiday is not interrupted by urgent questions about integration principles.

Have a good summer!

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram

Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time

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.

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.

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram

Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time

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.

Who owns EA?

It sounds like a reasonable question. Clear, practical, almost managerial. The kind of question that might fit nicely into a governance slide. But the question matters because EA without ownership has a very familiar failure mode.

Work gets done, but its mandate remains unclear. Deliverables are created, but no one knows who maintains them or where they should be used. Decisions keep shaping the real architecture of the organization, while leadership may still treat architecture as something owned by the architects rather than by the people making the decisions.

That is why ownership matters. It determines whether EA is part of how the organization makes decisions, or just a parallel expert activity that—in the best case—documents reality after other people have already changed it.

The difficulty is that EA can mean several related but different things. It can mean the architecture work: the function, roles, methods, tools, governance routines, and activities through which architecture is created and used. It can mean the architecture deliverables: principles, models, roadmaps, portfolios, standards, and decision materials. And it can mean the actual architecture of the organization: the capabilities, processes, data, applications, technologies, suppliers, dependencies, and compromises that exist in reality.

These are connected, but they are not the same thing. They also need different kinds of ownership. Ownership here means mandate, accountability, and sometimes direct responsibility.

Before looking at those ownership types, it is worth looking at what happens when ownership is missing. That is usually where the problem becomes visible.

When Ownership Is Missing

EA does not disappear when ownership is unclear.

Architecture always exists. The only question is whether it is intentionally shaped or accidentally discovered later.

When architecture work has no clear owner, EA becomes optional. It may be used when people already believe in it, when a project manager happens to remember it, or when an architect is persistent enough to get invited. This creates a fragile operating model where value depends too much on individual energy and personal relationships.

This is also where ownership starts to affect actual EA utilization. Clear ownership does not make architecture valuable by itself, but it gives architecture work a place in the organization’s normal decision-making. It helps define where EA is used, who is expected to use it, and what decisions it is supposed to support. Without that, EA remains useful in principle and inconsistently used in practice.

When architecture deliverables have no owner, they lose relevance. They may be created once and then slowly detach from reality. At first the gap is small. Then an application is replaced, a process changes, a new data flow appears, and suddenly the model describes an organization that exists mainly in the past tense.

When leadership does not recognize its ownership of the actual architecture, architecture becomes the side effect of local decisions. Each decision may be reasonable from its own perspective. A business unit solves its immediate need. A project chooses the fastest route. A vendor solution is adopted because it was available. An exception is accepted because the deadline was yesterday, as it often is.

That is how complexity accumulates. Not usually through one terrible decision, but through many reasonable decisions made without enough shared context. It is slightly annoying, because it means the villains are often just normal people trying to get work done.

Three Types of Enterprise Architecture Ownership

EA ownership becomes easier to discuss when it is split into three parts. Architecture work, architecture deliverables, and the actual architecture of the organization are connected, but they are not owned in the same way. Mixing them together makes the ownership question look simpler than it is, which is usually a reliable way to make it less useful.

Architecture Work Needs an Owner

This may sound obvious, but in practice it is often surprisingly vague. Many organizations have architects, architecture models, architecture forums, architecture principles, and maybe even an architecture tool. Still, the actual ownership of the architecture practice may be unclear.

Sometimes the EA function belongs to IT. Sometimes it belongs to a strategy or transformation function. Sometimes it is distributed across the organization, which can work well in theory but, in practice, may mean that no one owns it when difficult work needs to be done.

The owner of architecture work should not be the person who updates the diagrams or maintains the modeling tool. That work matters, but it is not ownership. Ownership means responsibility for why the architecture function exists, what it is expected to support, how it is connected to decision-making, and what kind of mandate it has.

In my view, architecture work needs a senior leader as its owner, preferably someone close to, or in, the management team. This does not mean that a senior leader should personally review every diagram. That would be one way to make everyone regret the EA operating model quite quickly.

The point is different. Architecture work needs an owner who can connect it to real priorities, real decisions, and real leadership routines. If EA is expected to support strategic planning, transformation, portfolio decisions, investment planning, operating model development, or technology direction, it cannot sit too far away from the places where those topics are decided.

Otherwise, EA becomes a helpful expert activity that may produce good material, but has no natural place to land. It can still be useful in that situation, but it will always struggle.

Deliverables Also Need Ownership

Even when architecture work has a general owner, the deliverables themselves can still become orphaned. A capability map is created. A target state is defined. Architecture principles are approved. An application portfolio is documented. Then everyone moves on, because organizations are very good at moving on from their own documentation.

A deliverable needs at least four kinds of clarity.

First, who owns the content? If a capability map describes the business, the business should own the meaning of that content. The EA team may facilitate, structure, model, and maintain it, but it should not become the sole owner of what the business actually is.

Second, who maintains it? This may be the architecture team, a domain architect, a business owner, an application owner, or someone else. Maintenance should be explicit, because otherwise architecture content ages in a very human way: slowly, unevenly, and with some parts pretending to be younger than they are.

Third, who approves it? Approval matters when the deliverable is used to guide decisions. A target state that no one has approved is often just a well-designed opinion. It may be a good opinion, but still an opinion.

Fourth, where is it used? This may be the most important question. A deliverable that is not connected to any decision-making process becomes documentation for documentation’s sake. It may be accurate, elegant, and nicely colored. But if no one uses it to decide anything, its organizational value remains limited.

The Real Architecture Is Not a Deliverable

The actual architecture of an organization is the structure that exists in reality: business capabilities, operating models, processes, data, applications, technologies, integrations, vendors, customers, employees, funding structures, decision rights, and all the compromises that have been made along the way.

Some of this may be described in architecture models. Much of it usually is not.

The real architecture changes when management and domain owners make decisions. It changes when a new product is launched, a process is redesigned, an application is implemented, a platform is selected, a vendor contract is signed, a business unit builds its own solution, an exception is accepted, or a transformation program quietly changes scope for the fifth time.

Sometimes these decisions are called architecture decisions. Usually they are not. But that does not matter. They still shape the architecture.

This is why the actual architecture cannot be owned by the EA team alone. The EA team can describe it, analyze it, challenge it, improve it, and make its consequences visible. It can support decision-makers and help the organization understand what it is building. But it cannot own the whole organizational reality on behalf of everyone else.

The actual architecture is ultimately owned by management, because management owns the direction, priorities, investments, and cross-domain trade-offs that shape it. Domain owners remain accountable for the substance of their own areas, but leadership owns the consequences that cut across them.

In a company, the ultimate ownership is of course with the owners and the board at the highest level. They set direction and governance expectations. But they usually do not get involved in whether a specific integration pattern creates too much dependency between two platforms. This is probably healthy for everyone involved.

In practice, the management team and senior leaders own the operating model, investment decisions, priorities, risk acceptance, and structural compromises that define the organization. They may not always think of this as architecture ownership. But it is.

If leadership decides the direction, funds the work, accepts the trade-offs, and lives with the cross-domain consequences, leadership owns the architecture in the sense that matters most.

Consultants Can Support, But Not Own

Consultants can play a useful role in EA. They can help establish an EA practice, assess the current situation, create deliverables, facilitate discussions, bring comparison from other organizations, structure unclear problems, and provide capacity when the internal organization is stretched. Sometimes they can also say things that internal people have said before, but which become somehow more interesting when said by an external person with a slide deck. This is one of the mysteries of consulting, and perhaps also one of its business models.

But consultants cannot fully own EA for the client.

They can own their assignment. They can own the quality of their work. They can own specific deliverables until they are handed over. They can support the architecture practice and even act as an external architecture resource for a longer period.

But they cannot own the organization’s architecture direction, priorities, and long-term consequences. That ownership has to remain with the client organization.

If an organization effectively outsources the ownership of EA, it risks outsourcing part of its own thinking. The work may look efficient for a while. Deliverables appear. Meetings happen. Models improve. But if the internal ownership is weak, the architecture practice remains dependent on external energy and external memory. That is not a good long-term structure.

A Practical Ownership Model

A practical ownership model does not require one person to own everything. In fact, that would be a bad idea. Anyone who claims to own all of EA either has an unusually broad mandate or has not yet understood the job.

A more realistic model separates the different types of ownership.

The senior executive owner owns the purpose and mandate of the EA function. This person ensures that architecture work is connected to management priorities, decision-making forums, and the organization’s development agenda. The role is not to manage modeling details, but to make sure EA has a legitimate place in how the organization is led.

The architecture lead or chief architect owns the architecture practice in daily work. This includes methods, quality, prioritization, ways of working, architecture governance, and the coordination of architecture work across domains. This person turns the mandate into something that can actually be done without requiring a philosophical debate before every workshop.

Business, domain, process, data, application, and technology owners own the content of their areas. They know what exists, what is changing, what matters, and what constraints apply. The architecture team may provide structure, but the substance must come from those who own the actual domains.

The management team owns the real architecture through decisions. It owns the priorities, investments, trade-offs, exceptions, and consequences. It does not maintain the architecture repository, but it shapes the actual organization more than any repository ever will.

Consultants support, structure, challenge, produce, and accelerate. They can be very useful. But they do not own the client’s architecture.

This division may sound simple. But in practice, it requires discipline. It requires that EA is treated as part of how the organization makes decisions, not as a separate expert hobby with diagrams.

Ownership Makes Enterprise Architecture Real

EA ownership is not about finding one heroic person who owns everything. That person does not exist. If they do, they are probably already in too many meetings to help.

The practical question is more precise: who owns the work, who owns the deliverables, and who owns the decisions that shape the actual architecture?

The practical consequence is simple: EA ownership should show up in how work is done. Architecture work should be connected to real decision-making. Deliverables should have owners, use cases, and maintenance routines. The decisions that shape the actual architecture should be made with enough shared context to understand their wider consequences.

EA can make dependencies visible. It can clarify options. It can improve decision quality. It can help the organization understand the consequences of change before those consequences become expensive enough to get everyone’s attention.

But the EA function cannot own reality on behalf of the organization.

That is why EA needs ownership close enough to real leadership. Without it, EA may still produce useful work, but it remains too easy to ignore when decisions are made.

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram

Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time

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.

The assignments have varied quite a lot. Some have been clearly project-based: improving an EA practice, supporting a transformation, describing parts of the overall architecture, or preparing architecture content for a new initiative. In other cases, I have worked more like an external architecture resource inside the client organization. My longest assignment lasted around two years, which is already enough time to stop feeling like a brief external visitor. You may still have a consultant badge, but by then you also know where the coffee machine is and which steering group materials are mostly ceremonial.

At the same time, I have worked with many internal enterprise architects. That has made one thing quite clear: the title may be similar, but the structural position is different.

Internal enterprise architects and consultants often use the same concepts, methods, tools, and diagrams. They may participate in the same discussions and support the same decisions. But their mandate, access, incentives, and value logic are not the same.

Neither role is inherently better. They simply create different conditions for doing architecture work.

Continuity and Comparison

The internal enterprise architect usually has one major advantage: continuity.

Internal architects can stay with the same organization long enough to understand its history, constraints, politics, systems, operating model, and recurring patterns. They know which initiatives have been tried before. They know why some decisions were made. They also know which applications are officially strategic and which ones are, in practice, impossible to remove before retirement age. Sometimes the application’s retirement age, sometimes the architect’s.

This continuity creates organizational memory. Internal architects can see how decisions accumulate over time. They can recognize when a small local choice starts to become a wider pattern. They can connect current initiatives to earlier decisions and long-term direction.

But continuity also has a downside. Internal architects may become so familiar with the existing structure that some assumptions become invisible. They know why things are difficult, but they may also become used to the difficulty, or even be part of it. The internal role often creates depth, but not always distance.

The consultant usually brings a different advantage: comparison.

Consultants see multiple organizations, industries, operating models, and architecture practices. This makes it easier to recognize patterns that may be difficult to see from inside one organization. A consultant may quickly notice that a problem presented as unique is, in fact, a very familiar species. It may have slightly different coloring, but it belongs to the same family.

This external perspective can be useful. Consultants can challenge assumptions, bring reference models, introduce practices seen elsewhere, and accelerate work that the internal organization has not had time or capacity to structure. They can also sometimes say things more easily than internal people. Not always, but often.

The limitation is obvious enough. Consultants may not fully understand the organizational context. They may see the structural problem, but not the history behind it. They may recommend a perfectly sensible target state without understanding why the last three attempts to move in that direction failed.

Mandate and Access

Internal architects and consultants often have different access patterns.

An internal architect may have long-term access to people, forums, and informal knowledge. They can build trust gradually. They may know who really decides, who understands the dependencies, and where the real constraints sit. That kind of knowledge is rarely visible in an operating model diagram.

But internal access does not automatically mean influence. Internal architects may be present in many discussions and still have a weak mandate to shape decisions. They can become advisors whose input is appreciated, noted, and then quietly stepped over when delivery pressure arrives.

Consultants often enter through a more specific mandate. They may be hired to support a transformation, assess a situation, create EA deliverables, work as an architecture resource, or help solve a visible architecture-related problem. This can give them a clearer temporary role and stronger attention from leadership.

But the mandate may also be narrow. A consultant may be asked to produce a view, support a project, or assess a limited area without access to the wider decision-making context. This becomes difficult when the work is supposed to influence decisions that are actually made in leadership, portfolio, or transformation forums. Consultants can have a sharper entry point, but they do not automatically get access to the right tables.

Remote work can make this even more visible. If the consultant only meets the people included in formal calendar invitations, a large part of the organization remains outside reach.

Focus and Context

There is also a practical difference in daily work.

Internal architects often carry a broader mix of responsibilities around the architecture work itself: internal planning, governance routines, reporting, stakeholder coordination, tool maintenance, practice development, and many small requests that accumulate over time. Some of this work is necessary. Some of it is useful. Some of it is simply what happens when you are part of the organization.

Consultants are more often brought in for a defined assignment, which can allow them to focus more directly on actual architecture work. They may also be spared from some internal organizational work: recurring status meetings, internal alignment rounds, performance discussions, and political negotiations. This can make consulting work feel more efficient, at least within the boundaries of the assignment.

The trade-off is that some of those internal discussions are exactly where context, trust, and informal influence are built.

Internal architects often understand the surrounding organizational reality more deeply because they live inside it. Consultants may have more focus. But internal architects usually have more context.

Value Looks Different From Each Side

The value of internal architecture work is often indirect.

The internal architect may improve decision quality, reduce duplication, clarify dependencies, maintain organizational memory, and support coherence across initiatives. These effects accumulate over time. The organization may benefit significantly, but the contribution can be difficult to isolate. If things go better because someone helped prevent a bad decision, no one may notice.

There is no incident report for the architecture mistake that did not happen, which is unfortunate for those who enjoy measurable value.

The consultant’s value is usually more explicitly framed. There is a contract, assignment, deliverables, or business problem to solve. The work has a clearer commercial boundary. The consultant’s contribution is easier to connect to a defined engagement, even when the real value still depends on what happens after the consultant leaves.

This can make consulting value more visible in the short term. It also creates pressure. Consultants often need to demonstrate usefulness quickly. They may not have the luxury of building influence slowly over years. Their value needs to become visible within the rhythm of the assignment, sometimes after only a short time to understand the organization, its people, and its constraints.

Living With the Consequences

One important difference is that internal architects live with the consequences of decisions for longer.

If a principle is too abstract, they will see it ignored. If a platform decision creates friction, they will hear about it later. If a target state is unrealistic, they may need to explain it for years.

That creates practical discipline. Internal architecture cannot remain only conceptually elegant. It has to survive contact with budget cycles, delivery constraints, organizational habits, vendor contracts, legacy systems, and normal human behavior.

The internal architect also has to maintain relationships after difficult discussions. They cannot simply challenge everyone and leave. This makes the role relationally demanding. Influence depends heavily on trust, timing, and persistence.

Consultants face a different discipline. They need to create value before full context exists. They must learn quickly, ask good questions, identify patterns, and avoid confident recommendations based on incomplete understanding. Good consulting is not just bringing best practices from elsewhere. It is helping the organization understand its own situation more clearly.

A Career Perspective

There is also a career angle here. Working as an internal enterprise architect can build deep organizational understanding, long-term influence, and the ability to live with architectural consequences. These are valuable skills, especially for roles where architecture is closely connected to strategy, governance, portfolio work, or organizational transformation.

Consulting builds different muscles. It forces the architect to learn quickly, structure unclear situations, communicate value, and work across different organizational contexts. It can broaden perspective and make patterns easier to recognize, simply because you see more than one version of the same problem. Sometimes many versions. Organizations are creative, but not always in completely original ways.

Neither path is automatically better for career development. They develop different kinds of strength. Moving between the two can be especially useful: consulting can give breadth and comparison, while internal architecture can give depth and consequence. The important question is what kind of architect you want to become, and what kind of work will actually develop that direction.

Architecture Ownership Cannot Be Fully Outsourced

I do not think EA work can be owned only by consultants.

Consultants can support architecture work, provide capacity, bring external perspective, lead specific assignments, or work as architecture resources inside the client organization for a longer period. That can be useful, and I have personally done plenty of that kind of work.

But someone on the client side still needs to own the architecture direction, priorities, decisions, and long-term continuity.

That is different from using consultants as architecture support. The problem starts when the organization effectively outsources ownership of EA itself. Some consulting firms may offer this kind of service, and in some cases it may sound efficient. But EA is too closely connected to organizational memory, decision-making, internal priorities, and long-term accountability to be fully externalized.

Working Together

In many situations, the best results come when internal architects and consultants work well together.

Internal architects bring memory, relationships, and context knowledge. Consultants bring comparison, structure, focus, and external perspective. Together, they can create better outcomes than either could alone.

This requires mutual respect. Consultants should avoid treating internal architects as people who simply failed to solve the problem earlier. Often they have been carrying the complexity for years with limited mandate, time, or sponsorship. Internal architects should avoid treating consultants as outsiders who cannot possibly understand anything useful. Sometimes distance is exactly what helps reveal the pattern.

The useful question is not which role is better. The useful question is what kind of contribution the situation needs.

Internal enterprise architects and consultants often work with similar concepts, but under different structural conditions. The internal architect has continuity, memory, and long-term relationships. The consultant has distance, comparison, and a clearer assignment boundary.

Both can create significant value. Both can also create very little value if positioned poorly.

EA is shaped by methods, tools, and models. But it is also shaped by the position from which the architect works.

🗓️ On Work, Writing, and Making Room for What Matters

I published a short guest post in Finnish on a topic I keep coming back to: what happens when demanding expert work, writing, family life, and recovery no longer fit neatly into the same week.

In my case, the solution has been the four-day workweek. Not because it magically creates more time, but because it forces a different way of structuring work.

If you read Finnish, the post is here:

Kun kaikki tärkeä ei mahdu samaan viikkoon

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram

Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time

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.

Still, application development guidance and early assessment of development ideas are practical areas where EA can create real value. At least in my own work, I have ended up doing quite a lot of this. It is not always glamorous, and it does not usually look like high-level strategy work. But it can be impactful, because many expensive problems start as small, unclear, or underestimated change requests.

That is why the early stage of an initiative matters. Early on, there is still room to clarify assumptions, adjust scope, change sequencing, and choose a better path before decisions become expensive to revisit.

I use the word “initiative” broadly here. The same logic applies whether work is organized as a project, program, process or product development effort, continuous improvement item, or smaller change request.

What is known at that point may be quite rough: “we need a new application,” “we need better reporting,” “we need to automate this workflow,” “we need an integration,” or simply “we need this capability.” The initiative may already have a business owner, a preliminary scope, and even a preferred solution direction. That is useful, but not yet enough.

From an architecture perspective, the first question is usually not “what should the target solution look like?” That comes later. The earlier and often more important question is:

What does this change actually affect?

Before solution design moves too far, it is useful to understand the scope, dependencies, and likely impact of the change. Otherwise, the initiative may start making decisions with a narrower view than the situation deserves.

This does not require a massive architecture exercise. Often a few good questions and one simple diagram are enough.

What Is Actually Changing?

Initiative names can be misleading. A “CRM improvement” may actually change many processes and customer data ownership. A “reporting enhancement” may reveal unclear definitions and data quality problems across business units. A “small integration” may introduce a new dependency between two critical processes. A “workflow automation” may quietly change roles, responsibilities, and control points.

So the first architecture question is about the real object of change.

Is the initiative changing a capability, a process, an application, a data object, an integration, a user experience, cooperation with an external party, an operating model, or some combination of these?

That matters because the formal scope and the architectural impact of the initiative are not always the same thing. The scope may describe what the initiative is expected to deliver. The impact describes what the change touches.

Many problems in development start when something is treated as “out of scope” even though it is clearly not out of impact.

If it is difficult to identify what the change affects beyond a single architectural component, the change may not be very architectural in the first place. That is also a useful finding. Not every initiative needs deep architectural analysis. Sometimes a lightweight check is enough.

What Dependencies Are Already Visible?

The next question is about dependencies. What other applications, teams, processes, data sources, vendors, platforms, or ongoing initiatives does this change depend on? Which decisions cannot be made independently? Which parties need to be involved or at least informed? Which other changes could affect the timing or feasibility of this work?

Dependencies are often known by someone, but not necessarily visible to the initiative early enough.

This is where architecture work can create very practical value. It helps bring scattered knowledge into the same conversation before dependencies turn into delivery surprises.

The point is not to identify every possible relationship in the enterprise. That would be a fine way to turn a useful discussion into a small documentary series. The point is to identify the dependencies that can materially affect scope, sequencing, cost, risk, or design choices.

The earlier these are visible, the less they look like surprises later.

What Decisions Would Be Expensive to Reverse?

Not every decision deserves the same level of architectural attention.

Some choices are easy to change later. Others quietly become foundations for many future decisions.

Before an initiative starts moving too fast, it is useful to ask which decisions would be expensive to reverse. Examples include platform choices, integration patterns, data models, ownership boundaries, product or vendor selections, and decisions about where specific responsibilities should sit.

These choices may not look dramatic at the time. They may appear as practical delivery decisions. But once other applications, processes, teams, and contracts start building around them, they become harder to change.

Architecture helps by making these decisions visible before they harden. It does not need to slow everything down. It simply helps distinguish between choices that are local and reversible, and choices that may create long-term structural consequences.

What Should a Good Early Architecture Diagram Show?

Before an initiative starts, the most useful architecture view is often not a polished target architecture diagram. It is a simple picture of scope and dependencies.

If the high-level EA current state has already been described, this becomes much easier. Existing architecture elements and relationships can be used as a starting point instead of reconstructing the landscape from scratch. This is one of the practical reasons why maintaining a sufficiently current, high-level view of the organization is useful.

A good early architecture view should help people see what the initiative touches and what touches the initiative.

I usually recommend anchoring the view to one or a few types of functional elements, depending on what has already been described in current-state EA. Capabilities, processes, organizational units, and external stakeholder types are often useful anchors, because they connect the change to business activity and responsibility rather than only to applications or technical components.

From there, the view can show affected applications, data objects, integrations, and related initiatives. The point is not to model everything, but to show the relevant scope and dependencies clearly enough for early decisions.

The picture should help answer questions such as what is in scope, what is affected, where are the dependencies, and which areas require alignment before decisions are made?

In my EA book, I have emphasized simple views of scope and dependencies for exactly this reason. At the beginning of an initiative, clarity often matters more than modeling elegance. A rough but useful diagram is usually better than a beautiful diagram that arrives after the important decisions have already been made.

Closing Thought

Early architecture work does not need to solve everything. It does not need to define the full target state, design the complete solution, or produce a large architecture document before anyone is allowed to move. That would often be too much, too early.

But it should happen early enough. Ideally when the initial need is known, but before key decisions have been made.

In practice, this means bringing the architecture discussion into the forum where the initiative is shaped—or, at the latest, before it is approved to move into detailed planning. This may be portfolio prioritization, project intake, investment preparation, or another decision point where scope and assumptions are still open enough to influence.

The exact forum matters less than the timing. The result should not be just a diagram, but a clearer view of dependencies, stakeholders, decisions that require alignment, and assumptions that should be tested before solution design moves too far.

At that stage, the most useful architecture question is often simple:

What does this change affect?

That question helps prevent the initiative from starting with an unnecessarily narrow understanding of its own impact.

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram

Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time

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.

More governance. More principles. More standards. More repository content. More architects.

It is a tempting idea, especially for architects. If some architecture is useful, surely more architecture must be even more useful. It is also, conveniently, a good way to justify having more architecture work to do.

Unfortunately, organizations do not work like that.

Architecture creates value when it is proportionate to the situation. Too little leaves important structural questions unresolved. Too much creates overhead that may not improve decisions.

The practical question is not whether EA is good or bad. The better question is: how much architecture is enough for the context?

The Basic Principle: Proportional Architecture

EA should not be applied with the same intensity everywhere.

Some decisions need careful structural analysis. Others need only light guidance. Some initiatives create long-term consequences across the organization. Others are small, local, and easily reversible.

The value of architecture depends on the context. If a change affects several capabilities, applications, data domains, teams, vendors, or customer journeys, the need for architecture work is usually higher. If a decision creates long-term constraints or becomes a foundation for future work, architecture is more likely to add value.

If the change is narrow, isolated, reversible, and follows an already known solution pattern, heavy architecture work may not add much. In fact, this is often where architecture theater begins: architecture process and content expand, but decisions do not improve.

This is where many organizations struggle. Too little architecture allows duplication, hidden dependencies, inconsistent patterns, and long-term complexity to accumulate. Too much architecture creates delay, unnecessary documentation, governance fatigue, and a sense that architecture exists mainly to be satisfied.

Both create problems.

A proportional approach does not mean weak EA. It means applying enough architecture to improve the decision, reduce uncertainty, or prevent avoidable structural cost—without turning every change into an architectural exercise.

Where More Architecture Is Justified

More architecture is usually justified when decisions are difficult to reverse.

A temporary workflow, small user interface change, or local experiment may not need heavy architectural involvement if it can be changed or removed with limited cost. A core platform decision, master data model, integration pattern, sourcing arrangement, or application replacement is different. Once other applications, teams, and processes are build around such decisions, changing direction becomes expensive.

The less reversible the decision, the more architecture it usually deserves.

EA work is also more valuable when dependencies are significant. If a change affects one team and one application, simple guidance may be enough. If it affects multiple teams, applications, data flows, vendors, processes, or customer groups, the need for shared structural understanding increases.

Dependencies are where many surprises live.

They are also where architecture can create practical value: by making relationships visible earlier, clarifying ownership, and helping teams understand what else is affected before decisions become expensive to revisit.

Foundational choices deserve special attention. Platform choices, data architecture, identity and access management, integration approaches, product and capability structures, core application boundaries, and technology standards often shape the conditions for future work.

A weak decision in a foundational area can create years of friction. A good decision can make future delivery easier, more consistent, and less expensive.

This is where architecture work can be highly valuable even if the immediate output looks small. A well-timed clarification, principle, option comparison, or dependency view can influence many downstream choices.

Architecture is often most useful before concrete hardening happens. Before the platform becomes the default. Before the integration pattern spreads. Before the data model becomes embedded. Before the exception becomes normal.

When Lightweight Architecture Is Enough

Not every change needs a full architecture process.

For local, low-risk, reversible work, lightweight architecture is usually enough. This may mean a short check against existing principles, use of an established pattern, or a quick discussion about dependencies, data, security, or lifecycle implications.

The goal is to avoid unnecessary overhead while still maintaining a connection to the broader landscape.

This is especially important in experimentation. Early exploration often benefits from speed. Architecture can help by setting simple boundaries rather than demanding premature completeness.

An experiment may not need a detailed target architecture. But it may still need clarity on whether it uses sensitive data, whether it could become operationally important, or whether it depends on a platform that the organization is trying to retire.

Lightweight does not mean careless. It means proportionate.

The same applies to highly standardized implementation work. If the solution pattern is already known, the platform is established, responsibilities are clear, and relevant constraints and dependencies have already been defined, additional architecture work may not add much. In these cases, architecture effort should focus on the remaining structural choices, not on re-analyzing what has already been standardized.

The right amount of architecture can also change over time. A local tool may start as a small experiment and later become a shared operational solution. A project may begin with limited scope and gradually reveal broader dependencies. A technology decision may become more important as adoption spreads. Architecture effort should adapt as the structural relevance of the work changes.

A Practical Way to Decide

The difficult part is that too little and too much EA work can exist in the same organization at the same time.

An organization may require detailed architectural analyses for low-risk changes while major strategic decisions move forward with surprisingly little structural analysis. That is surprisingly common.

It usually happens when the organization has not clearly defined where architecture matters most.

The required level of EA involvement depends partly on the organization itself. Large, complex, highly integrated, or regulated organizations usually need more shared architectural structure than smaller or simpler environments.

It also depends on the decision context. Strategic planning, major investment decisions, platform choices, mergers, sourcing decisions, and transformation programs usually require more architectural attention than isolated project-level design work.

A simple way to estimate the needed architecture effort is to ask a few questions:

• How many teams, applications, processes, vendors, or customer journeys are affected?

• How reversible is the decision?

• Does it create a foundation for future work?

• Are there significant data, integration, security, compliance, operating model, or lifecycle implications?

• Could multiple initiatives solve the same problem differently?

• Would a poor decision create long-term coordination cost?

If the answers are mostly small, local, and reversible, keep architecture lightweight. Use principles, patterns, and quick checks. Avoid turning every change into a ceremony.

If the answers point to broader dependencies, long-term consequences, foundational choices, or cross-organizational effects, more architectural attention is justified.

The goal is not to maximize architecture effort but to apply enough architecture to improve the decision.

Closing Thought

EA effort should be proportionate. Enough architecture means applying the right level of structural thinking to the situation: more when decisions are long-term, cross-functional, difficult to reverse, or foundational; less when the work is local, simple, reversible, or already covered by established patterns.

Too little architecture allows structural complexity to accumulate unnoticed. Too much architecture creates overhead without improving outcomes.

The aim is not to make everything architectural.

The aim is to make the important structural choices visible early enough to make better decisions

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram

Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time

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.

TOGAF, EDGY, Zachman, ArchiMate, UML, BPMN, maturity models, metamodels, governance models, architecture tools. Entire religious ecosystems exist around them. Some architects speak about them with the kind of emotional commitment usually associated with sports teams or operating systems.

To be fair, these things can absolutely be useful. Frameworks can provide structure, common terminology, reusable practices, and ways to organize architecture work. Architecture tools can improve visibility and maintainability. Methods can help avoid reinventing everything from scratch.

The problem starts when these things are treated as if they automatically produce value on their own.

I have also been asked whether EA work should be justified to leadership through a specific framework or methodology.

My answer is usually no.

Not because they are useless, but because this is rarely how leadership evaluates the value of architecture in the first place.

Executives usually do not wake up thinking:

“We urgently need better metamodel governance.”

They worry about slower change, overlapping investments, unclear priorities, integration problems, operational risk, failed transformations, or why five teams are building the same thing in slightly different ways again.

These are structural problems. Architecture can absolutely help with them.

But the value does not come from the framework itself. It comes from improving decisions, coordination, visibility, and change execution. That distinction matters.

Frameworks Are Internal Tools, Not Business Value

Frameworks and methods are primarily internal tools for architecture work.

They help structure thinking, define viewpoints, organize information, and create consistency across architects. In larger environments, this can be genuinely useful.

But frameworks are not business outcomes.

The fact that an organization adopts TOGAF or ArchiMate does not automatically reduce complexity, improve strategy execution, or align investments. Those outcomes only appear if the organization changes how decisions are made and coordinated.

This sounds obvious when stated directly, but architecture discussions often blur the distinction.

Architecture tooling is a similar example. Platform vendors frequently describe benefits such as improved alignment, governance, or strategic planning. Technically, these things may become more possible.

But tools do not create those outcomes automatically. A repository filled with outdated diagrams is still an outdated repository. A perfectly modeled landscape that nobody uses in decisions is still unused architecture.

Why Framework-First Positioning Often Fails

If EA gets introduced primarily through frameworks, governance models, or architecture processes, the discussion quickly moves toward modeling standards, repository structures, diagram templates, governance processes and compliance checkpoints.

All of these may have an important role. But from leadership’s perspective, it can easily sound like additional process overhead rather than support for solving business problems.

This creates an unfortunate positioning problem. EA starts to appear as something the organization must comply with instead of something that helps the organization operate more effectively.

In practice, many executives care much less about how architecture work is performed than about whether it improves outcomes.

If architecture reduces duplication, clarifies priorities, supports transformation planning, improves coordination, or helps avoid expensive surprises, leadership is usually interested.

If the primary message is “we should adopt this framework because it is best practice,” the reaction is often more cautious, which is very reasonable.

Leadership Usually Experiences Structural Problems, Not Architecture Problems

The bigger issue is that leadership rarely experiences problems as “missing architecture” in the first place.

Instead, they experience projects moving in conflicting directions, strategy execution becoming fragmented, integrations becoming expensive, duplicated investments, unclear ownership, slow coordination between teams, increasing technology complexity, or uncertainty during mergers and reorganizations.

These are structural issues. EA can help make them visible, understandable, and manageable. But the connection needs to be explained in those terms.

This is why method-first positioning often misses the point. If leadership does not naturally frame the problem as an EA problem, it is unlikely to care deeply about the internal method architects use to solve it. The method may matter to architects, but it is rarely the reason leadership supports EA.

In practice, the value of EA usually appears through better decisions. Architecture helps organizations understand dependencies earlier, compare alternatives more realistically, recognize overlaps, identify long-term consequences, and coordinate change across organizational boundaries. This can improve portfolio prioritization, platform strategy, operating model changes, mergers and acquisitions, sourcing decisions, data governance, integration approaches, and transformation sequencing.

Why Architects Gravitate Toward Frameworks

Framework-oriented thinking persists for understandable reasons.

Frameworks are concrete. They provide certainty and structure in environments that are often messy and ambiguous. They also create professional identity. Certifications, modeling standards, governance processes, and tooling ecosystems make architecture work feel more systematic and mature.

They are also easier to explain than impact. It is much simpler to say “we follow TOGAF” than to demonstrate that EA has improved the quality of long-term investment decisions across the organization. The first is visible immediately. The second can be real, but harder to isolate and measure.

As a result, architecture discussions can gradually drift toward methods, tools, compliance, and process maturity instead of organizational outcomes.

Surprisingly often, the EA practice starts optimizing itself rather than the enterprise. An occupational hazard, perhaps.

A More Effective Way to Position Enterprise Architecture

EA tends to gain more support when it is positioned around organizational problems rather than architecture methods.

For example, EA can be positioned as a way to help strategy translate into executable change, improve portfolio coordination, reduce duplication, support large transformations, clarify dependencies, improve long-term technology decisions, reduce structural risk, and support organizational memory.

These are outcomes leadership usually recognizes more easily than frameworks, methods, or tooling choices.

This does not mean frameworks and methods are irrelevant. Good architecture practices still matter internally. Frameworks, tools, and governance models can help architects structure their work.

But they should support the outcome, not become the primary value proposition.

EA becomes easier to justify when the conversation starts from those outcomes: better decisions, clearer coordination, reduced complexity, and fewer expensive surprises. The method can remain in the background, where methods usually belong.

Closing Thought

EA does not create value because a framework exists, a repository is populated, or a governance process has been documented.

Those things can support architecture work internally. Frameworks can help architects structure their thinking, tools can improve visibility, and governance can create useful decision points.

But the actual value of architecture appears when organizations make better decisions, coordinate change more effectively, reduce unnecessary complexity, and avoid structural problems that would otherwise become expensive later.

Leadership usually cares less about the method itself and more about whether the organization works better as a result.

Leadership rarely buys frameworks. It buys better organizational outcomes.

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram

Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time

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.

Sometimes EA work makes a clear and visible difference. Sometimes its contribution is more modest, and a lighter approach is enough.

This does not mean that architecture is useful in some organizations and useless in others. It means that architecture work should be positioned carefully: close to the decisions, changes, and coordination problems where structural understanding actually matters.

Understanding this difference helps organizations use architecture more effectively. Not everywhere with the same intensity, but where it can make the greatest practical difference.

Contexts Where Enterprise Architecture Adds the Most Value

EA adds the most value when decisions or changes affect several parts of the organization, have long-term consequences, or require coordination across teams, applications, data, processes, or other organizations.

Strategic Planning, Strategy Execution and Portfolio Prioritization

EA adds significant value when strategy needs to be updated or translated into concrete development priorities.

EA can support strategic planning itself by providing a realistic view of the current state. For example, understanding the maturity of existing capabilities helps strategy work stay connected to what the organization can actually change.

Many strategies remain abstract unless the organization can see which capabilities, processes, data, applications, and technologies need to evolve. EA helps connect strategic goals to the actual structure of the organization.

This also supports prioritization. It helps identify which initiatives are necessary, which overlap, which depend on each other, and which should perhaps not be started at all.

Without this structural view, strategy execution can easily become a collection of disconnected projects. Each project may make sense on its own, while the overall direction remains unclear. A familiar organizational sport, unfortunately.

Major Project, Program and Capability Preparation

EA can be especially useful before major projects, programs, or capability-building efforts are formally launched.

At this stage, architecture helps clarify scope, dependencies, existing assets, risks, constraints, and possible implementation options. This reduces the likelihood that large initiatives start with unrealistic assumptions or discover major issues too late.

This is especially relevant when the change affects several capabilities, business units, applications, data domains, or external stakeholders.

It does not require producing a large architecture document before anything can move forward. The value is in making the starting point clearer, so that the initiative can be planned with fewer blind spots.

Large Structural and Operating Model Changes

One of the clearest contexts where EA adds value is during larger structural or operating model changes.

Examples include mergers and acquisitions, major outsourcing arrangements, insourcing, reorganizations, shared service models, or large-scale transformations. In these situations, multiple applications, processes, data flows, roles, responsibilities, and organizational structures may need to be combined, separated, or reshaped.

Without a shared structural view, it becomes difficult to understand overlaps, dependencies, integration challenges, and transition risks. Surprises tend to appear late, and the effort needed for integration or separation may be underestimated.

EA helps make the structure visible early enough to support planning, sequencing, and decision-making.

Cross-Organizational and Ecosystem Coordination

EA becomes more valuable when decisions need to be coordinated across multiple teams, business units, partner organizations, or even entire ecosystems.

In decentralized environments, different parts of the organization may develop solutions independently. This can support local flexibility, but it can also lead to duplication, fragmentation, inconsistent data definitions, and incompatible integration models.

Similar coordination challenges appear between organizations. Partner ecosystems, outsourcing arrangements, public sector collaboration, and large enterprise networks often require several actors to align processes, data, responsibilities, and interfaces.

EA can provide shared language, structures, and reference points that help align decisions without requiring full centralization. This becomes increasingly important when multiple parties influence shared capabilities, data flows, or customer experience.

Regulatory, Risk, Security and Compliance-Driven Change

EA is also valuable when change is driven by regulatory, security, privacy, or risk-related requirements.

In these situations, it is rarely enough to check one application or one process in isolation. The organization needs to understand where critical data is used, which applications support regulated activities, where integrations exist, who owns key responsibilities, and which capabilities are affected.

EA helps connect requirements to the actual operating model and application landscape. This reduces the risk of local fixes that solve one visible issue but create wider problems elsewhere.

This is particularly important when compliance requirements cut across organizational boundaries. A requirement may look simple on paper, as requirements sometimes enjoy doing, but its real impact may span processes, data, applications, vendors, and governance structures.

Long-Term Platform, Data and Integration Decisions

Some decisions have effects that extend far beyond their immediate context.

Platform choices, data structures, integration patterns, master data decisions, and core application selections can influence the organization for years. The cost of changing these decisions later can be significant, especially when other systems, processes, and teams start building on top of them.

EA helps make these longer-term implications visible at the time decisions are made. It supports better trade-offs between local needs, enterprise-wide consistency, cost, flexibility, risk, and future change.

This does not mean every technology decision needs heavy architectural analysis. But when a decision creates a foundation for many others, architecture should be involved before the concrete is poured.

Reuse, Standardization and Organizational Memory

EA is particularly useful in environments where reuse and standardization can create significant benefits.

When similar problems appear across the organization, shared solutions can reduce duplication, improve consistency, and make development more efficient. However, identifying these opportunities requires visibility across initiatives, capabilities, applications, and data.

Architecture work helps make patterns visible. It supports decisions about when reuse is beneficial, when standardization is necessary, and when local variation is justified.

EA also supports organizational memory over time. As applications evolve and people change roles, knowledge about structures, dependencies, decisions, and design rationale can become fragmented. Architecture helps retain and structure this knowledge so it can be reused in future decisions.

This is especially important in larger organizations where continuity cannot rely only on individuals. People move on. Applications remain. Sometimes the only thing more persistent than a legacy application is the mystery of why it exists.

When Architecture Adds Less Value

There are also situations where the value of formal architecture work is more limited.

In small, well-contained initiatives with few dependencies, the overhead of detailed architecture work may outweigh the benefits. If the change affects only a narrow area, has little impact on other teams or systems, and does not create long-term consequences, lightweight guidance is often enough.

The same applies in early experimentation. When the main goal is to learn quickly, test an idea, or explore an uncertain opportunity, flexibility and speed may be more important than structural alignment. Architecture can still help by setting simple boundaries, but it should not slow down learning.

Architecture also adds less value when the work does not involve meaningful architectural choices. If there are no real trade-offs around capabilities, data, integration, technology, security, scalability, compliance, or long-term maintainability, formal architecture involvement may add little.

Another low-value context is easily reversible decision-making. If a choice can be changed later with limited cost, limited risk, and limited impact on others, a short architectural check or simple principle may be sufficient.

The same is true for highly standardized implementation work. If the solution pattern is already known, the platform is established, responsibilities are clear, and relevant constraints have already been defined, additional architecture work may not add much. But this does not mean that the context can be ignored. Even in a standardized ERP, CRM, or platform implementation, the organization still needs to understand processes, roles, data, integrations, and operating model implications. The point is that architecture effort should focus on the remaining structural choices, not on re-analyzing what has already been standardized.

In these cases, the right answer is not to force architecture into the work. Lightweight guidance, reusable patterns, reference models, or simple principles may be enough.

Even then, it is useful to keep high-level current-state descriptions updated. A small change may not need much architecture by itself, but many small changes can gradually reshape the broader landscape. Without some shared visibility, the organization may only notice the accumulated complexity once it has already become expensive. “Just one small exception” has a surprisingly active social life.

Closing Thought

EA does not create the same value everywhere. Its impact is highest where structure matters: when complexity is high, dependencies are significant, decisions have long-term consequences, or coordination across teams, functions or organizations is required.

This is why architecture work should be positioned deliberately rather than applied uniformly. It helps to understand which neighboring functions and stakeholder groups most often need architectural support, such as strategic planning, portfolio management, delivery, data management, security, and procurement.

When architecture is close to the right questions at the right time, even relatively small contributions can have a meaningful effect.

The value of EA work is not only in what it produces, but in where and when it is applied.

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram

Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time

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.

More often, the opposite is true. There are models, principles, governance processes, review forums, templates, and structured ways of working. Architecture is visibly present across initiatives. From the outside, the practice may look mature.

In fact, architects are often very good at finding things to work on—for themselves and for others.

But not all of that work is necessarily useful. The impact on actual decisions, priorities, or outcomes can remain limited.

The issue is rarely lack of effort—even if time and resources are often perceived as limited. It is also not always about quality. More often, it is about how the EA practice is positioned relative to planning, decision-making, and delivery. In some organizations, EA practices unintentionally create conditions where architecture work is actively done, but does not meaningfully influence outcomes.

That is architecture theater.

When Enterprise Architecture Practices Become Theater

Architecture theater emerges from recurring practices that look reasonable in isolation but gradually optimize for activity instead of impact. These practices may produce visible work, but their connection to outcomes is weak.

Architecture Defined Through Activity

In some organizations, architecture is understood mainly through what the EA practice produces and maintains: models, principles, roadmaps, standards, and governance activities such as meetings, reviews, and decision forums.

These outputs and routines can be useful. The problem emerges when their existence becomes the measure of progress. Work is considered complete when something has been produced, documented, or reviewed, not when it has informed or changed a decision.

This can be seen, for example, when capability maps are regularly updated but not used in prioritization, or when principles are defined but rarely applied in concrete design situations.

Architects keep busy, even when their impact is limited.

Governance Without Real Influence

Architecture governance may include review processes, checkpoints, templates, and approval mechanisms. Projects engage with the EA practice at defined stages, and the process looks structured.

The key question is whether the process changes anything.

Governance becomes theater when it mainly confirms decisions that have already been made, checks whether required materials exist, or documents choices without shaping them. Reviews may focus on whether documentation is complete and in the correct format rather than whether the underlying solution is sound or aligned with broader structure.

Governance creates value when it helps clarify options, improves decisions, and ensures that relevant aspects of the current state—such as existing capabilities, dependencies, and constraints—are properly taken into account.

Required Deliverables Without Purpose

As part of governance, some EA practices require projects to produce standard architecture deliverables regardless of context.

A project may need to create target state descriptions or provide detailed explanations of how principles are applied simply because the method requires them. In some situations, that can be useful. In others, the material is produced mainly to satisfy the process.

These deliverables can create value when they are actively used—for example, to assess the feasibility of a solution, to evaluate how well it fits with existing capabilities and constraints, or to align individual initiatives with broader architectural direction.

However, when the connection to actual use remains weak, the same work can become largely formal. Deliverables are created, reviewed, and stored, but do not meaningfully influence decisions.

In such cases, the practice may appear disciplined, while its impact on outcomes remains limited.

Optimizing the Practice Instead of the Outcome

EA practices can also become focused on their own internal consistency.

Effort goes into refining metamodels, improving notation, organizing repository, or making the practice more complete. In many cases, enterprise architects spend significant time on developing tooling—configuring architecture tools, extending data models, creating integrations, or optimizing how information is captured and maintained. In a similar way, effort may also go into aligning work with selected frameworks or ensuring compliance with methodology, regardless of whether it improves decision-making in practice.

These activities are not inherently wrong. They can support quality, consistency, and maintainability of architecture work.

The challenge emerges when the focus shifts from supporting decisions to improving the practice for its own sake. Tooling, models, structures, and framework alignment become increasingly refined, but their connection to real decision situations remains weak.

At that point, the practice may become internally strong but externally less relevant. A comprehensive architecture repository is useful only if it helps the organization reason about change.

Architecture Disconnected from Planning and Delivery

Perhaps the most important anti-pattern is architecture work that is not embedded in real planning, decision-making, and delivery processes.

Architecture may happen alongside the organization rather than inside the flow of work. Architects produce material, but are not consistently involved when priorities are set, trade-offs are made, or delivery decisions are finalized.

This disconnection can appear in several ways. Architecture deliverables may be produced too early, before the decision context is clear, or too late, after key choices have already been made. In some cases, relevant architecture input is not produced at all for the situations where it would matter most.

Interaction with stakeholders may also remain limited. If architects are not closely engaged with business, product, and delivery teams, the work may not reflect real needs or constraints. Without regular dialogue, architecture risks being based on assumptions rather than actual decision situations. Sometimes this is due to how the organization is structured—architects are just not invited into the right conversations early enough. In other cases, it may reflect how architects engage with stakeholders and position their contribution.

As a result, even well-structured material may remain unused, or used only partially. And when this happens, the EA practice may be active but structurally distant from outcomes.

Why This Happens in Practice

Architecture theater is rarely intentional. It often emerges from everyday, reasonable choices. Deliverables are easier to count than better decisions. Reviews are easier to schedule than meaningful influence. Framework compliance is easier to demonstrate than reduced complexity. Visible activity is easier to manage than impact.

All on all, it is often easier to produce something concrete than to influence decisions, which is more abstract and situational.

At the same time, the EA practice is not always positioned where decisions are actually made. It may sit slightly outside planning and delivery. Architects may be involved, but not always at the moments that matter most.

There are also practical constraints. Time is limited, priorities compete, and not every situation gets the attention it would ideally need. In such conditions, it is natural to focus on what is visible, structured, and expected.

Over time, these patterns reinforce each other. Organizations reward activity that can be seen and reported. EA practices adapt to those expectations.

The result can be a function that looks mature on paper, but has limited effect on how the organization actually changes.

Where Architecture Actually Creates Value

A useful way to evaluate an EA practice is to focus on where it changes something. Not where it produces artifacts. Not where it creates meetings. Not where it satisfies a method.

But where it leads to better choices, reduced complexity, or more consistent outcomes.

A few simple questions can help make this visible:

• What is the intended purpose of this architecture work?

• When was this architecture work last used?

• Where does architecture actually change decisions?

• In which situations would the outcome be different without it?

• Which stakeholders actively use architecture in their work?

• Where does architecture help avoid rework, duplication, or unnecessary complexity?

If these questions are difficult to answer, it may be a sign that the connection between activity and impact is weak.

Closing Thought

EA practices do not create value simply by existing. They create value when they improve how the organization plans, decides, and delivers change.

Architecture theater emerges when the form of architecture remains, but the connection to outcomes weakens.

The goal is not to remove structure, governance, or deliverables. The goal is to ensure that they are used in situations where they actually influence what happens next.

Because architecture work only becomes valuable when it changes how the organization acts.

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram

Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time

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.

What has changed is the speed and scale at which such solutions can now emerge.

Low-code platforms, SaaS tools, automation services, and AI-assisted development allow individuals and teams to build solutions that previously required dedicated development capacity. Workflows can be automated in hours, reporting solutions assembled quickly, and small applications created without formal project structures.

These tools often solve real problems fast. They reduce waiting time and help teams move forward when centralized development capacity is limited. Initially, usage is typically local and the benefits are immediate.

Over time, however, some solutions expand beyond their original scope. Data accumulates, more users adopt the tool, and new dependencies emerge. What began as a local productivity improvement gradually becomes part of operational routines—and eventually part of the enterprise structure.

The challenge is not the tools themselves, but the moment when they begin to influence shared data, recurring processes, or dependencies between teams. Locally optimized solutions may start shaping the broader enterprise architecture (EA) even though they were not designed with the same expectations for security, lifecycle, or long-term maintainability as enterprise systems.

This transition rarely happens through an explicit decision. Structure emerges incrementally.

Enterprise architects can help recognize when local solutions begin to have structural impact and support their evolution into more sustainable parts of the overall system.

Why Shadow IT Persists

Shadow IT often appears when the official system landscape does not fully support emerging needs.

Centralized development capacity may be limited, prioritization cycles long, and existing applications difficult to adapt to new needs. End-user tools allow teams to solve local problems quickly without waiting for budget approval, formal procurement, or development capacity. Solutions can then evolve gradually as needs become clearer.

Governance can also unintentionally contribute. If official channels are experienced as slow, unclear, or disproportionate to the size of the need, teams will look for alternative ways to move forward. Often the issue is not resistance to governance itself, but the absence of a practical path for smaller changes.

From a local perspective, shadow IT is therefore often rational. It reflects a need for flexibility where the existing structure does not fully support how the organization needs to work.

When Local Solutions Become Structural

Not all end-user solutions become structurally relevant. Many remain small and temporary. Some are replaced by more robust solutions later. Others are abandoned when needs change.

However, certain characteristics often indicate that a local solution is becoming structurally significant.

The solution begins to store information that other processes rely on. Multiple teams start to depend on the same tool. The solution becomes part of recurring operational workflows. Integration needs begin to emerge. Replacing the tool would disrupt daily work.

At this point, the question is no longer only about local productivity. It becomes a question of structural dependency. And challenges start to emerge when structural dependencies remain implicit.

Typical Structural Risks

When end-user solutions grow without visibility at the EA level, familiar structural patterns tend to appear.

• Fragmented data structures. Similar information may be stored in multiple locations with slightly different definitions. Customer or product data may exist in CRM, spreadsheets, and local applications simultaneously, gradually diverging in meaning and structure.

• Implicit process dependencies. Critical workflow steps may rely on locally maintained automations or applications. When knowledge about the solution is concentrated with a single individual, continuity and maintainability become uncertain.

• Uneven security and access practices. Tools originally intended for local use may not align fully with broader security or access management practices. Permissions may evolve organically, and potential vulnerabilities or compliance considerations may not have been fully evaluated.

• Increasing integration complexity. As locally created solutions begin to exchange data with other systems, point-to-point integrations can accumulate. Even when shared integration platforms exist, common conventions for data structures, versioning, or lifecycle management may not be consistently applied.

• Scalability limitations. Many end-user solutions are built for a small number of users and limited data volumes. As usage expands, expectations may change faster than the solution’s technical or operational robustness.

• Unmanaged lifecycle and support. End-user solutions often fall outside normal IT service management practices. Support responsibilities may be unclear, change management informal, and documentation limited. Access rights or operational knowledge may depend on individual people.

Individually, these situations rarely create immediate disruption. More often, the effects accumulate gradually and appear later as increased coordination effort, migration complexity, or reduced flexibility when changes are needed.

How Enterprise Architecture Can Help

The most useful EA response to shadow IT is usually not tighter control, but earlier visibility.

Heavy approval processes for every spreadsheet or automation would only push activity further underground. A more effective approach is to define simple thresholds for architectural attention. For example, a solution may become relevant when it stores shared business data, supports recurring operational work, is used by multiple teams, integrates with other systems, or would cause disruption if unavailable.

Several lightweight practices can help improve visibility without slowing down experimentation:

• Visibility of structurally relevant solutions. Enterprise architects can help introduce lightweight ways to identify solutions that begin to influence the broader system. A short description, simple classification, or visibility in a shared repository can already help create awareness. Small cross-functional forums can also help identify patterns when similar tools emerge in parallel across different units.

• Proportional governance and simple classification. Not every end-user tool requires architectural involvement. A personal productivity tool is different from a solution that stores shared business data or supports recurring operational workflows. A lightweight classification helps distinguish harmless local experimentation from solutions that require ownership, lifecycle thinking, or integration awareness.

• Prevention through principles and guidance. Architecture can help reduce future problems by guiding development early enough. Lightweight principles can steer local solutions toward compatible choices without slowing experimentation. Guidance may clarify preferred integration approaches, identity services, data handling practices, or reuse of existing platforms. When teams understand what capabilities already exist, they are less likely to create isolated alternatives. Supporting reuse across initiatives is one of the basic benefits EA is expected to provide.

• A gradual path from local solution to shared capability. Organizations can define a simple path for solutions that become more important over time. A local tool may first be registered, then assigned an owner, aligned with shared data or access practices, and eventually migrated, productized, or replaced if its role becomes sufficiently critical. This allows useful solutions to evolve without forcing every idea through a heavy project model from the start.

The objective is not centralized control, but shared understanding of when local solutions begin to influence the broader system. When emerging dependencies are visible early enough, organizations retain more flexibility in how solutions evolve, integrate, or scale. EA can help ensure that useful local solutions can grow into sustainable parts of the landscape rather than isolated islands of functionality.

Shadow IT as Early Architecture Signal

Shadow IT is often described primarily as a risk. From an architectural perspective, it can also be seen as information.

It highlights areas where existing systems do not fully support evolving needs. Patterns in end-user tooling often reveal structural demand before formal initiatives appear.

Repeated use of similar tools may indicate the need for shared data structures. Parallel workflows may signal gaps in process support. Increasing reliance on local automation may point to opportunities for shared capabilities.

These signals can also inform portfolio planning. If several units independently create similar solutions, this may indicate stronger demand than a single formal business case.

The EA function can help translate these weak signals into structural questions: is a shared capability missing, should an existing platform be extended, or is there a need for more consistent data or integration structures? When such patterns are recognized early enough, organizations can respond more deliberately and shape emerging structure before dependencies become difficult to change.

Closing Thought

Local solutions will continue to emerge wherever unmet needs exist. This is unlikely to change.

Shadow IT is not eliminated by ignoring local needs or by trying to prevent experimentation. Teams will always find ways to solve immediate problems when existing applications or processes do not provide a sufficiently usable path forward.

The structural challenge is not the existence of local solutions, but recognizing when they begin to influence shared data, recurring processes, or dependencies between teams. At that point, what started as a useful local improvement becomes part of the broader EA.

This transition rarely happens through an explicit decision. Structure emerges gradually through many small choices.

EA can help make this transition visible early enough. When emerging dependencies are understood in time, organizations retain more flexibility in how solutions evolve, integrate, or are gradually replaced with more sustainable alternatives.

Structure will emerge in any case. EA helps ensure that it does not emerge entirely by accident.

📕Further Reading: Where My Writing Career Started

A small side note before the end: although this Substack focuses on enterprise architecture and organizational change, my writing career actually started elsewhere.

Before the enterprise architecture books, I wrote two practical books on IT consulting: Technology Consultant Fast Track and Successful Technology Consulting. In many ways, those books were the real beginning of my career as an author.

They were written from practical experience, with a fairly direct approach and little patience for empty career advice. Even now, I think they remain very relevant for anyone interested in consulting work, expert careers, and professional growth.

Especially Successful Technology Consulting is relevant for enterprise architects (and other knowledge workers, too). Enterprise architecture can, of course, also be the substance of consulting work.

Both books are currently on sale for $0.99 + tax:

Technology Consultant Fast Track
https://www.amazon.com/dp/B0918JB48D

Successful Technology Consulting
https://www.amazon.com/dp/B0B379SWDR

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram

Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time

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.

At the same time, a significant part of its impact becomes most visible only when it is missing.

When architecture works well, decisions feel easier to make. Dependencies are clearer earlier. Initiatives align with fewer surprises. Delivery progresses without unnecessary structural friction. The effects accumulate quietly across many changes rather than appearing as a single visible outcome.

When architecture is missing or only loosely connected to change, the symptoms tend to appear elsewhere. Not as a single failure, but as a recurring pattern.

Where The Effects Typically Appear

The effects of missing architecture tend to appear at multiple levels simultaneously.

Some appear in individual decision situations, where choices are made with a narrower view of dependencies, constraints, or longer-term structural consequences. When a holistic perspective is missing, decisions may still be reasonable locally, but the broader implications remain less visible.

Other effects accumulate gradually in the landscape itself. Similar capabilities emerge in parallel, technologies diversify, and integration structures become heavier over time. The structure evolves incrementally without an explicit view of how individual changes relate to each other.

A third group of effects becomes visible in delivery work. Teams spend additional time reconstructing context, coordinating dependencies, or resolving structural surprises later in the lifecycle. The effort required to understand and align increases.

These patterns are often connected. Small local decisions gradually shape the structural environment in which future decisions are made.

Typical Structural Costs Of Missing Architecture

When shared EA structure is limited or not actively used, the consequences rarely appear as a single dramatic failure. More often, the effects accumulate gradually across initiatives and become visible as additional effort, coordination complexity, or reduced flexibility.

The organization is still able to deliver change. Projects move forward. Solutions work. But the cost of change tends to increase over time.

Many of the effects described earlier become visible here in concrete form: repeated analysis, parallel solutions, fragmented technology choices, and growing coordination needs.

Below are some recurring structural patterns where the absence of sufficiently shared architecture can create hidden cost.

Repeated Work and Rediscovery

At the most visible level, missing architecture content often leads to repeated analysis work.

Similar current state mappings are recreated across initiatives. Dependency analyses are performed again and again. Teams spend time reconstructing context that already exists somewhere in the organization.

Sometimes the same conceptual work is repeated in slightly different formats. Each project builds just enough understanding to move forward, but the knowledge does not fully accumulate.

When analysis is done under time pressure, important dependencies or structural implications may also be overlooked. Issues that could have been identified earlier may surface later in delivery, when changes are more expensive to make.

The cost usually appears as duplicated effort rather than clearly visible architectural gaps.

Repeated Conceptual Alignment and Boundary Decisions

Organizations often revisit similar structural questions across initiatives:

What exactly is meant by “customer”?
What distinguishes an “order” from a “transaction”?
Which application is the authoritative source for specific data?
Should this technical capability belong to this application or another?
Is this an integration or part of the same solution?
Which team owns this responsibility?

The terminology may appear familiar, yet meanings and boundaries are not always fully aligned. Each initiative establishes just enough shared understanding to move forward, but the structural clarity does not always accumulate.

As a result, conceptual alignment and boundary decisions are often made locally during delivery work. The solution may function in its own context, yet similar questions are revisited in parallel elsewhere in the organization.

The cost appears as slower convergence of shared understanding, additional coordination effort, and structural compromises that may reduce long-term clarity of the landscape.

Duplicate Solutions And Parallel Capabilities

Without sufficient visibility across initiatives, similar solutions may be developed multiple times.

Solutions are often created for a specific immediate need, usually under delivery pressure. The primary objective is to solve the problem at hand rather than evaluate whether an equivalent technical capability already exists elsewhere in the organization. A related pattern is that similar problems are solved using different structural approaches.

As a result, different units may implement overlapping capabilities independently. Similar integrations may be built separately. Reporting solutions may be created locally. Customer data may be stored in multiple systems with slightly different structures. Authentication or authorization mechanisms may be implemented differently across solutions.

Each decision may be locally justified based on context, timelines, or team familiarity. Over time, however, the overall landscape becomes heavier than necessary. Also, learning does not compound as effectively, and reuse becomes harder to achieve.

The cost appears as redundant development, reduced consistency, fragmented ownership, and increased long-term maintenance effort.

Increasing Integration Complexity

When shared structural guidance is limited, integration patterns often evolve incrementally.

For example, point-to-point integrations may accumulate over time. API management practices may vary across teams when no role actively steers shared API conventions. Even when an API platform exists, interfaces may still be designed locally without consistent approaches to data structures, versioning, reuse, or lifecycle management.

As the number of connections grows, dependencies become harder to understand. Small changes may require coordination across multiple teams.

Integration effort increases not only because of technical complexity, but because the structure of the landscape becomes less predictable.

The cost appears as slower change and increased coordination effort.

Fragmented Technology Portfolio

Over time, local optimization can lead to a heterogeneous technology landscape.

Multiple tools may be introduced for similar purposes. Platforms may overlap. Skill requirements diversify. Vendor relationships multiply. Teams spend time evaluating similar tooling options independently.

Individually, each decision may have been justified based on local constraints, existing competencies, or delivery timelines.

Collectively, however, the portfolio becomes more difficult to manage and evolve. Opportunities for reuse decrease. Knowledge becomes more fragmented. Coordination effort increases.

The cost appears as increased maintenance effort, reduced economies of scale, and higher cognitive load across teams.

Misaligned Application Choices

Architecture also helps evaluate whether an application fits its intended purpose within the broader environment.

Without a sufficiently holistic view, application selection decisions may focus primarily on local requirements. A solution may appear to be a good match for the immediate need and may accelerate local delivery.

However, the application may introduce structural constraints that become visible later. Examples include incompatible data models, limited integration capabilities, inflexible licensing structures, or assumptions that do not align with the broader landscape.

A locally optimal decision can gradually reduce flexibility at the system level.

The cost appears as adaptation effort, additional integration work, and reduced optionality in future change.

Structural Consequences in Larger Changes

The effects of missing architectural perspective often become more visible in larger structural transformations.

In outsourcing situations, insufficient understanding of dependencies may lead to contractual structures that are difficult to operate effectively. In mergers or acquisitions, overlapping capabilities may be discovered later than expected.

In such situations, the lack of shared structural understanding can increase both uncertainty and effort.

The cost appears as delayed synergy realization, increased integration complexity, or reduced speed of structural change.

Closing Thought: The Cost Of Change Depends On Structure

At a broader level, the patterns above often share a common structural characteristic: no single decision causes the situation.

Complexity emerges gradually when no role consistently looks across initiatives, capabilities, and dependencies. Local optimization accumulates into system-level friction.

Without a perspective that connects individual changes into a coherent whole, almost any combination of outcomes becomes possible. Solutions work locally, but the overall structure becomes heavier than necessary.

This hidden cost of missing architecture is rarely measured directly. It does not usually appear as a single budget item. Instead, it is distributed across projects, solutions, and time. It appears as additional effort, repeated analysis, duplicated technologies, coordination overhead, and slower adaptation when priorities change. Because the effects are diffuse, they are often accepted as part of normal operations.

One way to observe the absence of architecture is to look for recurring decision friction: situations where similar questions are repeatedly resolved without accumulating shared architectural clarity.

From a structural perspective, architecture influences how expensive change becomes over time. It helps reduce repeated work, supports more consistent decisions, and makes dependencies visible earlier. These effects do not always produce immediate visible outcomes, but they shape how efficiently the organization can evolve.

The absence of architecture does not prevent change. It usually makes change more expensive or reduces the range of viable options over time.

In many cases, the question is not whether architecture creates value, but whether the organization recognizes the cost of operating without sufficient shared structure.

🧩 A Structural Perspective On Expert Value

Many expert roles create value in similar ways. The contribution often improves the conditions under which many decisions are made, rather than producing a single visible outcome. The value is real, but the connection between the work and its economic consequences is not always immediately visible.

I explore these dynamics further in my The Senior Expert Playbook series which looks at how structural positioning, visibility of contribution, and proximity to economically meaningful decisions influence how expert roles are recognized and compensated over time.

If the themes in this article resonate, the book expands the perspective beyond enterprise architecture to expert work more broadly.

The launch offer is still available, including the Expert Bundle:

• The Senior Expert Pay Playbook

• The Senior Expert Career Playbook

The bundle looks at expert work from two complementary angles: how expert roles create value inside organizations, and how that value translates into long-term career and compensation development.

The launch pricing is available via my Gumroad store until April 15.

Launch discount codes:

PAYSTRUCTURE22 – The Senior Expert Pay Playbook
EXPERTMODEL22 – Bundle including both books

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
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.

And yet, a familiar situation often emerges.

The deliverables exist, but they are not actively used.

They may be referenced occasionally, but they do not consistently shape decisions, prioritization, or design choices. Over time, the organization may even forget that certain artifacts exist at all.

In earlier posts, I have discussed how architects in their roles can help improve the use of architecture in decision-making. In this article, the focus is slightly different: the structural characteristics of the deliverables themselves. What makes some architecture artifacts more likely to be used than others?

Challenges That Limit The Use Of Enterprise Architecture Descriptions

Below are some recurring structural reasons why architecture deliverables remain underutilized, together with practical ways to improve their usability.

No Clear Use Case Or Decision Context

A common structural challenge is that the deliverable does not have a clearly defined use case, user, or decision context.

Architecture artifacts often describe a well-structured current landscape, but it is not clear who is expected to use the material or in which situation. A target architecture may exist, but no investment decisions explicitly refer to it. A capability map may describe the landscape, but it is not used when prioritizing initiatives. Principles may be documented, but not actively applied in project or steering discussions.

Decisions are the situations where architecture becomes actionable. When it is unclear which decisions a deliverable is meant to support—and who is expected to use it—the artifact can remain conceptually sound but practically distant.

Usability often improves when the intended use context is made explicit and embedded into existing methods and decision processes. For example, a capability map can be used as a standard input in prioritization discussions, a target architecture as a reference point in investment planning, or principles as part of solution design reviews and governance checkpoints. When the user, decision situation, and practical touchpoints are clear, the deliverable is more likely to be used consistently rather than occasionally.

Too Generic To Guide Decisions

Generic guidance is often easy to agree on but difficult to apply in practice.

Principles such as “reuse before build”, “prefer standard solutions”, or “ensure scalability” are broadly sensible, yet they rarely resolve concrete trade-offs. In real situations, teams need to balance cost, speed, technical constraints, existing contracts, skill availability, and delivery timelines. General guidance alone does not indicate what should be done in a specific situation.

A similar challenge appears with overly generic architectural descriptions. Reference architectures may describe broadly accepted patterns but remain too abstract to guide actual design choices. The same applies to current and future state descriptions such as capability maps, application landscapes, or data models that operate at such a high level that the connection to real operational context remains unclear. As a result, the same material may be interpreted differently across stakeholders, or bypassed altogether when time pressure increases.

Usability often improves when the description remains simple but becomes more concrete. A principle can become more actionable when supported by examples from recent initiatives, clarification of typical trade-offs, or illustration of how the guidance applies in common design situations. Similarly, a model can remain high-level while still connecting architectural elements to recognizable business concepts such as products, customers, transactions, or operational processes.

When architecture deliverables remain understandable but relate clearly to real-world constructs, they are more likely to support consistent decisions rather than remain abstract representations.

Unclear Reliability or Quality Issues

Architecture deliverables are less likely to be used when their reliability is uncertain or quality is poor.

Common issues include descriptions that are not up to date, unclear version status, or uncertainty about what exactly is being described. For example, it may not be obvious whether a diagram represents current state, a planned change, or a conceptual example. In some cases, the information may also be partially incorrect or incomplete.

Another typical situation is that the deliverable does not align well with other architecture views. The same concept may be described differently across diagrams, or relationships between elements may not be consistent. Inconsistent or unclear use of notation can further reduce confidence, especially when similar symbols appear to represent different meanings in different diagrams. Unnecessarily complex models can amplify these issues, making it harder to verify consistency and maintain reliability over time.

When users are unsure whether the content is accurate, consistent, or still valid, or find it difficult to understand, they may hesitate to rely on it in decision situations.

Usability often improves when the scope, status, and level of completeness are made explicit. Indicating whether a description represents current state, target state, or work in progress can reduce uncertainty. Quality can also be strengthened by keeping key views reasonably up to date, using notation consistently, ensuring that related deliverables describe the architecture in a coherent way, and avoiding unnecessary complexity that makes models harder to maintain and trust.

Architecture descriptions do not need to be perfect in order to be useful, but they need to be sufficiently reliable and understandable that decision-makers feel comfortable using them as part of their reasoning.

The Level Of Detail Does Not Match The Situation

Architecture operates at multiple levels of detail, but the usefulness of a deliverable depends on whether the level matches the situation and the needs of the user.

If the model is too high level, users may struggle to translate it into concrete design implications. If the model is too detailed, decision-makers may not see the structural relevance or may find the material unnecessarily heavy for the question at hand.

The same deliverable may be useful for one role but not for another. For example, a high-level system landscape can help a CIO understand application portfolio complexity, identify consolidation opportunities, or visualize cost distribution—especially when the visualization includes attributes such as lifecycle status, ownership, criticality, cost, or technical risk. For a solution designer working on a specific implementation decision, the same diagram may offer limited guidance.

Usability often improves when the level of detail is aligned with the decision context. Coarse-grained views can support prioritization and communication, while more detailed views can support solution design and implementation planning. At the same time, the relationships between different levels of detail need to remain reasonably consistent, so that detailed views can be understood in relation to broader structures.

Produced At The Wrong Time or Not Available When Needed

Timing has a strong influence on usability. A common challenge is that architecture deliverables are either produced too early or not available when decisions actually need to be made.

Sometimes architecture work happens before the surrounding decision context is sufficiently clear. The deliverable may reflect reasonable assumptions at the time, but those assumptions evolve as the initiative progresses. The artifact can then feel outdated before it has had a real opportunity to be used.

In other situations, the opposite occurs: the material would be useful, but it is not available when needed. Or it technically exists, but is difficult to find when needed. Teams then reconstruct their own view of the current state, dependencies, or constraints repeatedly, often under time pressure. Similar analyses may be recreated multiple times across initiatives because shared material is missing or difficult to locate.

Many architecture deliverables are most useful when the decision space is sufficiently defined, but still flexible enough to influence outcomes. At that point, key questions are becoming clearer, but structural choices have not yet been locked in.

Usability often improves when architecture work is more closely aligned with the planning, prioritization, and solution design cycles. Instead of producing material far in advance, some artifacts may be more effective when developed iteratively alongside initiatives, allowing assumptions to evolve together with the decision context.

At the same time, maintaining a lightweight high-level current state description is often worthwhile. In sufficiently mature environments, there is continuous need for a shared overview of capabilities, applications, and key dependencies. Even a coarse but reasonably up-to-date baseline can significantly reduce repeated discovery work across initiatives.

No Clear Ownership

Architecture deliverables often exist in shared repositories, but responsibility for maintaining and applying them can remain unclear.

When ownership is diffuse, artifacts can gradually drift out of date. Teams may not know whether the material still reflects current situation or whether it has been superseded.

Ownership is not only about maintaining the content itself. It also involves supporting its use in practice. If no one is responsible for connecting the deliverable to ongoing initiatives, design discussions, or planning processes, its practical relevance can weaken over time.

Architecture material tends to remain useful when someone actively keeps it connected to real change. This can include updating key views when the landscape evolves, clarifying how the material should be interpreted in specific contexts, and ensuring that relevant stakeholders are aware of its existence.

Clear ownership helps ensure that deliverables remain sufficiently current, understandable, and usable. It also creates continuity in how architectural guidance is applied across initiatives, reducing the likelihood that each team interprets the material independently.

Closing Thoughts: From Deliverables To Decision Support

EA does not necessarily need more deliverables. In many situations, a smaller number of artifacts that are clearly connected to decision contexts can create more impact than a large collection of loosely connected materials.

The goal is not to produce documents, but to support decisions.

A simple question can often help clarify direction before creating a new artifact:
Which decision does this help us make?

When the connection to decisions is clear, architecture deliverables tend to remain useful for longer. They become part of how the organization reasons about change, rather than static descriptions stored for reference.

When architecture artifacts function as shared tools for structuring discussions, clarifying trade-offs, and supporting consistent choices, they tend to stay relevant.

And when they stay relevant, they tend to be used.

📘 New Book: The Senior Expert Pay Playbook

If you work in enterprise architecture or another senior expert role, you have probably noticed that compensation does not always follow effort, competence, or even impact in a straightforward way.

I recently wrote a short book, The Senior Expert Pay Playbook, which looks at compensation from a structural perspective: how positioning, visibility of value, and proximity to important decisions influence long-term earning development.

In a way, the book applies architectural thinking to compensation. How does value become legible inside organizations? Which roles are easier to connect to economic outcomes? Why do some expert positions develop more leverage over time than others?

Many of the patterns are familiar to enterprise architects.

The book includes my own 20-year salary trajectory together with structural analysis of what influenced the progression.

The launch offer is still available:

PAYSTRUCTURE22 – The Senior Expert Pay Playbook
EXPERTMODEL22 – bundle with The Senior Expert Career Playbook

Available via Gumroad.

If you are interested in how structural positioning affects both influence and compensation, the perspective should feel quite natural.

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
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.

I have described the benefit creation process in EA in my dissertation and earlier posts in more detail, but the basic pattern is quite stable. Architecture improves how organizations plan and decide. It helps teams choose more viable options, recognize constraints earlier, and avoid expensive misalignment between initiatives. Over time, this translates into higher-quality investments, fewer delivery surprises, and more coherent development of business and technology capabilities.

The challenge is that in EA, the chain to economical value is often notoriously long:

An architect supports a project.
The project proposes a solution.
The steering group approves it.
The delivery team implements it.
The solution supports a product or service.
The product generates revenue or improves cost efficiency.

Architecture often operates one or two steps removed from where economic outcomes become directly visible, sometimes more. In practice, EA can easily become a support function to a support function. And when the value chain becomes long, attribution becomes harder.

This structural position also shapes how architects themselves are perceived. Enterprise architects rarely sell directly, make final investment decisions, carry explicit profit responsibility, or control significant budgets. Much of the work is about enabling others to succeed.

The challenge is usually not the absence of value, but the distance between architectural work and its economic consequences. Some architectural work sits close to decisions that directly influence revenue, cost structure, or strategic positioning. Other work operates further away, strengthening the system within which those decisions are made.

Both are necessary, but the visibility of impact varies—and visibility often influences how expert work is recognized, how influence develops, and ultimately how the architect’s compensation evolves.

Distance To Value Creation As A Useful Lens

One helpful way to think about architectural work is as a continuum based on distance to value creation.

Close to value creation are activities that influence strategic direction, major investment choices, significant transformation programs, and solution structures that directly support sales or materially affect the cost base. In these situations, the connection between architectural work and business outcomes is usually easier to follow. The feedback loop is shorter, and the contribution becomes visible faster.

Further from value creation are activities such as maintaining repositories, developing standards, coordinating alignment, and ensuring consistency across domains. These create stability and continuity. They reduce entropy in the system. When they work well, they are often barely noticed.

Both ends of the continuum are necessary. Organizations need shared structure as much as they need direction-setting decisions. But the distance has practical implications for architects themselves.

Work that sits closer to economic consequences is usually easier to explain in terms that resonate with leadership priorities. The contribution becomes easier to connect to investment logic, growth targets, or cost structure development. This tends to influence how roles are perceived, how influence evolves, and often how the architect’s compensation develops over time.

Work that operates further away from visible value creation can still be essential, but the contribution may remain implicit. The organization benefits from reduced friction and improved coherence, yet the connection to economic outcomes may not be explicitly clear. When value remains less visible, it can also become harder to position the architect’s role in economic terms.

Understanding distance to value creation is therefore useful not only for structuring architectural work, but also for understanding how different architectural positions tend to translate into influence, recognition, and compensation over time.

We can make this more concrete by looking at a few recurring architectural archetypes—not as personality types, but as structural positions that tend to sit at different distances from value creation.

Archetype 1: The Current State Steward

One recurring EA position focuses on maintaining a coherent representation of the current landscape. The work often revolves around repositories, the quality and usability of descriptions, shared meta-models, and governance practices that keep things reasonably consistent as the organization evolves.

At its core, this role builds and maintains shared understanding. When the current state is sufficiently clear, decisions can be made faster and with more confidence. Dependencies are easier to identify. Impacts can be estimated with less guesswork. Conversations move forward without repeatedly stopping to reconstruct the same basic picture of how things fit together.

Without this foundation, organizations tend to rediscover the same things again and again. The same mappings are recreated in multiple projects. Similar dependency analyses are repeated from scratch. People spend time rebuilding context instead of moving decisions forward. And often, decision-makers do not have a handrail available when they need it. The material needed to support decisions exists somewhere, but not in a form that is easy to use in the moment.

In practice, the architect’s influence is mostly indirect. Instead of shaping individual high-visibility decisions, the work can improve the quality and speed of many decisions across the organization. A central part of the role is helping others make effective use of the architecture—making existing structures and dependencies understandable enough to support better-informed choices.

The value of this role is continuity. The organization develops a shared memory that reduces repeated effort and supports more consistent reasoning about change.

Still, the distance to value creation is relatively long. The contribution rarely shows up as a single visible win. Instead, it reduces friction across many situations. Its absence is usually easier to notice than its presence.

This also creates a structural challenge. When the benefits remain mostly invisible, the work can be perceived as optional. The contribution may not be clearly reflected in compensation, even when many teams quietly rely on it. In cost pressure situations, roles with less immediately visible impact can be easier to question, even if removing them gradually increases coordination cost elsewhere.

Archetype 2: The Delivery Enabler

Another common architectural position works close to initiatives that are actively delivering change. The focus is less on describing the landscape and more on helping concrete solutions fit into it in a sensible way.

The work typically happens in close collaboration with delivery teams, project managers, product owners, and program or steering groups. Architecture becomes part of the conversation where scope, sequencing, dependencies, and trade-offs are actively negotiated.

Influence in this role often combines collaboration, recommendations, and governance touchpoints such as design reviews or steering discussions. Instead of making decisions directly, the architect helps shape how decisions are made by clarifying constraints, highlighting dependencies, and making structural consequences visible early enough to matter.

Typical questions revolve around compatibility, reuse, dependencies, and sequencing. How does this solution interact with existing capabilities? Which choices create unnecessary lock-in later? Where could a seemingly local design decision create friction somewhere else in the system?

A significant part of the work is about making implicit assumptions visible early enough. When dependencies are identified late, delivery slows down. When integration complexity is underestimated, costs increase quietly. When design choices drift too far apart across teams, coherence gradually weakens.

Here architecture acts as a stabilizing force during movement.

The value shows up through smoother delivery, less rework, and fewer unpleasant surprises late in the implementation cycle. Teams can move faster when they do not repeatedly pause to resolve structural conflicts. Programs become more predictable when key design choices align reasonably well with the broader system.

Sometimes the contribution is very concrete: avoiding duplicate integrations, reusing an existing technical capability instead of rebuilding it, or identifying a dependency early enough to adjust designs without disruption. Small structural adjustments can prevent disproportionately large coordination effort later.

The distance to value creation is moderate. The work is connected to real change initiatives, but still one or two steps removed from direct economic outcomes.

From a compensation perspective, this position often sits in an interesting middle ground. The contribution is tangible enough to be appreciated, but not always directly attributable to a single measurable outcome. Visibility may depend on how explicitly architectural work is connected to delivery success, rather than being perceived as part of the background structure that simply allows projects to move forward. Recognition also depends on context. When initiatives are visible and strategically important, architectural contribution becomes easier to see and articulate.

Archetype 3: The Decision Partner

Some architectural roles operate very close to strategic decision-making. This often means working directly with senior leadership, department leads, business line owners, or transformation steering groups. The conversations are less about individual applications and more about direction, sequencing, and structural consequences. What capabilities should we strengthen first? Which investments create the most long-term leverage? How does the current architecture enable or constrain strategic options?

Capability-based planning is a good example. Instead of starting from individual projects or applications, the discussion shifts to the capabilities the organization needs in order to execute its strategy. This makes it easier to see where multiple initiatives are strengthening the same underlying ability, where fragmentation creates unnecessary cost, and where investments reinforce each other.

Architecture can also help make path dependencies visible before they fully form. Many decisions are difficult to reverse later not because change would be technically impossible, but because the surrounding ecosystem has already adapted to earlier choices.

Architecture in this position typically influences decisions more directly than in other architectural roles. The contribution is often visible in how priorities are framed, which alternatives are considered viable, and how resources are ultimately allocated. The value appears through improved decision quality and greater strategic clarity. Options can be compared on a more explicit basis. Risks become easier to reason about. Investment logic becomes easier to communicate across stakeholders.

Sometimes the contribution is helping an organization avoid an attractive but structurally limiting direction. At other times, it is about recognizing opportunity earlier—for example when a shared capability can support multiple strategic initiatives simultaneously.

The distance to value creation is short. Decisions influenced at this level shape multiple downstream initiatives and budget allocations, which makes the connection between architectural contribution and economic outcomes easier to observe.

Visibility also tends to increase naturally in these contexts. When architecture participates in conversations where priorities and funding directions are defined, the contribution becomes easier to associate with concrete organizational outcomes.

From a compensation perspective, roles closer to resource allocation and strategic direction often benefit from this shorter distance to visible impact. The work is easier to describe in terms that resonate with business priorities, which can strengthen both perceived relevance and negotiating position over time.

Visibility Shapes Influence and Recognition

None of these positions is inherently better than the others. Complex organizations need continuity and change at the same time. They need shared structure, but also the ability to adapt it. They need coordination, but also local autonomy. Architecture plays a role in balancing these forces.

However, the positions do differ in how clearly their contribution can be observed. Some work naturally produces artifacts that are easy to point at: a solution blueprint, an investment recommendation, a structural simplification that reduces cost or enables speed. Other work improves the conditions under which many decisions are made, without attaching itself to a single visible outcome.

Visibility has practical consequences. It influences how work is understood, how priorities are set, and where additional resources are directed. It shapes how influence evolves inside the organization. And over time, it often affects how architect roles are positioned and how compensation develops.

Distance to value creation partly explains why some contributions are easier to see than others. But visibility is not fixed. Even structurally indirect work can often be made more legible by clarifying how it improves decision quality, reduces coordination cost, or enables more consistent execution across initiatives.

When the connection between activity and economic consequence becomes easier to understand, recognition tends to follow more naturally—not always immediately, but more consistently.

A Structural Perspective On Expert Value

This pattern is not unique to EA. Many expert roles create value indirectly through improved decisions, reduced risk exposure, or better coordination across organizational boundaries. The value can be significant, yet its impact is not always immediately visible.

When the connection between contribution and economic outcomes is less direct, the value may remain harder to describe in terms that resonate in resource allocation discussions. The work may be widely appreciated, yet still difficult to express in language that clearly links it to growth, cost structure, or strategic priorities.

Many senior experts encounter this structural pattern in their careers. The question is often not whether value is created, but how clearly that value connects to decisions that carry economic weight.

Differences in compensation frequently emerge not only from differences in capability, but from differences in how legible the contribution is within the organization’s decision logic.

I explore these dynamics more systematically in The Senior Expert Pay Playbook, which examines how structural positioning influences recognition, influence, and compensation over time. The central idea is straightforward: in expert roles, compensation often follows visible value creation—and visible value creation is shaped by how closely your work connects to decisions that affect economic outcomes.

📘 New Book: The Architecture of Expert Compensation

I recently wrote a short book, The Senior Expert Pay Playbook, which examines how expert compensation actually forms inside organizations. The focus is on structural patterns behind pay development rather than individual negotiation tactics.

In a way, the book looks at the architecture of compensation: how roles, responsibilities, positioning, and organizational context influence long-term earning trajectories. The perspective is likely familiar—and useful—also for enterprise architects.

The book includes my own salary graph together with structural analysis of expert compensation development.

The book is already available via my Gumroad store.

Launch discount codes (valid until April 15):
PAYSTRUCTURE22 (The Senior Expert Pay Playbook
EXPERTMODEL22 (bundle with The Senior Expert Career Playbook)

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
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.

In this case, the starting point was a set of familiar data challenges.

The organization was dealing with issues such as:

• the same data existing in multiple applications

• information not moving smoothly between applications

• data structures that had become increasingly complex over the years

• difficulties in producing reliable information for management and customers

• data quality issues affecting day-to-day operations

None of these challenges were particularly new. People in the organization were aware of them. What was missing was a clear understanding of how the organization’s core data actually fits together.

Management had recognized this gap and decided to approach the problem through a data architecture assignment.

The goal was to build a shared understanding of the organization’s current key information structures. At the same time, the assignment aimed to define a target state for the data architecture. The work was carried out at a more detailed level than typical enterprise architecture (EA) descriptions, focusing on the logical structure of the organization’s core information.

From an EA perspective, this was an interesting starting point. Many transformation initiatives begin with applications, processes, or individual projects. Here, the organization intentionally started with data architecture.

At the same time, process descriptions were produced in a separate assignment, which complemented the picture nicely.

Mapping the Current State

The current state model was built through interviews across the organization.

These discussions focused on questions such as:

• what key information entities exist

• how they relate to each other

• which applications handle them

• what kinds of challenges people face when working with the information

The work focused on building a logical-level data model of the organization’s core information. The model was expressed as a color-coded UML diagram, complemented with descriptions of entities, their key attributes, and the applications responsible for handling the data.

One thing that stood out positively was the atmosphere in the interviews. People were consistently constructive and willing to help. In architecture work this is not always guaranteed.

Regular follow-up discussions with the key participants proved essential. The model evolved through iterative validation, not through one round of workshops. Without that loop, the model would quickly drift away from reality.

Another practical factor helped a lot: the customer had a strong project manager who knew the organization well. She was able to identify the right people to involve and provided useful background material before the interviews.

Building the Target State

Constructing a logical target state model is not particularly difficult in theory, but the real difficulty is this: who can really say what the business and its information structures should look like five or ten years from now?

Any target model inevitably contains assumptions about the future. The goal is not to predict the exact structures, but to define something that can support the organization’s development without locking it too tightly into today’s situation. In practice, this means navigating between different expectations and perspectives across the organization.

At the same time, the model still needs to resonate with the organization. People inevitably compare the target state with the structures they know from their daily work.

There was also a personal challenge. I had only recently entered this particular organization. Building a meaningful data model in that situation requires some humility—and a lot of questions.

Another challenge was the level of abstraction. The target state needed to support the organization’s future growth and scalability, which meant the model could not be tied too tightly to the current structures.

At the same time, if the model becomes too generic, it quickly loses its practical value. The real task was to find a balance between concreteness and generality. This was also visible in the model itself. The target state ended up containing significantly fewer entities than the current state.

The modeling approach itself remained similar to the current state description. The entities and relationships were presented in a comparable visual structure, which made it easier for participants to follow the discussion. The key difference was that the target model was not tied to specific applications. Instead, it focused purely on the logical structure of the organization’s core information.

Enough time was reserved for both developing and validating the target state. Validation was done through concrete business situations: how the model would support actual operational scenarios. This approach made the discussions much more productive than abstract architecture debates.

An Interesting Side Effect

The modeling work itself was valuable, but the most interesting effects appeared elsewhere. Once the structures were visualized, several things started to happen.

First, describing the organization’s data also helped clarify the business itself. In many organizations, the underlying information structures reflect how the business actually operates. Once those structures became visible, it became easier to understand and discuss the business as a whole.

Second, the root causes of many data quality problems became easier to see. When the entities, relationships, and responsible applications were mapped out, some of the issues that had previously looked like isolated operational problems turned out to have structural causes.

Third, the model helped clarify how ongoing and planned projects affected the overall data landscape. Development initiatives that had previously been viewed separately could now be seen in relation to the same information structures.

But perhaps the most noticeable change was in the discussion itself. Once the structures were visible, people started discussing data across organizational silos. The diagrams made dependencies visible in a way that had not been obvious before.

The conversation also shifted in tone. Instead of general concerns about “data challenges,” discussions increasingly focused on specific structures, entities, and relationships.

The topic attracted notable interest from leadership. That alone is often a sign that the discussion has moved beyond technical details. When the structures of information become visible, they tend to raise questions that are directly relevant to how the organization operates and develops.

Often the value of architecture work is not in inventing something completely new. It is in making the existing structure visible. And once that happens, the conversation tends to change.

📘 New Book: The Architecture of Expert Compensation

I have recently written a short book called The Senior Expert Pay Playbook.

It continues the same structural perspective as The Senior Expert Career Playbook, but focuses specifically on how compensation actually forms inside organizations—in a way, the architecture behind how expert compensation develops over time.

The book will be published in early April, but it is already available in my Gumroad store.

A launch discount is available with the code PAYSTRUCTURE22 (for The Senior Expert Pay Playbook) and EXPERTMODEL22 (for the bundle including both books).

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | The Senior Expert Career Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
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.

At the time, I was working in a university research project related to EA. A steady stream of material seemed to appear from all directions: research papers, consulting frameworks, government guidelines, and industry white papers. Especially in the United States, the public sector was producing large amounts of architecture-related material.

Around the same time, several frameworks and approaches gained wider attention. TOGAF was evolving into its modern form, and legislation such as the Clinger–Cohen Act had already pushed federal agencies to adopt architecture practices.

There was a fair amount of hype around the topic, as often happens when a new management idea gains momentum. But it also felt like EA was becoming a major new discipline for managing organizational complexity.

Twenty years later, the situation looks somewhat different. EA certainly still exists, and if anything, there are more frameworks, tools, and opinions about EA than ever before. But if you ask ten organizations what EA actually is, you may receive ten very different answers.

In some organizations, EA is a strategic function working closely with leadership. In others, it primarily plays a governance role, reviewing project designs and enforcing architectural principles. In many organizations, however, architecture ends up closer to everyday project work, with architects supporting development teams and helping resolve practical design issues. All of these interpretations—and more—exist in practice.

This variety is not necessarily a problem. Organizations are different, and architecture work naturally adapts to local needs. But the situation does raise a slightly uncomfortable question:

If EA means something different in almost every organization, what exactly is the discipline supposed to be—and how do you explain its purpose and value to leadership?

Different Faces of Enterprise Architecture

Part of the confusion is that EA is understood in many ways: as a set of architecture models, a process, an organizational function, a role, “everything in an organization”—or sometimes all of these at once. This also becomes visible in practice in how EA is used and where architects spend their time.

Over the years I have seen EA work take several different forms.

In some organizations, it is connected to strategy. Architects help translate strategic goals into concrete development directions. Capability maps, roadmaps, and high-level architecture views are used to guide long-term change.

In others, EA’s role is much more operational. Architects review project designs, participate in steering groups, and provide architectural guidance to development initiatives. They help projects navigate dependencies between applications, ensure that solutions follow agreed architectural principles, and sometimes contribute directly to solution planning.

Sometimes EA revolves around maintaining architecture descriptions. The focus is on building and updating models that describe the current state of processes, data, applications, and technology. These descriptions aim to create a shared understanding of the organization’s structure.

EA can also take a more formal governance role. Architects review solution designs, approve or challenge architectural decisions, and ensure that development follows agreed principles and standards. When this works well, it helps maintain coherence across projects. When it does not, architecture reviews may be perceived as little more than an additional bureaucratic step slowing down delivery.

And occasionally, the architecture role becomes something closer to internal consulting. Architects spend much of their time facilitating workshops, challenging assumptions, and helping teams think through complex problems.

In practice, much of the architecture work I have seen tends to fall into the operational end of the spectrum. Direct involvement in strategic decision-making appears somewhat less common, even though strategy is often mentioned as a central goal of EA.

None of these roles is inherently wrong. The problem arises when the expectations surrounding EA remain unclear.

When Expectations Are Misaligned

If stakeholders expect different things from EA, the work can quickly become confusing.

Leadership might expect strategic guidance. Project teams might expect practical design support. Architects themselves might believe their primary task is to maintain architecture models. Each of these expectations is reasonable on its own. But if they are not aligned, the architecture function may end up trying to do everything at once—and satisfying nobody particularly well.

This is one reason why EA sometimes struggles to demonstrate its value. The function is judged against multiple, partly conflicting expectations. Is EA supposed to guide strategy, support projects, maintain models, or all of the above?

In practice, this confusion is surprisingly common. EA often grows gradually rather than through a clearly defined mandate. New responsibilities are added over time, different stakeholders form their own assumptions, and eventually the architecture function finds itself operating without a shared understanding of what it is actually supposed to achieve.

Part of the explanation is simply how EA’s role evolves in practice. The work often ends up reflecting where architects are invited to participate and with whom they are able to collaborate. If architects are mostly involved in projects, the role naturally becomes project support. Strategic involvement, on the other hand, usually requires access to leadership discussions—something that does not automatically happen in every organization.

Without clarity on expectations and purpose, architecture work can easily drift. Architects may spend time on activities that feel useful but are not aligned with what the organization actually expects from them. Stakeholders may assume that the EA function is responsible for tasks it was never meant to handle.

Clarifying the Role of Enterprise Architecture

One useful starting point is simply to ask the stakeholders. Architecture leaders or external facilitators can interview key groups across the organization: executives, project managers, development teams, and other functions interacting with architecture.

Several simple questions often reveal a great deal. For example: What do you think EA means in this organization? What do you expect from it? And also: How do you actually interact with architects or architecture content today? Do people meet architects in projects, steering groups, or strategic discussions? Do they use architecture models at all? It is also useful to ask a more direct question: What do you feel you are currently getting from EA? The differences between these answers can be very revealing.

Once these expectations are visible, the organization can have a more explicit discussion about what EA should actually mean in that particular context. There is no universal answer. In some organizations, EA may primarily support strategy. In others, it may focus on guiding projects, maintaining shared current state views, or improving coordination between development initiatives.

What matters is that the organization defines it consciously—based on what EA is actually expected to do in practice, not only on what EA frameworks say it could provide in theory.

A clear identity does not mean that EA must only perform one role. In practice, EA often combines several responsibilities. But there should still be a shared understanding of its primary purpose: why the function exists, what problems it is expected to solve, and what kind of value it aims to deliver.

Once this purpose is reasonably clear, it becomes much easier to define the practical operating model that supports it—how architects work, where they participate in decision-making, what kind of architecture content is maintained, and how architecture interacts with projects and leadership.

Clarifying the identity of EA will not solve every challenge. But it provides something that many architecture initiatives initially lack: a shared understanding of what the discipline is actually trying to achieve in that organization.

A Simple Question

If EA in your organization disappeared tomorrow, what exactly would be missing?

Would leadership lose an important strategic perspective?
Would projects struggle without architectural guidance?
Or would the architecture repository simply stop being updated?

The answer says something important about what EA actually is in your organization, and whether its identity is clear enough for others to understand its value.

In a way, the question of EA’s identity has been present throughout the discipline’s history. My own recent book Enterprise Architecture: Your Guide to Organizational Transformation is one attempt to describe what EA could be when it works well in practice: how it connects strategy, development, and decision-making through a small set of shared architectural views.

Whether organizations adopt that kind of approach or something entirely different, one thing seems clear: without a reasonably shared understanding of what EA is supposed to achieve, it becomes very difficult for the function to demonstrate its value—or to design the operating model that allows it to deliver that value in practice.

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | The Senior Expert Career Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
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.

There is rarely a moment when leadership gathers in a meeting room and formally declares that the architecture function has not delivered what was promised (although I have occasionally seen that happen). No official memo circulates explaining that the organization will now move forward without EA work.

Instead, something much quieter happens. EA fades away gradually, through small changes and shifting priorities, until the function no longer plays a meaningful role in the organization’s development.

This slow disappearance is surprisingly common. If you talk to architects across different organizations, you will hear familiar stories. EA was once an ambitious initiative with clear goals and strong support. There were plans, models, governance structures, and discussions about long-term transformation.

Yet a few years later, the same organization may struggle to explain what the EA function actually does—or whether it still exists at all. The repository may still be there. The architects may still have their titles. But very few real decisions are influenced by architecture anymore.

The Enthusiastic Beginning

Most EA initiatives start with genuine enthusiasm. For example, the organization realizes that development has become fragmented. Applications overlap, projects move in different directions, and decision-makers lack a coherent view of how the organization actually operates. Strategic initiatives depend on dozens of interconnected applications and processes, but nobody has a clear picture of how they fit together.

At that moment, EA sounds like exactly the kind of capability the organization needs. Leadership hopes that architecture will bring structure to development and help decision-makers see the bigger picture. Architects are appointed, an operating model is designed, and architecture tools are selected. Workshops are organized to describe capabilities, processes, applications, and technology platforms. Diagrams begin to appear that finally make the organization’s complexity visible.

For a while, the energy around the initiative is high. The architecture team believes it is building something important. Stakeholders are curious about the new function. There is a sense that EA might finally bring order to the organization’s development efforts.

But this phase doesn’t last forever.

When Reality Appears

After a year or two, the excitement around EA usually settles into something more ordinary. The initial effort of launching the function has been completed. An operating model exists, the first architecture descriptions have been created, and architects have begun supporting projects and decision-making processes. At this point, the real nature of architecture work becomes visible.

EA is rarely a continuous stream of strategic breakthroughs. Much of the work is routine. Architecture descriptions need to be updated, meetings follow a regular agenda, and projects require architectural input as applications and processes gradually change.

In other words, architecture becomes part of everyday organizational work. In many ways this is exactly what success looks like. EA is no longer a special initiative but a normal part of how development is guided.

But this is also the phase where subtle problems can begin to emerge.

The Slow Erosion

Once EA has settled into everyday work, its long-term success is no longer determined by the initial launch. Instead, it depends on whether the function continues to stay relevant to the organization’s real needs.

This is where things often become complicated. EA rarely collapses because of one dramatic mistake or a single bad decision. More often, the problems appear gradually and from several directions at once.

Some of these challenges come from within the architecture work itself. Others emerge from the surrounding organization—changing priorities, project pressures, or simple loss of attention. None of them looks particularly serious in isolation, and many of them are perfectly understandable responses to everyday work situations.

Sometimes architects drift into discussing architecture mainly with other architects, while conversations with the people actually running projects and making decisions become less frequent. Architecture content may also easily become increasingly detailed and technically refined, but the topics being modeled are so specific that very few stakeholders find them useful.

It is also possible that very little modeling happens at all. Architecture work may consist mostly of meetings, advice, and occasional diagrams created for individual initiatives, without a coherent architectural view being maintained over time.

None of these situations necessarily looks alarming in the moment. But over time they can begin to pull architecture away from the decisions it was originally meant to support.

When several of these small shifts happen at the same time, the architecture function may slowly drift into a position where it still exists on paper, but plays a smaller and smaller role in guiding actual development.

When Interest Begins to Fade

What makes the situation particularly interesting is that this erosion rarely triggers any dramatic reaction. There is usually no meeting where leadership suddenly questions the value of EA. Instead, interest on it gradually fades.

Stakeholders who once attended architecture workshops with curiosity begin focusing on their own operational concerns. Projects move forward under tight schedules, and architecture involvement becomes less visible. Over time people simply stop expecting architecture to play a significant role in everyday decisions.

A similar shift may happen within the architecture team itself. As development pressure grows, architects are increasingly pulled into operational work. One architect becomes heavily involved in a project. Another ends up coordinating a complex initiative. Before long, architects may find themselves acting as solution designers, technical leads, or even project managers.

These assignments are usually useful for the organization. But they also mean that less time and attention is spent maintaining the shared architectural view.

No single event causes the change. Interest simply fades on multiple fronts at the same time.

When the Engine Quietly Stops

If this drift continues long enough, the change eventually becomes visible in everyday practice.

Architecture descriptions are updated less frequently. Governance meetings attract fewer participants. Projects move forward without actively seeking architectural input, not because they reject architecture but because it no longer seems necessary. In some cases architects simply move on to other roles or leave the organization, and the architecture function slowly loses the people who originally drove it forward.

The organization may still have some architects. The repository may still contain hundreds of diagrams. Architecture may even remain part of official governance documents. Yet the role of EA in guiding development has largely disappeared.

What makes this process remarkable is how quietly it happens. There is rarely a formal decision to stop EA work. The organization does not consciously abandon it. People simply stop relying on it.

And by the time someone reflects on the situation, EA has already faded into the background of the organization’s operations.

Why It Happens

The quiet death of EA usually has very ordinary causes. Sometimes architecture becomes too inward-focused, with the team spending most of its time refining models rather than supporting real decisions. In other cases the opposite problem occurs: architecture loses its structure and gradually turns into an informal advisory role with little tangible output or shared content.

Governance can also play a role. If architecture processes become too heavy, stakeholders may begin to see EA as bureaucracy rather than support. Conversely, if governance becomes too weak, architecture loses its ability to influence development and slowly fades into the background of project work.

Another common factor is simple neglect. EA work requires constant attention. Without ongoing effort, the architecture function gradually loses its relevance.

External factors can accelerate the process as well. Changes in leadership, organizational restructurings, or budget cuts can easily disrupt architecture work. A new executive team may have different priorities. A reorganization may shift responsibilities and dissolve established practices. In cost-saving situations, architecture functions are sometimes reduced simply because their benefits are not immediately visible compared to operational delivery work.

Keeping Enterprise Architecture Alive

The uncomfortable truth is that EA work does not sustain itself automatically. Launching an architecture function is only the beginning. After the initial setup, the real challenge begins: maintaining the function’s relevance over time.

EA must remain closely connected to real decisions and real development work. Architects need to support projects, participate in strategic discussions, and maintain a clear and usable view of the organization’s structure. The architecture content must stay understandable and up to date, and stakeholders must experience its value in their daily work.

Perhaps most importantly, the benefits of architecture must remain visible. Architecture rarely survives on promises alone. It survives when people across the organization can clearly see how it helps them make better decisions.

Keeping the function alive also requires persistence from those leading it. Most often EA work fades because nobody consistently pushes it forward. Maintaining architecture work means continuing to update the content, engaging stakeholders, communicating benefits, and defending the function’s role even when attention shifts elsewhere.

In practice, this often demands a fair amount of stubbornness from the people responsible for EA. The work requires someone who keeps the effort moving forward, even when the excitement of the early phase has passed and the work has become routine. Without that kind of persistence, architecture can slowly drift into the background—until it eventually disappears from everyday development altogether.

A Question Worth Asking

For anyone working in EA, there is one uncomfortable question worth considering.

If the architecture team stopped attending meetings for the next six months, what architectural understanding would remain in the organization?

Would the shared view of processes, applications, and dependencies still be available and used? Or would that understanding slowly disappear together with the architects themselves?

The answer reveals something important—not only about the quality of the architecture descriptions, but about whether EA in the organization is truly embedded in its way of working. Or quietly fading away.

Author News

In addition to writing about consulting, expert careers, and architecture, I also write fiction. My debut novel Pohjoisen tie (The Northern Road) was recently published in Finnish. It follows a daughter searching for answers after her father disappears during a glider flight.

If you happen to read Finnish and are curious, the book can be ordered also directly from the author.

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | The Senior Expert Career Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
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.

A comment on my previous article about ArchiMate’s motivation layer prompted me to write this piece. The question was simple, almost blunt: is the entire ArchiMate notation useless in practice?

Those who have read my earlier posts know that I have a certain appreciation for ArchiMate. I find it structurally elegant, even if it is not visually beautiful. Still, I try to approach this question as objectively as possible. Liking a notation is not the same as justifying its use.

It is also worth acknowledging that the alternative is rarely “nothing.” In practice, enterprise architecture (EA) artifacts are created in multiple ways. Some are drawn in PowerPoint for executive discussions. Some are created in generic diagramming tools like Visio or draw.io. Others live inside architecture tools that use proprietary or customized meta-models. All of these approaches can produce useful visuals in the right context.

PowerPoint, in particular, is not the enemy. It is often the right tool for communicating with leadership. It supports clarity, narrative flow, and visual simplification. The question is not whether we should use PowerPoint. We should.

The deeper question is what happens behind those slides. What notation underpins the structural thinking? How consistently are concepts defined across models? How transferable is the architectural knowledge over time?

The choice of modeling language quietly shapes how consistently architecture is understood, reused, and evolved.

Among available options, ArchiMate remains the only widely adopted, cross-layer standard that covers business, application, and technology concerns within a coherent meta-model at a level that genuinely supports EA work. It is not perfect, and it is not visually elegant, but it provides structural advantages that informal or tool-bound diagramming rarely achieves.

Shared Semantics Over Visual Convenience

One of the less visible advantages of a standard notation is shared semantics.

Creating architecture diagrams in presentation tools or in modeling platforms that use proprietary or customized meta-models is not inherently problematic. An internal notation can work perfectly well—sometimes even better than a standard—if it is consciously designed and consistently applied.

The difficulty arises when semantics are left implicit. When a box labeled “Customer Platform” appears in a slide deck, what does it represent? A capability? An application grouping? A product construct? A logical abstraction? If the answer depends on who created the diagram, the notation is carrying little meaning on its own. The same applies to relationships. An arrow may imply dependency, flow, ownership, or influence, but unless these meanings are explicitly defined and consistently used, interpretation remains situational.

In internally developed or tool-specific notations, those definitions must be consciously created and maintained. Someone needs to decide what element types exist, what relationships are allowed, and what each connection actually means. Without that effort, the notation gradually drifts into convention rather than structure.

A standard notation such as ArchiMate provides these distinctions by default. A capability is defined differently from an application component. A process is distinct from an organizational unit. Relationships have specified semantics. The language brings a built-in meta-model that reduces the need to invent and govern one locally.

Internal or tool-specific notations can achieve the same level of clarity—but only if their purpose and semantics are explicitly articulated. Are they optimized for communication? For repository consistency? For analytical traceability? For executive storytelling? Without that clarity, notation becomes decorative rather than structural.

Over time, explicit semantics reduce friction. Less effort is spent clarifying what something represents. Models become easier to extend, compare, and reuse. The notation supports thinking instead of relying entirely on explanation.

In that sense, the issue is not standard versus custom. It’s clarity versus convention.

Reducing Cognitive Overhead in Modeling

Another practical advantage of a standard notation appears in the modeling process itself.

When using generic drawing tools—or even sophisticated architecture platforms with extensive, customizable symbol libraries—a surprising amount of attention is spent on representational choices. Teams discuss shapes, colors, grouping conventions, line styles, and naming patterns. Over time, each project may drift toward its own visual dialect.

These decisions rarely feel strategic. Yet they accumulate. They consume cognitive capacity that could instead be directed toward clarifying structure, dependencies, and consequences.

A standard notation externalizes many of these choices. Instead of inventing symbols or navigating a broad visual palette, architects select from a defined conceptual vocabulary. The conversation shifts from “how should we draw this?” to “what is this, conceptually?” That shift may seem subtle, but it often improves precision.

Standardization in this sense is not about methodological compliance. It is about reducing modeling friction and freeing attention for structural reasoning.

A Shared Language for Architects

EA is rarely a solitary activity. Teams change. Consultants are engaged. New architects are hired. Over time, architecture work extends across projects, domains, and even organizational boundaries. In such contexts, a shared professional language becomes valuable.

ArchiMate benefits from an international ecosystem of training, literature, tooling, and certification. It is possible to recruit someone who already understands the notation, or to send internal staff to formal training. External partners can read and interpret models without extensive onboarding into a locally invented modeling convention. That shared baseline reduces ramp-up time and lowers the risk of misinterpretation within the architecture function.

This portability matters especially in larger organizations and multi-vendor environments. When architecture relies solely on an internally defined visual vocabulary, knowledge tends to remain tightly coupled to individuals. Standards help decouple architectural artifacts from specific people and make them more stable over time.

At the same time, it is important to be realistic: business stakeholders and executives rarely read ArchiMate models fluently. Nor should they be expected to. Formal notation is not automatically an executive communication tool.

However, architects do benefit from a shared conceptual language. Within the architecture community, precision matters. And over time, even business counterparts can learn to engage with certain views. I have seen layered diagrams developed collaboratively with business representatives work well when the abstraction level is appropriate and the focus remains on planning and decision support rather than notation purity.

In that sense, standard notation strengthens the professional backbone of the architecture function, even if the final conversation with leadership is translated into simpler visuals.

Diagrams Versus Repository Thinking

There is an even more fundamental distinction than standard versus custom notation. Are we creating isolated diagrams or are we building a repository?

A diagram is a snapshot. It exists to support a specific discussion at a specific moment. Once the meeting ends, the slide may be archived, forgotten, or partially outdated. Its elements are rarely reused in a structured way.

A repository, by contrast, treats architectural elements as persistent objects. A capability is defined once and referenced in multiple views. An application component exists independently of a single diagram. Relationships are maintained across contexts. Attributes can be queried. Relationships can be analyzed.

This distinction is independent of notation, but notation strongly influences whether repository thinking is practical.

You can draw ArchiMate elements in draw.io and still remain at the diagram level. Conversely, you can build a repository using a custom meta-model. The key question is whether architectural elements are treated as reusable, governed constructs rather than drawing artifacts.

Standard notations such as ArchiMate support repository thinking because they define a meta-model upfront. Tool support, exchange formats, and consistent semantics make it easier to maintain coherence over time.

Without repository discipline, architecture work tends to fragment. Each project produces its own diagrams. Definitions drift. Concepts multiply. Eventually, architectural knowledge becomes presentation-dependent rather than structurally anchored.

The value of standard notation becomes significantly clearer once architecture is treated as a long-term knowledge asset rather than a collection of slides.

Tooling and Architectural Longevity

There is also a technical dimension to consider.

ArchiMate is not just a visual language. It is an open standard, and many serious architecture tools support it natively. That matters. When a notation is standardized, tool vendors implement it consistently, exchange formats are defined, and models are not tied entirely to one proprietary interpretation. In practice, this reduces vendor dependency.

If your architecture repository is built around a proprietary meta-model that exists only inside a single tool, migrating away becomes structurally difficult. Even if export is technically possible, semantic fidelity is rarely guaranteed. Diagrams, element types, relationships, and attributes may not translate cleanly.

ArchiMate, by contrast, has a defined model exchange format. It is currently the only broadly adopted cross-layer notation in EA with a standardized way to transfer near-complete repository content between tools. That does not eliminate migration effort, but it reduces structural lock-in. Your architecture is anchored to a standard, not solely to a vendor.

This distinction becomes more important as architecture repositories mature. Once models accumulate over years—including relationships, attributes, viewpoints, and cross-domain connections—they become organizational memory. At that point, portability is not a theoretical concern. It’s strategic resilience.

There is also a forward-looking aspect. When architecture models are structured according to a well-defined meta-model, they become more than diagrams. They become structured data. That data can be queried, analyzed, and extended. Organizations can build custom reporting, dashboards, or even AI-based applications on top of their repository. For example, impact analysis, redundancy detection, capability coverage analysis, or risk pattern recognition can be automated more reliably when the underlying semantics are explicit and standardized.

This does not require ArchiMate specifically. A well-designed internal meta-model could also support such use cases. The key point is structure.

However, using an open standard lowers the threshold. Tool support is mature. Exchange formats exist. External expertise is available. The foundation is already defined.

Standard notation, in this sense, is not just about cleaner diagrams. It is about architectural longevity—ensuring that your models remain interpretable, portable, and extensible as your tooling, teams, and technologies evolve.

Expressiveness and the Need for Restraint

One of ArchiMate’s strengths is its expressive range. It can represent strategic motivation, capabilities, processes, applications, infrastructure, and the relationships between them within a unified language. This makes it possible to describe complex enterprise structures without inventing new symbols for each new situation.

However, this richness requires discipline. The language contains many element and relationship types, and using them all can easily produce models that are technically correct yet practically unreadable.

In most organizations, it is sensible to define a limited modeling profile: a consistent subset of elements and relationships that serve the organization’s actual decision needs. The goal is coherence, not exhaustiveness. A restrained, well-understood subset often delivers more value than a fully expressive but inconsistently applied model.

It doesn’t happen automatically. It requires conscious design of the meta-model in use, practical modeling guidelines, and training that goes beyond notation mechanics. Architects need shared conventions about abstraction levels, naming principles, and when to model—and when not to.

Without that discipline, the language’s expressive power turns into noise. With it, expressiveness becomes an asset rather than a burden.

Standard Notation and Executive Communication

A common objection is that formal notation does not resonate with leadership audiences. It is largely true. ArchiMate diagrams are rarely the optimal format for executive storytelling.

Yet this does not undermine the value of standard notation within the architecture function itself. Insights derived from structured models can be translated into simplified visuals for decision-makers. The internal rigor supports external clarity.

Importantly, structured notation allows complexity to exist in the background without overwhelming the conversation. The full set of relationships and attributes can remain modeled and analyzable within the repository, even if only a simplified view is presented in a steering meeting. The architecture retains its depth, while communication remains focused.

In other words, standard notation strengthens analytical work even if the final communication artifact is adapted for its audience. It allows complexity to be managed structurally, rather than suppressed or improvised.

So, Is It Worth It?

The ultimate advantage of using a standard notation is discipline. It forces architects to decide what something is, not just what it is called. It enforces distinctions between concepts that might otherwise blur together. It encourages explicit relationships instead of informal assumptions and visually convenient shortcuts.

That discipline shapes thinking. It reduces accidental ambiguity. It makes models more comparable over time. It creates continuity even as people, projects, and tools change.

Of course, standard notation comes with a cost. It requires learning. It requires agreement. It requires governance. Without restraint and guidance, it can also create unnecessary complexity.

The real question is not whether a standard is elegant. It is whether the structural clarity it introduces is worth the additional effort.

EA is, at its core, about creating shared structural understanding in complex environments. If that understanding needs to persist beyond a single workshop or presentation, then discipline matters. A standard notation does not guarantee good architecture, but it provides a stable foundation for it.

Over the long term, that stability is often more valuable than aesthetic flexibility or short-term convenience.

And that, in my experience, is where the trade-off becomes easier to justify.

A Practical Note on Modeling Subsets

If you are interested in how to define a pragmatic ArchiMate modeling subset in practice—including abstraction levels, element selection, and governance patterns—I explore this in more detail in my book Enterprise Architecture: Your Guide to Organizational Transformation.

The goal there is not methodological completeness, but sustainable modeling discipline in real organizations.

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | The Senior Expert Career Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
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.

It includes elements such as stakeholder, driver, assessment, goal, outcome, principle, requirement, and constraint. The intent is clear: to capture why change happens and to connect external pressures and strategic intent to architectural decisions. In theory, it provides traceability from high-level drivers all the way down to implementation.

I have seen motivation models with dozens of elements and full cross-layer traceability. Strategy slides are taken from an executive presentation and decomposed into drivers and goals. Sometimes, those goals are further refined into requirements. Goals or requirements are linked to work packages. Work packages are connected to capabilities or applications. The modeling tool happily visualizes the entire chain.

The result looks impressive. You can click a strategic goal such as “accelerate digital growth” and immediately see which programs and projects supposedly support it. The diagram shows clean lines from ambition to execution. It feels structured and aligned.

And internally, it often feels satisfying. Architects can demonstrate that everything is connected.

Conceptually, it makes perfect sense. Enterprise architecture (EA) should help translate strategy into structure. Used well, the motivation layer can clarify assumptions, expose inconsistencies, and make hidden trade-offs visible.

But the real question is not whether the motivation layer makes sense in theory. It is how it is actually used—and whether those elegant traceability chains genuinely provide any benefit.

How the Motivation Layer Is Often Used in Practice

In practice, I have seen the same pattern repeat surprisingly often. The motivation layer becomes an internal architecture exercise.

Architects gather in workshops—or sometimes simply work through the material themselves—and start “breaking down” strategy into drivers, goals, assessments, and requirements. A high-level slide from the executive team is translated into structured elements. Vague statements such as “accelerate digital growth” or “improve customer centricity” are decomposed into more detailed architectural constructs. The model begins to grow layer by layer.

Soon, the original three bullet points from the strategy deck have turned into a network of drivers, goals, outcomes, principles, and requirements. Each abstraction is carefully named. Dependencies are defined. Everything appears logically connected.

From inside the architecture function, it feels productive. Ambiguity is reduced. Structure emerges from fuzziness. Strategy becomes something you can point to and navigate.

The question is whether the same clarity exists outside the room. In many cases, leadership is not involved in shaping these models. The strategic statements are interpreted rather than jointly refined. Trade-offs are assumed rather than explicitly debated. In practice, the motivation model reflects what architects believe the strategy means—not necessarily how executives would actually prioritize.

The result can be a parallel strategy model: internally coherent, logically structured, but only loosely connected to real decision-making. The issue is positioning, not the notation.

The Temptation of Mechanical Traceability

There is another pattern that often follows. Architects begin linking motivation elements systematically to other layers of the model. Goals are connected to requirements, which are connected to work packages, which are connected further to capabilities, applications, or sometimes even technical components. If the modeling tool supports full traceability across layers, the result can look impressive: a clean chain from a strategic goal all the way down to a specific implementation artifact.

From a modeling perspective, it feels rigorous and complete. From a decision-making perspective, it is often superficial.

Strategic goals are typically abstract by design. Statements such as “improve customer experience,” “increase operational efficiency,” “enable digital growth,” or “strengthen resilience” are intentionally broad. They provide direction, not operational detail. They are meant to guide thinking across contexts, not define concrete implementation logic.

When dozens of work packages or other architectural elements are directly attached to such abstract goals—or to architect-invented sub-goals derived from them—the traceability becomes formal rather than meaningful. The diagram shows alignment. Everything appears connected. But has understanding improved? Often, the answer is no.

This mirrors a broader challenge in project governance. In many organizations, every initiative must declare which strategic objective it supports. Predictably, most projects end up referencing the same few high-level goals. On paper, everything aligns with strategy. In practice, very little differentiation or prioritization becomes clearer. Similarly, if every architectural element is traceable to a strategic goal, the traceability no longer clarifies trade-offs or choices. It merely confirms that someone has drawn a line.

True architectural value emerges when models expose tension, constraint, and consequence—not when they demonstrate universal alignment.

When the Motivation Layer Creates Real Value

The motivation layer becomes valuable when it is used as a facilitation tool, not as a documentation artifact.

Its real strength emerges when leadership actively participates in interpreting what the strategy actually means in practice. Strategic statements are almost always abstract and politically balanced. They leave room for interpretation by design. The important work is not decomposing them mechanically, but clarifying their practical implications: What does this priority mean for trade-offs? What do we deliberately choose not to optimize? Which driver dominates when objectives conflict?

When executives engage in articulating drivers, debating goals, and validating trade-offs, the model becomes a structured thinking space. It makes implicit assumptions explicit. It forces uncomfortable questions into the open. It clarifies which objectives truly dominate when constraints collide. In that context, the motivation layer helps translate strategy into shared understanding.

The difference lies in who is in the room.

Even then, it is rarely necessary to model the entire chain from high-level drivers down to other architecture elements. In many cases, the most useful bridge between strategy and architecture is capabilities. Capability-based design allows you to connect strategic intent to structural change without forcing artificial traceability to every project or application component. Capabilities provide a more stable and meaningful abstraction layer for discussion. The relative importance of capabilities can often be captured in simple attributes—investment focus, target maturity, time horizon—or even in workshop materials. Not everything needs to be pulled into the EA repository to be structurally useful.

Similarly, influence diagrams can sometimes serve the conversation better than detailed motivation models. By mapping cause-and-effect relationships and feedback loops, they help leadership understand dynamics rather than classifications. They reveal leverage points instead of just documenting alignment.

The goal is to clarify decisions. Often that requires fewer elements, but better conversations.

Ask This Before You Model

Before investing significant effort in building a detailed motivation model, it is worth pausing and asking a few uncomfortable questions:

• Who will actively use this model?

• Will it shape a real decision—or simply document assumptions someone has already made?

• Is leadership genuinely engaged in defining and validating these elements?

In any case, not everything needs to be modeled into EA. The goal is not to pull every strategic statement into the EA repository, but to clarify the structural consequences that actually matter. Architecture is not a storage system for strategy; it is a thinking tool for decisions.

Modeling is not valuable because it is complete. It is valuable when it improves understanding where it actually affects outcomes.

The motivation layer is not useless. In the right context, it can structure strategic dialogue and expose hidden assumptions. But without the right conversation, it risks becoming a beautifully structured explanation of assumptions that were never truly debated.

And in EA, the difference between documentation and influence is not methodological. It determines whether the function is taken seriously.

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | The Senior Expert Career Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
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.

But does that seniority actually show up in career progression? Or is an enterprise architect senior mainly in responsibility and workload—not in structure?

If you stay in the role long enough, you start noticing a pattern. You are pulled into projects that need “just a bit” of architectural input. Operational teams ask for clarification. Vendor discussions require your presence. Escalations land on your desk because you understand the bigger picture. Over time, you find yourself firefighting more than architecting. People rely on you because you get things done and because you rarely make things worse.

You are constantly working—often on tasks that genuinely matter. Projects move forward because you stepped in. Risks are reduced because you noticed something early. Conflicts calm down because you translated between sides. It feels productive. You may even feel indispensable.

But less and less of your time sits at the core of EA. Instead of shaping long-term structure, you are stabilizing the present. Instead of defining direction, you are absorbing complexity so others can continue.

At the same time, your career does not necessarily move forward in proportion to that weight. Titles remain the same. Compensation improves slowly, if at all. From the outside, everything looks stable. From the inside, progress can feel oddly horizontal.

This is rarely about competence or effort. It is usually structural.

Enterprise Architecture Is an Expert Role in a Managerial System

There are enterprise architects who run boutique consultancies. There are chief architects, EA practice leads, and managers with architecture backgrounds. Those roles exist, and for some people, they are a natural next step.

But most enterprise architects are experts first. Their value lies in judgment, synthesis, and structural thinking. They connect strategy to operations and technology. They make complexity understandable. They influence decisions without necessarily owning budgets or headcount. That is expert logic.

Most organizations, however, are built around managerial logic. Career progression is easier to define when it is tied to teams, budgets, and formal authority. Growth is visible when something scales in size. Performance is legible when it can be summarized in simple numbers.

EA does not scale that way. Its value accumulates slowly. It often shows up as avoided mistakes, cleaner roadmaps, fewer overlaps, and more coherent decisions. That kind of impact is real—but harder to measure and explain upward.

Dual career ladders exist in many organizations. On paper, senior expert paths are supported. In practice, they are often thin, vaguely defined, and dependent on informal sponsorship.

You are expected to be valuable. But the system is just much less clear about how that value translates into progression.

The Reliable Architect Becomes the Default Solution

There is a specific trap that catches many experienced architects. If you are reliable, calm under pressure, and know a bit about everything, you become the safest person in the room. You are asked to step into project issues, help with operational planning, review vendor contracts, translate between business and IT, smooth conflicts, and “quickly take a look” at something outside your formal scope.

Individually, these requests make sense. Collectively, they reshape your role. Gradually, less and less of your time is spent on long-term EA. More and more is spent on project work, operational firefighting, and coordination. You are busy. You are useful. You are exhausted.

I have seen very capable architects drift into this state over years. Not because they lacked boundaries, but because being dependable felt like professionalism. Their days fill with meetings, steering groups, and escalations. They are present everywhere, but rarely have time to think deeply. They draw fewer diagrams. In the best case, consultants produce the required materials and they have time to steer the work.

From the outside, it looks like influence. From the inside, it can feel like slow drift away from the core of EA. You are indispensable, but not clearly advancing. You are critical, but not necessarily progressing.

The Value Problem in Enterprise Architecture

EA has another structural challenge: its value is difficult to make concrete.

If leadership does not clearly perceive value from EA, the entire function becomes vulnerable. I have seen organizations significantly shrink their EA teams—even consider removing them almost entirely—simply because executives felt they were not “getting enough out of it.”

This is not always a fair assessment. But it reflects a real risk. The hard benefits of EA are structural and long-term: better alignment, fewer redundant applications, more coherent transformation roadmaps, avoided risks. These do not always create immediate, visible wins. They prevent future losses.

If that value is not translated into language decision-makers recognize, it becomes abstract. If it becomes abstract, it becomes optional. And optional functions are easy to question.

For individual architects, this creates two connected problems.

First, visibility. If the organization struggles to articulate what EA delivers, it also struggles to justify senior roles, promotions, and meaningful compensation growth.

Second, career progression. When value is diffuse and indirect, advancement depends heavily on timing, sponsorship, and organizational politics rather than clear criteria.

Compensation often becomes a lagging indicator. It does not collapse. It simply stops keeping pace with responsibility and complexity. The gap widens quietly.

It is rarely about negotiation skill. It is about whether your value is legible inside the system that determines rewards.

The Career Path Question: Where Do You Actually Advance?

At some point, the structural challenge becomes very concrete. Where does the role actually lead?

Internally, the formal steps are often limited: architect, senior architect, perhaps principal or chief architect, if the organization is large enough. There, the path usually splits. Either you move into management—owning people and budgets—or you remain an expert with increasing informal influence but limited hierarchical movement.

Expert ladders in EA are typically shallow. Organizations do not need ten layers of enterprise architects. A chief architect role only opens when structure changes or someone leaves. Until then, you may already be operating at that higher level in practice without formal recognition. This creates a ceiling that appears earlier than many expect.

Consulting firms often provide a clearer ladder: consultant, senior consultant, director, partner. Revenue and client impact create tangible signals. The progression logic is not always comfortable—it may involve sales responsibility and commercial pressure—but it is visible.

Internal architects face a different reality. The organization may not grow the EA function—and often it shouldn’t. If EA is scoped sensibly, there is only a limited amount of real EA work to be done. It does not scale endlessly.

That means vertical space is naturally limited. You cannot keep adding layers of enterprise architects in the same way you add managers or project roles. Advancement therefore becomes dependent on rare structural openings rather than steady expansion.

Why Working Harder Rarely Fixes It

When architects sense stagnation, the instinct is predictable: work harder. Be more available. Take on more responsibility.

It feels logical. If progress slows, increase output. But in most cases, effort is not the constraint.

Most senior architects already operate near capacity. Adding more work usually just increases load, not leverage. Without boundaries, reliable architects absorb more operational noise and become the organization’s shock absorbers. Important, yes—but not necessarily advancing.

Without conscious positioning, structural impact remains invisible. Stability improves, but few connect it clearly to architectural work. Without deliberate career thinking, progression depends on reorganizations and rare openings rather than competence.

More effort creates motion. It does not automatically create direction.

At some point, the real question shifts from “How do I do more?” to “What exactly is this work building for my long-term role?”

Practical Moves That Actually Matter

For years, I relied on effort and availability. I said yes. I stepped in. I handled things. It worked—until it plateaued.

At some point, I realized that working harder was not changing my trajectory. It was only increasing load. The shift came when I started treating my career like an architecture problem.

• What am I actually optimizing for?

• Which responsibilities compound my long-term value?

• Which ones simply consume energy?

• Where is the real leverage?

That change in perspective made things clearer. Not easier, but clearer.

There is no universal template for designing an expert career. Context matters. Organizations differ. But a few structural principles consistently make a difference:

• Protect time for actual EA work. If you are permanently in project and operational mode, your role will drift—no matter how capable you are.

• Collect evidence of positive EA impact—and communicate it upward. If you don’t connect architectural work to visible outcomes, it will quietly blend into the background. Over time, perception determines funding, roles, and compensation.

• Clarify your direction: expert depth or managerial scope. Ambiguity here creates long-term frustration.

• Avoid becoming the default firefighter for everything. Reliability without boundaries leads to exhaustion, not progression.

• Understand the structural limits of your current context. If the ladder is shallow, decide consciously whether to stay, reshape the role, or move.

These are not productivity hacks but structural adjustments. And structural problems require structural responses.

Designing Expert Growth

Enterprise architects are trained to see systems, dependencies, and structural constraints. Ironically, many of us leave our own careers to emerge from whatever structure happens to exist around us.

Architect careers stall not because architects lack ability, but because expert growth rarely has a built-in path.

I have explored this pattern more systematically in my recent book The Senior Expert Career Playbook, which examines how senior experts—including enterprise architects—can build visibility, influence, sustainability, and fair compensation without becoming managers. The underlying structural challenges are surprisingly consistent across domains.

You cannot redesign your organization’s career system, but you can stop leaving your progression to chance and start designing how your expertise actually grows within it.

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | The Senior Expert Career Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
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.

In enterprise architecture (EA), the intent is always to work from source information and to apply architectural judgment. What I am discussing here is something else: content that is produced without an architect’s active involvement. Automatically. Via integrations, mining tools, AI assistants, or the famous “one-click EA.”

This idea is heavily marketed today. Well-known EA tool vendors talk about it, smaller and newer players talk about it even more loudly, and the promise keeps getting broader. I also touched on the topic in the final chapter of my book, because it keeps coming up in real projects and tool selections.

The appeal is obvious. Architecture that updates itself. A current state that is always up to date. No workshops, no interviews, no digging through old PowerPoint decks and SharePoint folders.

And, perhaps most importantly, the promise of finally getting rid of routine work. The idea that architects could stop maintaining inventories and diagrams and instead focus on more “strategic” work. That is a familiar message. Almost every major technology shift of the past decades has been sold with the same promise: automate the boring parts, free people to think at a higher level.

The real question is not whether it sounds attractive. The question is how realistic it actually is today—and at what level.

To keep this grounded, I will structure the discussion into three categories: what is easy, what is possible under certain conditions, and what is either unrealistic or simply not worth doing.

What Is Relatively Easy: IT Current State (If the Sources Exist)

Automatically generated EA content works best when you stay firmly on the IT current-state side.

Application portfolios are the classic example. If an organization already has reasonably structured sources—CMDBs, ITSM tools, or asset inventories—then producing an application list or a basic application map is fairly straightforward. In many cases, the information already exists; EA tooling mainly aggregates and visualizes it.

Workload-wise, that the real value here is not the list of applications itself, but their attributes. Ownership, lifecycle state, criticality, vendor, technology stack, data sensitivity, cost signals. These are the things architects actually use when supporting decisions. Automated approaches work reasonably well as long as these attributes are present, consistently defined, and kept up to date in the source systems. That is a big “as long as,” but when it holds, automation genuinely helps.

Even in this “easy” category, problems show up quickly. Coverage is rarely complete. Definitions differ between systems. One source describes applications at a logical level, another at a technical deployment level, and a third mixes the two freely. Depending on the source, entire classes of applications are often missing—especially externally used systems, SaaS tools adopted outside IT, and applications sitting at the far ends of integrations. Ironically, these are often the systems that matter most from a risk and dependency perspective.

The resulting architecture picture can look coherent at first glance, but small inconsistencies accumulate fast. Over time, the model becomes less a representation of reality and more a reflection of whatever data happened to be easiest to integrate. At that point, keeping the model useful usually requires manual work: normalizing definitions, filling gaps, reconciling conflicting sources, and making conscious decisions about what belongs at the EA level and what does not.

Still, as long as expectations are modest, this is where automated EA content delivers the most value with the least friction. As a continuously updated baseline for IT current state, it can work well—not as a fully self-sustaining architecture, but as something that stays usable precisely because someone takes responsibility for its interpretation and upkeep.

What Is Possible, With Conditions: Processes, Data Flows, Information, and Technology

Once you move beyond relatively static IT inventories, things become more fragile.

Processes and Process Mining

Automatically identifying processes is usually more limited than tooling demos suggest. Process mining relies on event data, which means it only covers processes that are both sufficiently digitized and instrumented. In practice, data sources rarely cover all relevant processes, and almost never the full end-to-end picture. As a result, an architect still needs to identify the relevant processes, understand their dependencies, and decide which parts of the organization and value chain actually matter from an EA perspective.

With well-defined, repeatable processes and good event data, process mining can nevertheless produce genuinely useful insights. You can see real execution paths, variations, bottlenecks, and deviations from the “official” process descriptions.

At an EA level, this supports qualitative assessment rather than precise modeling. Process mining can provide indicators such as throughput times, error rates, and rework frequencies, which can be aggregated and visualized at the EA level—for example as heatmaps. This kind of information can be very valuable when deciding where deeper analysis or change is needed.

The trade-off is abstraction. Process mining tends to operate at a more detailed level than EA normally does. You are no longer describing structure so much as behavior. That does not make it useless, but it does mean that process mining complements EA rather than replaces process maps and other architectural views.

Data Flows and Integrations

There are tools that claim they can automatically discover integrations and data flows. Technically, they often can. APIs, message brokers, configurations, logs, and integration platforms all provide material that can be analyzed and correlated.

The challenge is not detection, but meaning. A technical connection between application A and application B does not yet tell you what information actually matters, why it is exchanged, or how critical it is to the business. Automated discovery tends to produce diagrams that are technically accurate but architecturally blunt. Everything looks equally important, equally complex, and equally connected. In addition, the discovered integrations do not necessarily map cleanly to the logical applications that EA typically deals with. Technical endpoints, middleware components, and shared services often sit in between, obscuring the high-level architectural intent.

Even integration platforms are not a complete answer. They rarely cover all integrations, and they usually reflect how things were implemented, not how they should be understood at the EA level. Point-to-point integrations often fall outside their scope, even though these are precisely the integrations that tend to be most interesting from an EA perspective.

At this point, automated EA starts to resemble IT asset mining rather than EA. It gives the architect raw material to work with, not a ready-made architectural model that supports decision-making. Without interpretation, you get noise faster than insight.

Information Architecture

Information architecture highlights the same pattern as integrations and processes. Technical metadata, schemas, and data flows can be discovered automatically, and they provide useful raw material. At that level, automation can be genuinely helpful.

At the EA level, however, information architecture is not about tables and fields. It is about meaning, ownership, and usage across processes, capabilities, and applications. Defining what the organization’s core information actually is—and how it should be understood consistently—requires abstraction and shared interpretation. That cannot be inferred reliably from technical sources alone, no matter how complete they appear.

Technology and Infrastructure

A similar logic applies to technology and infrastructure views, but the abstraction challenge is even more explicit. Servers, platforms, cloud services, containers, and environments are already machine-readable by nature, and from a purely technical standpoint, discovering and updating them is not particularly controversial. Most of the work is about reuse and consolidation of existing data sources.

From an EA perspective, the key question is not visibility but level. EA should usually operate at a logical level, not at the level of individual virtual machines, Kubernetes pods, or cloud accounts. The architectural value comes from abstraction: platforms, environments, and major technology choices—not their every instantiation.

This is where linking becomes essential. Automated tooling needs to respect the boundary between EA-level structures and operational detail. Without conscious abstraction, technology views either become unreadable very quickly or drift into operational documentation that belongs elsewhere. In practice, the only workable approach is to keep EA content logical and high-level, while linking it explicitly to more detailed technical inventories and management tools when deeper inspection is needed.

What Usually Does Not Make Sense: Business Architecture, Target States, and Dependencies

The higher the level of abstraction, the less convincing automated content becomes.

Business architecture—such as capability models—and especially target states are not discovered from data. They are defined through choices. They reflect intent, priorities, and trade-offs, not historical traces left behind in applications or documents.

There is growing interest in using AI solutions to extract business concepts from documents, meeting notes, or strategy decks. As a drafting aid, this can be helpful. As a source of inspiration, even more so. But treating such output as EA content is risky.

Capabilities are not just frequently mentioned nouns. They represent shared agreement about what the organization must be able to do, at what level, and why. That agreement cannot be inferred reliably from transcripts or loosely related documents. It emerges through discussion, negotiation, and conscious decision-making.

Target architectures are even more problematic. They are normative by nature. They describe what should exist, not what already exists. No amount of system telemetry will tell you where the organization wants to go next year, what it is willing to invest in, or which compromises it is prepared to accept. And meeting notes do not fundamentally change this. They may capture intentions, open questions, and provisional agreements, and they can be useful as supporting material. But they usually reflect conversations in motion, not settled architecture-level decisions. Extracting target architectures from meeting notes risks mistaking discussion for commitment and ambiguity for direction. At best, such material can inform architectural thinking; it cannot define a target state on its own.

Finally, what automation does not reliably produce are the connections between architectural perspectives. Linking applications to processes, processes to capabilities, and processes to information requires interpretation and choice. These relationships are not hidden in any single data source. Defining which connections matter—and which do not—remains an architectural responsibility.

It is also worth pointing out that current state is rarely the hardest part of EA work—except, perhaps, for integrations. In practice, setting up and configuring automated data collection, integrations, and tooling often takes more time and money than producing the initial current-state descriptions manually. The real effort usually lies elsewhere: in abstraction, interpretation, prioritization, and change planning. Reality does not present itself in an architecturally meaningful form. Someone still has to do that work.

So What Is Automation Actually Good For?

Automatically generated EA content is not a scam, but it is not a shortcut out of architecture work either. Used well, it removes some mechanical effort and gives architects more time to think. Used poorly, it produces polished diagrams that look authoritative and say very little.

Automation does not remove the need for EA; it shifts where the effort goes. The hard part was never the diagrams themselves, but deciding what matters and at what level—and that remains a human responsibility. Many architects are highly technical and enjoy building and tuning tools, which is fine. But automation is only useful when it serves architectural purpose, not when it becomes an end in itself.

If you want a short, practical takeaway:

• Use available source data wherever it makes sense, including automated and integrated sources. Application attributes are often the easiest and most useful starting point—if there is a reasonably high-quality source behind them.

• Treat discovery tools and AI assistants as support, not as replacements for architectural judgment. They can surface patterns, gaps, and candidates for discussion, but they do not decide what matters.

• Respect the abstraction level of EA. Do not try to model reality at full detail. EA is about selecting, grouping, and simplifying—not about mirroring operational complexity.

If automation truly frees architects to focus on more strategic work, that work still has to be done. EA does not disappear when tools get better—it simply becomes more visible where judgment is missing.

✍️ Author News

My debut novel, Pohjoisen tie (The Northern Road), will be published in Finnish in March 2026 by Momentum Kirjat.

The novel is a psychological and adventurous story about loss, family secrets, and the search for answers. It follows a young woman traveling through the far North—both geographically and mentally—after receiving an unexpected lead about her father’s disappearance years earlier.

The book can be preordered without commitment, directly from the author. Preordering ensures early delivery at a reduced price, with an optional signed copy.

More details closer to publication.

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | The Senior Expert Career Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
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.