Should Customers Be Involved in Enterprise Architecture?

Link: https://www.eatransformation.com/p/should-customers-be-involved-in-enterprise

From Enterprise Architecture Transformation: A Practical Guide

More than ten years ago, I attended a local evening event on enterprise architecture (EA). If I remember correctly, someone wanted to collect data for a scientific study from it, but I never heard anything about it since. Anyway, we moved around in small groups, stopping at different discussion points to talk about architecture and topics somewhere around it. One of the topics was customer-centric EA.

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.

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.