Bringing SOA and BPM Closer Together
In his recent blog - Keep Your SOA and BPM Initiatives Separate - JP Morgenthal argues that the:
... entanglement of SOA and BPM into a single effort is fraught with problems and failure. Each initiative should be undertaken separately and with definitive goals that do not list each other as one of the outcomes. If as part of the rationalization that SOA provides, there happens to be some services exposed that simplify the implementation of a particular business process, then that would certainly be a slam-dunk. However, SOA and BPM each have their own metrics of success and their own barriers to success. Combining them into one, well, the words "boiling the ocean" comes to mind.
According to JP, although:
Historically, SOA and BPM rose in popularity at or around the same time. SOA, led primarily by technological practitioners, responded to the needs of BPM practitioners for a framework to capture and implement newly-designed and efficient cross-organizational business processes with technology.
His point was strongly argued by Zapthink’s Jason Bloomberg, who advocates a process-centric view of SOA, where the point to building loosely coupled business services is to support metadata-driven compositions that implement business processes. Such approach is based on the Process Isomorphism pattern, which can help organizations pull their BPM and SOA efforts together, and improve the alignment of their SOA initiatives with core business drivers.
... if you were to model a business process, and as a separate exercise, model the composition of Services that implements that process, where those two models have the same structure, then they would be isomorphic.
Jason explains that process decomposition can be used as a foundation of services definition and as such can provide the common language between business and IT efforts, but only in the case when SOA design is done right:
... the one-to-one correspondence between process sub-tasks and supporting Services is by no means a sure thing, and in practice, many organizations fail to design their compositions with such a correspondence. Frequently, the issue is that the SOA effort is excessively bottom-up, where architects specify Services based upon existing capabilities. Such bottom-up approaches typically yield Services that don't match up with process requirements. Equally common are BPM efforts that are excessively top-down, in that they seek to optimize processes without considering the right level of detail for those processes to enable Services to implement steps in the processes. Only by taking an iterative approach where each iteration combines top-down and bottom-up design is an organization likely to achieve Process Isomorphism.
According to Jason, the essential benefit of Process Isomorphism is the ability to use the process to represent service composition and vice-versa.
This informal equivalence gives us a variety of benefits. For example, if process steps correspond directly to Services, then Service reuse is more straightforward to achieve than when the correspondence between steps and Services is less clear. Service reuse discussions can be cast in the context of process overlaps. If two processes share a sub-task, then the SOBAs [Service-Oriented Business Applications] that implement those processes will share the supporting Service. In addition, the metadata representation of the composition logic, for example, a BPEL file, will represent the process logic itself. Without process isomorphism, the process logic the BPM team comes up with won't correspond directly to the BPEL logic for the supporting composition. This disconnect can lead directly to misalignment between IT capabilities and business requirements, and also limits business agility, because a lack of clarity into the relationship between process and supporting composition can lead to unintentional tight coupling between the two.
Composability is one of the main characteristics of business services. It is composability that allows to build different business solutions from the same set of services. One of the most common approach in building composable, business aligned services, is defining them based on a process decomposition. On another hand, the business process is one of the prevalent approaches to compose individual services into business solutions. The Process Isomorphism pattern, defined by Jason, is an important instrument for formalizing alignment between services and processes which could improve both.
Bottom Up vs. Top-Down Capabilities
Probably an iterative approach as suggested in the article from both sides could bring some relief, but this also makes people notice sooner or later that sometimes you really make the promised benefits if you start migrating that legacy...having some corner of a new, guarded "green field" is a breath of fresh air. This often ends like in the very nice story told by Eric Evans (posted on InfoQ) about the bounded context and the big ball of mud swallowing it in 2 years :-)