I used Google NotebookLM to create a short AI-generated audio discussion based on my article The Quiet Death of Enterprise Architecture. Rather than simply reading or summarizing the article, the two AI hosts discuss and challenge its main ideas: how enterprise architecture gradually loses relevance, what the warning signs look like, and what architects can do about it.

I reviewed the discussion before publishing it, but the voices and conversation are AI-generated.

🎧 Have a listen!

👨‍💻 About the Author

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

Follow him elsewhere: Homepage | LinkedIn | Substack (expert work) | 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 strategy, change, and delivery.

With the arrival of AI-assisted software development, and especially vibe coding, this technical curiosity has found a new outlet. Instead of writing the code yourself, you describe what you want in natural language, let AI generate the code, and refine the application through further prompts. In its purest form, you barely need to look at the code at all. A working prototype can sometimes be created in an evening.

And naturally, enterprise architects have started building their own enterprise architecture (EA) tools.

I have done it myself, and I have also been asked to review and comment on tools that other architects have developed. Browsing professional networks and online communities suggests that I am hardly alone.

This raises some interesting questions. Are we entering an era when individual enterprise architects can develop tools that genuinely challenge established software products? Could these applications make EA more accessible and useful? Or are we simply making it easier to create yet another collection of architecture repositories that nobody maintains? It is worth having a closer look.

A Growing Phenomenon?

I have no reliable numbers on how many architect-made EA tools exist, or how many have been created through vibe coding. I suspect nobody really does. Some are publicly available, while others are personal experiments or internal applications that never leave their developers’ computers.

I started noticing these applications through my professional network, when fellow architects shared their projects, sometimes asking for feedback. Similar examples occasionally appear on LinkedIn. I cannot say for sure how many of these tools have been developed through vibe coding, but I strongly suspect that many have.

From what I have seen, most seem to focus on architecture modeling, basically on creating diagrams. Some address quite specific needs, such as helping users identify the appropriate ArchiMate relationship types. There are also more ambitious applications built around architecture repositories.

Until recently, there were relatively few serious free alternatives to commercial EA modeling tools. Archi, an open-source ArchiMate modeling application with extensions available, has been my go-to option for years. I have used it for personal exercises and in client assignments where no EA tool was available.

Now, creating a customized alternative has become considerably easier. Whether this will produce a significant new category of EA software or mainly a collection of interesting experiments remains to be seen.

Why Build Yet Another Enterprise Architecture Tool?

Commercial EA tools offer sophisticated modeling, repositories, integrations, reporting, visualizations, collaboration, and various governance features. However, they can also be expensive, complicated, and rather demanding to implement and maintain.

For a small organization with simple EA needs, introducing a comprehensive EA platform can feel like buying a large enterprise resource planning system to manage the office coffee supplies.

An architect developing a tool for a particular purpose can concentrate on precisely what is needed. Perhaps that means simple modeling, managing an application portfolio, visualizing dependencies, or producing a specific analysis. Features that nobody needs can be left out.

For solution architects, a lightweight browser-based modeling application can also lower the threshold for getting started. Open the application and start modeling, without installing and configuring software.

Vibe coding also makes experimentation much more practical. An idea can be turned into a working prototype quickly, tested with users, and improved based on their feedback. Some of these applications may even be better than certain commercial products for their intended purpose.

I also suspect that many architects simply want a tool that works exactly the way they prefer. Having used several EA tools over the years, they probably have quite specific ideas about how modeling and visualization should work.

And, of course, there is the simple pleasure of building something yourself. I suspect this motivation is more influential than we might want to admit. After all, developing a new tool may be considerably more interesting than updating the current-state application map. But every hour spent coding is also an hour away from actual architecture work and its stakeholders.

From a Simple Application to an Enterprise Architecture Repository

The opportunities are real, but so are the limitations. Much depends on what kind of application we are talking about.

At the simpler end are lightweight tools for creating architecture diagrams, visualizing dependencies, or analyzing architecture information. These can be genuinely useful, either as standalone applications or as extensions to an existing EA repository.

Building such browser-based applications is relatively straightforward with AI. I suspect many architect-made tools are primarily frontend applications that use local files or browser storage. For individual modeling, demonstrations, and specific analyses, that may be perfectly adequate.

At the other end are comprehensive EA tools with shared repositories, portfolio management, reporting, collaboration, and various visualization capabilities. Developing these is a considerably bigger undertaking. A proper backend, database, user management, and supporting infrastructure require much more effort than creating a browser-based interface.

The shared repository is particularly important. Organizational EA work typically requires several people to maintain and access the same information. Without a shared database, managing versions, responsibilities, updates, and consistency becomes difficult. This is also a limitation of traditional desktop modeling tools such as Archi. Although Archi supports Git-based version management, I have found this functionality rather cumbersome in practice.

Another challenge is the quality and consistency of architecture information. A tool may produce impressive diagrams without properly supporting architecture modeling. Does it follow established concepts and relationship rules, such as those defined in ArchiMate? Can the same elements be reused across different views? Is the information structured for analysis and exchange with other tools? Otherwise, architects may end up creating new information silos while encouraging everyone else to follow standards and improve interoperability.

More advanced tools also need integrations, data portability, testing, software updates, and ongoing support. These requirements become increasingly important as the application gains users and the organization starts depending on it.

The initial development may take a weekend. Maintaining the application can turn into a permanent responsibility.

What About Data Security?

A very real concern is the processing of actual architecture information.

EA documentation can contain sensitive information about an organization’s applications, technologies, dependencies, and business operations, and sometimes even personal data. Exposing this information may create security risks.

Some lightweight EA applications promise that everything happens locally in the browser and that no information is uploaded to external servers. This sounds reassuring, but such promises should be verified rather than simply accepted.

For example, an application may use external libraries, scripts, analytics services, or AI functionality. Information may be stored in the browser, and the application itself may have vulnerabilities. Whether data actually stays local depends on how the software has been implemented and what it communicates to external services.

For repository-based tools, data security becomes even more important. Where is the architecture information stored, who can access it, and how are access rights managed? If data is hosted externally, the organization also needs to understand who operates the service and how the information is protected.

Before using a homegrown or otherwise unverified application with real organizational data, I would expect a proper security assessment. This should cover the application’s data flows, external dependencies, storage, hosting, and access controls, as well as applicable privacy and organizational security requirements. AI-generated software is still software, with the usual security concerns and potentially some additional ones.

For experimentation, synthetic or otherwise non-sensitive data is a much safer starting point.

When Would I Use an Architect-Made Tool?

I would distinguish between using a small application for a specific task and adopting one as the organization’s main EA platform.

For limited purposes, architect-made tools can be excellent. A tool that produces useful visualizations from exported architecture information, for example, may provide value without introducing major dependencies. Similarly, an intuitive modeling application that lowers the threshold for creating architecture descriptions may be perfectly suitable for occasional users.

Using a homegrown application as the main EA repository requires more consideration. Without a shared database, it may be difficult to support collaborative architecture work. The organization also needs to know that the information can be maintained, protected, and eventually migrated elsewhere. Someone must take responsibility for the application’s continued development and operation.

The fact that a tool was built by an experienced enterprise architect is encouraging when it comes to understanding EA requirements. However, developing and maintaining production software requires a different set of skills.

Ultimately, a good EA tool should be evaluated based on how well it supports actual EA work, rather than the elegance of its interface or the technology used to create it.

Thinking of Building Your Own?

Having experimented with this myself, I understand the attraction. Seeing an application take shape after describing a few requirements to an AI assistant is quite satisfying.

If you are considering developing your own EA tool, I would suggest keeping a few things in mind:

1. Start with a genuine need. Identify a specific problem and the people who would benefit from solving it. Consider what your application would offer compared with existing products, including free tools such as Archi and Draw.io. Do we really need another version of Archi with slightly different features?

2. Keep the scope manageable. A specialized visualization or analysis tool is much easier to develop and maintain than a general-purpose EA platform. Think carefully before trying to recreate everything existing products already offer.

3. Design the data model properly. Define the architecture elements, relationships, attributes, and modeling rules early. Consider whether users need shared data, persistent storage, and integrations. These decisions are much more difficult to fix after the application has grown. Using ArchiMate or another established metamodel makes things easier.

4. Take software engineering and security seriously. Review and test AI-generated code, understand how information is processed, and arrange a security assessment before using sensitive data. Production use also calls for documentation, version control, backups, and a maintenance plan.

5. Make sure your data is portable. The application should support importing and exporting architecture information in commonly used formats, preferably established exchange formats such as the ArchiMate Model Exchange File Format, where applicable. You should be able to move data between tools and switch to another application without losing years of work.

6. Think about the long term. If you publish the application for others to use, are you prepared to maintain it, fix bugs, answer questions, and keep it working as technologies change? Even a free tool can create expectations among its users.

Finally, consider the alternatives. Vibe coding may reduce initial development effort dramatically, but testing, maintenance, security, and support still require time. Sometimes configuring an existing product or building a small extension to it is more sensible than creating something entirely new.

A Tool Is Still Just a Tool

There is something slightly ironic about enterprise architects becoming enthusiastic about building their own software.

After all, we spend much of our professional lives encouraging organizations to reduce unnecessary complexity, reuse existing solutions, manage application portfolios, and make sensible build-versus-buy decisions.

And now we have discovered a convenient way to create new applications ourselves.

I do not see this as a bad thing. On the contrary, I believe AI-assisted development opens interesting opportunities for making EA more flexible, accessible, and useful. It also encourages architects to experiment and develop their technical understanding. Perhaps the greatest potential lies in complementary applications: specialized analyses, visualizations, and quality checks that use information from existing EA repositories, without introducing another database to maintain.

