BPM and SOA - Distinct, but Synergistic
Jesper Joergensen's Blog |
June 17, 2006 7:29 AM
|
Comments (4)
The discussion of BPM and SOA has taken on momentum the last 5-6 months. Both topics have been hot for years but they have been discussed in mostly separate forums by disjoint sets of people. This is now changing because both consumers and providers of these diciplines and related technologies are increasingly looking at both together.
The BPM camp has traditionally claimed that SOA was not necessary to implement BPM. Just deploy a BPM suite and you can achieve your goals much faster with less complexity.
The SOA camp has focused on how to fix the complexity of enterprise IT in general. This camp has often claimed that BPM is a feature of SOA that is part of the solution but not a separate thing. When SOA people talk about BPM it is often synonomous with service orchestration or process integration without the emphasis of business analyst friendly modeling or human interaction that are so important to the BPM camp.
To get past these misconceptions, I think it is useful to clarify the different nature of "BPM" and "SOA".
SOA is an architectural approach.
BPM is a set of coordinated activities.
Thus, you can very easily have BPM with or without SOA and vice verca. Let's look at the advantages of different combinations.
If you deploy a BPM suite without SOA, you achieve the ability to quickly create, execute and monitor/manage business processes. The model of the business process can be created by a business analyst, but the full implementation will require integration to underlying IT systems (as well as defining how users interact with the process, but forget about that for now). BPM suites (like BEA's AquaLogic BPM Suite) can enable easy access to applications and databases using various techniques, service-oriented or not. The implementation will consist of code and metadata that is derived from and dependent on the underlying system interfaces and thus, any change to underlying databases and applications will require changes to the business process.
This is fine if the organization and IT environment are reasonable small and the same group of people control all systems including the BPM suite. It also works well if the underlying systems do not change at all.
But if the BPM suite is deployed by one group and it consumes services from systems in another group, then it can quickly become hard to coordinate and manage change within each group. This is the classical problem that SOA was meant to address and thus, it applies to the deployment of a BPM suite as it does to everything else.
If BPM is deployed as part of SOA, it means that when a business process connects to underlying systems, it connects to proxy services provided by an enterprise service bus that hides the complexity of the underlying applications and databases. This has the following advantages:
* It becomes simpler to connect the business process to the systems because IT can expose more useful interfaces such as aggregated data services or services that uses standard instead of proprietary protocols. This reduces the "IT work" that is needed as part of the process implementation and enables process people to focus on process, not the technologies needed to glue the process to the underlying systems.
* It makes the implementation more robust because changes to underlying IT systems do not have to impact the interfaces that the process uses.
* It provides a separate level of control and governance outside of the BPM suite. This enables IT groups to better manage policies and resources for the services they own and maintain.
SOA also enables better visibility from the BPM suite into the systems that it can connect to. IT groups can register services in a service registry and process developers (and possibly even business analysts) can browse such a registry as they are building a process. This ensures that services are being properly used and reused, and it often simplifies the business processes because using the right services will minimize the complexity of the process itself.
Of course these advantages only materialize when the IT infrastructure is sufficiently complex and/or when the BPM project reaches a certain scope and scale. Therefore, there are plenty of cases where BPM should be rolled out first without worrying too much about SOA components until later.
The best approach is to have a good dialog between business operations teams and IT enterprise architecture groups early on and plan for the future while enabling tactical execution. This requires the right mix of products. For example, it is important that a BPM suite can provide rich connectivity by itself, so that you do not have to roll out a full-blown SOA to make BPM work. Similarly, it is also important that the BPM suite is "SOA enabled", so that the two don't end up existing in isolated silos.
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
interesting post.
In which way is Bea's BPM strategy differentiated from its competitors' BPM offerings?
Is the increased momentum in SOA adoption also leading to more momentum in BPM demand?
thx
Posted by: agnesmuylle on June 21, 2006 at 12:30 PM
-
I think no vendor is better geared to providing superior BPM as part of an enterprise-wide SOA transformation. The increased SOA momentum is leading to increased demand for BPM because enterprise architects know that the line of business does not see value in SOA itself. BPM projects are really where the business gets engaged and sees what impact SOA transformation can have. Let me stress though that BPM does not require SOA. It has its own momentum and will continue to be deployed independently of SOA projects.
Posted by: jesperfj on June 30, 2006 at 2:48 AM
-
Interesting. I always thought SOA as the subset of BPM.
If I correlate BPM as IT derivative of BPR (Business Process Reengineering) and if we consider a broader business strategy (from business user point of view) I think the services orchestration is just an optional part of BPM. Please correct me if I am wrong - thanks. Shashank
Posted by: shashank_srivast on July 13, 2006 at 3:56 AM
-
Great post - nice to see someone present SOA and BPM as complimentary so clearly. I also think that there is a rule for BRM (Business Rules Management) in this stack and that BRM is also highly complimentary to both BPM and SOA. In particular using a BRM really complements BPM.
Posted by: jamet123 on August 18, 2006 at 9:28 AM
|
