Business Process Composition
From ViaNovaArchitecturaWiki
- This pattern has been originally described in the article “Architecture Patterns for Enterprise-wide SOA” [Cace, 2008][1]
Figure 1 Sample insurance claim process depicted in ArchiMate [Lankhorst, 2004]
Contents |
Context
… Flexibility in modifying an organization’s processes is a tenet of business agility. This can be best achieved by separating the process flow from the business logic. This pattern also completes the Multi-channel Bridging by providing entry-points to business service delivery –automated processes are exposed as services to channel applications.
Problem, Forces and Tensions
Automating a business process without a means to keep the process modifiable hampers the agility of the business.
There is a continuous evolution in automating information-intensive business processes. The classical, monolithic information systems provide the necessary functionality but are not adaptive to changes. New business requirements typically require programming changes in software which consequently lead to a variety of software maintenance problems. The time-to-market is unsatisfactory and the risks involved may become unjustifiably high. A way to deal with this problem is to identify and separate the stable processing elements from those that are predisposed to change. The assumption is that the changes in business requirements are mostly related to just a limited number of services and the process flow.
Following this line of thought, business processes should be automated in a way that separates services (that, in general, tend to remain stable) from the process flow which needs to be adaptable. The implementation of a process flow then consists of a number of service execution steps invoked according to the pre-defined sequential process logic.
The idea of automating business processing in explicit processing steps is neither new nor directly related to some new, ‘SOA’ way of looking at enterprise architecture; document workflow has existed for many years, although focused on organizing and coordinating human work. However, the continuous trend towards automating routine-cognitive human work has opened new possibilities. Some well defined units of information-processing can be exposed as services and those services can be orchestrated into a complete business process. This entire ‘orchestration’ is also a service; most typically processes automated in this way are initiated by invoking an operation of the service.
Although this ‘process composition’ appears conceptually simple, its implementation requires a professional product (for example based on the open standard WS-BPEL). Orchestrating services means integrating independent services. This involves issues like waiting for currently unavailable services, compensating transactions, waiting for long-lived transactions and so on. All these issues have been addressed in the so called BPM-engines and no enterprise should attempt custom-made solutions. There are multiple additional benefits of the appropriate tooling. The operational business intelligence (BAM - Business Activity Monitoring) and other Business Process Management facilities are commonly provided ‘out of the box’ as a part of the product.
The human workflow (In this I refer to any human contribution to process execution, disregarding the implementation option: a workflow package, a portal solution or a 3GL application.) must also be considered in this solution. Few of the processes are entirely automated for a variety of reasons. It may be that there are special cases that cannot be automated or there may be legal constraints that demand human involvement. Human workflow imposes additional requirements on Business Process Management. Firstly, it is necessary to be able to allocate and distribute units of work to the appropriate human agents. Secondly, it is necessary to be able to ensure that each process instance is completed within an acceptable time.
There are two available options:
- The human involvement may be supported in the same BPM engine as the rest of the orchestration
- A (possibly already existing) workflow solution can be exposed as a service and invoked by top level orchestration.
It has to be noted that this BUSINESS PROCESS COMPOSITION pattern is far from simple to apply. Gartner [Gartner, 2007] says about this:
“The BPM-style pattern of SOA use is an advanced case of SOA. It requires an advanced level of maturity in the organization regarding:
- The management of service registries and metadata repositories
- The underlying middleware and quality of services
- The coordination of service releases and version control. ”
Moreover, some business process composition attempts have led to disastrous pseudo SOA implementations, probably due to gross, but unfortunately widespread misunderstandings of service orientation. Those situations apparently reiterate and are also described as anti-patterns. The so called POA (Process Oriented Architecture) is described in Steve Jones’ ‘SOA anti-patterns’ [Jones, 2006]. Some ‘dos and don’ts’ of POA related to the ignorance of the elementary aspects of architecture and SOA in particular are summarized here:
- ‘Grand designs’ do not work; enterprise architecture should envisage an adaptive, self-growing ‘system-of-systems’.
- Business process composition is about business; BPM tooling can only solve a recognized business problem. If a business problem is only recognized by IT people, then to introduce SOA and BPM on a large scale could create huge problems.
- If analysis shows that a business problem should be solved without BPM and/or SOA, do not misuse those; just leave out what’s not applicable.
- Operation of a service should expose well defined and coarse business functionality (CRUD services are usually a bad idea [Microsoft,2005])
However, the benefits of composing services into business processing are obvious. Gartner [Gartner, 2007a] states: “SOA and flow management go hand-in-hand: flow management is an enabler for SOA, and SOA facilitates process integration through flow management.”
Therefore:
Solution
Improve business agility by automating information-intensive business processes via the orchestration of services. Use the appropriate tooling to implement these orchestrations.
Figure 2 Process orchestration in the context of multi-channeling
Resulting Context and Consequences
{needs editing}
Expose process orchestrations as services too. Implement these orchestrations in a professional, ‘off-the-shelf’ tool.
When invoking transactional operations from orchestrations, use reliable-messaging in order to ensure transactional integrity between the Business Process Management software and the invoked service. Alternatively, consider modeling those operations to be idempotent (see Pattern #2: Idempotent Message in [Microsoft, 2005]).
(Transactional operation is an operation of a service that may result in a database update on the service provider side. In SOA, one should not use a distributed transaction monitor to synchronize this transaction with eventual other transactions of the service consumer. Instead, a compensating approach should be used.)
Access to enterprise data can be improved by Enterprise Data Retrieval Services and possibly by Replication in the Middle and Composite Retrieval Services.
The use of Business Process Management software makes it a challenge to implement new versions of a process definition in such a way as to enable current process instances to procede using the new definitions where that is appropriate. That's something you should think about before implementing the process design.
The use of Business Process Management requires careful management of the way in which application data and metaprocess information within the BPM environment together map to the real world. It is normally far from trivial to design the applications and the service which they provide in such a way as to be able to freely adapt process flow without compromising the logical integrity of the BPM and services as a whole.
Even the most simple process designs soon become complicated when their logic goes beyond the basic process flow in order to cater for all the things that can go wrong. For example, if every step of a process needs to check whether the citizen has withdrawn his application, died and/or moved interstate, and then take appropriate action, you will end up with a process design so complicated that it will become almost impossible to update. In general it is better practice to make each service responsible for checking that the preconditions under which it can be invoked are satisfied.
Examples
{Example(s) of applying the pattern.}
Example {company name or another reference}
Example {company name or another reference}
References
- [Alexander, 1977] C. Alexander et al, “A Pattern Language”, Oxford University Press, 1977
- [Cace, 2008] B. Cace, “Architecture Patterns for Enterprise-wide SOA”, Via Nova Architectura, 2008[2]
- [Gartner, 2007] Y. Natis, “Applied SOA: Transforming Fundamental Principles Into Best Practices”, Gartner Research Note Id G00147098, 4 April 2007, [3]
- [Gartner, 2007a] M. Pezzini, “Flow Management in SOA: One Size Doesn't Fit All”, Gartner Research Note Id G00150251, 23 August 2007, [4]
- [Jones, 2006] S. Jones, “SOA anti-patterns”, InfoQ, [5]
- [Lankhorst, 2004] M. Lankhorst, “ArchiMate – Integrating and Visualizing Architecture”, PowerPoint presentation) Telematica Institute, 2004
- [Microsoft, 2005] J. Evdemon, “Principles of Service Design: Service Patterns and Anti-Patterns”, MSDN, [6]