But the ease of building software can make us focus too much on the software itself. AI makes developing applications easier, but deciding what is worth developing still requires some judgment.

The real challenge in EA has never been the lack of tools. It is getting relevant architecture information created, maintained, understood, and used in actual planning and decision-making. These are largely organizational challenges involving people, responsibilities, collaboration, and working practices.

A better application may help address them. Sometimes considerably. Still, even an impressive repository with beautiful diagrams is of little value if nobody uses the contents. And a simple spreadsheet may be perfectly adequate when it helps people make better decisions.

The same principle applies whether we use an established commercial platform, an open-source application, or something an enthusiastic architect created during a weekend with the help of AI.

The tool is just a tool. What matters is what we achieve with it.

🧐 Can Enterprise Architects Afford to Be Arrogant?

Enterprise architecture seems to attract some strong personalities, and I have met my share of them both offline and online. In fact, some of the most arrogant experts I have met during my consulting career have been enterprise architects. To be fair, many have also been exceptionally good at their jobs.

But how much arrogance can you afford if you are really good? And what if you are not quite as good as you think?

I explored this in my Expert Work by Design article: Can You Afford to Be Arrogant If You’re Really Good?

🔗 You May Also Like

Are you looking to dive deeper? Here are some related articles you might find useful:

👨‍💻 About the Author

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

Follow him elsewhere: Homepage | LinkedIn | Substack (expert work) | 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 strategy, change, and delivery.

The podcast explores how organizations can become more foresight-driven: better able to study change, understand what emerging developments could mean, and connect future possibilities to decisions made today.

That creates an interesting connection with enterprise architecture. Foresight can help identify changes that may matter. Enterprise architecture can then help make their implications visible across strategy, operations, data, applications, and technology—and support decisions about what to do next.

In our roughly 25-minute conversation, we discuss why useful architecture insight so often fails to influence actual decisions, what enterprise architecture benefit realization means in practice, how its value can be measured and made visible, and how architecture can help organizations understand and manage change. We also touch on the role of capabilities as a way to connect strategic ambitions with what the organization actually needs to be able to do.

One theme runs through much of the discussion: enterprise architecture creates value only when it is actually used. Good models and analyses matter, but the real test is whether they improve understanding, influence a decision, reduce uncertainty, or help an organization make change more deliberately.

This also makes measurement challenging: architecture outputs are relatively easy to count, while the more meaningful outcomes and benefits are often indirect, shared with other activities, and realized over time.

One broader thought the conversation left me with concerns target states. We did not go into details on this, but it is something I consider important in enterprise architecture. Defining a meaningful target state is difficult, and in my experience relatively few organizations do it systematically at the enterprise level. Still, I recommend it. Without some shared view of where the organization is trying to go, it becomes much harder to make coherent choices about capabilities, applications, data, investments, and transformation initiatives.

It was a short conversation but one that connects several topics I find increasingly important: foresight, architecture, decision-making, change, measurement, and the practical realization of benefits.

🎧 Listen to the episode here

You can also learn more about The Foresight-Driven Enterprise on Substack. I recommend following it if you’re interested in foresight, organizational change, and how future-oriented thinking can connect with enterprise decision-making.

🔗 You May Also Like

Are you looking to dive deeper? Here are some related articles you might find useful:

👨‍💻 About the Author

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

Follow him elsewhere: Homepage | LinkedIn | Substack (expert work) | 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 strategy, change, and delivery.

This conversation prompted me to write about an issue I have encountered quite often in my work.

Over the years, I have worked with enterprise architects in dozens of client organizations. I have also spent longer periods working as an architect myself in a few organizations, and discussed the topic with both new and long-time colleagues. One thing seems to be fairly consistent, at least in Finland: enterprise architecture (EA) usually sits somewhere within IT. Occasionally, it belongs to a broader business or organizational development function, but that seems to be the exception.

I have seen this arrangement cause problems more than once. Being part of IT can affect what an enterprise architect gets to work on, who they collaborate with, and how much influence they have outside their own department. As a consultant, the problem can be even more pronounced. You are already an outsider, and reaching people beyond the department that brought you in may take considerable effort.

Of course, the organization chart does not tell the whole story. As the architect I mentioned had discovered, it is quite possible to build connections and influence across organizational boundaries, even when your formal position is less than ideal.

So, does it really matter where EA sits in the organization? And what can you do if you suspect you are in the wrong place?

IT Is a Good Place to Be, but There Is More to the Organization

Placing EA within the IT department makes perfect sense in many ways. EA has strong roots in IT, and many enterprise architects have moved into their roles from more technical architecture positions. Besides, much of the planning and decision-making within IT can benefit from EA.

Managing the IT environment, developing the application portfolio, selecting technologies, and planning development initiatives are all natural use cases for EA. There is nothing wrong with that.

The problem arises when EA activities become limited to these areas. After all, EA is an approach to planning and developing the organization as a whole. It considers the structures and dependencies between business operations, information, applications, and technology. And many of the organization’s most important development needs originate somewhere other than IT.

Consider an organization planning to improve its customer service. Such an initiative may require changes to business processes, responsibilities, employee competencies, information management, and IT systems. EA could help considerably in planning this kind of transformation. However, if the enterprise architect only gets involved when the necessary IT solutions are being designed or acquired, many important decisions have already been made.

At that point, the architect’s role may be reduced to checking whether the proposed IT solution fits into the existing application landscape. That is useful work, of course, but it leaves much of EA’s potential untapped.

Ideally, enterprise architects should also participate in strategic planning, as well as in planning and developing the organization’s core operations, preferably from the early stages when needs and alternatives are still being discussed. This requires collaboration with senior management, business units, development functions, and other supporting functions. And this is where the organizational position starts to matter.

The Organization Chart Matters More Than You Might Think

An organizational structure defines responsibilities, reporting lines, and management relationships. At the same time, it influences how people collaborate and whose business they are expected to get involved in.

In some organizations, collaboration across departmental boundaries is completely natural. Specialists contact each other directly, participate in joint planning, and solve problems without much bureaucracy. In others, people are very particular about who can contact whom, who gets invited to which meetings, and whose responsibility a particular issue is. Sometimes departmental boundaries seem almost like national borders.

The latter situation is particularly challenging for EA. The whole point of EA is to develop an overall view of the organization and identify dependencies that extend beyond individual functions and departments. If the architect only has access to discussions within IT, the resulting architecture work will likely be rather IT-centric.

The manager’s position also makes a difference. A CIO may have close connections to senior management and an important role in strategic planning and organizational development. In that case, an enterprise architect reporting to the CIO may have excellent opportunities to influence matters beyond IT.

The situation can be quite different when the architect reports to, say, an IT service manager whose responsibilities and influence are limited to one department. The manager may be very supportive of EA but lack the authority or connections to help the architect participate in activities elsewhere in the organization.

The organizational position can also shape expectations about the architect’s work. If an enterprise architect belongs to IT, others may expect them to focus primarily on IT matters. Getting involved in business process development, for example, may be seen as stepping into someone else’s territory.

In the worst case, the enterprise architect is expected to look after the interests of the entire organization, while their objectives, resources, and management come from just one small part of it. That is not exactly an ideal starting point for an enterprise-wide function.

Your Manager Is Not Necessarily Your Enterprise Architecture Sponsor

An enterprise architect’s manager naturally has an important role in defining their responsibilities, allocating resources, and managing their work. However, managing the architect and steering EA activities are two different things.

If EA is expected to support strategy execution and organization-wide development, its steering should also come from a sufficiently senior level. Otherwise, there may be a mismatch between the objectives assigned to EA and the opportunities available to achieve them.

This is where EA sponsorship comes in. Ideally, EA should have a sponsor in management who considers the function important, helps define its objectives, and enables collaboration across organizational boundaries. This could be the CIO, a development director, or another member of the management team.

The sponsor and the architect’s line manager can be the same person, but they do not have to be. A CIO who participates actively in strategic planning and business development may be an excellent sponsor. On the other hand, an IT manager whose responsibilities are limited to one department may have fewer opportunities to support organization-wide EA activities, however positive their attitude toward EA might be.

Of course, simply naming someone as the EA sponsor achieves very little. Sponsorship should be visible in practice, for example, in the assignments given to architects, their participation in development planning, and the use of architecture in decision-making.

The enterprise architect needs access to the people and discussions where architectural input could make a difference. That matters more than the reporting line itself.

So, Are You in the Wrong Place?

Would it then be better to place EA directly under the CEO or somewhere else near the top of the organization?

Perhaps, but there is no single correct answer. Organizations differ in their structures, management cultures, and ways of working. In a small organization, EA may work perfectly well as part of IT. In a large corporation, it may make sense to have a central EA function working together with architects in different business units or subsidiaries.

A position high in the organization also comes with higher expectations. If EA reports directly to senior management, it should be able to actually contribute something to strategic planning and organization-wide development. Maintaining a collection of current state architecture diagrams will hardly be enough.

Before proposing an organizational restructuring, I would therefore look at how EA could work better within the existing arrangements. Could the architect participate in business development planning? Could the EA function establish closer relationships with process owners and information management specialists? Would a shared architecture forum help bring together people from different departments?

Sometimes relatively small changes in collaboration and governance can make a considerable difference. The architect’s formal position remains the same, but their actual opportunities for influence improve.

However, organizational structures can also become genuine obstacles. If the architect is effectively prevented from participating in activities outside IT, and management is unwilling to support broader collaboration, there may be little room for improvement.

