The end game is the same: Business agility, flexibility to respond to change, reusability to cut costs and increase...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
efficiency and closer alignment between IT and business.
The drivers of business process management (BPM) and service-oriented architecture (SOA) are quite different, though: BPM is a business-driven initiative whereas SOA is an IT-driven initiative.
And while one is an architecture and the other consists of tools and rules used to automate business processes, of late BPM and SOA are being used in the same breath. The reason? SOA is giving BPM new life and helping it to deliver on the promise of agility. At the same time, BPM is putting a business face on SOA and helping to bring the business and IT sides of the house closer together.
According to Gary So, vice president in the office of the CTO at webMethods, Inc. there are two different camps talking about BPM and SOA. "Some talk about BPM and SOA being diametrically opposed and competing for the attention of the enterprise," he said. "Others, like WebMethods, think of BPM and SOA as a new six-letter acronym. It's really two sides of the same coin. We see SOA as a catalyst for accelerating a BPM initiative."
Industry analyst Bruce Silver of Bruce Silver Associates said, "There are some uninformed people who say [BPM and SOA] are at cross purposes. It's more that they're orthogonal. SOA is a vague concept right now, but as it gets firmed up BPM will use it more and more. In that sense BPM requires SOA for at least its agility promise."
However, application like BPM will always be dependent on the underlying architecture, said Maureen Fleming, a program director for the business process automation service at International Data Corp. "There will always been a need to integrate applications and automate business processes. The tools will follow whatever architecture is prevailing in the market. SOA is the favored architecture. That means all companies that do application deployment things need to support this architecture."
But, she stressed, there is nothing inherent to BPM that requires SOA. "A business process may or may not be composed of services—you can do business process automation without SOA," she said "At same time, where it makes sense, you better believe companies are looking at doing things in a service-oriented way."
New lease on life for BPM
The concept behind BPM is to help organizations automate and optimize their business processes and performance. BPM products provide process modeling tools and key performance indicators to monitor and measure against operational targets. BPM encompasses both system and human workflows and BPM as a product market has been around since the 1990s.
"BPM as an enabling technology for rapidly deploying process-centric applications predates any concept of SOA in so far as BPM leverages whatever existing assets are in the business," said Rob Risany director of product marketing at Savvion Inc. "Whether you're exposing [that asset] via a Web services layer or a traditional messaging layer for doing integration, BPM sits on top and acts as a superset to the business community about what's available to the business."
While BPM is not new, "it's getting new life from SOA," said WebMethods' So. Providing a framework to manage the coordination and streamlining of manual activities, as well as automation of system to system activities "is where the rubber has failed to meet the road in the past with BPM," said So. "It's easy to make a nice picture of how you'd like an organization to operate around a business process and define metrics to measure that process, but where things have fallen down is how to make that happen in reality."
Aside from significant organizational and people issues, BPM requires getting the underlying systems to work together. "SOA is providing the foundational capabilities to make some of more hollow promises of BPM in the past more feasible" So said.
At the same time, BPM is making SOA more palatable to the business community. "What we hear as a frustration in the business community is that SOA has too much focus on architecture and not enough on business services. This increases the separation between business and IT," said Savvion's Risany. "Business people are sick of having business initiatives sacrificed on the altar of architecture."
BPM, Risany said, converges the needs of business and IT, and when SOA embraces that convergence and allows the business to be more agile, it resonates. "Our big customers see the tight relationship between their SOA approaches in terms of way they use components and the role BPM provides in allowing business to define the way processes work and the way to orchestrate the underlying components."
Software's newest tag team
According to Stephanie Wilkinson, manager of WebSphere product marketing for IBM, "BPM is one of the main entry points for the business side of SOA. SOA is about building reusable services. BPM is focused on business processes and management and how you do modeling and monitoring. You want to do all that on top of an SOA so you have a flexible architecture. They will be tightly linked."
One obvious link is the process model, said Anne Thomas Manes vice president and research director for the Burton Group.
"If you are doing SOA you should be taking a business process modeling perspective," she said. "Your design starting point should be what business processes do we want to execute?"
According to Ron Schmelzer, a senior analyst at ZapThink LLC, over time BPM and SOA will become more complementary. "BPM in general is the idea that we can model a business in terms of its processes and then represent them in a way that computers can understand and process. SOA has as its fundamental core the idea that business processes should be represented as services and then exposed as services so that different applications can consume and compose them in a loosely coupled manner," he said. "This means that as companies move to adopt SOA, they will necessarily implement BPM solutions as service-oriented versions, representing processes as services and BPM tools simply as service-oriented composition applications."
However, Schmelzer said, "That doesn't mean that BPM tools will disappear, but necessarily they will become service composition and composite application monitoring tools that assume that rather than outputting code or simply models for developers to use, they will output service-oriented metadata that is directly consumed by service-oriented composite applications."
Ultimately, BPM is about empowering business users to make changes based on business requirements, said Shane Pearson, vice president of marketing and product management for BEA Systems Inc. "BPM complements and is part of a broader SOA strategy," he said. "As we've gotten new technologies and standards, you start to see BPM products that allow business users to do more and more. This very much goes hand-in-hand with SOA, which exposes services or applications with the concept that they can be changed quickly. Business rules and BPM take advantage of that technology."
This makes SOA more interesting to the business side, Pearson said. "They can see how the applications they use every day are better because of the IT investment."
BPM and SOA infrastructure vendors are looking more interesting to each other, too. The next installment of this series will examine how they are reaching into each other's markets.