You can't judge a book by it's cover. Today we have autobiographies that turn out to be fiction, and we have fictional accounts of the truth. Why, these days, you can't even tell a book by the book.
I guess it's always been this way. Neither Hemingway nor Malraux could have been who they were without their participation in the Spanish Civil War... who knows how much of their fictional accounts were true? Theodore White and Anonymous both participated in battles of a different kind and wrote non- and fictional accounts of each, respectively. I tend to think that Anonymous's fiction was more accurate than White's non-fiction.
And then there was Hunter S. Thompson. I mean, can you say in. the. moment.? He didn't write fiction or non-fiction. I don't know what he wrote. Drudge meets Jonathan Schwartz maybe. The First Blogger. Hunter S. Thompson: Patron Saint of Bloggers. I miss Hunter but you can't say he ever let a fact get in the way of a good sentence. He didn't even let a good sentence get in the way of a good sentence. And as for history or trends... he'd shoot before worrying about such weighty matters. He just participated and then wrote about what he'd participated in. Or wrote and then participated in what he'd written about.
What's all this got to do with "process"? Well, nothing really. But there is the ever-present hype factor of technology, the myth of the silver bullet all told with the straight face of the zealot-vendor or zealot-open-sourcer. What's real and what's fiction?
Today I read Kiran K. Garimella's new book The Power of Process. I was pointed to it by James McGovern, who says it's "one of the most enjoyable reads I have had in a long time." Hopefully James meant "one of the most enjoyable business reads" he's had in a long time. If not, James, here's a few truly enjoyable reads of my past month: Carter Beats The Devil, Peter Guralnick's Dream Boogie: The Triumph of Sam Cooke, and And A Bottle Of Rum: A History Of The New World In Ten Cocktails. Less enjoyable but a solid business read is Patricia Seybold's latest: Outside Innovation (get it?).
Not wishing to bury the lead (led, actually, if you're a journalist) below the sixth paragraph: I recommend Garimella's book for IT people who are tasked with "selling" BPM to the business. It's an effective distillation of many of the concepts of BPM and does a good job of staying above the fray. I think some biases do come out a bit... but overall Kiran does a very good job of dealing with the big topics of SOA, Six Sigma and LEAN and their relationship with BPM.
The book is written in the fictional story-style of The Goal, so it is easy to read and because it's written this way, he's able to have characters ask the questions you'll be asked and delivers the answers without it being dry.
Overall, Garimella walks through the TLA's with humor and gives pretty much just the right amount of airplay to them. He does a great job of articulating that BPM is not SOA, and also that BPM is more organizational than technical.
But the book suffers from some confusion. Although at the outset, Garimella has one of his characters state clearly that the implementation is distinct from the architecture [of SOA], he routinely gets implementation confused with architecture (and process management) throughout much of the book. This is particularly evident when he talks about modeling and executing. His main BPM protagonist in the book correctly identifies MDA (Model Driven Architecture) as the basis for abstracting the Process Model from the real-world implementation, but he then drives right down to the [so-called] benefits of the BPEL execution language. MDA is, in fact, rooted in the belief that the model is abstracted from the implementation. They, in essence, have nothing direct to do with one another. The model is transformed into an implementation, and the implementation can be one of many.
For those of you who don't know my biases, let me give it to you straight: BPEL has nothing to do with Business Process Management. It has nothing to do with BPMN portability. It is an implementation language that, if used at all, generally impedes agility and increases cost.
However, the principles of MDA are the basis for modeling the business. MDA rests on the foundation of having a CIM, or Computationally Independent Model. This is where agility, portability and re-factoring are enabled - at the CIM level. The corollary to being independent of implementation constraints means that I am also able to choose different implementation mechanisms for different types of problems. Who cares how a process is implemented if the following exists:
-- we share a common understanding of the process ("share the model")
-- that common understanding is faithfully executed ("the picture is the process")
-- the common understanding can be shared with others ("the model is portable")
The more the industry focuses on implementation, the more BPM is just the same old thing.
In addition, as Garimella points out really well, understanding messages in the context of the process (call this "BAM" for now) is far more important than requiring a particular implementation mechanism. Thus, modeling using an implementation-independent model is key to modeling processes that live (and report, and can be managed) on top of many different types of systems, services and people. Indeed, for processes at companies of any size whatsoever, being able to model "above" the execution layer is required, given the investment and magnitude of existing legacy systems.
And now for a word from our sponsor...
Of course, OMG (the Object Management Group, an international standards organization) is "father of MDA." And, the OMG's combination of BPDM (for BPM models) and UML (for SOA models) are both standards-based, computationally independent models that deliver the flexibility and portability required for business and service modeling. Transformations off of these CIM's into PIM's and PSM's (simply, the mechanism under MDA whereby a computationally independent model is transformed into a deployable application using one of a number of implementation languages) can be made to Java, BPEL, etc.
And this, James, also answers another question you had a while back, I believe: I think you asked in a blog about your ability to transform from a MOF-based metamodel into BPEL or other execution languages? Yes, coming soon... look for progress on this from OMG sometime between December and March when BPDM is approved (it's final version has recently been submitted, so a vote is forthcoming) and also some good work tying BPEL, BPMN, UML and BPDM together... and you'll be able to measure your effectiveness at doing this within an upcoming OMG-based Business Process Maturity Model...
Kiran Garimella's book is a good read for IT folks needing some concise explanations to technical topics... and watch the OMG for other good news on the standards front about many of the things Garimella writes about...
Technorati Tags: BPDM, BPEL, BPM, BPMN, James McGovern, OMG