In that case, it may be necessary to reconsider where the EA function belongs. Alternatively, its objectives should be adjusted to match its actual mandate and opportunities for influence. There is little point in promising organization-wide strategic benefits if the architect is only allowed to participate in internal IT meetings.

How to Work Beyond Your Department

Most enterprise architects have little say in where they sit in the organization. However, their actual opportunities for influence can be considerably broader than the organization chart suggests. Much depends on how they approach their work and build relationships with others.

Here are a few things worth trying:

1. Clarify Your Mandate and Find a Sponsor. Discuss with your manager what EA is expected to achieve. If the objectives extend beyond IT, try to get support from someone in senior management who can help you get involved in organization-wide planning and development. Your line manager and EA sponsor can be different persons.

2. Get to Know the Business. Find out what people outside IT are working on and where EA could help. Start with concrete development needs rather than architecture methods and frameworks. A useful contribution to one business initiative may open doors to several others.

3. Build Relationships and Join Existing Activities. Get involved in development planning, portfolio management, and other activities where architectural input could be useful. Build connections with business developers, process owners, information management specialists, and project managers. Try to make EA part of existing ways of working rather than introducing yet another layer of meetings and governance.

4. Make Organizational Obstacles Visible. If your position prevents you from contributing to important development activities, discuss this with your manager and sponsor. Use concrete examples of missed opportunities and explain how broader EA involvement could help. You have a better chance of changing things by demonstrating value than by arguing about your position in the organization chart.

Look Beyond Your Department

Ultimately, the value of EA depends on how well it is used in organizational planning and decision-making. The organizational position matters, sometimes quite a lot, but it does not determine everything. The architect’s own initiative, credibility, and ability to build relationships also make a difference.

The architect I mentioned at the beginning had recognized that their position in the organization was probably less than ideal. Yet, they had managed to build connections across departmental boundaries and expand their opportunities to contribute.

I think that is a good example to follow. You may have limited influence over where your position sits in the organization chart, but you can often do quite a lot to extend your reach beyond it.

You can certainly belong to the IT department. Just remember that your job concerns the entire organization.

🎓 Yes, Enterprise Architects Can Go Back to School

Enterprise architecture is a field where much of the learning happens through projects, clients, and experience. But there are other options too.

I spent ten years completing a PhD on enterprise architecture benefit realization alongside a consulting career. It taught me a lot about research, the field itself, and the practical limits of doing serious study on evenings and weekends.

In my Expert Work by Design Substack, I wrote about the full journey, what I got out of it, and whether I would recommend doing a PhD alongside an expert career.

🔗 You May Also Like

Are you looking to dive deeper? Here are some related articles you might find useful:

👨‍💻 About the Author

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

Follow him elsewhere: Homepage | LinkedIn | Substack (expert work) | 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 strategy, change, and delivery.

I do not remember where the discussion ended up. But I do remember my first reaction: how exactly can EA be customer-centric?

At a fundamental level, the idea is not particularly strange. Most organizations exist to create something useful for their customers and other stakeholders, and their architecture should ultimately support that purpose as well. The more difficult question is what this means in practical EA work.

In practice, EA deals mainly with high-level structures and dependencies. It describes things like capabilities, processes, information, applications, technologies, and the relationships between them. Customer-centricity, on the other hand, sounds like something that belongs to customer service, service design, marketing, and product development.

A small clarification is probably needed. By customers, I mean the actual end customers of the organization. From a consultant’s perspective, the customers of my client. And not the internal stakeholders who sometimes happen to be called customers of the EA function.

I also take the involvement of these internal stakeholders as a given here. In my own work, EA has always been something done with people from different parts of the organization, even though I know there are architects who prefer to work rather independently.

So, I have spent quite a few hours in EA meetings during my career. I can remember business managers, CIOs, project managers, process owners, solution owners, developers, security specialists, and plenty of architects sitting around the table. But I cannot remember ever seeing an end customer there.

Still, that does not necessarily mean they should not be involved.

What Would a Customer Do in an Enterprise Architecture Meeting?

There is an obvious problem with the idea of directly involving customers in EA work. An end customer probably has very little to say about an application portfolio, a capability map, let alone an EA metamodel. They certainly do not need to comment on technology platforms or integration principles. Asking a customer to participate in a three-hour focus group on EA development would probably be an efficient way to make sure they never volunteer to help your organization in any way.

Customers experience something completely different. They notice that they have to enter the same information three times. They notice that an online transaction stops halfway and they have to call customer service. They notice that one part of the organization has no idea what another part has already agreed with them. They notice that changing an address works in one service but somehow not in another.

These are customer experience problems. But some of them can also be symptoms of architecture problems. And once the underlying issue involves processes, information, applications, or their dependencies, we are already entering enterprise architect territory.

From Customer Feedback to Architectural Root Causes

Suppose customers regularly complain that they have to provide the same information several times. There are many perfectly sensible ways to react to this. Perhaps customer service needs better instructions. Maybe the user interface could remember previously entered information. Perhaps the wording on the website should be clearer, or one step in the process could simply be removed.

An architect might ask a slightly different question: why does the organization need to ask for the same information several times in the first place?

Perhaps customer information is stored in three different systems. Maybe there is no clear master for the data. Perhaps integrations are missing, or different parts of the organization have developed their own processes and applications independently over the years. The customer sees a clumsy form or repeated question. Underneath, there may be a much wider structural issue.

The same logic applies to many common customer complaints. A slow service process might be caused by unnecessary handovers between organizational units. Poor visibility into the status of a customer case may come from fragmented applications. Inconsistent service between channels may reflect separate processes and systems that have never really been designed as one whole. A surprisingly complicated contact detail change may turn out to be a small window into years of accumulated system fragmentation.

None of these conclusions can be drawn from a customer complaint alone. But the complaint can tell us where to start looking.

This is where EA can add value. Architecture is good at connecting things. If customers report a recurring problem, the architect can trace it through the organization: which process is involved, what information is needed, which applications process that information, where data moves between them, and where responsibilities change hands.

A vague complaint such as “dealing with this company is unnecessarily difficult” can then become a much more concrete development question. Perhaps the issue is an overly complicated process. Perhaps responsibilities are unclear. Maybe two units are doing essentially the same thing. Or perhaps the technology really is the problem.

The useful part is getting from the symptom to the structural reason instead of fixing only what is visible.

In that sense, customer feedback could be another source of information for EA work, alongside strategy, development plans, regulations, system lifecycle information, costs, risks, and all the other inputs architects already use. It would simply provide another perspective on where the current architecture causes friction in real life.

This probably sounds fairly obvious once written down. Still, I do not remember seeing it done very systematically.

Do Customers Need to Participate Directly?

This brings us back to the original question. Should customers actually participate in EA work?

Sometimes, probably yes. If an organization is designing the target architecture around a major customer-facing service, understanding the customer journey is clearly relevant. The same applies when designing digital services or IT solutions that customers themselves will use or provide to their customers. Direct customer participation can provide information that architects would otherwise have to obtain indirectly.

In practice, however, these situations often move closer to solution architecture or service design than organization-wide EA.

In any case, I would be careful about turning customer participation into another universal stakeholder rule. Customers do not need to sit in every architecture workshop, and in many cases their direct participation would add little value. There is a difference between bringing the customer perspective into architecture work and bringing actual customers into every room where architecture is discussed.

The more useful principle might be, that customer’s perspective should be present in architecture work even when the customer is not.

That perspective can come through customer research, service design, surveys, analytics, feedback, support cases, or people who work closely with customers. The architect’s job is then to connect this information with the bigger picture and determine whether the customer problem reflects something structural.

Bringing Customer Experience Into Enterprise Architecture

The information flow should probably work in both directions.

Customer experience and service design people can tell architects where customers struggle. Architecture can help explain why. If a customer journey shows that one particular step consistently causes problems, looking at the architecture behind that step might reveal five applications, three manual handovers, duplicated data, and an integration built sometime around the invention of the iPad.

The customer journey map shows where the customer suffers. The architecture shows what might need to change. Neither view is complete on its own.

This is also why I would not try to expand EA into customer experience management. EA does not need to own customer journeys, customer satisfaction, service design, or customer research. There are already people who know much more about those things. They are separate but related disciplines.

EA can instead connect their findings to the structures and dependencies underneath. Customer experience information can also be brought into architecture models as additional attributes. Processes, capabilities, applications, or other architecture elements could, for example, be associated with customer satisfaction, recurring complaints, or identified pain points and visualized as heatmaps. This can help show where poor customer experience overlaps with architectural complexity or other structural problems.

In this way, EA can provide a consolidated view of customer experience without trying to become the function responsible for it. It can show how a seemingly small customer problem relates to processes, information, applications, ownership, and development priorities. That is a more modest role, but probably a more useful one.

So, What Is Customer-Centric Enterprise Architecture?

I used to think that “customer-centric enterprise architecture” was slightly strange terminology. Maybe I was interpreting it too literally.

Customer-centric EA does not mean drawing architecture diagrams from a customer’s point of view. Nor does it mean inviting customers to discuss application rationalization or technology standards.

It means making sure that architectural decisions eventually improve something that matters outside the architecture function. After all, the processes, information, applications, and technologies we describe exist to enable the organization to do something useful. Customer experience is one part of that.

One practical way to start would be surprisingly simple: take recurring customer feedback and ask whether there is an architectural root cause behind it. If customers repeatedly struggle with the same process, channel, or piece of information, trace the problem through the architecture and see what appears underneath.

Sometimes there will be nothing architectural to find. The answer may really be better instructions, clearer wording, or a small user interface change.

