Classic question. Faced with a surge in acronyms, it is not always easy to really understand the challenges, especially when confusion is possible in their interdependence, in particular. In the domain that is of interest to us, the two symbols that recur most often seem to be BPM (Business Process Management) and SOA (Service Oriented Architecture). What is the relation between the two?


Without going into details, the BPM consists in formalizing and automating the business processes of the enterprise by including users and applications in the same processes. To do this, it is necessary to set up a software solution, on one hand by providing parameterization tools for the modeling and description of links in the process steps and on the other hand, an execution engine that will process each of the files initiated by users (front office agent, buyer…), by events (new mail, new XML file…) or by applications (API call, application message, web service…). The BPM software suite by default, provides the techniques necessary for handling these three “populations”, whether for starting a new file, processing a step, where each “participant” will bring value addition to the file during processing or access to an information system resource.


The SOA is a manner of designing, deploying and managing the software infrastructure where resources are formulated in the form of independent services accessible under a standardized format by persons and systems.


A service is a business task or a correctly defined and repeatable function that can be called in a standard manner. The nature of this function can be more or less broad. It can be a simple single task, such as updating the address of an employee or a more complex task involving several actions and a certain number of possible results.


The convergence between SOA and BPM seems to be relatively obvious; a process becomes a service composed of elementary services that are the process steps. Similarly, the process can be a standard consumer of information system services.


The joint approach of the BPM and SOA answers another problem, which is probably more complex: How to define the granularity of services, how to organize the re-engineering? In fact, implementing the SOA is the task of re-engineering the information system with the risk that it involves a tunnel effect if a certain number of operational or functional objectives are not fixed. The BPM experience shows that on streamlining their formalization, the setting up of processes results in the market to pursue for the gradual passage of applications to interface with an SOA architecture, as the BPM is essentially focused on business requirements.


Finally, this convergence will be beneficial only if we do not forget that the BPM is not a service or orchestration tool, rather a centralized approach to formalization of business processes and thus focused on the users’ requirements.