From Processes to Underlying Architecture and Back Again: Part 1

Most service problems do not start where customers notice them. They start earlier, inside the process that delivers the service. Delays, errors, and frustration usually trace back to a sequence of activities that did not work as intended.

Every service depends on such a sequence. Tasks need to be executed, systems need to respond, data needs to be available, and people need to hand work over at the right moment. When one of these elements fails, the service suffers, even if the issue is not immediately visible.

Improving a service, therefore, means understanding its process in detail. Improving the process means understanding why specific steps fail or slow down. That requires looking beyond what happens on the surface and examining the systems, applications, data, and roles that enable each activity.

This is exactly why Business Process Management (BPM) and Enterprise Architecture (EA) should work together. BPM helps you see what is happening and where things (might) go wrong, while EA helps you understand why they happen that way. Treating them separately limits what either can achieve.

In this blog post, we'll explore how you can start at the process level and dive deep into the underlying architecture. However, this is not a one-way street. In a follow-up blog post, we'll also look at the opposite direction: how you can start from the strategic level with EA and translate those insights into meaningful changes in your processes. 

Process improvement initiatives rarely start from a clear understanding of the problem. They usually begin when a situation becomes uncomfortable enough to demand attention. Work takes longer than expected, and teams start compensating in informal ways, making small adjustments to keep things moving. By the time the issue is discussed openly, the process has already absorbed the problem instead of addressing it.

That is where many improvement efforts lose direction. The focus shifts to what can be seen and measured quickly, even though the visible issue is often only the outcome of something else failing underneath. Treating that symptom as the problem may ease pressure temporarily, but it does not explain why the process behaves the way it does, and most importantly — does not prevent it from happening again.

An airport check-in process illustrates this well. Long queues are obvious, but they say very little on their own. The actual cause might sit in a single activity that no longer scales, a system response that varies depending on data quality, or a handover that introduces waiting time at peak hours. From the outside, all of these produce the same symptom, even though they require very different responses.

This is why BPM matters at this stage. Mapping the process forces assumptions out into the open. Tasks, handovers, and waiting time are no longer inferred from experience but shown explicitly. Once that happens, the discussion changes. Instead of debating impressions, teams can point to specific steps and ask why they behave the way they do. From there, people can decide where to intervene. The focus shifts away from broad changes or urgent reactions and toward the activity that actually causes delay or error.

BPM helps us identify the problem, but this is only the first part of the story. The next question is: how do we actually fix the issue? 

To answer that, we need to uncover what happens behind the scenes. Returning to the check-in example, a task that causes delays does not exist in isolation. It depends on applications, system software, data, interfaces, and the people who work with them. This network of interrelated objects can already tell us a lot. But we can dive even deeper.

Imagine we discover that a supporting application is the real issue. Then the next question becomes: why doesn't this application work as expected? Just like processes, applications also depend on a network of objects, such as interfaces, system software, and underlying platforms. If an application depends on a faulty interface or runs on outdated system software, it simply won't perform as expected. And this is exactly where Enterprise Architecture (EA) comes in. EA helps us to: 

• Model the entire architecture 

• See dependencies across systems and components 

• Identify critical points and weaknesses 

With this level of insight, we know exactly where the problem occurred and how to fix it. If the issue is a faulty interface, we fix the interface. If it's outdated system software, we replace it. This means we move from guessing to knowing, from general assumptions like "we need to improve this process" to concrete, actionable decisions such as "we need to fix the application supporting this task, and we will do that by addressing its interface."

When BPM and EA truly work together, the benefits become impossible to ignore. Leveraging tools that share a common repository elevates this collaboration to a whole new level. By enabling business process managers and enterprise architects to share their knowledge and collaborate, you get greater alignment, efficiency and insight. The following are only some of the key practical outcomes of integrating our BPM suite ADONIS with the EA suite ADOIT: 

BPM can show you where a process is breaking down, while EA reveals the architectural reason behind it. Combining the two not only saves your time in chasing the symptoms, but also enables you to quickly move from a visible process issue to an underlying application, interface, or data problem, dramatically reducing resolution time. 

Hint: See how process mining uses real business data to reveal hidden inefficiencies and improve processes based on evidence, not assumptions.

Using tools such as ADONIS and ADOIT for BPM and EA respectively, enables your business process owners and enterprise architects to work on a shared foundation. Because the two share a repository, insights from BPM become instantly actionable in EA and architectural changes are transparently reflected back in processes. This shared view bridges the gap between business and IT. 

Identifying a problem is the first step. Finding an actual issue is the second. Defining an actionable next step is the third. Using ADOIT Workspaces, you can define roadmaps, prioritize requirements, assign responsibilities, and track progress, all in the same place. This way, improvements are no longer just an idea — they become concrete, traceable actions with clear ownership. 

Finding the root cause of a problem rarely stops at a single issue. An application interface that fails for one component can affect others. This, in turn, can disrupt additional processes. EA makes these ripple effects visible, allowing people to anticipate risks and address weaknesses in applications, interfaces, or data before they cause larger disruptions.

When you understand the real root cause of a problem, investment decisions become much more focused. Resources can be directed exactly where they're needed and where they'll have the biggest impact. 

Solving root causes instead of symptoms leads to faster, more reliable and more consistent services. This, in turn, leads to better customer experience and increased customer satisfaction. 

Every service depends on a process, and every process relies on supporting infrastructure. BPM shows what happens in a process and where it slows down. EA reveals the systems, applications, and data that make each task work. Together, they let people identify exactly what needs to change and why. When BPM and EA use the same repository, process managers and architects can point to the same objects, understand dependencies, and act on real issues instead of assumptions.

Remember, this is only one side of the coin. In the next blog post, we'll explore how insights from the strategic level (EA) can be translated into changes at the operational level (BPM).