Mapping Business Process Concepts to BPUA
The "Introduction into Business Process" chapter defines the language of the business process concepts. BPUA defines the software structure that implements that language.
This page connects those two layers directly by showing how each major business process concept appears inside BPUA-based software.
Without this mapping, business process theory can remain disconnected from implementation. Architects may speak about states, transitions, and subprocesses while developers are asked to build pages, controllers, and CRUD endpoints. The vocabulary changes, and the business process disappears inside technical layers.
BPUA avoids that loss of meaning. It preserves the business process vocabulary all the way into the software structure. The same ideas introduced in the conceptual chapter remain visible in the runtime architecture.
This continuity is one of the most important strengths of BPUA. The business analyst, architect, and developer can all talk about the same thing: current process state, valid transitions, required context, and the logic that must run during the transition.
Instead of translating business process concepts into unrelated technical artifacts, BPUA keeps the software aligned with the process itself.
| Business Process Concept | Meaning in the Conceptual Model | BPUA Architectural Form |
|---|---|---|
| Business Process | A bounded business flow that moves from an initial situation to a business outcome. | Collection of Business Process Units (one per use case) |
| Business Subprocess | Use case — a manageable portion of a larger business process. | A Business Process Unit that owns the execution of the use case. |
| State | The current business situation of the process. | The current process state owned by the Business Process Unit and represented through its transition context. |
| Transition (Business Process Activities) | A controlled move from one business state to another. | Pipeline of Transition Handlers. |
| Finite State Machine | A formal model where valid transitions depend on the current state. | State-aware routing that determines which transitions are valid and which handler must execute them. |
| State Logic | Process of selecting a state handler for the current business process state. | Logic that resolves the current business process state to its corresponding State Handler. |
| Business Logic | Applies rules and decisions that determine the business outcome. | Business Logic Handler that determines the target state of the transition. |
| Data Processing Logic | Transforms raw data into decision-ready information. | Data Processing Logic Handler that manages transformations applied to the transition context. |
| Data Access Logic | Loads and saves process data. | Data Access Logic Handler, which manages persistence steps. |
| Transition Context | The complete information required to execute the transition correctly. | A structured context container, such as POCO DataSet, carrying business data and metadata. |
| Observable State | The visible process state presented to the user. | An observation layer that reflects the owned execution state without replacing it. |
BPUA is not a separate idea added after business process analysis is complete.
It is the architectural form taken by the concepts introduced in the business process chapter.
Business Process Units, transition handlers, structured context containers, and observation layers are not arbitrary design choices. They are the software expressions of business processes, states, transitions, and activity pipelines.
Table of Content Previous: From Business Process to Execution Architecture
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.