BPM Enterprise Homepage



BLOGGERS
 
Nari Kannan [59]  RSS  Nari Kannan's Biography
Jim Sinur [23]  RSS  Jim Sinur's Biography
Ismael Ghalimi [23]  RSS  Ismael Ghalimi's Biography
Jeffrey Mills [21]  RSS  Jeffrey Mills's Biography
Louis DiToro [15]  RSS  Louis DiToro's Biography
Kiran Garimella [12]  RSS  Kiran Garimella's Biography
Vinayak Khadye [9]  RSS  Vinayak Khadye's Biography
Carlos Accioly [7]  RSS  Carlos Accioly's Biography
Russ Stalters [6]  RSS  Russ Stalters's Biography
Samah Ghanem [6]  RSS  Samah Ghanem's Biography
Bruce Silver [6]  RSS  Bruce Silver's Biography
Sandy Kemsley [4]  RSS  Sandy Kemsley's Biography
John T. Wilson [4]  RSS  John T. Wilson's Biography


CATEGORIES
 
BPM [118]  RSS
Companies [63]  RSS
Conference [3]  RSS
General [188]  RSS
People [33]  RSS
Research [62]  RSS
SOA [10]  RSS
The Buzz [22]  RSS
Vendors [32]  RSS


RECENT ENTRIES RSS
 


BLOG ARCHIVE RSS
 



LATEST COMMENTS
 
 


 Ad Links
 
Process Management Training Slides
 

1 January 2008 by Jim Sinur
Printable version  |  Email to a friend

What is the Nature of the BPM/SOA Codependence?

BPM/SOAI 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:

BPM/SOAService-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.

Cross-posted from www.global360.com/blog

 
BPM , SOA
posted by Jim Sinur  at  12:00 AM ET | comments [0] | trackbacks [5]


BLOG COMMENT
ADD COMMENT
(*) indicates required fields
author (*) :
email address :
url :
 
  bold italic underline add hyperlink add email hyperlink centre unorder list order list add image quote emoticon smiles
 
comment (*) :

max characters : 1500

characters remaining :
remember me :
To help us prevent spam-generated submissions,
please enter the summation of 4 and 7 below: