This is my first installment into the BPM and SOA Synergy topic. There are many resources discussing this topic and one would expect that most important issues are well understood and described. However, some key concepts are often presented in a way that leaves a room for interpretation and, therefore, may cause confusion. This is the case with the role some resources give to processes in the context of SOA Reference Architecture. For example, the below diagram is used in the Open Group’s draft of the SOA Reference Architecture.
According to this diagram services are orchestrated by Business Processes which in turn are driven by Consumer Interfaces. Services are implemented by business components that are accessing Operational Systems. Alternatively, Services can be directly driven by Consumer Interfaces and themselves can directly access Operational Systems. All these connections are shown in the above diagram as white dashed links.
This model definitely makes sense, however, with the caveat that some services are not directly implemented by components but are implemented as processes orchestrating other services – see the red arrow (added by VK) in the diagram below.
Further analysis of the modified diagram tells us that there are two distinct roles that processes are playing in the SOA architecture:
a) Business Processes– human-centric asynchronous long-lasting Business Process with human UI activities (Consumer Interfaces) that are invoking services using their service activities
b) Service Orchestrations – synchronous non-human transaction–like processes that orchestrating services and they are wrapped by stateless services.
These roles are not explicitly shown in the Open Groups diagram. Therefore, additional knowledge (above and beyond explained in the diagram) in order to understand the difference between architecture, implementation, deployment and operational aspects for these two process roles.
The below diagram illustrates the SOA architecture in a way that explains the difference between two different roles of processes.
The difference between BPM and SOA is more significant that it may appear first. They require different definition languages and different tools. The first type is best defined using a now standard business-like language – BPMN. It is best implemented using BPMS tools (.e.g. Pega, IBM Lombardi, Appian, etc.). The second type is traditionally defined with BPEL and implemented using a BPEL language. These are important distinctions that imply need in different skills (BPMN vs. BPEL) and procurement of different tools (BPMS vs. BPEL engine).
The organizations that do not have comprehensive technology guidance may commit to misusing tools (e.g. using BPMN/BPMS for services orchestration) that reduces quality of solutions (e.g. performance characteristics) and increases their costs.One of the ways to prevent this from happening is establishing SOA and BPM Centers of Excellence that would educate and recommend methodologies, architecture patterns and tools that would fit purposes of the organization.
Please stay tuned for the next installment into the BPM and SOA Synergy topic.
