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.

So, before going any further, a quick thank you is in order: to those who commented thoughtfully, to long-time readers, and to everyone new who decided to subscribe along the way.

More importantly, it sparked discussion. And whenever a piece actually does that, a familiar pattern tends to repeat itself. Almost without exception, there is someone who steps in and demands either hard ROI numbers or declares that EA “does not work”—quickly and loudly.

What makes this interesting is not the question itself. Asking for return on investment is perfectly reasonable. What is more revealing is that the demand is often presented in one of the two forms: either ROI is demanded as a number detached from any value creation mechanism, or it is conveniently bundled with a software tool that claims to produce it automatically. In both cases, ROI becomes a rhetorical endpoint or a marketing pitch—not the start of a serious conversation about value creation.

I ran into exactly this reaction after my previous post. Most of the comments were thoughtful and engaged with the topic in different ways. One commenter, however, stood out. I have encountered it before, but rarely in such a confrontational form. Much of what they contributed added little to the substance of the discussion. Once the rhetoric was stripped away, the only coherent point that remained was a familiar one: a demand for ROI.

That response is not unusual. And that is precisely why this article exists.

The problem is not ROI, but skipping straight to it while bypassing the layer where EA value actually begins to form. Without immediate, direct benefits in place, any ROI discussion is simply disconnected from reality. EA sits alongside other management support functions—such as strategic planning, portfolio management, and risk management—that rarely produce isolated ROI, but consistently shape better decisions over time.

How Do Direct Benefits Actually Form?

Direct benefits are the ones that appear immediately, in real situations, when architecture is actually used.

They form in everyday work: projects starting, decisions being prepared, discussions getting stuck. In those moments, architecture either helps people think more clearly together—or not. There is no hidden pipeline where value magically accumulates.

The three mechanisms below are tightly connected, but distinct. Together, they explain why some EA efforts produce immediate value while others remain inert.

Clarity Is the First Real Outcome

Before anything else happens, architecture work either clarifies things or it fails. There is no neutral outcome. If describing an organization, an ecosystem, or a change effort results in more confusion, no downstream benefits should be expected later.

Clarity emerges when a structure is made explicit. A picture, a map, or a simple model forces fuzzy ideas into a shared form. It does not need to be exhaustive or elegant. What matters is that it introduces a visible structure of something: an application landscape, a capability set, a process, a dependency chain. Once that structure exists, people are no longer relying solely on their own internal interpretations.

This is also where thinking itself starts to change. When you try to explain a structure by pointing at it, gaps become obvious. Contradictions surface. Assumptions that felt solid suddenly look shaky. That friction is not a side effect—it is the mechanism through which clearer thinking is produced.

Simple example:

A digitalization project is about to start. The project manager, a couple of business leaders, and IT representatives are in the room. Someone asks a seemingly simple question: what exactly are we changing?

Everyone has an answer—but they are not the same answer.

Instead of debating the answers in the abstract, the group starts by working together on a first approximation of the scope. A single architecture view provides a shared starting point. It is assembled from elements that already exist in EA: the relevant processes, the applications that support them, the key data involved, and the most important integrations.

This is not about getting it right on the first attempt. It is about making an initial version of the scope visible. What is included, what is not, and where the boundaries roughly sit can now be discussed explicitly. Instead of starting from a blank slide, the conversation anchors itself to a shared structure that has already been named and thought through.

This is usually the moment when assumptions surface. Someone realizes that a system they considered “central” is actually peripheral. Another notices a dependency they were not aware of. The structure does not provide answers, but it gives the discussion a shape and a direction.

Knowing What We Are Actually Talking About

One of the most underestimated benefits of shared visuals is how effectively they reduce misunderstanding.

Without a common reference, conversations depend on language alone. And language is ambiguous by nature. “That application,” “customer data,” or “the core process” can mean completely different things to different people, even when everyone believes they are aligned. Misunderstandings stay hidden until decisions start producing unexpected results.

Simple example:

An organization wants to develop a specific business line. The intention is clear enough, but once the discussion starts, it becomes obvious that people mean different things by it.

For one person, development means improving customer service processes. For another, it is mainly about sales support. Someone else sees it as a data and reporting problem. IT focuses on the aging CRM system. The discussion keeps circling, not because people disagree, but because they are not talking about the same thing.

At this point, a capability map often helps more than further debate. By laying out the relevant business capabilities and naming them explicitly, the group can start by identifying which capabilities are actually in scope, and which are not.

Instead of arguing about solutions, the discussion shifts to structure. Are we talking about customer relationship management, billing, onboarding, or after-sales support? Once the capabilities are visible and named, it becomes easier to say: this is what we are focusing on now.

