Welcome!

SOA & WOA Authors: Liz McMillan, Richard Moulds, Michelle Drolet, Elizabeth White, Patrick Carey

Related Topics: SOA & WOA

SOA & WOA: Article

"The Backdoor" – BPM Solutions Pay

"I tend to like to go with technology because it makes sense"

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.

More Stories By Sean Rhody

Sean Rhody is the founding-editor (1999) and editor-in-chief of SOA World Magazine. He is a respected industry expert on SOA and Web Services and a consultant with a leading consulting services company. Most recently, Sean served as the tech chair of SOA World Conference & Expo 2007 East.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Derek Miers 02/15/06 08:27:44 AM EST

Naive, ill-informed, confused ... just three of the adjectives that spring to mind while reading this piece.

There probably isn't a Fortune 2000 company that is not gaining significant benefits from the deployment of BPM technology. Mostly these projects are still in the mode of strategic experiment, but the evidence is plain for all to see.

Some of Sean's assertions are just plain wrong (like the bit about BPM code being poorly implemented), while others show a lack of understanding of the real issues and benefits.

Suggest you do a little more research next time before wading in to an area that you obviously have little contact with.

IMNSHO, SOA and BPM initiatives are fairly much joined at the hip. SOA is a "way of thinking" based around the notions of service orientation ... it allows an organisation to support the high level business capabilities that keep the firm in business, marrying that up to the low level technology and procedural elements.

OTOH, BPM is a business discipline that puts continuous performance improvement center stage in the way the firm is run. It involves a highly iterative approach to supporting the way systems are rolled out. From the perspective of this discussion however, BPM Suites provide the ability to orchestrate services in line with corporate objectives.

The ROI and business benefits are clear, making business justification relatively straight forward ... it just requires understanding of how those benefits transform into enhanced productivity, customer service, traceability and transparency.

Check out the papers on my site if you want an alternative view (or much of the material available on sites such as BP Trends, BPM.com)

SYS-CON Italy News Desk 02/14/06 07:19:24 PM EST

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.