BPM + SOA = Serious Corporate Cost Cutting Potential

Loraine Lawson

Eric Koch, a CTO who blogs at IT Toolbox, made an intriguing observation on his blog yesterday. He wrote about a recent TechTarget SOA adoption survey which showed integration is the most cited reason for adopting SOA. But, he noted, the second most-cited reason is Business Process Management.


Koch contends that BPM is actually the "next level of maturity from an application perspective" for SOA, after integration. And, really, all three are linked together:

This is just the common sense approach to using SOA to improve application integration, thereby reducing maintenance and support costs within IT and reducing duplicate data entry and errors for the end-users. And using SOA to improve business processes to reduce labor costs and improve productivity is the next step after integration -- end-to-end process automation most often requires integrated systems.

Now, I'd already written about the survey's integration findings, but I skipped over the BPM stuff. After reading Koch's post and doing a little more digging, I've seen the error of my ways.


You may be wondering why it matters which three-letter acronym you embrace first. Here's the deal: Business Process Management is emerging as a useful tool for cutting costs. In fact, despite the economy, more than 500 executives turned up at Gartner's recent BPM conference to learn how BPM can help them "surgically and intelligently remove costs through quick and precise actions," as Gartner analyst Jim Sinur noted on his blog.


You can read Sinur's post to get a general idea of how BPM accomplishes that, or, if you prefer specifics, check out how Forbes' JargonSpy explained BPM. For the case study devotees out there, there's also this Baseline Magazine feature detailing how Enterprise Rent-A-Car used BPM to create a common platform and streamline their workflow.


If you don't want to do all that reading, the overarching theme here is that companies are successfully using BPM to find ways to save and make money. The catch is, for the BPM tool to give you the information you need, it's got to be able to talk to your other systems-and that requires integration. Tons of it.


Previously, if you wanted to do BPM, you just had to do a lot of custom code, according to Sandy Kemsley, a BPM consultant and Column 2.0 blogger. But if you've built a service-oriented architecture, or really just service-enabled your applications, then you can cut out all that nasty integration work and just have your BPM tool call, or consume, the services instead, as Kemsley explained in a March on-demand webinar.


Now, I'll be honest with you: I hate webinars. They take at least 30 minutes and usually cover material that I could've read in five minutes, on a slow day. In my book, that's a poor information-to-time ratio. So, when I saw it was a 33-minute webinar, I wanted to crawl out of my skin, but I stuck with it. And it was actually really good. It cleared up a lot of questions about what BPM does, how the tools evolved and work, and how BPM fits in with SOA. I even made it all the way to the summary, so kudos to Kemsley on that one.


In it, Kemsley explains that organizations often deploy BPM after SOA or start with BPM and move to SOA. There are problems with both approaches, which is why she suggests taking a hybrid approach. By developing BPM and SOA in tandem, you can actually make better progress on both, she contends. This is because BPM can help you prioritize your services, which can force you to be less application-focused when building services. And because BPM will consume the services you've built for SOA, you've got a bit of a boost on SOA's return on investment.


It seems to make perfect sense, but I'd be remiss in my duties if I didn't point out that not everyone thinks BPM is so great for SOA.


Still, Kemsley makes a convincing case for developing BPM and SOA in tandem. If BPM continues to build a reputation as a cost-cutting, money-making initiative, then SOA might get a second wind.

Add Comment      Leave a comment on this blog post
Apr 2, 2009 4:57 AM Anthony McClay Anthony McClay  says:

SOA should not need a lift from BPM, but I am a fond believer that the combination will help drive business solutions. 

The Evolution of a mature SOA environment is reached when the services being created are in line with the business needs.  There is no better way to expose those Business Level task Services, than through standard SOA technology.

This is why the stronger of the SOA vendors also have very strong BPM tools as well.  Such as Tibco's SOA Active Matrix Environment and their Tibco IProcess BPM tool set.

The combination can be very very powerful.  I am sure this is the same with other vendors and the mixing of the vendors as well.  SOA environments produce standard SOA (http/soap/wsdl) interfaces no matter the vendor, but the BPM tools usually run in custom engines.  Most use the standard BPMN notation, but the operating engines are different. 

A very powerful combination.

Apr 2, 2009 8:46 AM Sandy Kemsley Sandy Kemsley  says:

Hi Loraine, glad to hear that you made it all the way through! At the rate that I talk, I probably cram in at least 10 minutes of material into a 30-minute podcast.

Apr 3, 2009 10:22 AM Chris Schulz Chris Schulz  says:

Interesting article. Combining BMP and SOA efforts seems so self-explaining and obvious. Excellent Webinar by Sandy Kemsley, some really good points, worth the trouble of registering for the on-demand webcast. Thanks for that. Is there a transcript btw?

Also @ Loraine, you are mentioning that "not everyone thinks BPM is so great for SOA" referring to a blog, however the link doesn't seem to works. What source or blog where you referring to?

Apr 3, 2009 10:33 AM Loraine Lawson Loraine Lawson  says: in response to Chris Schulz

Here's the link:


Not sure why it didn't insert. I'll try to get it fixed.

Apr 14, 2009 1:41 AM Cameron Chehreh Cameron Chehreh  says: in response to Loraine Lawson

Loraine I am glad to see the attention this is now getting. 3 years ago when SOA was becoming popular we built a prototype that leveraged the best in class ESB and BPM tools. This prototype linked a CRM system to an HR and Finance system. We found that although SOA and the tools to execute it are a step forward, the only way to really bridge the chasm was to couple the ESB with a BPM tool. This solution provided enterprise level orchestration of services rather than application specific. The only drawback was WS-Security and security payload. 

The heart of this discussion is not technology but rather business process. This further illuminates the need for us as technologist to become business technologist and invest the time to understand the business workflows and compliment them with technology. Glad to see this focus. Cheers


Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.