But every now and then, the annoying little problem reported by customers may be the visible end of a much larger structural problem. And finding those is more or less what enterprise architects are supposed to be good at.

🎉 A Small Milestone: 1,000 Subscribers

Two weeks ago, Enterprise Architecture Transformation passed 1,000 subscribers.

That is probably not enough for a public celebration in the town square, although I did have a can of non-alcoholic beer on that week’s Friday. Still, for a fairly narrow topic like EA, 1,000 people voluntarily asking to receive the next article in their inbox feels like a decent milestone.

To my opinion, it also says something about the demand for practical EA content internationally. EA is not exactly the easiest topic to make viral, although a sufficiently provocative headline sometimes helps.

Thanks for reading—and especially for subscribing.

🔗 You May Also Like

Are you looking to dive deeper? Here are some related articles you might find useful:

👨‍💻 About the Author

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

Follow him elsewhere: Homepage | LinkedIn | Substack (expert work) | 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 strategy, change, and delivery.

The actual date was somewhere back in February. I missed it completely by several months. That tells you something about milestones in professional life—if nobody puts an alarm into the calendar, two decades can slip by without cake or speeches.

The beginning was partly accidental. I certainly did not have a master plan to build a career in EA. I barely knew what the term meant when I started. Still, that accidental start ended up determining the direction of my entire career.

Twenty years is long enough to see quite a few waves come and go. Frameworks, maturity models, service-oriented architecture, cloud, digital transformation, data, agile, AI. Architecture tools have changed. The terminology has changed. The things organizations are excited about have definitely changed.

My own view of EA has changed as well.

Early on, I was interested in how architecture should be described and how the work should be organized. Later, I became much more interested in a different question: what is all of this actually useful for?

Nowadays, I think of EA mainly as a way to understand the whole, the dependencies within it, and the impacts of change—and ultimately to help organizations make better choices about where they are going and how they get there.

The models still matter. So do methods, frameworks and tools. I use them a lot. They have just moved into their proper place.

From Research to Consulting—and From Models to Value

In early February 2006, I started working at the University of Jyväskylä in a research project focusing on EA quality management. There was just one small problem: I did not really know what EA was. Before my first day, I was given a book on EA frameworks to read. The book compared 14 different frameworks, which was quite an introduction to a subject I knew practically nothing about.

I did not let that bother me too much. I jumped straight into studying the theoretical background, collecting data from companies, and writing research papers. I was surprisingly productive, particularly when it came to writing. Looking back, perhaps that was an early indication of the writing career that would follow years later.

Our project worked closely with companies and covered topics such as EA maturity models, architectural risks, and the quality of architecture documentation. I also happened to enter the field during something of a golden age of EA enthusiasm. New frameworks, methods, and maturity models seemed to appear constantly, promising to bring order to increasingly complicated organizations and IT environments.

I found the subject interesting, but one question started to bother me. Having a mature architecture practice and high-quality documentation sounded good, but what did the organization actually gain from them? The research literature offered surprisingly few concrete answers. This eventually led me to start doctoral research on EA benefit realization.

When the research project ended, I was offered a funded PhD researcher position. Consulting seemed more interesting, so I turned it down and joined Accenture in May 2008. The PhD came with me, although completing it alongside consulting turned out to be a rather lengthy exercise.

From Models to Operating Models

My first years at Accenture were very practical. I created architecture models, collected information, interviewed people, prepared deliverables, and supported more experienced consultants in their projects. There were plenty of workshops, PowerPoint slides, and, of course, boxes and lines. Later, I also moved into more detailed application architecture and solution design, with identity and access management (IAM) becoming a new area of specialization.

It was also where I learned how different actual organizations are from the relatively tidy world of EA frameworks. Information is incomplete, responsibilities overlap, and application landscapes have often evolved through decades of local decisions and temporary solutions that somehow became permanent. Drawing an architecture model is fairly straightforward compared with understanding why things look the way they do.

In 2013, I moved to Coala, a small Finnish consultancy specializing in EA, where I eventually became a partner. My work gradually shifted toward EA governance and operating models: how architecture work should be organized, who should be responsible for what, and how EA should connect with development, portfolio management, and decision-making.

That also changed my thinking. Architecture documentation alone achieves rather little. Someone needs to use it, preferably before important decisions have already been made. Otherwise, even an excellent capability map may spend most of its life peacefully in some forgotten corner of an architecture repository.

Meanwhile, my doctoral research continued. I finally completed my PhD in 2016, almost exactly ten years after starting my EA career. The thesis examined how EA benefits emerge through architecture products, services, stakeholders, and, importantly, their actual use. In a way, it brought together my original research interests and what I had learned through consulting.

From Architecture Work to Managing Change

In 2022, I moved to CGI, where I have continued working with enterprise and solution architecture, operating models, transformation, as well as AI adoption and other practical client assignments. Over the years, my focus has increasingly moved from producing and organizing architecture toward understanding how it helps organizations plan and manage change.

These different experiences have gradually shaped my own view of EA. I see it primarily as a way to help an organization understand itself well enough to make informed decisions about change. Architecture makes structures and dependencies visible, connects different perspectives, and provides something concrete for planning and discussion. The architect’s role is as much (or even more) about bringing people together as it is about producing architecture content.

I still enjoy practical modeling work, though. Sometimes understanding an application landscape or a few important data flows is exactly what is needed.

Writing has also become an important part of my work during the past five years or so. My books and articles have given me an opportunity to develop these ideas beyond individual client assignments. Explaining something to readers forces me to organize my thoughts and occasionally reconsider things I thought I already understood. Feedback brings in perspectives I might otherwise miss.

In that sense, writing has become another way of learning about EA, alongside research and consulting. And after twenty years, there is apparently still plenty to learn.

What I Have Learned

After 20 years, a few ideas have become much more important to me than individual frameworks, tools, or modeling techniques.

1. The Main Job Is to Understand the Whole and the Change

These days, I see EA primarily as a way to understand the whole, the dependencies within it, and the impacts of change. Organizations are complicated systems. Capabilities are realized through processes, people, information, applications, technologies, suppliers, and many other things. Change one thing and something else usually moves with it. And some of the architectural elements occasionally have their own opinion about the matter.

EA helps make these dependencies visible and usable in planning and decision-making. The trick is to describe enough, but not too much. Trying to model absolutely everything is a good way to build an expensive repository that is already outdated when you finish it.

For me, this is probably the most enduring value of EA: helping people understand what depends on what before they start changing things.

2. Enterprise Architecture Is Largely About Dialogue

Earlier in my career, I thought about EA more through its outputs: models, principles, roadmaps, and other documentation. I now think much more about the conversations around them.

Business, IT, security, data management, and development projects all look at the same organization from different perspectives. Each has its own priorities, terminology, and understanding of how things work. Architecture provides a common structure for connecting these views. Sometimes an architecture workshop is simply a good excuse to get the right people around the same table and discover that their decisions depend on each other.

EA governance often receives a lot of attention, but I see architecture primarily as an enabler. An enterprise architect should be an integrator and facilitator rather than someone who dictates how everyone else must work. In practice, they do not usually even have the mandate for it. Models, principles, and governance practices can help bring different perspectives together and support informed decisions.

3. Models Are Just Tools—But You Still Need the Models

I have become quite pragmatic about architecture documentation. A technically perfect repository that nobody uses has limited value. A rough application map drawn in half an hour for the right discussion may be far more useful than a meticulously maintained model containing thousands of elements.

Still, I strongly recommend maintaining a reasonably comprehensive, coherent, and deliberately coarse description of the current state. Knowing which applications you have, what capabilities and processes they support, how information flows between them, and what technologies they depend on is useful in almost any development initiative. There is little sense in rediscovering the same things at the beginning of every project.

You need enough detail to support planning and decision-making, while keeping the architecture manageable. A handful of attractive PowerPoint diagrams will rarely be sufficient, but neither is there much point in modeling every database field or server. Keep the overall architecture broad and connected, then go into detail where needed.

4. Structure Alone Is Not Enough

Traditional EA focuses on structural elements and their relationships: capabilities, processes, information, applications, and technologies. This provides a useful foundation, but much of what matters in organizational change lies outside these structures.

People, money, and organizational power structures can have a considerable influence on what can actually be changed. An application may look perfectly replaceable on an architecture diagram, but the reality can be rather different once you consider its business criticality, costs, ownership, and the people who depend on it.

Fortunately, architecture models can be enriched with additional information. Attributes such as costs, lifecycle status, criticality, risks, and ownership make structural descriptions much more useful for planning. Organizational interests, informal power structures, and skills may require additional analysis and discussions with stakeholders.

I also see visualization as an important part of this. Heatmaps and other visualizations can turn rather technical architecture information into something that management can actually use to compare alternatives, identify priorities, and assess the impacts of change.

The structural model provides the foundation. The additional information helps turn it into something useful for decision-making.

5. The Value of Enterprise Architecture Comes From Use

If I had to pick one idea that connects most of my career, it would probably be this: architecture creates value through use.

A capability map, an architecture principle, or a target-state model has little value sitting in a repository. It becomes useful when someone uses it to understand a situation, compare options, coordinate work, avoid problems, or make decisions.

This sounds rather obvious. It also happens to be one of the main findings of my PhD thesis. Apparently, some obvious things still take a considerable amount of research to establish.

In practice, this simple observation has important implications for how EA should be organized. Start by identifying the decisions and planning activities that architecture should support, rather than the models you want to produce. Measure how architecture information is used instead of counting deliverables. And integrate EA with the activities where development is already planned, managed, and governed.

