Commentary: Business Process Management Is SOA's Killer App

	Bookmark This Page Email This Page Format for Printing Submit an Article Read More Articles
	Related Tools & Articles What is Business Process Management? 5 Trends in Business Process Management 5 Steps to Choosing The Right BPM Suite
	Discussion Forum "What are the differences of SOA and BPM and in particular how do those differences affect an organization? There is so much hype these days on BPM, I'm wondering where SOA fits in." Contribute to this Discussion

By Ismael Ghalimi

BPM is SOA's killer application, and SOA is BPM's enabling infrastructure. We've used this tagline before, but simple truths are worth repeating. After all, their deceiving simplicity might overshadow their relevance.

On one hand, and to a large extent, service oriented architecture (SOA) is a solution in search of a problem, and the return on investment (ROI) that customers can expect from any SOA initiative has been a hot topic of discussion lately. In such a context, business process management might very well be the one indisputable reason why any IT shop should consider deploying SOA today.

On the other hand, the benefits BPM can offer to the business, in terms of agility, affordability and accountability, can't be gained without the proper underlying infrastructure. So far, BPM has remained a point solution, deployed through proprietary products. The emergence of SOA, and the establishment of industry standards that take advantage of it -- BPEL being first among them -- should lay the ground for BPM's mainstream adoption.

BPM is SOA's Killer Application

The problem with SOA is that it's exactly what its name implies: an architecture. It's a set of guiding principles. It's a philosophy. It can help an architect design a blueprint for something concrete, but nothing more. It's not the blueprint, even less the building. Architecting is not building, and if companies do just that, they'll end up with very little in the end, after having spent a lot of time, money and effort getting there. SOA should not be seen as the end, but the means to the end. The challenge then becomes about finding what the end is that will justify the means.

Advocates of SOA have heralded the need for agility as the main business driver for deploying their architecture of predilection. Unfortunately, business types have found it difficult to understand how SOA could provide true business agility. The most literate among them might have realized the benefits it could bring to their IT departments in terms of costs reductions, but the other quickly dismissed it as yet another IT fad.

From a business standpoint, a service is too small a unit to really appeal to the business side of the house. Its granularity is too fine. And it's only when elevated to the level of processes that business folks usually start paying attention. Reusing a currency conversion service across multiple applications and saving three people-months of development along the way is one thing. Being able to shave three weeks in the overall order-to-cash process is another. Guess which of the two will get the CFO's attention?

Once customers start putting an SOA in place, the desire to tie their newly-available services together into coarser-grain services -- or higher-level processes -- is felt rather rapidly. This should not come as a surprise; services can be seen as neatly-packaged units of functionality, and the main reason for such a packaging is to enable their composition.

Now let's make a little experiment: I suggest you draw a set of boxes on a whiteboard, and give them names of "services" that make sense for the particular business you're in. Then ask a colleague to "combine" them into something useful. I bet what you'll see being drawn on the whiteboard is a set of arrows connecting the boxes and resembling the flowcharts you used to draw when practicing the principles of the good old business process reengineering methodology. Here you have it: a process!

But BPM would not be SOA's killer application if it would work only after you get SOA, for, as I indicated before, you might never get it. Instead, BPM is SOA's killer application because it will give you the reason for doing SOA in the first place. Without BPM, the main ROI for SOA is reduced IT costs. With BPM, you can directly link the ROI for your SOA project to the ROI you could get from any improved business process. All you have to do is ask the business which processes they'd like to fix first, put ROI tags on them, and you'll get the justification for your SOA initiative, with the budget to deploy it.

Better yet, deploying SOA in the context of BPM-powered process work will give you the right SOA. Here is why: SOA is more philosophy than religion. The book of SOA is more Tao Te King than Bible. For example, no consensus has emerged as to what the level of granularity of services should be. Some will say it should be at the level of fulfilling a purchase order; others will advocate that it should be lowered to the level of recording the purchase order; others will recommend that it should be down to the level of creating the header for the purchase order, while using another service to record each line item. Who's right? Nobody knows.

