Ajit Sagar

I'd like to take a moment to introduce myself. I've been working with SYS-CON for about eight years now, across different publications, so when Sean talked to me about providing regular content for WSJ, I thought to myself, "Cool." I am also the enterprise editor for JDJ - so you should see a lot of cross-magazine content. Part of what I want to bring in as "International Technical Editor" for WSJ is some articles from around the world.

So, the uppermost thought in my mind is that I just started jogging two days ago after a gap of several years. While I was cajoling my body to go along with my mind - tricking it into going a further distance than what we had mutually agreed upon, my thoughts started wandering to the commentary for this month. I also thought about the several client engagements that Infosys has been called in on to help the client determine how much of BPM to bring into their organization. I guess the two scenarios (jogging and consulting) have some commonality - the negotiation of "selling" more than the original agreement, and maybe offering questionable benefits (at least that is what my body told my mind!).

Recently I've been involved in initial discussions with folks from some large firms in the financial industry who are considering adopting BPM because of several reasons:

• It is the new buzzword
• There is promise of integration to a level never seen before
• Workflow did not fulfill the promise of enabling the agile enterprise - BPM will
• It is time to adopt SOA
• BPM will bring in the ability to do Web services.

Fortunately, the folks at the CTO/CIO level in the financial sector are driven by reason (and cost), and understand the workings of their existing portfolios enough to at least ask the question - what is it we are gaining, and is it worth the cost? As one of the CTOs of a large global investment banking firm mentioned to me in a recent meeting, "The vendors we are looking at promise functionality that will solve only 60% of my problem, and only 30% of the functionality they offer is useful to me." In other words, 40% of this problem remains unsolved and 70% of what he bought is useless to him. Furthermore, the cost of the products is in the millions of dollars. However many factors, including rigorous changes in compliance rules, have led people to look at BPM as the next big thing.

First of all, there is a mishmash of terms that confuse the whole issue. There is obvious confusion between workflow and business process management, process orchestration and service orchestration, enterprise application integration, and process integration. And vendors from each of the spaces have wrapped their offerings under the BPM umbrella; same pig, new lipstick. It used to be all about work management and integration. Now it is all about process management.

BPM is composed of five building blocks - a graphic process designer/modeler, a runtime engine, process monitoring and management capabilities, analysis tools, and an interface to modify the process at runtime. If you look closely, you will see that each of these has its humble (or grand) beginnings in the offering from a workflow vendor, or an application server vendor, and so on. At the end of it, you have to determine which part of the suite is really beneficial for you. Unfortunately the BPM standards haven't been adopted widely enough to mix and match offerings between vendors or with your own in-house components.

Don't get me wrong. I think BPM has a great future, but you need to choose wisely when you bring it into your organization. You need to proceed with due diligence and a rigorous cost-benefits-analysis. And yes, Web services can be leveraged at many levels without requiring a formal BPM tool; however, if you find yourself in the situation where you are building too much from scratch (or had little in-house IP to start with), consider a BPM tool.