Disagreements do not disappear, but they become concrete. The group may still argue about priorities, but at least they are arguing about the same capabilities. At that point, architecture has already delivered a direct benefit: people know what they are actually trying to develop, and what they are not.

Dependencies and Impacts Become Visible

This is the point where architecture moves from shared understanding to decision support.

When they are visible, dependencies stop being an abstract idea and become something concrete. It becomes much easier to see what depends on what. Changes are no longer isolated decisions. A small adjustment in one place suddenly has a visible ripple effect elsewhere—across applications, processes, teams, or timelines.

Simple example:

A project is scoped as “just a small change” to one application. Once the architecture view is on the table, it becomes obvious that the application is tightly coupled to two others, relies on shared master data, and exposes interfaces used by external partners.

This is where many of the “surprises” in projects actually come from. Not from technical complexity, but from hidden dependencies that no one had articulated before.

Once dependencies are explicit, impacts can be discussed more honestly. What really changes if we choose option A over option B? What breaks if we delay this? What risks are we implicitly accepting?

Architecture does not answer these questions for you. But it makes it much harder to ignore them.

Why Direct Benefits Don’t Appear on Their Own

This is the point where many organizations get disappointed. Direct benefits do not appear simply because architecture descriptions exist. They do not emerge automatically from an architect’s advice. They certainly do not come from buying a tool. And they do not follow just from the fact that an organization has an “EA practice” or a formally named architecture function. All of these may be necessary conditions—but none of them are sufficient.

Benefits only start to appear when architecture content is actively used in real conversations, real planning, and real decision situations. When people engage with the structures, challenge them, refine them, and use them as a shared reference. Without that, architecture content remains inert, no matter how correct or complete it is. This is why it is more useful to talk about benefit mechanisms than benefits themselves.

In practice, a few very concrete conditions need to be in place.

Relevant architecture content has to be available and reasonably up to date. If people cannot find it, or if they do not trust it, it will not be used—regardless of how well it was originally produced.

Relevance also depends on the situation. Sometimes what is needed is a clear view of the current state. In other cases, a rough but shared picture of the target state is far more useful. In both cases, the content has to be understandable to its intended users. If a model only makes sense to the person who created it, it will not clarify anything for others. Architecture that requires constant translation fails at its primary task.

The structure must also be relevant to a real question or problem. Generic completeness rarely helps. Purpose does. Architecture works best when it is pulled into a discussion because someone needs it, not pushed in because it exists.

In addition, architecture models need to tell something that was not already visible in one place. The value often comes from bringing previously separate pieces together into a single, coherent structure. That synthesis—making relationships, overlaps, or gaps explicit—is often more important than any individual detail.

Finally, there must be a situation where people are forced to look at the structure together. Planning, prioritization, scoping, and risk discussions are typical examples. Clarity does not emerge in isolation. It emerges in interaction.

This is also why direct benefits rarely come from diagrams alone. Architecture descriptions do not use themselves. In practice, it usually requires the architect to step in: to bring the right people together, select the relevant views, and help interpret them in the context of the situation at hand. Sometimes this means jointly producing an initial description. Other times it is simply walking through existing views and testing whether they still hold.

In both cases, the value comes from shared use, not from the artifact itself. When business and IT experts work through the structures together, the architect helps keep the discussion grounded: what is actually in scope, what is not, where assumptions are being made—and what is being decided. Just as importantly, those decisions get captured in a form that can be revisited later.

This does not require a formal workshop. It can be a project kickoff, a steering group discussion, or a short working session. What matters is that someone actively enables the use of the descriptions and provides interpretation when needed.

When these conditions are met, conversations change. General statements give way to more concrete questions: what depends on what, what actually changes, and which decisions can no longer be postponed.

So Where Do the Real Benefits Come From?

The longer-term benefits people usually ask for do exist. Better decisions. Fewer surprises. Projects that start faster because basic dependencies are already understood. In some cases, even new business opportunities. Over time, these effects accumulate and begin to show up on the bottom line. For example, as cost savings in the IT portfolio, through fewer overlapping solutions, less rework, and a more coherent set of technologies to maintain.

But none of that happens without the immediate benefits first.

Before any cost reduction, productivity gain, or innovation can be credibly attributed to EA, something much more basic has to work. People have to think more clearly together. They have to share an understanding of what they are discussing. Misunderstandings have to decrease. Conversations have to become sharper and more concrete.

These are the direct benefits. They appear early, in meetings, planning sessions, and decision situations. They are not glamorous, and they rarely come with a price tag attached. But they are still the foundation for everything that follows.

