Does it make sense to fuse SOA to business process management (BPM)? Many see the SOA-BPM alliance as an inevitable convergence -- a topic we've riffed on repeatedly here at this blogsite.
Should SOA be viewed as 'the nail for BPM’s hammer'?
So, the SOA-BPM alliance is a great thing, right? Actually, at least one informed observer questions whether SOA and BPM were really meant to be together at all. JP Morgenthal cautions that "SOA and BPM have very different goals. SOA is about application rationalization via a service metaphor, and BPM is about business process analysis and optimization." They are not -- repeat, are not -- related, JP says.
A SOA-BPM union, forced or otherwise, may even create some big problems, he adds:
"This entanglement of SOA and BPM into a single effort is fraught with problems and failure. Each initiative should be undertaken separately and with definitive goals that do not list each other as one of the outcomes. If as part of the rationalization that SOA provides, there happens to be some services exposed that simplify the implementation of a particular business process, then that would certainly be a slam-dunk. However, SOA and BPM each have their own metrics of success and their own barriers to success. Combining them into one, well, the words 'boiling the ocean' comes to mind."
Plus, attempting to fuse SOA and BPM into one mega-effort is biting off more than most organizations can chew, he warns. SOA practitioners may see the mapping business processes into technology frameworks as the be-all and end-all. However, the BPMers are usually focused on other things, such as getting business units that may reside in separate continents on board with a redesign process. This is a bigger deal "than not having a Web service available to invoke," he says. As JP puts it, "SOA should not be viewed as the nail for BPM’s hammer."
JP's view runs contrary to what many other analysts/observers seem to have been saying in recent years, that while clearly still distinct and separate, SOA and BPM are coming together, and the lines between the two disciplines are blurring. JP argues that SOA and BPM should not be one single effort, which, from a digestible project management perspective, makes sense. And BPM can currently exist without SOA. However, there is a lot of work taking place on the SOA side in terms of architecture, which lays out the blueprint for the most effective deployment of technology to support business processes. Business leaders don't care if an initiative is called "SOA," "BPM," or "EA," or "DOA." They want an initiative that achieves faster time to market, streamlines an outmoded process, or improves front office productivity.