- 
- « Happy holidays | Home | What is the Difference between ERP and BPM? »
What is the Nature of the BPM/SOA Codependence?
By Jim Sinur | January 2, 2008
I have had many discussions with business folks and IT types about the link of BPM and SOA and after several drinks we concluded that BPM and SOA are linked more than it appears on the surface, but the views going into the discussion are often at polar ends of the spectrum.
The BPM View:
Unless an organization is highly automated, like in the manufacturing of hard goods, a great deal of business activity revolves around human interaction and collaboration of knowledge workers. Very little of this activity can be put into applications or transactions, much less become service enabled.
There is another class of work that revolves around human activity where the knowledge level is not as intense and revolves around workflow-like activities. This work has also eluded automation at the level that a service would be needed.
Typically 80% of business activity does not include systems, integration, straight-through processing and transactions (the playground of SOA). The 20% that is highly automated is certainly the most efficient and productive; therefore, the more work an organization can push there, the better.
It is important to understand SOA in the context of an overall process; otherwise IT falls into the myopic world that typical functional business professionals fall into. We have to make sure we have an attitude that SOA helps the company better manage what’s automated, so we need to pursue SOA, but not to the detriment of other activities. Even when services are utilized, there are services in BPM.
The SOA View:
Service-oriented architecture represents the latest wave on the evolutionary path of application development. SOA is not just an infrastructure issue, it also has a significant impact on how organizations develop and deliver applications and processes in the future.
A process or a system built with an SOA consists of subsystems that interact in a loosely coupled, coarse-grain manner, with a minimum of state, and with a well-defined contract.
These subsystems / sub-processes are fully autonomous (there is no requirement, for example, that these subsystems / sub-processes be built by the same organization, on the same platform, or with the same toolset). Rather, each is assumed to have its own life cycle, and can freely participate in interactions with a number of other autonomous systems or processes.
In addition, all interactions are governed by the same contract or formal interface description, as long as there is agreement on the mechanics of intersystem / process communication. The power of the SOA architectural approach is that it enables autonomous subsystems to be assembled into entities (SOA applications / processes ) that can be as cohesive externally as applications built with older architectural approaches (classic components, modularization, or object-oriented paradigm).
The benefit of SOAs over these older approaches is increased agility and greater tolerance for change throughout the life cycle of a system, especially compared with a system that assumes tight coupling and homogeneity across the subsystems.
Services can also be consumed by processes, and services themselves may be process flows that can be leveraged in master flows. Some of the infrastructure for SOA can be leveraged for the reuse of process snippets (a directory for instance). So there is BPM inside of SOA as well.
Bottom Line:
Like it or not, there is an implicit link to BPM; particularly for processes that are below the waterline and linked to straight-through activity.
While BPM does support SOA for system tasks, BPM can live well managing the human-only activities without SOA. But as more rules and processes are leveraged as reusable components, they take on a SOA flavor. In reality they really help each other and the failure of one could impact the success of the other.
BPM enhances the very essence of Service, but services can also be processes. It is a strange relationship and certainly a codependent one, indeed. This is why there is BPM in my SOA, and SOA in my BPM.
Topics: BPM |
January 2nd, 2008 at 12:48 pm
Jim,
You are abosolutely correct. We have found that in any given process almost all work event transactions are asynchronously human driven.We listen to varieties of technlogies to monitor human activities. I believe SOA is just a repository of stateless processes (rules) that are called by human collaborative process states to peform atomic actions.
Rajeev
January 8th, 2008 at 9:28 am
[…] a recent post, Jim Sinur sheds more light on SOA-BPM, calling this interaction a “strange relationship and […]
January 11th, 2008 at 12:30 am
Jim
Some good points as always and you prompted a quick post on the role of decision management over on my ebizQ blog - http://www.ebizq.net/blogs/decision_management/2008/01/adding_decisions_to_the_soabpm.php
JT
Author of Smart (Enough) Systems