Susan Hall spoke with Joe McKendrick, who heads the trend-spotting service McKendrick & Associates and serves as analyst for Evans Data Corp. He blogs on service-oriented architecture for ZDNet and ebizQ.
Hall: We've heard BPM called the "killer app" for SOA. Why?
McKendrick: Ever since service-oriented architecture emerged as a buzzword, many have regarded it as a solution in search of a problem. That is, the idea of SOA was nice to have for companies, but not seen as an absolute necessity. A business can run fine, thank you - and most still do - on their portfolios of legacy, point-to-point applications. But the time is approaching when these creaky old siloed systems will noticeably hold back progress.
While SOA is still a source of confusion, there's no question that business process management ranks high on corporate agendas - and is clearly understood by executives. Many companies are looking for ways to get to market a lot faster, and deliver products and services much more efficiently, through both internal and outsourced processes. BPM can be done without SOA, but having standards and integrated systems made possible through SOA will make BPM a whole lot easier. An analogy I've heard is that trying to do BPM without SOA is like juggling with one hand tied behind your back.
A process that may have taken months to assemble and align with underlying older technology may literally take hours if the technology is flexible and adaptable enough. For example, a company that sees an opportunity to sell more product through a new type of promotion, such as stepped-up customer financing, may have to go to its IT department and have numerous systems and interfaces changed within its financial and customer-relationship management systems. When you make one change in an older legacy system, you have to go through the entire infrastructure to change and re-test all the modules that connect with the changed system. With SOA, perhaps only one service or interface would need to be created or adapted, without breaking the rest of the system.
Hall: Why are BPM and SOA coming together at this point in time?
McKendrick: A convergence of standards and business necessity. An important standard in the SOA world is BPEL, or Business Process Execution Language, which serves as the glue to tie SOA-based services together into processes. Also, again, businesses are challenged with being able to quickly assemble and align processes with fast-changing markets. SOA can provide this agility to quickly deploy services that leverage existing back-end technology.
Hall: What is the criticism of BPM and SOA together? I've heard that companies thinking of it as a "once-and-done IT project" could face disillusionment when it turns out to be an ongoing process. What else?
McKendrick: I haven't actually heard a lot of criticism of BPM and SOA together, but in many ways, it certainly is like mixing oil and water. The main challenge is that the IT/SOA proponents and BPM proponents tend to come from different parts of the organization - they are two different disciplines. SOA is still driven by the IT department, and therefore tends to have a technical focus. BPM has a business focus, and BPM folks tend to be turned off by the tech-speak that still surrounds SOA.
Hall: What dangers do you see for organizations putting the two together? What caveats?
McKendrick: The greatest concern is that SOA is too automation-centric and lacks support for human interaction with the workflow. Many business processes still require the "human touch," by both business and legal necessity. Processes get touched many times and sometimes are required to be by law or regulation. I like to think of business process workflows as rivers: Each one has its own unique sources and outlets. But there are also plenty of waterfalls, dams and locks that can gum up the works. Workflows all have their own points where humans intercede. We are only in the early stages of automating BPM, and have only begun linking business processes to SOA. SOA promises to speed up much of our workflows, but the points requiring human interaction may negate efficiency and speed gains. It will be a while before SOA-based processes can address these bottlenecks, and it's probably risky to leave processes entirely to automation.