Ultimately, I see EA as a way to help organizations understand themselves well enough to manage change. The descriptions, methods, and tools are what make that possible.

6. Methods, Frameworks, and Tools Should Stay in Their Place

I started my career reading about EA frameworks, so perhaps it is appropriate that I have become increasingly relaxed about them. TOGAF, ArchiMate, reference architectures, maturity models, and architecture tools all contain useful ideas. I use many of them myself.

They are, however, merely supporting machinery. A good framework provides structure, and a good EA tool makes maintaining architecture information easier. Neither guarantees that the organization will actually benefit from architecture work.

I am therefore more interested in whether an organization’s EA practice works than whether it follows a particular framework. Is architecture information used? Does EA support development and influence decisions early enough to matter? Can people understand the relevant dependencies?

Those questions tell me considerably more than framework compliance or a maturity score.

7. EA Needs to Be Both Strategic and Very Practical

EA is often presented as a strategic discipline. Fair enough. It should connect with strategy work and major organizational change. But not every architecture task needs an executive steering group, a transformation roadmap, and three slides all containing the word strategic.

I still enjoy practical architecture work. Give me a confusing application landscape or a messy set of information flows and I am quite happy to start drawing. Sometimes the useful contribution is simply clarifying which system sends what information to which other system, who owns it, and what happens if one of them is replaced.

I also believe in being helpful. If someone needs a process mapped, an conceptual diagram, or some other practical support, an architect should be happy to help. These smaller assignments are also good opportunities to understand what is actually happening in the organization, build relationships, and make architecture useful to people who might otherwise have little contact with it.

The strategic view needs a sufficiently concrete understanding of the underlying architecture. More detailed process and solution architecture work, in turn, benefits from understanding the bigger picture. I see these as complementary activities, each with its appropriate level of detail.

The Next 20 Years

Predicting the next 20 years in technology is probably a good way to embarrass yourself later, so I will keep this on fairly high level.

AI, data, automation, and regulation will certainly change architecture work. AI can already help analyze large amounts of information, produce documentation, identify dependencies, support modeling, and act as a sparring partner for architects. I expect these capabilities to improve quickly, and there are plenty of architecture tasks I would happily delegate.

At the same time, the basic problem EA addresses seems remarkably persistent. Organizations keep changing their operations, technologies, business models, and structures, while regulation adds its own requirements. These changes create dependencies and consequences that someone needs to understand, preferably before the changes are implemented.

For the time being, I also believe we still need human architects. If EA is largely about dialogue between different people, organizational functions, and perspectives, the job is difficult to reduce to producing models or analyzing data. Someone needs to understand the context, ask the awkward questions, bring people together, and help them make sense of the proposed changes.

AI will probably become a significant part of this work, but I suspect the human side will remain the more difficult part. Technologies, methods, and fashionable terminology will come and go. The need to understand the whole and work across organizational boundaries is less likely to disappear.

So I suppose there is enough work left for another 20 years.

🔗 You May Also Like

Are you looking to dive deeper? Here are some related articles you might find useful:

👨‍💻 About the Author

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

Follow him elsewhere: Homepage | LinkedIn | Substack (expert work) | 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 strategy, change, and delivery.

Back in 2006, I was finishing my student exchange abroad and trying to find a job—without much luck at first. Eventually, I scored a researcher position at the University of Jyväskylä in a project on EA quality management. I knew pretty much nothing about EA at the time, so well before my first day, I was handed Jaap Schekkerman’s How to Survive in the Jungle of Enterprise Architecture Frameworks.

The appropriately named book compares 14 different EA frameworks. I remember reading it and thinking: is this really what EA is all about?

(As a side note, the university copy got ruined when a gift bottle broke in my backpack on a return flight from UK. I had to buy them a new one.)

Almost twenty years later, I still find EA frameworks interesting, but I am also quite critical of them. In my own EA book, I deliberately skip the usual framework tour. There is a good reason for that, and I will get back to it later.

Instead of asking which framework is the best, I think we should start with a simpler question: what are we actually trying to structure here? In this article, I look at the roles EA frameworks can have, why they differ so much, and how to use them without making the framework itself the main goal.

A Framework Is Not Enterprise Architecture

EA is a strategic approach to managing change. It helps an organization understand its structures and dependencies and supports planning and decision-making. I explore what EA actually includes—and where its boundaries should be—in a recent article.

An EA framework is something more limited: a generic structure for supporting architecture work. It may help define what to describe, how architecture work is organized, and how the resulting models are represented.

The distinction sounds obvious, but it matters. It is surprisingly easy to start talking about TOGAF as if TOGAF and EA were more or less the same thing. From there, architecture work can gradually turn into implementing a framework rather than solving the organization’s actual planning and development challenges.

That happens surprisingly easily with frameworks, methods, and tools. People start discussing whether something is “TOGAF-compliant,” whether the correct phase has been followed, or whether a particular notation is used properly. All of these can be relevant questions, but only after the more important one: does this help us understand or change the organization?

I would rather treat a framework as a toolbox. Use what helps, understand why it helps, and leave the rest alone.

Three Kinds of Structure

One reason the framework discussion gets confusing is that very different things are called frameworks. I find it useful to separate three kinds of structure.

The first is content structure: what architecture consists of and how its different viewpoints and elements are organized. This may include capabilities, processes, information, applications, technologies, and the relationships between them. TOGAF, Zachman, ArchiMate all provide some structure of this kind.

The second is method: how architecture work is actually done and used. This includes processes, roles, governance, and ways of connecting EA with planning and development. TOGAF’s Architecture Development Method is probably the most familiar example.

The third is notation: how architecture is represented. ArchiMate is the obvious EA example. I can confess I am a fan. It provides a consistent language for high-level architecture models without forcing every architect to invent their own collection of arrows, boxes, colors, and symbols. BPMN, UML, and C4 solve related representation problems in somewhat different areas.

Then there are reference architectures, which are often mixed with frameworks. A reference architecture provides generic architecture content for a particular domain or solution area. A framework mainly helps organize architecture work; a reference architecture gives you something more concrete to as a basis for your modeling. To make things more confusing, some frameworks also come with quite a bit of reference content. TOGAF includes reference models for technology and information infrastructure, while the US Federal Enterprise Architecture (FEAF) has gone considerably further with common reference models for business, data, services, technology, and performance.

The borders are naturally fuzzy. This is EA, after all. Some terminological suffering comes with the territory.

The Framework Jungle Is Still There

There are plenty of frameworks and framework-like approaches around: TOGAF, Zachman, Lean EA, FEAF, EDGY, DODAF, E2AF, EA3 Cube, and others. Especially in the early 2000s, new EA frameworks seemed to appear like mushrooms after rain.

Even in a small country like Finland, the public sector has been surprisingly active in developing its own approaches. We have had frameworks and official recommendations such as JHS 179 and, more recently, the Suomi.fi EA framework.

They are also quite different. Some mainly structure architecture content, some provide methods for doing architecture work, and some focus on notation. Many cover more than one of these areas.

TOGAF, for example, combines a development method with content structures and plenty of supporting material. ArchiMate focuses on modeling: it provides both a high-level structure for organizing architectural viewpoints and a more detailed notation for describing elements and their relationships. The Zachman Framework, in turn, is better understood as an ontology: it provides a systematic way to classify architectural descriptions. EDGY is an interesting newer approach that combines perspectives from EA, enterprise design, strategy, and service design. It goes beyond a modeling language by also offering practical guidance and patterns for collaborative enterprise design.

So, which framework is best? I would probably avoid that question.

Do Not Choose a Framework

Frameworks have obvious benefits. Someone else has already spent considerable time thinking about architecture structures, methods, terminology, and good practices.

But also have equally obvious limitations.

There are too many alternatives. Generic frameworks cannot take into account the goals, maturity, organization, existing governance, or very practical realities of your organization. Many are too heavy to use as they are. Some are theoretically elegant but become rather thin when you start looking for practical examples.

My recommendation is therefore somewhat paradoxical:

Do not start by choosing a framework to implement. Start by identifying what you actually need, then use suitable parts from one or more frameworks and complement them with other good practices.

This is not even contrary to what the better frameworks recommend. TOGAF, for example, is explicitly meant to be tailored to the organization and the situation.

For example, you might use ArchiMate as your modeling language, TOGAF for high-level development phases, and selected EDGY practices for collaborative enterprise design. Then combine these with whatever already works in your organization.

In any case, the parts still need to fit together. In practice, this means agreeing on a reasonably consistent terminology, content structure, and way of working—and documenting these choices in your EA operating model.

There is little reason to reinvent these things. At the same time, I would not create yet another generic framework and give it an impressive acronym. The world has enough of them already.

Instead, design an EA operating model for your organization.

Build the Operating Model You Actually Need

The operating model should explain, in practical terms, how EA is maintained and used in your organization.

At minimum, I would think about the goals and scope of EA, organizational commitment, integration with other functions, architecture content, resources and skills, and working methods and tools.

In any case, keep it lightweight. But not too light. A reference to TOGAF or some other framework is not enough. Someone still has to decide what the framework means in your organization.

The integration with other functions is probably the most important part. EA is not some enormous parallel management function. It should support and connect with strategy implementation, process development, project portfolio management, IT service management, security and risk management, and IT development.

The same principle applies to architecture content. Define what you need and keep the structure simple. A capability map, process map, major data entities, application map, information flows, and technology platforms already take you surprisingly far. Add a simple metamodel so that the relationships between these elements remain understandable.

Use the Structure, Skip the Religion

EA frameworks contain decades of useful thinking. Ignoring them completely would mean repeatedly solving problems that others have already solved.