Only once these direct benefits are consistently present does it make sense to talk about indirect benefits over time. Avoided mistakes. Projects that were never launched. Investments that did not drift off course. Occasionally, opportunities that become visible precisely because the structure made them easier to see.

These outcomes are harder to trace back to architecture, and they resist traditional cause–effect measurement. Still, they are not accidental. They are built on the same mechanisms, repeated over time. Without the initial clarity, they simply do not materialize.

Put bluntly: EA does not create value by existing, by being formalized, or by being well tooled. It creates value when it makes thinking visible and shared—early enough that decisions can still change.

Measuring What Actually Matters (and Inviting the Right Debate)

This also explains why EA benefits are difficult to measure in the traditional sense. You cannot reliably isolate them the way you would measure the ROI of a single investment, such as a factory, a machine, or a specific IT system. The effects are indirect, cumulative, and deeply intertwined with decision-making across the organization. Outcomes emerge from many interacting factors rather than a single cause.

That does not mean nothing can be measured. Direct benefits are often visible if you know where to look. Are discussions shorter or more focused? Do projects spend less time rediscovering the same dependencies? Are key questions raised earlier than before? Do decision-makers agree more often on what is actually being decided? If you cannot see these signals at all, the problem is rarely measurement—it is that architecture is not yet being used where it matters.

Often, the most honest picture comes from simply asking the people who actually use architecture in their work. Project managers, product owners, and decision-makers tend to notice very quickly whether architecture helps or gets in the way.

These signals are imperfect, but they are real. And they are far more honest indicators of architectural value than forcing everything into a spreadsheet that was never designed for this kind of use.

For the owner of the EA practice, this means accepting a different kind of accountability. You will not get instant ROI. What you get first is signal: clearer discussions, fewer surprises, and earlier visibility into risks. Managing EA is largely about recognizing and protecting these early signals long enough for the longer-term effects to accumulate.

I have unpacked the longer-term benefit mechanisms in more detail elsewhere, including in my PhD research, my EA book, and in an earlier article. This piece deliberately stays closer to the ground. If the immediate benefits do not appear, the long-term ones are largely theoretical.

Finally, a note on discussion. Debate about EA is both necessary and welcome. Strong disagreement is fine. What matters is that the debate stays focused on the substance—mechanisms, assumptions, and outcomes—not on people. If nothing else, architecture should help us have better arguments.

🔗 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 | 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 there is another, slightly more uncomfortable angle to the same problem.

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

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

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

Common Ways Architecture Drifts Away from Descriptions

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

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

The “Advisor-Only” Architect

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

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

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

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

“We Don’t Have Time to Model”

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

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

“Modeling Is Too Operational”

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

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

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

“We Have Plenty of Architects”

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

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

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

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

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

Between No Models and Too Many Models

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

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

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

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

So What Is the Architect’s Role, Then?

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

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

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

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

And those foundations are, still, the descriptions.

🔗 You May Also Like

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

👨‍💻 About the Author

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | 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, modeling still feels heavy. So what, exactly, is getting in the way?

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

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

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

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

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

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

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

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

Too Much Detail, Too Early

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

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

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

Theoretical, Generic Models

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

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

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

Point Solutions Do Not Create a Whole

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

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

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

Don’t Tools Matter at All?

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

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

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

When Modeling Problems Are Leadership Problems

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

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

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

Modeling Is Not a Mystical Skill

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

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

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

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

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

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

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

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

The Process in Practice

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

Step 1: Clarify the Type of Description and Its Purpose

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

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

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

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

Step 2: Assemble Source Material and Create an Initial Draft

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

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

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

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

Step 3: Validate and Refine Through Expert and Management Input

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

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

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

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

Step 4: Define Boundaries and Make Deliberate Omissions

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

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

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

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

Step 5: Approval

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

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

Step 6: Use and Maintenance

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

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

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

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

What This Process Actually Teaches You

This process highlights a few recurring realities of architecture work.

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

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

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

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

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

🎤 Upcoming Enterprise Architecture Webinar (in Finnish)

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

👉 Register for the webinar

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

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

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

👉 Watch the recording

🔗 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 | 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 turn of the year is supposed to be about fresh starts. Calendars reset, priorities get reshuffled, and for a brief moment it feels like some things might finally be left behind.

That’s the theory, anyway. In practice, in some of my current assignments, I have a task list in Outlook that never really changes. Items rotate, dates move, details are added—but the list itself remain. Tasks are not so much completed as carried forward, quietly surviving every planning cycle. At some point, you stop expecting the list to get shorter. You just learn to live with it.

