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.