At the same time, following one framework religiously creates the opposite problem.

The practical middle ground is to understand what your organization needs, take the best available practices, and document how they work together in your EA operating model. For me, that is the useful structural view of EA frameworks.

Frameworks provide structure for content, work, and representation. They give us a common starting point. Some have even become de facto standards: for example, TOGAF and ArchiMate are the obvious frameworks worth knowing and, if certifications matter to your work, probably the ones worth certifying in. But none of them is EA itself.

Twenty years after starting my career with a book about surviving the framework jungle, my advice for surviving it has become fairly simple:

Take the useful tools with you. You do not need to take the whole jungle.

🔗 You May Also Like

Are you looking to dive deeper? Here are some related articles you might find useful:

👨‍💻 About the Author

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

Follow him elsewhere: Homepage | LinkedIn | Substack (expert work) | 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 strategy, change, and delivery.

This time, let us do it a bit differently. I want to step down from the usual high-level view and talk about something much more practical. It is about control, technology dependencies, and how to keep things running when situations change.

This topic has become very real for me in a recent client project. We have been helping a public sector client to design a highly integrated system. In the project, we have to think about what digital sovereignty actually means in practice for this specific solution.

The big question is not just where the data is stored, where the service runs, or which country the service provider comes from. The more interesting question is actually this: What must stay strictly under the organization’s own control, and what happens if a critical dependency suddenly changes?

Lately, digital and technological sovereignty has been a big topic here in Finland. A large part of the discussion is about how dependent Europe is on US technology giants. People also talk about the risk that access to important technology could be restricted somehow. If you work in IT here, you have definitely heard about this.

In the US, the discussion is quite different. From what I understand, the main focus there is on China. The US government and companies are worried about relying on Chinese hardware and software—and also about Chinese actors getting access to their data.

But in both cases, sovereignty is about much more than just the nationality of the vendor. It is also not just about some hypothetical “kill switch” button somewhere on another continent.

And it is definitely not something you only think about when selecting a cloud service provider. Actually, this issue touches almost all technology purchases, big and small.

As an enterprise architect, you can face these exact same questions in a very concrete situation: when choosing an EA tool. Where is the data stored? Who can see it? Which laws apply? And what happens to all your models and metadata if you decide to change the tool later? An architecture repository can hold a comprehensive picture of your organization’s business, applications, technologies, data, and dependencies. Suddenly, even choosing an EA tool becomes a decision about sovereignty.

Why Digital Sovereignty Actually Matters?

The most serious sovereignty risks are geopolitical. In a worst-case scenario, an organization could lose access to a critical technology or service completely. Another risk is that foreign authorities get access to the organization’s data based on their local laws.

For critical public services and infrastructure, both of these scenarios deserve serious attention.

However, most dependency issues in daily life are much more ordinary. A provider might change their pricing or licensing models, discontinue a product, or the service quality just drops. Sometimes ownership changes, regulations shift, or accessing your own data becomes too dependent on the provider’s tools and support. These are real concerns in almost any technology purchase.

The architecture problem starts when enough dependencies accumulate that changing direction becomes practically impossible.

A system might depend on a single provider’s identity platform, proprietary data model, integration services, development tools, and operations—not to mention their specialists’ competence. Even if the organization legally owns the data, they might still depend entirely on the provider to access, export, or recover it.

Each individual choice probably made perfect sense at the time. But together, they can create a web of dependencies that the organization can no longer realistically control. At that point, the supplier relationship has become part of the architecture.

What Does Digital Sovereignty Mean for an Architect?

Digital sovereignty is one of those terms that starts sounding obvious after you have heard it often enough. Then someone asks what it actually means, and the room becomes suddenly quiet.

At the European level, technological sovereignty generally refers to the ability to act independently in the digital world by controlling important technologies, data, and infrastructure, and by reducing excessive dependencies.

An individual organization needs something more concrete. From an architecture perspective, I find two ideas particularly useful:

• Verifiable control over critical digital assets and decisions.

• The ability to keep acting when providers, technologies, regulations, or other dependencies change.

The word verifiable matters. A supplier presentation stating that the customer remains in control is not yet evidence of control. Neither is a contract clause that nobody has connected to the actual solution architecture.

Can the organization access its data independently? Who controls administrative identities, certificates, and encryption keys? Can the service be restored somewhere else? Can the organization continue operating if the supplier is unavailable? Who can update, suspend, or disable the service?

These are architecture questions, even when most of the answers are often found in contracts, operating procedures, security documentation, or procurement materials rather than architecture models.

Sovereignty also does not mean complete independence. Modern IT is built on specialization, external service providers, software ecosystems, and shared services. Trying to remove every dependency would be both expensive and unrealistic.

Otherwise, we would all be manufacturing our own processors and writing operating systems in the basement. That would certainly improve independence, along with a few other problems. The more realistic goal is controlled dependency.

What Does Digital Sovereignty Include?

There is no single feature that makes a solution sovereign. For architecture work, I find it more useful to look at a few practical dimensions. Their importance depends on the solution and its criticality.

Control and Decision Rights

Who actually controls the solution? This includes ownership and governance, but also administrative identities, encryption keys, certificates, domains, source code, configurations, and deployment mechanisms.

Can the provider make critical changes independently? Could ownership or control of the provider change? Can the customer still access and operate its critical assets without the provider?

Formal ownership is not enough if practical control remains elsewhere. Owning your data on paper while depending entirely on someone else to access it is not a very useful form of ownership.

Data and Technology Independence

Critical data must remain accessible, understandable, and transferable. This includes not only business records, but where relevant also metadata, configurations, access rules, logs, and audit histories.

Technology matters as well. Documented interfaces, standards, modular structures, and replaceable components improve independence. Proprietary services and configurations increase dependency.

This does not make provider-specific technology automatically bad. Lock-in can be a reasonable tradeoff. Accidental lock-in is less impressive.

Operational Sovereignty and Exitability

A solution can be portable on paper while the organization remains unable to operate or move it.

Does the organization have the documentation, skills, backups, recovery procedures, and alternative arrangements needed to continue without the current provider? Could another provider realistically take over?

Exitability asks a very concrete question: Could we actually change the provider or technology if we had to?

A contractual exit clause or an export button does not answer that. Interfaces, identity services, integrations, networks, and other shared dependencies may make the real exit much harder. Therefore, exitability cuts across familiar architecture qualities such as portability, interoperability, recoverability, maintainability, and resilience.

Jurisdiction and Supply Chain

The organization also needs to know which jurisdictions apply to the provider, its parent company, subcontractors, data, and operations. Which authorities may compel access to data or restrict a service?

Data-center location alone does not answer that. GDPR compliance does not make the jurisdiction question disappear either.

The direct provider is only one layer. For instance, an European supplier may depend on non-European infrastructure, software, or support. Provider nationality matters, but the whole dependency chain matters even more.

Security and Continuity of Control

Finally, sovereignty also concerns who controls security and continuity. Who can access logs, respond to incidents, apply critical patches, restore the environment, or revoke access?

Security and sovereignty overlap, but they are not the same thing. A secure service can still create a dependency that the customer cannot control.

The common thread across all these dimensions is therefore quite simple: who controls what, which dependencies matter, and how much ability the organization retains to act when circumstances change.

Great, Another Framework

The European Commission’s Cloud Sovereignty Framework provides a broad view on the topic, covering strategic, legal, data, operational, and other dimensions. It is a useful tool that shows sovereignty is more complex than just data center location or provider ownership. It offers a systematic way to analyze control and dependencies.

However, I would be careful not to put every desirable technology property under the title of sovereignty. Important topics like privacy, security, and sustainability have their own specific goals and methods. A solution can be secure but not sovereign, or environmentally friendly but difficult to replace.

When every positive quality is called sovereignty, the concept becomes too broad and starts to cover all of EA. It is better to use sovereignty frameworks as a source of questions and assessment criteria, not as a reason to rename every existing architecture concern.

What Should an Enterprise Architect Do?

Enterprise architects are unlikely to negotiate every supplier clause, configure encryption keys, or write migration scripts. Their role is rather to make important dependencies visible and ensure they are considered in decisions.

A useful starting point is the existing architecture. Which critical capabilities depend on which applications and platforms? Which providers are behind them? Where do several critical capabilities depend on the same company, identity service, cloud platform, or infrastructure component? What would happen if one of those dependencies disappeared or changed substantially?

Existing EA content can provide much of the needed structure. They can reveal concentrations and dependencies that are difficult to see from individual projects—assuming, of course, that the organization has invested in keeping it comprehensive and reasonably up to date.

There is no need to build a separate sovereignty repository containing thousands of new elements. A dependency view, a few additional attributes, and perhaps a heatmap may be much more useful.

For example, applications or platforms could be assessed based on criticality, provider concentration, applicable jurisdiction, data portability, technology portability or operational dependency. Exitability could then be visualized directly on an application map, for example with a simple heatmap.

Architecture principles can also turn the topic into something actionable. For example:

• Critical capabilities should have a level of technological independence proportionate to their business impact.

• Important provider-specific dependencies should be visible and consciously accepted.

• Critical data and configurations should be accessible in a usable form.

• Jurisdiction and supply-chain dependencies should be considered in important technology choices.

• Exit costs, duration, and operational impact should be understood before committing to strategic platforms.

• High-impact recovery or exit arrangements should be tested when appropriate.

The exact requirements naturally depend on the organization and solution. A small internal survey tool does not need the same level of sovereignty as a payment platform, healthcare system, or national infrastructure service. Maximum sovereignty everywhere would be enormously expensive and probably counterproductive.