Architecture work has a peculiar rhythm like that. Priorities shift, roadmaps evolve, diagrams get updated. From the outside, it looks like steady progress. But the work itself rarely ends. Items don’t disappear; they rotate. If you are an architect, this probably feels familiar—and slightly irritating.

To be clear, enterprise architecture (EA) work is continuous by nature. It does not “finish,” and it shouldn’t. But individual architectural tasks are different. They should have a clear endpoint: a deliverable produced, a review completed, or an approval given elsewhere. When that distinction starts to blur, everything begins to feel permanently unfinished. And that is usually not a personal productivity problem. It is a structural one.

This article is about why architecture work so often feels like this—and what architects can realistically do when “done” keeps drifting just out of reach.

Organizations Love Beginnings

That sense of permanent incompleteness is not accidental. It follows a pattern that many organizations share.

New strategies appear regularly. New technologies are introduced with enthusiasm. New initiatives are launched before the previous ones are properly closed. Old work is not finished; it is reclassified as “ongoing,” “continuous,” or quietly folded into “phase two.”

From an architectural perspective, this creates a one-way accumulation. Portfolios grow wider every year but almost never smaller. Applications, integrations, and data groups are added, but rarely retired. Temporary solutions settle in and become permanent residents. Priorities shift, but they are seldom removed.

The structure strongly rewards starting new work, while offering very little support for deliberately finishing and closing the old.

The Architect’s Role Makes This Worse

The feeling of permanent incompleteness is amplified by the nature of the architect role itself.

Architects depend on other people’s work and on information that lives elsewhere. They do not invent the content of the current state; they structure, validate, and make visible information provided by others. They also don’t implement solutions or own budgets, and rarely make the final decisions.

Architect’s role is to facilitate, clarify, and support: to make dependencies and consequences visible, and to structure discussions so that decisions can be made. But making decisions possible is not the same as making decisions happen.

Architects can complete their outputs—current state models, principles, target states—but not the outcomes they are meant to enable. You can finish the model, but not the change. You can close the architectural task on paper, while the real issue stays open.

Motion Without Closure Looks Like Progress

The actual decision-makers usually sit higher in the organization. They carry formal responsibility, but their attention is fragmented across strategy, operations, politics, and the next urgent issue. Architectural topics compete with many others, and postponing a decision is often the easiest short-term option. Nothing breaks immediately. The meeting still has to end on time.

This creates a structural gap. Architectural work progresses, but decisions lag behind.

Topics move through forums, documents get refined, and alignment increases—but ownership does not. It looks like progress from the outside. Inside, it feels like motion without arrival.

What an Architect Can—and Cannot—Do

There is an uncomfortable truth here: an individual architect cannot fix this alone.

You cannot create architectural content alone. You cannot force decisions you don’t own. You cannot end initiatives that management keeps alive. And you cannot “solve” structural indecisiveness with better diagrams.

What you can do is help the organization see the cost of never finishing.

Some survival tips that may actually help:

• Take care of your own patch. Finish your part cleanly, so nothing unnecessary is left hanging on your side. Be explicit about what is done, what is intentionally left open, and what is no longer owned by architecture. Structural ambiguity is an organizational issue—not a personal one.

• Design for endings. When something new is introduced, ask what will be retired. Name the application, integration, report, or process that should disappear. If nothing is named, “nothing” is already the decision.

• Make closure visible. Treat end states, exit criteria, and decommissioning as part of the design itself. If an initiative has a start date, make its end condition visible—even if that end is conditional or phased.

• Lower the bar for input—and make assumptions explicit. Do not wait for perfect information. Use partial input, document reasonable assumptions, and mark them clearly. Incomplete input is often more useful than no input at all.

• Show drafts and timebox waiting. Rough models trigger reactions; empty templates do not. Set a visible deadline after which the work continues with assumptions rather than waiting indefinitely.

• Frame incompleteness as a trade-off. Not everything has to end. But keeping everything open consumes attention, budget, and decision-making capacity. Make that cost explicit: what cannot change as long as this remains unfinished?

• Separate architectural work from organizational waiting. Waiting for input, decisions, or alignment is not architectural progress. Make that distinction visible—to others, and to yourself.

• Use language that reflects reality. If something is stalled, call it stalled. If ownership or input is missing, say so. Soft wording makes unfinished work easier to tolerate and harder to resolve.

This does not magically create closure. But it turns vague frustration into a conscious structural issue, which is already an improvement.

A Different Question to Ask

At the start of a new year, organizations usually ask what they should begin: new initiatives, new capabilities, new transformations.

Architects might want to ask a different question:
What will we actually allow to end this year?

Not pause. Not reframe. Not absorb into something bigger.

But end.

