
A couple of weeks ago, I was asked to review a new book on creating SOA-based applications. I was surprised to be invited to review a technical book because I am pretty lightweight technically. But I was also pleased that this blog has attracted enough readership so that the publisher thought a mention here could help get the word out about this new book.
Despite my trepidation that reading the book would tax my understanding of the technology (after all, I am a marketing guy, not a developer), I found reading Business Process Driven SOA using BPMN and BPEL (Matjaz Juric and Kapil Pant, 305 pages, Packt Publishing, August 2008, $59.99) surprisingly easy.
Still, to be very honest much of the technical discussion was lost on me. To my novice eye, the book is well organized and well presented. The initial chapter presents an excellent argument for developing SOA applications; later chapters move progressively from conceptual modeling to BPMN and then into the deployment of processes using BPEL.
My only regret is that the authors were forced to (I hope they didn’t want to) use the Oracle stack of products to illustrate many of the actual implementation considerations, especially when describing BPEL. Naturally, it hurts me to read all about a competitor’s product, especially when we believe ActiveVOS 6.0’s BPMN-to-BPEL integration is far easier to use and implement. Had the authors used the ActiveVOS visual orchestration system, they could have eliminated pages of Oracle product names descriptions and “when to use what” recommendations. Maybe the authors will consider changing for the next edition of the book.
But as I read the book, it occurred to me that my surface understanding of the technology actually made it easier for me to see the “theology” inherent in the BPMN and BPEL debate we so often hear about. Consider this passage:
The fundamental difference between BPMN and BPEL is also the reason why some tools have started providing extensible features…to allow a round-trip feedback loop between the business process users working in BPMN and technical teams developing in BPEL…This is a topic of debate, as we are asking our business community to think like a programmer and model business processes to create consistent technical output in the form of BPEL, which is unfair.
Here, the authors have the exposed the fundamental issue for creating SOA-based BPM applications: should the top-down, business-analyst creates-a-model-for-everything, BPMN view of work reign supreme? Or should the structured, execution-oriented BPEL approach to automation be ascendant?
My answer? It depends. If you are in a company in which the objective is 100% transparency of processes, in which people are told what to do and how to do it, in which creativity flows from the BPMN diagram, your approach is clear…and doubleplusgood. (And, yes, I have an opinion.)
OTOH, if you believe that computers are tools for people, that it’s better to let machines do the repetitive parts of a process while easily including less-structured human tasks, you have the choice of a different approach using BPEL and BPMN. And I think the choice has a lot to do with your company’s cultural ethos.
Still, what’s nice about these standards is even though they’ve been put together in a shotgun wedding and the marriage is far from comfortable, the union of these two technologies gives users ultimate flexibility to implement SOA applications as they prefer. And as a book to illustrate how to implement these choices, you can’t go wrong with Business Process Driven SOA using BPMN and BPEL (as long as you don’t use Oracle stuff to do it).