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, for their deceiving simplicity might overshadow their relevance.

On one hand, and to a large extent, the Service Oriented Architecture (SOA) is a solution in search of a problem, and the Return on Investment (ROI) customers can expect from any SOA initiative has been a hot topic of discussions as of late. In such a context, Business Process Management (BPM) 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, cannot 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 the Service Oriented Architecture is that it is 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 is 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 efforts 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 litterate 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 man-month 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 a Service Oriented Architecture 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 white board, 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 you that what you’ll see being drawn on the white board 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 we indicated before, you might never get it. Instead, BPM is SOA’s killer application because it will give you the reason for doing SOA at 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 Return on Investment 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, orders will advocate that it should be lowered to the level of recording the purchase order, yet 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 is 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 to compose coarser grain services out of smaller existing ones, or expose technical details of another into finer grain ones, but you will 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 after.

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. And 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 at 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 did not 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 were not ready for prime time, 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, then started thinking about an architecture for managing it all, and SOA was born. 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 others, and sharing a common language is usually a good way to foster communication. This lead 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 remember WSFL and XLANG today, 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 — what some call BPM 2.0 — 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

<출처 : http://itredux.com/blog/2006/08/13/bpm-is-soas-killer-application/>