Analysis: Differences and relationships between BPM and SOA

The discussion on the relationship between business process management (BPM) and Service-Oriented Architecture (SOA) is very lively. The two have also been a hot topic for many years. However, discussions about them usually appear in irrelevant forums, and the people who discuss them usually belong to different circles. However, this situation is changing as the two concepts and the users and providers of related technologies are increasingly looking at them together.

The BPM camp usually claims that SOA is not necessary for BPM implementation. You only need to deploy a BPM suite to achieve your goals faster without increasing complexity. The SOA camp focuses on solving the complexity of enterprise it in the general sense. This camp usually claims that BPM is a feature of SOA, but it is part of the SOA solution, rather than a separate thing. When people in the SOA field talk about bpm, this term is usually synonymous with service orchestration or process integration, without emphasizing friendly modeling or human interaction for business analysts, the latter is very important to the BPM camp.

To clarify these misunderstandings, I think it is necessary to clarify the different nature of BPM and SOA: SOA is an architectural approach; BPM is a group of coordination activities.

Therefore, you can easily obtain BPM that uses SOA or does not use SOA, and vice versa. Let's take a look at the advantages of different combinations.

If you deploy a BPM suite that does not use SOA, you can quickly create, execute, and monitor/manage business processes. The business process model can be created by the business analysts, but its complete implementation requires integration with the underlying it system (and how users interact with the process, but we will not consider it now ). BPM suites (such as BEA's AquaLogic BPM suite) Support applications using a variety of technologies (service-oriented or not service-oriented)ProgramAnd databases for easy access. ImplementationCodeAnd metadata from and dependent on the underlying system interface. Therefore, any changes to the underlying database and application will lead to changes to the business process.

If the Organization and IT environment are relatively small and the same group of people control all systems (including BPM suites), this is all right. This method also works well if the underlying system does not change at all.

However, if the BPM suite is deployed by one group and consumes services from the system of the other group, it will become very difficult to coordinate and manage the change tasks in each group quickly. This is a typical issue to be solved by SOA. Therefore, SOA can be applied to the deployment of BPM suites, just as it is applied elsewhere.

If BPM is deployed as part of SOA, this means that when a business flow is connected to the underlying system, it is connected to the proxy service provided by the Enterprise Service Bus, this hides the complexity of underlying applications and databases. This has the following advantages:

It is easier to connect a business flow to a system because it can publish more useful interfaces, such as aggregated data services or services that use standard protocols rather than proprietary protocols. This reduces the IT workload required to implement the process and allows process personnel to focus on the process, rather than sticking the process to the technology required by the underlying system.

It makes the implementation more robust, because changes to the underlying it system do not have to affect the interfaces used by the process.

It provides independent control and management beyond the BPM suite. This allows IT teams to better manage the policies and resources of the services they own and maintain.

SOA also supports better visibility into the systems it connects to from the BPM suite. The IT team can register the service in the service registration database. Process developers (or even business analysts) can browse such registration databases when building the process. This ensures that the service can be correctly used and reused, and generally simplifies the business process, because using the right service can minimize the complexity of the process itself.

Undoubtedly, these advantages can only be revealed when the IT infrastructure is complex enough and/or the BPM project reaches a certain scope and scale. Therefore, in many cases, BPM should be developed first, while SOA components should be considered later.

The best way is to maintain a good dialogue between the Business Operation Team and the IT Enterprise Architecture team from the beginning, plan for the future, and support tactical execution. This requires a correct combination of products. For example, it is important that the BPM suite itself provide a wide range of connectivity so that you do not need to fully apply a complete SOA to make BPM run. Similarly, BPM suites should support SOA so that BPM and SOA do not exist in Independent Silos. This is also important.