Until organizations become as intentional about endings as they are about beginnings, architecture work will continue to feel unfinished. And architects will keep noticing it first—not because they are cynical, but because they see the structure clearly.

Sometimes that uneasy feeling is not a problem to fix. It is simply architecture doing its job.

🎥 New Video: What My Enterprise Architecture Book Is Really About

I’ve just published a short and lighthearted video introducing my book Enterprise Architecture – Your Guide to Organizational Transformation.

In the video, I explain what the book covers, who it’s written for, and what you’ll get from.

🎞️ Book Launch Videos Available

If you couldn’t attend the launch for my book Enterprise Architecture – Your Guide to Organizational Transformation live, the recordings are now available.

If you want a compact overview of why the book was written and how enterprise architecture is approached in practice, this is an easy way to catch up.

Each video includes the presentation part. The Q&A session and participant list have been removed for privacy reasons.

English event recording (Thursday, October 30, 2025)

Finnish event recording (Wednesday, October 22, 2025)

👨‍💻 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 | 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.

From Drafts to Deliverables

Looking back, 2025 was above all fragmented. Several projects running in parallel, different kinds of deadlines, and an unusually large amount of polishing and closing things off rather than starting something new. Not particularly glamorous work, but absolutely necessary if you want ideas, drafts, and plans to turn into something that actually exists.

One Visible Outcome, Many Hidden Phases

The only clearly visible publication milestone was the release of my English-language enterprise architecture book in October: Enterprise Architecture: Your Guide to Organizational Transformation. By that point, the core writing work was already behind me.

What remained was the kind of work that often stays invisible: commenting on layouts, refining details, aligning content, and—above all—marketing. Not particularly interesting in itself, but entirely unavoidable. I invested more time in marketing than in any previous year, and the impact was immediately visible in how my time was actually spent.

Knowing When “Good Enough” Is Enough

After the summer, my focus returned to my debut novel Pohjoisen tie (The Northern Road), which had a hard deadline in November. In many ways, this was the heaviest project of the year.

Not because anything essential was missing, but because there was always something that could still be improved. This is a familiar situation in architecture work as well: at some point, the value of further refinement drops below the cost of delay. You have to make a decision, accept trade-offs, and move on.

Parallel Work, Different Maturity Levels

Alongside that, I finalized a children’s nonfiction book about money, built around storytelling, with a deadline at the end of the year. This required only a couple of editing rounds, as the core writing had been completed years earlier.

In the fall, I also took part in a children’s writing competition with another narrative nonfiction manuscript. Earlier in the summer, I published a short English-language children’s book as a self-publishing experiment.

Experiments and Mixed Results

On the short fiction side, the year was oddly split in two. A school-themed competition, Art Breaks Walls, brought a top-16 placement and an anthology publication for a text that came together with surprising ease. That was clearly the highlight.

At the same time, my atmospheric horror story didn’t place in either Nova or Portti (established Finnish speculative fiction writing competitions), despite being one I personally liked quite a lot. On the brighter side, a short story combining Cthulhu with politics—originally started back in 2023—finally seems to have found a home for 2026. Towards the end of the year, I also wrote one more competition entry, almost out of habit.

Writing as Ongoing Practice

Writing didn’t stop at books or fiction. I published four articles in Juomaposti (Finnish publication focused on beverages, drinking culture, and related industry topics), wrote weekly for my Substack newsletters, and kept LinkedIn active. Along the way, I also started writing on Medium, mostly about writing itself.

A significant share of the work never shows up as a single publication: website updates, marketing materials, presentations, and other background tasks. Marketing took noticeably more time than in earlier years, but at this stage it felt like a justified investment rather than a distraction.

A Conscious Decision Not to Start Something New

What I didn’t do was start any entirely new book-length writing projects, either fiction or nonfiction. Ideas certainly existed, and I even pitched one of them to a publisher. It didn’t move forward—too B2C-oriented for their list—which was a sensible decision. There was already enough in progress.

A Solid Year Without a Grand Finale

So how did the year go? From my own perspective: quite well. There was a lot to do, and a lot got done, even if there wasn’t a single obvious finish line or triumphant moment. In hindsight, 2025 feels more like a year of building and preparation than one of visible results. And that’s perfectly acceptable.

None of this would have been realistic without a four-day workweek. Without that structural decision, pushing this many parallel efforts forward simply wouldn’t have worked.

What Comes Next

What’s next, then? In March, my debut novel will be released by Momentum Kirjat. In the summer, the children’s nonfiction book will follow with Aviador. There’s also an interesting new nonfiction idea in the back of my mind—but we’ll see what it turns into, if anything.

👨‍💻 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 | 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.