Some dependencies are perfectly acceptable. Some need safeguards. A few may be important enough to avoid altogether. The architect’s job is to help tell the difference.

Sovereignty as an Architecture Quality

For enterprise architects, digital sovereignty can seem like a new topic. It looks like it comes from regulation, geopolitics, and procurement. In practice, a lot of it is already familiar.

Architecture has always been about structures and how things depend on each other. We already check qualities like resilience, interoperability, portability, security, ownership, lifecycle, risks, and criticality. Sovereignty gives us a new reason to look at these same structures. It also adds a few more questions about control, laws, and depending on outside help.

So, it is more useful to see sovereignty as a quality or a capability of the architecture. It is not just a box to check in a procurement paper.

A part of it is technical.
A part is about operations.
A part is about the organization.
A part is about contracts and laws.

None of these views is enough alone.

The goal is not to buy everything from Europe. The goal is also not to build a digital fortress that is cut off from the world. From my European view, it is a good idea to have fewer critical dependencies. It can also be good to use great global technologies, if the dependency is understood and acceptable.

The goal is to protect the organization’s power to act. And a good, practical test for that is exitability.

If it is possible in theory to change a critical provider, but nobody knows how long it will take or how much it will cost, there is a problem. If nobody knows what data will be left, or if work can continue, then the organization has less control than it probably thinks it has.

🔗 You May Also Like

Are you looking to dive deeper? Here are some related articles you might find useful:

👨‍💻 About the Author

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

Follow him elsewhere: Homepage | LinkedIn | Substack (expert work) | 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 strategy, change, and delivery.

Apparently, the sensible way to return to enterprise architecture (EA) is to ask one of its least simple questions:

What is EA, actually?

The question keeps coming up in articles, frameworks, client discussions, and architecture communities. I also see it regularly in the comments on my LinkedIn posts. There is no shortage of definitions for EA. The problem is that people understand it in different ways, and you can often deduce what they mean only from the rest of the discussion.

However, many of these disagreements are not really about EA itself. They are about its scope. People use the same term for different things and then wonder why the discussion goes nowhere.

The problem begins with the word architecture.

When we talk about a building, architecture usually means the structure and design of the building. It is related to architects, drawings, methods, reviews, and construction, but they are not all called architecture.

With EA, we are less disciplined. The term may refer to the actual structure of the organization, descriptions of that structure, the discipline of designing and maintaining it, the organizational function responsible for the work, or the profession.

In my own books and publications, I have focused mainly on the latter four. Ross, Weill, and Robertson take a broader view in Enterprise Architecture as Strategy, which I am currently rereading, and discuss the actual architecture of the enterprise. That also explains why almost anything can be linked to EA online: if EA means the structure of the whole organization, the umbrella becomes rather large.

The meanings are connected. But they are still different, and separating them is useful before deciding what EA should cover.

Five Meanings of Enterprise Architecture

First, an organization has an architecture regardless of whether anyone has formally modeled it or not. Its capabilities, processes, information, applications, technologies, products, services, and business units exist in specific arrangements and depend upon one another. Some parts of this structure have been deliberately designed. A significant portion, however, has accumulated over time through projects, acquisitions, reorganizations, and temporary workarounds that have persisted despite best efforts.

Second, EA represents a professional discipline. It establishes and utilizes a structured understanding of the organization to guide planning, decisions, and change. This systematic view helps determine what to modify, standardize, retire, or invest in—and clarifies what other areas may be impacted by those decisions.

Third, EA refers to a set of descriptions and models. These documents illustrate the primary structures and relationships at a logical, organization-wide level. They are concrete enough to inform strategic decisions, yet they avoid the high level of detail required to document individual process steps, database fields, or server configurations.

Fourth, EA functions as an organizational practice. Enterprise architects maintain shared viewpoints, support project and portfolio decisions, facilitate collaborative planning, identify critical dependencies, and prevent different business units from solving identical problems in mutually incompatible ways.

Fifth, EA is a distinct profession. Enterprise architects require an uncommon combination of modeling skills, facilitation, analytical thinking, communication, and organizational dynamics. While the job title may not be so rare, the core work is typically conducted by a relatively small group of specialists.

All five interpretations are valid. Difficulties arise only when people discuss them as if they represented the exact same concept.

The actual architecture of an organization can encompass virtually everything. The only limit is your definition of what architecture or structure means in this context. However, the discipline, the documentation, the organizational function, and the profession should have boundaries. No organization has access to unlimited architects, time, funding, or patience—even though certain organizations and practitioners occasionally conduct themselves as if there is no such limits.

Enterprise Architecture Needs Boundaries

EA should cover the structures and dependencies needed to manage organization-wide change on a high level. Broad, yes. Everything, no.

The boundary has two parts: what the EA function does and what EA descriptions include. Without this distinction, EA tends to expand until nobody can maintain it—or explain why it exists in the first place.

Scope of the Enterprise Architecture Function

The EA function connects strategy, business development, portfolio management, projects, IT, data, security, and operations. The work is not mainly about producing descriptions. Architects support planning, facilitate discussions, bring the right people together, structure difficult questions, and help decision-makers understand the wider effects of their choices.

In practice, this may mean facilitating target-state planning, supporting project preparation, clarifying scope and dependencies, comparing solution options, or helping a management team turn a rather general strategic objective into something that can actually be implemented. Good architects often spend as much time asking questions, challenging assumptions, and building shared understanding as they spend modeling.

The EA function does not replace other functions. Strategy teams formulate strategy, process owners develop processes, solution architects design solutions, and engineers implement them. EA supports their work by providing context, shared principles, architectural knowledge, and a neutral view across organizational boundaries. In other words, enterprise architects may guide and connect activities across the TOGAF ADM cycle, but they are not responsible for performing all the work that the cycle touches.

The function should focus on areas where an organization-wide view and architectural support add value: major investments, cross-functional changes, shared information and platforms, lifecycle questions, and decisions with long-term consequences. Its role is to provide the basis, bring people around the same table, and help them choose a sensible route—not to control everything.

Scope of Enterprise Architecture Descriptions

EA descriptions show the main structures and relationships needed for planning and decisions. Typical content includes capabilities, processes, information, applications, technologies, initiatives, and the connections between them.

The descriptions should be coarse but concrete. Detailed workflows, solution designs, data models, technical specifications, security controls, and operating instructions belong mainly to their respective disciplines. EA may connect to them without copying everything into one heroic repository.

Descriptions can also become too abstract. A diagram filled with Digital Business, Customer Centricity, and Future Capabilities may look impressive, but it gives little guidance for what should change.

The useful level sits between these extremes: enough detail for analysis, but simple enough to understand and maintain. The goal is not more diagrams. It is consistent information that can be reused in real decisions. Coarse but concrete.

Dependencies Are the Main Point

A list of applications is useful, as are process and capability maps. But EA brings most value when two things come together: an enterprise-level view and the relationships between the parts. Which capabilities depend on which applications? Where does important information move? Which technologies support critical services? Which initiatives affect the same parts of the organization? And where does a sensible local decision create cost or complexity somewhere else?

I have seen this many times, most recently in an organizational renewal project where architecture work brought together people from different functions and roles. The challenge was not to design the organizational structure. That was the easy part. We rather needed to agree on how the different roles and business units would work together in practice. By structuring the discussions and making the connections visible, we helped the group define a shared target state and a common operating model.

That is easy to underestimate. Without a common view, each function tends to design its own part—usually quite sensibly—while the gaps between the parts remain for someone else to solve.

Few other disciplines or functions look at both the whole organization and the dependencies across it. Process management usually focuses on processes, portfolio management on initiatives, and IT management on IT services. Each sees an important part of the picture. EA connects the parts and keeps the enterprise-level view.

This combination is one of the most specific contributions of EA, especially where no single owner has responsibility for the whole chain. Without it, the connections often remain in separate systems, documents, or in the heads of a few experienced people who somehow seem to know everything.

Enterprise Architecture Between Strategy, Operations, Development, and Technology

EA forms a cohesive layer between strategy, operations, development, and technology. It is an artifact that can build shared understanding between diverse stakeholders. If you want to sound fancy, you could even call it a boundary object.

At its best, it translates strategic objectives into implications for capabilities, processes, information, applications, and technologies. It gives portfolio management a common view of initiatives, provides solution architecture with context and principles, and helps operations understand the sources of cost, complexity, risk, and technical debt.

This connecting role is where EA earns its keep. It makes information from different functions understandable as one whole.

But EA still needs to remain selective. A model understood only by architects has failed in a very professional-looking way. The aim is not to remove organizational complexity, but to make it visible and useful in decisions.

So What Is Enterprise Architecture?

In practical terms, EA is a discipline, a logical-level description layer, an organizational practice, and a specialized profession.

It is selective rather than comprehensive. It does not include every architecture-related activity or the most detailed version of every description. And despite some determined attempts, it is not a universal architecture repository.

Its value comes from showing how things fit together, what depends on what, and what a planned change is likely to affect. That requires deliberate boundaries: what the EA function does, what its descriptions cover, what belongs elsewhere, and where the organization-wide view adds value.

Clear boundaries do not weaken EA. They make it usable.

📰 A Small Publishing Update for This Substack

I am changing from weekly posts to one about every two weeks.

No, I am not running out of ideas for EA posts. It is simply because these topics usually need a bit more time. I hope the new publishing rhythm will be better for both the quality of posts and the sustainability of this newsletter.

So, there will be fewer posts, but hopefully they will be a bit more thought through.

🔗 You May Also Like

Are you looking to dive deeper? Here are some related 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 (expert work) | 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 strategy, change, and delivery.

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

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

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

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

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