In reality, there's no absolute answer to this question, and the right answer will depend upon the business scenario -- not to say business process -- the question was asked in relation to. As a result, deploying SOA in the context of a BPM process will help you package services with the appropriate level of granularity, at least within the context of the business processes they'll be involved in. Nothing will prevent you from composing coarser grain services out of smaller existing ones or exposing technical details of another into finer grain ones, but you'll do it for a very good reasons, always justified by business requirements. Again, SOA is a means to an end, and the way this means is shaped usually depends upon the actual end that is sought.

For all these reasons, BPM is SOA's killer application.

SOA is BPM's Enabling Infrastructure

One of the main ideas behind BPM is to abstract technical systems and requirements in such a way that new business processes could be designed, deployed, executed, monitored and optimized, without having to write any software code, while most of the work would be done by non-technical folks -- or at the very least less technical ones.

This in turn would bring agility, affordability and accountability to the business. Agility, as in the ability to change the process as fast as the business itself is changing. Affordability, as in the ability to deploy, in a cost-effective way, a new process that could not have been deployed with any other technology before. Accountability, as in the ability to prove, in a non-ambiguous way, that what your IT systems are doing in relation to your business processes is exactly what they were intended to do in the first place. In today's SOX-constrained world, people are discovering this to be a lot harder than they initially thought.

To some, this idyllic scenario might sound too good to be true, and until recently, it really was. Without a way to provide the functional richness of existing systems packaged into reusable units, without having to expose their technical complexity, what could have been presented as a silver bullet actually turned into magic pixie dust, which is another word for vaporware. It just didn't work, or at least not as advertised. And behind the neat little boxes and arrows, armies of developers would have to write arcane code, using languages such as C++, Java or JavaScript.

Granted, there were some technologies that could have been used to make it work. CORBA was one of them. Problem is, as early incarnations of what we call SOA today, they weren't ready for primetime and more often than not turned out to bring more complexity, exactly where there should have been less. Again, it just did not work.

Then came XML, and the idea of using standard Internet protocols to connect all the pieces together. People called it Web Services, and then started thinking about an architecture for managing it all. Thus was born SOA. It took some more years for the concept to mature, but it eventually reached a critical mass of adoption, making it the de facto standard for any enterprise architecture today.

Of course, industry standards played a key role in this adoption process. By its very nature, SOA is all about enabling different actors (people, processes and systems) to communicate with each other. Sharing a common language is usually a good way to foster communication. This led to the development of specifications such as SOAP and WSDL, which today are the fabric of any new application being developed.

Right around the same time, industry standards for BPM started to coalesce as well. BPML got rid of proprietary languages -- very few of us remember WSFL and XLANG -- and was eventually replaced by WS-BPEL, also known as BPEL, which took full advantage of the emerging stack of standards for Web Services (as well as IBM's deep-pocketed marketing resources). But because boxes and arrows seem to be more pleasing to the eyes of most business analysts than angle brackets, BPMN was developed and eventually established as the standard graphical notation for the modeling of executable business processes.

Ultimately, a stack emerged: WSDL for packaging services, BPMN for designing processes and BPEL for executing processes built out of packaged services. All of a sudden, true BPM became possible. It worked in a zero-code manner, supported one-click deploy for the most complex processes, and enabled a groundbreaking middle-out approach that empowered business analysts and less technical folks -- called process analysts today -- to work together on the same process, using the same tool.

Then BPM started to work, enabled by SOA.

Useful Links

Additional commentaries by Ismael Ghalimi:

"BPM 2.0"
http://itredux.com/blog/bpm-20/

"Zero Code"
http://itredux.com/blog/2006/05/01/why-zero-code-matters/

"One Click Deploy"
http://itredux.com/blog/2006/05/08/why-one-click-deploy-matters/

"BPM 2.0 is Middle-Out"
http://itredux.com/blog/2006/06/03/bpm-20-is-middle-out/

"Who is a Process Analyst"
http://itredux.com/blog/2006/03/13/who-is-a-process-analyst/

About the Author: