The Register rather mercilessly skewers Malcolm Gladwell in a recent posting. I’ll grant them that some of his grand proclamations turn out to be a bit hollow (discussed previously) but is that enough to conclude that he has nothing to say?
I recently purchased Gladwell’s new book Outliers. Hopefully I’ll have time to read it and draw my own conclusions as most of the comments in the Register’s posting refer to statements he has made in public presentations/discussions.
As I was reading Martin Fowler’s post on ServiceCustodian I was struck by something that, in his words, didn’t smell right. After re-reading the article several times, I finally put my finger on it. He appears to assume that a service is no different than Java .class file or a .jar . Nothing could be further from the truth.
A true service should reflect a reusable business function, not merely some technical/programatic detail. As such, it should have a business owner who defines and controls what changes are appropriate to that function at a business level. Having coders making changes willy-nilly could prove disastrous to the business (but quite satisfying to the coders). It is unlikely that the business service owner will be able to understand the nature of a change from a patch (or even what a ‘patch’ was for that matter). There is no substitute for appropriate documentation and change control procedures to avoid errant changes.
This seems to be an increasingly frequent miss for coders: focusing on the code and what is convenient for the coder rather than on what makes sense for the business that they are supposed to be supporting.
Auto makers: instead of going, hat in hand (fresh from your private jet) to the government and asking tax payers for a bailout, why not go to your biggest benefactor: the oil companies? You have tacitly been in their service for the last thirty years if not more, cranking out bigger and less fuel efficient cars that serve to line their pockets with more and more cash.
Why does a minivan need to have an engine in it that is bigger than what was in a ‘muscle car’ back in the 60s? Do you really need a 2.5 ton pickup truck to drive down to the wings place and pick up a case of beer on the way home? ‘No’ to both.
So there you go: ChrysForGM can consolidate and be the demand side for the oil companies who will continue to pay them for their wasteful services. After all, the oil companies are flush with cash and government is still giving them corporate welfare checks. Please don’t let it be American taxpayers. Again.
To save you the time, here is the formula for a Gartner blog posting of this type: “_insert technology to be disparaged here_ is/will be a failure if it doesn’t solve a business problem and is technology for technology’s sake. It will fail even faster if you do not manage it properly and don’t have accountability.” Done. There you have it. No insight, no facts, just the same set of pro forma platitudes that have existed in the IT industry for years.
It is equally important to notice what doesn’t get written: ‘We (Gartner) told you to drop everything and run after this technology previously without making sure it solved a business problem, etc’.
I was reflecting on the state of the BPM marketplace while returning from Software AG’s Innovation World. It seems that, by and large, there are few consultants out there who can advise you on the actual implementation of BPM (the hard part) but plenty of them that can fulminate on the easier theoretical portions. For example, here is a relative plot of the marketplace as I see it:
The justification phase is easy, as it primarily consists of the same pro forma advise for any IT-related project: have an executive sponsor, get business buy in, don’t try to justify a big bang approach, blah, blah blah. Check.
The analysis phase is where the Lean/Six Sigma types will descend upon you with endless discussion of SIPOC and other jargon. Don’t get me wrong, this is a valuable analysis to have, it just does not solve the entire problem.
Then comes the actual implementation and the sounds of crickets in the field. For implementation, that favorite consulting cliche comes out all too often: ‘it all depends’. Well, yes, it does all depend, but if anyone has successfully implemented BPM even a handful of times, they should be able to begin to synthesize a set of best practices and guidelines in general and offer specifics in a given tool stack. This area is sorely wanting — in most cases, even the vendors can’t tell you how to effectively use their own tool stacks in any detail.
Assuming that you have navigated the rocky shores of implementation, there are any number of Business Activity Monitoring and Business Intelligence vendors who will sell you their wares to help you visualize your process data as executive friendly dashboards and portals. They typically have nothing to say about effective data collection and meaningful representation of data.