Should your architecture focus on SOA or BPM?

While SOA was the big name in the buzzword tag cloud, BPM is quickly getting bigger and bigger. As organizations are becoming more aware of the need to tame their processes in order to get the benefits of IT investments, BPM is gaining importance and mindshare inside and outside of IT. Is one more important for your architecture? From BPM as an SOA platform to using BPM as a rationale to pursue SOA, the link between these two concepts has been growing tighter.

Dain Hansen at BEA recently published a "Blueprint for Successful SOA Integration" that detailed advice on what it takes to get SOA working in an organization. In the discussion, Hansen pointed out the importance of BPM - SOA integration.

We can't talk about IT integrating ERP systems without also considering how that integration will play with the business analysts or LOB who actually need that data or services for their business processes. These two often contradictory elements need to work together as part of a fully integrated solution. When SOA and BPM play well together we have seen enormous benefits. Not only is there alignment between the various roles in IT and the LOB, but the processes are implemented in an optimized way that both camps can successfully manage...

Once a business process model is implemented and automated across the SOA Integration, optimization occurs when runtime feedback is returned to the business analyst via integrated business-activity monitoring. This lets business users see where process improvement needs to occur in real time. Once improvements are identified, the business analyst can update both the models and the business and the development cycle begin anew. True business transformation and optimization are realized through this iterative business-integration cycle.

To see these types of benefits SOA and BPM needs to be integrated in such a way as to give multiple users in the organization common unified tools to share metadata, share governance and management information, and ultimately optimize the interoperability between a business processes and how those processes are translated to the back-end integration.

Quinton Wall, also of BEA, recently spoke about combining BPM with an SOA to maximize business agility. Wall stated that organizations could achieve IT and business alignment by leveraging BPM tools with an SOA: "The trick is to enable the business side to make changes in a governed manner while reducing its reliance on IT." That is, the BPM tools allow the line of business actors to take advantage of services and service composition with less IT involvement.

The BEA advice came from an "SOA-first" perspective that assumed the organization is already service-enabled. Several others took a business process centered view of the marriage between BPM and SOA.

Rich Seeley talked about the SOA initiatives at Delaware Electric Cooperative and how IT VP Gary Cripps made them successful. Cripps said that taking a business process decomposition approach helped immensely.

"I start breaking that down into all the processes," Cripps explained, "what we found was that, in an SOA engagement of this magnitude, we spent 55 percent of our time defining the processes. Fifty-five percent, I found that pretty amazing. Twenty percent of our time was in coding. The remaining 25 percent was in testing and implementation."

This is good news for small and medium sized businesses contemplating SOA, Cripps said. Business process identification and modeling can be done within the core team that includes the departmental stakeholders, but the 20 percent of the project that is coding can be outsourced.

In-house, the SOA team members have changed their way of thinking about applications in terms of business processes, Cripps said. "When we went with service orientation, as far as my team members were concerned, it really elevated their knowledge because it took a significant effort to understand the business processes and the business rules through multiple departments that would be involved in a particular transaction," he said.

Seeley also pointed out how the role of business analysts has been changed by the movement toward SOA. Quoting John Michelsen, iTKO, Inc. Chief Scientist, Seeley noted that it is the business analyst's responsibility for requirements as opposed to IT's responsibility to develop the components that is most effected by SOA initiatives.

"I think it might be fair to say that the individual developer writing code is the least affected because he or she is taking requirements and building a component, testing components, and plugging it into a larger system," he said. "That in itself is not that different than it was five years ago. So, ironically, the developer may be the least impacted by SOA."

In both of these cases, Seeley brought out the importance of business process management and analysis in dealing with creating and dealing with SOA.

Dennis Byron noted that BPM now deserves a first-class slot in the software stack. Byron's point was that BPM has moved beyond being part of the integration layer, where the IT perspective put it, and onto the top of the stack. With this business perspective of the software stack, IT can "look at BPM as a 'new development paradigm,' grounded in service-oriented architecture (SOA) methodologies."

In getting to the answer of the question "BPM or SOA?", Neil Macehiter and Neil Ward-Dutton talked about how the two concepts work in a modern organization. Instead of taking the traditional approach of "BPM is a top-down, business-driven initiative, whereas SOA is a bottom-up, technology-driven initiative", Macehiter and Ward-Dutton talked about how "top-down *and* bottom-up perspectives of service-orientation *and* process-orientation can all come together in a more holistic view of business and technology architecture." Following up on these statements Macehiter and Ward-Dutton showed how the process and service concepts unite through outcomes:

Outcomes are desired results. An outcome at the highest level is likely to be something concerned with the core value of the organisation, financial performance, etc. At this level, outcomes might link very straightforwardly to mission statements. At lower levels outcomes are going to be concerned with operational results - for example "product is delivered". Services are commitments to achieve outcomes. Processes are the methods through which outcomes are achieved.

Neil and Neil summed up the BPM/SOA perspective with this: "the truth is that *outcomes* come first, and services and processes are two sides of the same coin in achieving the right results."