I'm always coming across something that links SOA and business process management. I've shared many of these items with you, including discussions on how BPM can help solve SOA problems and whether you should start with BPM or SOA.
But to be perfectly honest with you, I never really questioned the premise: SOA and BPM are two technologies that go great together. I mean, just perform a search on the two. Almost everything you turn up, particularly with recent publication dates, pushes an alliance of SOA and BPM as solving all sorts of problems.
Note that I said, "Almost everything." The fascinating exception is blogger Steve Jones, the head of SOA and SaaS for Capgemini's global outsourcing business, member of the OASIS SOA Reference Model group, and author of a number of technology books, including Enterprise SOA Adoption Strategies.
I actually stumbled on Jones via a blog called "JOPX on SharePoint 2007 (MOSS and WSS V3 ), Office and SOA." Don't worry: JOPX isn't a language you haven't heard of. It's the blog name of author Joris Poelmans, a technical consultant at a Belgian IT Services company who does .NET development and work with SharePoint, Content Management Server and Project Server - at least according to his profile and blog posts. Apparently, Jones' contention that "BPM Screws up SOA" resonated with Poelmans.
Jones isn't particularly subtle with his opinions and you learn pretty quickly he's not a big fan of business process management anyway. And he has some very strong feelings about the whole "which should come first: BPM or SOA" debate:
BPM driven SOA tends to make bad SOA as it is driven from a procedural and process view, has poor separation of concerns and is mostly all about driving things from the technology perspective.
SOA makes great BPM, BPM makes crappy SOA.
He also believes starting with BPM just leads you to confuse a service with a step, and that's just wrong, he argues.
It's tempting to marginalize Jones' arguments, given how many analysts and vendors are shouting about the synergy between BPM and SOA. And the counter argument is that those too heavily vested in SOA don't really understand what BPM has to offer. But given his work with SOA and his role with standards groups, I think his blog deserves consideration.
Even if you disagree with his position on BPM, his blog is a great resource for moving beyond the "strategic overview" of SOA to understanding the actual architecture involved. Plus, he's not afraid to challenge the "conventional" views pushed by vendors.