1. Are the Open Architecture Issues Clear?

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

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

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

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

2. Are All Relevant Initiatives Supported?

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

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

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

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

3. Are Architecture Decisions Clear?

Architecture decisions have a habit of becoming blurry.

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

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

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

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

4. Does Every Architecture Task Have an Owner?

Architecture work often fails between meetings.

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

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

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

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

5. Are Escalation Paths Clear?

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

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

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

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

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

6. Are Architecture Descriptions Usable Without Their Author?

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

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

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

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

7. Is the Autumn Pipeline Visible?

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

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

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

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

Leave the Architecture Function in a Usable State

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

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

That is already a lot.

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

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

🏖️ A Short Summer Break

I will also take a short summer break from publishing.

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

Have a good summer!

🔗 You May Also Like

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

👨‍💻 About the Author

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

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

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

Web resources: Enterprise Architecture Info Package (FI)

📬 Want More Practical Enterprise Architecture Content?

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

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

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

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

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

Why We Use Jargon

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

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

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

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

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

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

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

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

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

Why Jargon Becomes a Problem

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

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

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

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

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

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

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

Speak So People Can Use It

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

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

The same architecture insight can be expressed in different ways.

An architect might say:

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

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

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

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

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

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

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

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

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

The Point Is Not to Sound Less Like an Architect

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

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

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

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

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

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

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

🔗 You May Also Like

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

👨‍💻 About the Author

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

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

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

Web resources: Enterprise Architecture Info Package (FI)

📬 Want More Practical Enterprise Architecture Content?

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

Who owns EA?

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

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

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

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

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

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

When Ownership Is Missing

EA does not disappear when ownership is unclear.

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

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

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

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

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

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

Three Types of Enterprise Architecture Ownership

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

Architecture Work Needs an Owner

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

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

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

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

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

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

Deliverables Also Need Ownership

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

A deliverable needs at least four kinds of clarity.

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

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

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

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

The Real Architecture Is Not a Deliverable

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

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

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

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

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

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

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

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

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

Consultants Can Support, But Not Own

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

But consultants cannot fully own EA for the client.

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

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

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

A Practical Ownership Model

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

A more realistic model separates the different types of ownership.

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

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

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

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

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

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

Ownership Makes Enterprise Architecture Real

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

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

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

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

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

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

🔗 You May Also Like

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

👨‍💻 About the Author

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

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

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

Web resources: Enterprise Architecture Info Package (FI)

📬 Want More Practical Enterprise Architecture Content?

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

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

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

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

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

Continuity and Comparison

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

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

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

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

The consultant usually brings a different advantage: comparison.

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

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

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

Mandate and Access

Internal architects and consultants often have different access patterns.

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

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

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

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

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

Focus and Context

There is also a practical difference in daily work.

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

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

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

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

Value Looks Different From Each Side

The value of internal architecture work is often indirect.

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

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

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

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

Living With the Consequences

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

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

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

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

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

A Career Perspective

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

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

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

Architecture Ownership Cannot Be Fully Outsourced

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

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

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

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

Working Together

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

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

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

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

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

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

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

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

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

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

If you read Finnish, the post is here:

Kun kaikki tärkeä ei mahdu samaan viikkoon

🔗 You May Also Like

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

👨‍💻 About the Author

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

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

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

Web resources: Enterprise Architecture Info Package (FI)

📬 Want More Practical Enterprise Architecture Content?

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

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

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

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

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

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

What does this change actually affect?

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

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

What Is Actually Changing?

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

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

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

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

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

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

What Dependencies Are Already Visible?

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

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

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

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

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

What Decisions Would Be Expensive to Reverse?

Not every decision deserves the same level of architectural attention.

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

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

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

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

What Should a Good Early Architecture Diagram Show?

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

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

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

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

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

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

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

Closing Thought

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

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

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

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

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

What does this change affect?

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

🔗 You May Also Like

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

👨‍💻 About the Author

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

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

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

Web resources: Enterprise Architecture Info Package (FI)

📬 Want More Practical Enterprise Architecture Content?

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

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

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

Unfortunately, organizations do not work like that.

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

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

The Basic Principle: Proportional Architecture

EA should not be applied with the same intensity everywhere.

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

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

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

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

Both create problems.

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

Where More Architecture Is Justified

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

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

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

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

Dependencies are where many surprises live.

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

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

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

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

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

When Lightweight Architecture Is Enough

Not every change needs a full architecture process.

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

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

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

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

Lightweight does not mean careless. It means proportionate.

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

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

A Practical Way to Decide

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

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

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

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

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

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

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

• How reversible is the decision?

• Does it create a foundation for future work?

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

• Could multiple initiatives solve the same problem differently?

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

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

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

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

Closing Thought

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

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

The aim is not to make everything architectural.

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

🔗 You May Also Like

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

👨‍💻 About the Author

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

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

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

Web resources: Enterprise Architecture Info Package (FI)

📬 Want More Practical Enterprise Architecture Content?

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

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

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

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

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

My answer is usually no.

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

Executives usually do not wake up thinking:

“We urgently need better metamodel governance.”

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

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

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

Frameworks Are Internal Tools, Not Business Value

Frameworks and methods are primarily internal tools for architecture work.

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

But frameworks are not business outcomes.

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

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

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

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

Why Framework-First Positioning Often Fails

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

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

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

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

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

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

Leadership Usually Experiences Structural Problems, Not Architecture Problems

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

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

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

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

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

Why Architects Gravitate Toward Frameworks

Framework-oriented thinking persists for understandable reasons.

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

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

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

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

A More Effective Way to Position Enterprise Architecture

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

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

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

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

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

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

Closing Thought

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

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

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

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

Leadership rarely buys frameworks. It buys better organizational outcomes.

🔗 You May Also Like

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

👨‍💻 About the Author

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

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

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

Web resources: Enterprise Architecture Info Package (FI)

📬 Want More Practical Enterprise Architecture Content?

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

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

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

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

Contexts Where Enterprise Architecture Adds the Most Value

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

Strategic Planning, Strategy Execution and Portfolio Prioritization

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

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

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

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

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

Major Project, Program and Capability Preparation

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

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

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

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

Large Structural and Operating Model Changes

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

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

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

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

Cross-Organizational and Ecosystem Coordination

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

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

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

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

Regulatory, Risk, Security and Compliance-Driven Change

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

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

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

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

Long-Term Platform, Data and Integration Decisions

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

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

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

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

Reuse, Standardization and Organizational Memory

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

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

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

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

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

When Architecture Adds Less Value

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

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

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

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

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

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

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

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

Closing Thought

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

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

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

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

🔗 You May Also Like

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

👨‍💻 About the Author

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

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

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

Web resources: Enterprise Architecture Info Package (FI)

📬 Want More Practical Enterprise Architecture Content?

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

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

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

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

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

That is architecture theater.

When Enterprise Architecture Practices Become Theater

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

Architecture Defined Through Activity

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

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

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

Architects keep busy, even when their impact is limited.

Governance Without Real Influence

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

The key question is whether the process changes anything.

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

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

Required Deliverables Without Purpose

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

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

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

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

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

Optimizing the Practice Instead of the Outcome

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

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

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

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

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

Architecture Disconnected from Planning and Delivery

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

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

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

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

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

Why This Happens in Practice

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

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

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

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

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

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

Where Architecture Actually Creates Value

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

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

A few simple questions can help make this visible:

• What is the intended purpose of this architecture work?

• When was this architecture work last used?

• Where does architecture actually change decisions?

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

• Which stakeholders actively use architecture in their work?

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

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

Closing Thought

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

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

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

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

🔗 You May Also Like

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

👨‍💻 About the Author

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

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

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

Web resources: Enterprise Architecture Info Package (FI)

📬 Want More Practical Enterprise Architecture Content?

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

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

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

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

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

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

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

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

Why Shadow IT Persists

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

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

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

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

When Local Solutions Become Structural

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

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

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

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

Typical Structural Risks

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

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

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

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

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

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

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

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

How Enterprise Architecture Can Help

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

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

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

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

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

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

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

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

Shadow IT as Early Architecture Signal

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

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

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

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

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

Closing Thought

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

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

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

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

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

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

📕Further Reading: Where My Writing Career Started

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

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

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

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

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

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

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

🔗 You May Also Like

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

👨‍💻 About the Author

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

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

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

Web resources: Enterprise Architecture Info Package (FI)

📬 Want More Practical Enterprise Architecture Content?

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

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

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

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

Where The Effects Typically Appear

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

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

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

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

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

Typical Structural Costs Of Missing Architecture

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

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

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

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

Repeated Work and Rediscovery

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

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

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

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

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

Repeated Conceptual Alignment and Boundary Decisions

Organizations often revisit similar structural questions across initiatives:

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

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

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

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

Duplicate Solutions And Parallel Capabilities

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

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

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

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

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

Increasing Integration Complexity

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

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

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

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

The cost appears as slower change and increased coordination effort.

Fragmented Technology Portfolio

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

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

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

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

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

Misaligned Application Choices

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

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

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

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

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

Structural Consequences in Larger Changes

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

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

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

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

Closing Thought: The Cost Of Change Depends On Structure

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

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

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

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

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

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

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

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

🧩 A Structural Perspective On Expert Value

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

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

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

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

• The Senior Expert Pay Playbook

• The Senior Expert Career Playbook

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

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

Launch discount codes:

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

🔗 You May Also Like

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

👨‍💻 About the Author

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

Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
Web resources: Enterprise Architecture Info Package (FI)

📬 Want More Practical Enterprise Architecture Content?

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