BPM and SOA need each other
Last week's post on SOA and business process management (BPM) ("Is there bad blood between SOA and BPM?") stirred up some thoughtful discussion across the blogosphere, particularly among industry watchers who strongly disagree that contention exists between the two camps.
I quoted the words of CIO Magazine's Chris Koch, who said there has been a long-simmering "war" between the business (BPM) and IT (SOA) camps.
Bruce Silver recently weighed in on the matter, noting that there is, in reality, little tension between the two disciplines, which, while converging, have distinctly different roles to play:
"Agility is important, and SOA is all about agility, but agility is really IT’s concern and not the central focus of business executives, nor is dealing with change the key objective of BPM. Better aligning processes with business goals; making processes faster, more efficient, and more reliably compliant with policies and best practices; making business performance more visible even when the process crosses organizational or system boundaries, and more actionable in real time… these are just as important as agility to business."
Where they do converge, Silver points out that "BPM and SOA are natural allies, not enemies.... True, BPM people and SOA people are concerned about mostly different things, but they are hardly opposing armies facing off with guns blazing," he says.
Silver adds that the issues arise when enterprises attempt to roll out SOAs before attempting to orchestrate the services. "BPM’s top-down model-initiated approach can actually accelerate the SOA rollout by fostering business-IT alignment with concrete performance metrics, and encouraging an iterative approach to the production implementation."
Phil Gilbert followed up on Silver's post with additional insights about the converging roles of SOA and BPM.
"BPM is not SOA, but that doesn't mean they oppose one another. They are distinct yet complementary platforms that, used properly, can help everyone in IT and 'the business.' SOA defines the way IT assets can be easily consumed by the business, and BPM defines their consumption."
Gilbert adds that for IT, "the benefits for the adoption (and promotion) of BPM are huge." He cites three advantages IT will see once a BPM effort is underway:
- Model-based definition: BPM promotes model-based definitions, which will ensure "absolute fidelity between what the business asks for and what they get." This model should be defined by the business, he adds, "as opposed to a BPEL-based articulation, which is a part of the SOA infrastructure."
- Prioritization of services. BPM helps avoid wasting time and money on systems the business doesn't need. Gilbert observes that vendors have often "led customers down the path of 'service enabling' a ton of legacy systems, only to find out after building, say, 1,000 re-useable services that only a few were needed by the business, that some that weren't built really were needed.
- Collaborative tools. A common set of tools and language used by both the business and IT sides will increase the "velocity of communication" across the enterprise -- always a good thing.