Process Orchestration Re-composition
How can process fragments be reused instead of duplicated if shared by multiple processes?
Process modeling groups together process-centric with process-agnostic logic which hinders the governance of the agnostic process parts. Ie. agnostic process fragments then get duplicated instead of reused across multiple processes which results in configuration management challenges, encapsulation in services and unnecessary duplicate work in general.
A process can be divided into meaningful agnostic and non-agnostic process parts. Agnostic process parts can be modeled as process fragments with an agnostic fragment goal, with certain inputs and outputs. A master process is designed to link and manage (recompose) the individual process fragments to reach the bigger master process goal. The agnostic process fragments can be centrally managed and reused in other processes.
Middleware platforms support is emerging to support necessary orchestration technology to support this pattern.
Modeling and design considerations similar to task services apply. Abstracting the parent process out, makes the parent process inherently dependent on the process fragments of which the parent process is comprised. The definition of each agnostic process fragment capability requires extra up-front analysis and design effort.
ArchitectureInventory, Composition, Orchestration
In larger organizations, the act of continuous process improvement is becoming a common act of business. The more mature an organization, the more shared business process fragments may be found in the organization. Typically, these agnostic business process fragments are reused in different agnostic master business processes.
Current process modeling methodologies use tooling which allows easy process orchestration design using graphical editor frameworks to model appropriate processes. When the need to repeat a certain process fragment arises, this is typically modeled over and over again wherever the agnostic process logic is required.
Issue with this approach is that instead of (re)using the agnostic process fragments, they are duplicated. Duplication of processes hinders governance, introduces configuration management challenges and increases the burden to manage the IT solution.
Figure 1 - Reused process fragments (highlighted) are commonly duplicated across multiple parent processes. This results in a physically decentralized process architecture.
Processes can internally have separation of concerns implemented. The master process can have non-agnostic macro process parts implemented delivering the actual overall business process.
Agnostic process fragment parts (delivering a certain agnostic business process goal) are separated into logical units to be used by one or more master processes, not necessarily limited to the same business unit or organizational unit. The master process is responsible for linking the individual process fragments to reach the intended larger overall business process goal. This should also allow for using the same process fragment multiple times or at separate occasions in the same process.
By centrally managing the agnostic process fragments, configuration management becomes less elaborate and the chances for proper governance are increased.
Figure 2 - The process fragments which must be shared by other processes are logically removed from the master processes and centrally located and governed. Note that these are not implemented as task services but reside inside the orchestration framework.
Middleware platforms support for the process orchestration re-composition is emerging. If no vendor tool or framework is used, a custom framework can be made to support this pattern, however this may again result in the implementation of task services. Contrary to the process centralization pattern which delegates to task services to facilitate reuse of business process logic, this pattern focuses on process fragment reuse inside the orchestration layer. Processes with a straight start-to-end unidirectional nature (goal based processes) ie. ordering and order fulfillment processing where process fragments do not properly belong to either specific process can benefit from this approach. Instead of re-implementing the same fragments in both processes, they are reused in the process orchestration management tooling.
Modeling and design considerations analogous to task service modeling and design apply. When the agnostic processes are separated from the process, this inherently makes the master process dependent on the process fragments from which it is comprised, resulting in a non-agnostic master process. This approach requires a different process design mindset and introduces extra up-front analysis and design effort.