BPM is SOA’s Killer Application
Sunday, August 13th 2006 | 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, 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.
Entry filed under: BPM 2.0, SOA
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ismael on BPM as SOA’s secret sauce……
Ismael knows a thing or two about business process management (BPM), and anyone that regularly reads his blog knows it’s not just a core competency but a passion for him. Today he took the time to explain in some detail…
Ismael,
You make a lot of good points in this article but I think that BPM is only ONE of the applications (or I would say adoption patterns) of SOA. We see a LOT of customers adopting SOA to solve simple point-to-point integration pains. So lighter-weight, code-free application integration is ANOTHER application of SOA. Finally, we start to see business activity monitoring as an important emerging third pattern.
At its heart, SOA is about building more open and integratable applications. I think that we have definitely not seen the limits to what people can do with those open interfaces.
-Edwin
Ismael,
I liked the way you described the realtionship between BPM and SOA the first time and now even more. Especially this: “deploying SOA in the context of a BPM process will help you package services with the appropriate level of granularity.”
I also liked “the whiteboard situation” you mentioned. A business is full of services exposed internally and externally between organisational units. Putting them into the context of processes will give you BPM on SOA. Like that!
-Jonas
Edwin,
I totally agree with you. BPM is only one application for SOA, but it’s the one that will help make SOA more palatable to a business audience, and as such, I consider it as SOA’s killer application.
Ismael,
It’s the business audience focus that I appreciated. A lot of technical folks I speak with sing the praises of SOA in various forms, but if this is going to be something deployed cross-enterprise at larger organizations, it HAS to resonate with the non-technical people (aka, those who write the checks), and BPM goes a long way in spanning that chasm.
Best,
-Jason
Jason,
I could not agree more. Thanks for the nice article!
[…] The first piece is by Ismael Ghalimi, who often talks about applying Business Process Managment or BPM — a well-known approach for creating business processes that are software assisted — in a more Web 2.0 fashion. In his write-up, "BPM is SOA’s Killer Application", Ismael notes that SOA does indeed turn our IT systems into foundational building blocks, but it’s the creation of processes out of them that delivers the actual return on having services in the first place: 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? […]
BPM is needed in a SOA Software Stack…
I have written before about the need for a software suite for SOA such as those offered by IBM, TIBCO and BEA. I have also written about the need to actually improve business process with SOA through the use of BPM to achieve benefits and ROI.
[…] Ghalimi’s post in particular, caught my eye, as he positions BPM as the potential "killer app" that may make all that SOA work worthwhile. Through BPEL and other standards, SOA can lay the ground for mainstream adoption of BPM He identifies SOA as a "a solution in search of a problem," which unfortunately, is true on many levels, beyond the IT process improvement offered through resuability and interoperability of components. […]
[…] Ismael Ghalimi knows a lot about BPM and wrote this great article […]
Ismael,
This is an excellent article that reminds me a lot of the discussions we had together a few years ago. There are too many parts in your article that are so well written that it is impossible to quote them.
If you allow me, I would only want to add few little thoughts.
1. BPM does not only make sense for business people. I like to think of a project in the same way as an “entrepeneur” that establishes a company and whose goal is to realize that project. When creating a company, you need to choose the right people, with the right skills. Not too many, not too few. People that cleverly execute a part of the project. And who need to be located in the right place — you will never hire a cook and place him far from the kitchen, right? The project — any project for that matter — is nothing more than coordinating the different specialists you hired in the location you gave them.
After all, an IT project needs to model something that actually exists, right?
2. In Business terms, each thing you do is a process. A company is organized through processes! Many times, though, companies execute processes that are not formalized. Formalizing them is one of the benefits that automation can bring. With, our without SOA, with or without BPM. But with BPM, we gain the possibility of implementing something that is closer to the reality.
3. Granularity is often a matter of power. What I mean is that the more fine-grained you think about your services, the more power you intrinsically give to the coordinator. And the more coarse-grained your services are, the more there are islands of power that you do not want (or cannot) break. What I want to say is that if you think of a project as a way to map an existing business process in a existing company (or a new one), you cannot abstract away from the actual organization.
4. Sometimes, instead of defining a formal processes where each service in the organization is clearly coordinated, it is easier to give each service the possibility to contribute… In that case, the important thing is to avoid having someone who has the coordination responsibility, and to give more responsibility to the periphery.
Stefano,
Thank you for these comments. Very insightful.
Good to meet you again by the way!
[…] Ismael Ghalimi’s “BPM is SOA’s Killer Application”. Ismael is the CEO of Intalio, a very bright mind in our industry and one of the people who clearly saw the importance of Business Process Management […]
I always considered that SOA and BPM are two sides of the same coin. After spending many years in EAI, and having just gone through various evaluations of BPM and SOA tools, I fully agree with Ismael’s characterization of BPM as a killer application…
We just went through a battle of selection of tools in our large COE. It was very clear from this that it was a lot easier to select tools from a BPM point of view, compared to SOA. In fact, as we started selecting a SOA registry, it quickly became a battle between SOA registry and repository. Quickly, we found that some SOA repositories even came from the Assent Management world. My point is that the requirements and tools in this area are still very immature, even at the lowest level of the SOA brick. I don’t even want to bring out non-interoperable messaging standards. Though we fully understand the value of point to point and EDA very well, as we have a large successful EAI infrastructure deployed.
On the other hand, selecting BPM was a lot easier as business quickly knew what is required. Though many vendors have significantly different capabilities, some leading ones came from the BPMN world, and they have done a great job of integrating services (non-standard way), presentation layer, etc. However, their integration is perhaps not as open as Intalio.
After having seen various generations of BAM, I can’t help asking Edwin Khodabakchian why he considers BAM has an important third pattern — I assume he means it in the context of plain vanilla SOA. It makes more sense to consider BAM has having more value when you tie around BPM &s; BRM, compared to a SOA centric process orchestration stack, such as BPEL or EAI based processes. What do others think?
I happened to come across your blog entry on BPM and SOA from last month… Bravo for such an articulate example of how one should not confuse approach, i.e. SOA, with an actual application/solution, i.e. BPM, that is realized via the approach! For the past 3 years, I’ve been helping clients navigate the murky “alphabet soup” that is pushed by industry pundits and vendors alike. Yes, there is a place for SOA and BPM in our vocabulary, and as others have already commented, we need to understand the importance of applying business rules as well as the multitude of problem scenarios (business and IT) that can be solved with an SOA approach. It’s nice to see that more and more of us are beating the drum that puts it all into proper perspective.
Kooros,
Thanks for the feedback, much appreciated.
-Ismael
Ismael,
My judgement is there is indeed a real value in the combination of BPM and SOA, which could solve every organisation’s problem: the business-IT alignment. However, the BPM/SOA convergence is only a vision, rather than an existing solution.
My experience shows that value must be presented to the business professionals. At the end of the day, they and “only they” have power in every organisations. Business folks must aks IT guys, before investing in any IT project: “show me the value”, “show me the money”. In the meantime, using BPM approaches, business managers understand the creation of value (feel added value) by modeling, designing, and reorganizing the processes as a result of market, legal, or customer requirements. However, they do not see value in the new IT buzzword: SOA. As you said, SOA is marketed as a philosophy, it is about agility, architecting, but “Architecting is not Building”.
Conclusion, before moving forward, both camps must seat together and find the interdisciplinary underlying concepts: The process? The service? Business managers must understand how and where processes meet SOA services, and how the orchestration of services will help in the development of applications, and foremost how additional value could be generated.
-Tomasz
Tomasz,
I fully agree with you.
[…] BPM is SOA’s Killer Application […]
[…] Dion Hinchcliffe, un auténtico especialista en Enterprise 2.0 (aplicación de la Web 2.0 en entornos corporativos), publica un interesante artículo acerca de esta tendencia. Una idea que me gusta es que el aporte de valor para el negocio viene de la mano de la utilización de servicios dentro de procesos de negocio (si, ya, tengo debilidad por los enfoques process-centric) más que de los servicios en si mismos. Esta idea la desarrolló Ismael Ghalimi de Intalio en su artículo “BPM is SOA’s Killer Application“. […]
[…] Ismael goes into more details, but the idea is that BPM … […]
Great article. Indeed BPM is one of the killer apps of SOA. The ultimate killer app in my book is the one which leverages the SOA infrastructure on an organization’s business requirements driven basis and delivers a process managed solution which makes sense to those particular requirements. This makes RoI a unique challenge per organization’s expectations. Thus far, I have yet to see a methodology that puts SOA, BPM and RoI in a predictable and deterministic context.
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment