What ever the tools and solutions used for BPM, it involves interactions with people and systems. Specially the process execution and monitoring phases have to interact heavily with the entities (i.e. people and systems) that perform actual tasks of the business process. For example, some where in the process, it may be required to query an inventory system to check the availability of an item. Or it may be required to get an approval from the branch manager to continue the process. So how does the process execution engine (in the process execution phase) communicate with these entities, which are outside the process engine itself. Let's ignore the interaction with the people part for the moment and focus on interactions with external systems (e.g. inventory system). Clearly, we need some interface from the system. But what should be the interface? Such external systems could provide some sort of interfaces to expose its functionality and data. But in some cases, it may not be the case and we may have to end up querying and updating files and databases of such systems. Either of these approaches are not good enough. Why? If we use the interfaces provided by different systems, we end up using large variety technologies and message formats in our deployments. Process execution engine may have to use RMI to communicate with the inventory system, file based communication method to communicate with CMS, some other messaging technology to interact with the HR system. This introduces enormous management and technological burden. Process engine has to understand all those communication technologies. It may have to use various plug-ins to support these different technologies. This is only one part of the problem. In addition, we have to deal with all the usual system to system integration problems as we are doing exactly a such integration here.
So, what is the role of SOA to play here? Well, system integration is what SOA is good at. And we have a big system integration problem in our hand. That is to integrate our BPM system (BPMS) with the existing and possibly new business systems. As the simplest solution, we can decide on set of services to be provided by such business systems. And implement those services using a suitable technology (preferably web services). Then it is a matter of invoking these services as required by the BPMS. We can decide on the required security level, message format, etc and make them common to all the services, thus reducing the burden of different communication methods.
We are not done yet. If you think of a typical system with a BPMS, you would find out that BPMS is one of the components that make most of the connections to other components of the system. So, use of an ESB would obviously help us here. We can use the pattern described here to minimize and manage the number of connections with the BPMS.
We can do even more with SOA. As the organizations grow larger and business processes become more complex, usually it is harder to capture all the steps of a process to a single model. Various organizational units may take different approaches for the (sub)processes and the modeler may not be aware of the details of such activities. And some departments could already have developed process models for some parts of the processes. This makes it obvious that it is better to let business units to define the processes that are most suitable to them and combine such sub-processes when it is required to develop a larger process involving many departments. Going inline with SOA, we can identify and expose sub-processes as services. Then invoke these services (thus executing the sub-process) from larger processes as required. This in turn creates a hierarchy of processes, and makes it possible to reuse existing processes.
As mentioned earlier, sometimes the interface provided by existing systems may not be sufficient for the BPMS. Specially, BAM solutions need to collect detailed information about the process execution. In such cases, we may have to query the databases and files of such systems. Again it would be much neater to wrap such data sources with data services and expose them as usual services. So the BPMS could simply invoke these services and the common concerns like authentication, authorization, message formats, etc are left to the SOA infrastructure.
Above diagram demonstrates above uses of SOA, in the context of BPM systems. Note that the use of three BPMS, each deploying one or more processes and exposing those processes as services. For example, BPMS3 may contain set of smaller processes, BPMS2 may contain set of smaller processes as well as set of composite processes integrating sub-processes of BPMS3 and BPMS2. And the BPMS1 may contain organization wide complex processes which extensively use the processes deployed in BPMS2 and BPMS3. As shown in the diagram, (authorized) external systems could also invoke these processes using the services they expose, thus creating cross-organizational business processes.
