People who know me would generally agree I'm a straightforward guy - I pretty much just like to move in the direction I've said I was going, rather than try to move from side to side and finesse something. So when it comes to technology, I tend to like to go with technology because it makes sense, and I usually assume that most IT organizations work that way as well.

But when you look at a technology like Business Process Management (BPM), you can see that the straightforward approach may not be the best, fastest, or even most successful route towards deployment.

BPM is a tougher sell on a straight technology basis, because it relies either on an SOA or an EAI environment that enables a service approach, and because the capabilities it provides have to date been implemented, albeit poorly, in actual code.

BPM as a technology extracts the business rules of an organization using advanced modeling techniques and software to define the business rules, the "what happens when" outside of lower level code. Besides allowing for rapid change in response to changing business conditions, BPM also allows the business community to take a much greater role in the definition of behavior within their software environments.

Clearly, this type of capability can be an asset to an organization that is confronted with frequent changes, dynamic market conditions, or even the consequences of a merger between organizations with disparate computing systems. Yet, because of the nature of the way IT projects are usually funded, this capability is frequently a difficult sell.

Most IT organizations have to fund their projects as discrete systems, therefore you can fund a CRM system, or an Order Management system, or a General Accounting system, even a User Portal. Each of these systems provides an "end user" benefit, one that can be easily quantified and budgeted for. BPM, by contrast, potentially cuts across all of these systems, while providing little visible or tangible benefit.

That's at least partially because funding a development effort and cost usually neglects the operational and maintenance cost of a system. These costs can often be multiples of the original implementation cost over the lifetime of a system. As an example, think of some of the COBOL programs that many large organizations have been nursing along for decades. Compared to the cost of creation, the maintenance costs are many times higher.

This is where the BPM solutions pay - they help reduce operational and maintenance cost. Anything that is programmed has to be tested to death, deployed, and managed. The model-driven architecture (MDA) approach seldom actually works all the way down to the code level and back again, so even if there is some modeling or design, it's typically only documentation when the coding gets done, allowing errors and omissions to creep into the process and creating troubleshooting nightmares.

In contrast, BPM presents the rules in a modeling environment that is completely round trip, and can be tested and debugged more effectively, especially in the difficult cases where a business transaction requires crossing system boundaries. We've all experienced the "he said, she said" finger pointing that goes on when a process that spans two or more systems experiences difficulty. BPM reduces cost by taking the management, the modeling, and the implementation out of multiple silo-based systems and centralizing the capabilities needed to effectively implement business processes rapidly.

It should not be surprising that the calculations necessary to quantify this benefit are convoluted and involved. They require analysis of maintenance and operations, as well as a good understanding of the actual software development life cycle in use in a particular organization - something that is seldom present. Thus while the technology clearly provides benefits, quantifying its value and justifying its cost remain elusive. In the end, the straightforward approach to the problem, which is simply stating the need for the capability, must give way to a more devious approach that builds the capability into the price of one or more system upgrades or packaged implementations.