From Business Process to Execution Architecture

Introduction

The pages of the "Introduction into Business Process" chapter explain what a business process is, how it is decomposed into subprocesses, how it is modeled, and how it evolves through states and transitions. Those pages established the business process conceptual model and introduced the essential ideas:

• A business process transforms an initial situation into a business outcome.
• Complex processes can be divided into subprocesses.
• Execution can be understood through finite state machine thinking.
• At runtime, a process moves through states and transitions.
• Each transition executes an ordered set of responsibilities described as a transition execution pipeline.
• The pipeline itself contains distinct kinds of logic such as state logic, business logic, data processing logic, and data access logic.

Once a business process is understood as a sequence of controlled transitions between business states, several architectural questions immediately appear:

• Where does the current business process state live?
• Which component is responsible for executing the transition?
• How is all required data delivered to the transition logic?
• How are edits, refresh, save, rollback, and recovery handled without losing correctness?
• How does the user interface observe the process state without becoming the owner of that state?

To answer these questions, a software execution architecture is required.

Why an Execution Architecture Is Required

A business process conceptual model can describe what should happen, but software must also define who owns state, who executes transitions, and how context moves through the system.

Without such an architecture, the process model may dissolve into pages, controllers, services, ORM tracking state, temporary caches, and ad-hoc conventions. The business process still exists conceptually, but its execution becomes fragmented and fragile.

Business Process Unit Architecture (BPUA) addresses this problem by giving executable software form to the business process concepts.

In BPUA, business processes are not implemented as scattered technical actions. Instead, they are composed from independent execution units corresponding to individual use cases. Each use case is executed inside a bounded context called a Business Process Unit. The unit owns the relevant process state, receives the transition request, executes the transition execution pipeline, and produces the next valid state of the process. The transition execution pipeline is implemented as a collection of components called Transition Handlers, each responsible for performing one step of the transition.

The relationship between the conceptual business process model and its software implementation can be summarized as follows:

Conceptual Model	Software Execution Model
Business Process	Collection of Business Process Units (one per use case)
Current State	Input Transition Context (representing the current process state)
Transition (Pipeline of Activities)	Pipeline of Transition Handlers
Target State	Output Transition Context (representing the updated process state)

Summary

The relationship between the two chapters of this book can be described simply:

• The "Introduction into Business Process" chapter explains the nature of business processes.
• The BPUA chapter explains how software can execute those business processes correctly over time.

In other words, the earlier chapter explains what a business process is, while BPUA explains how a software system should be structured to serve that process.

Table of Content Next: Mapping Business Process Concepts to BPUA

 

---

Business Process Programming in .Net
© 2004-2026 Laskarzhevsky Software Inc.
Unless otherwise noted, the content of this website is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0).
Code examples are provided under the MIT License.
You are free to share and adapt the material provided that appropriate credit is given and any modifications are clearly indicated.
The information provided on this website is for educational purposes only.
The author and publisher make no warranties regarding the completeness or suitability of the information and are not responsible for any damages resulting from its use.