For me, the most troubling part of the BPM Think Tank event was my roundtable on The Business Value of BPMS. The roundtable format was an open-ended discussion with 10-12 attendees on a specific topic, formulating a problem statement and then a proposed ideal future state. I expected a discussion about which of BPMS's putative benefits -- business/IT alignment, process efficiency, compliance, agility, and performance visibility -- was most valuable to the business or had some issue blocking full realization.
No I don't mean moblogging. More like "even my 79-year old Mom is into blogging." Not about BPM (that would be scary), but the more invigorating throw-da-bums-out-in-Washington variety. So over the weekend we both went to the YearlyKos convention in Las Vegas, where 1000 of the top political bloggers and their subscribers -- along with a surprising number of big-name politicians trying to grab onto the "netroots" wave -- got together face-to-face in a bunch of panels, workshops, and general socializing.
Don't ask me how, but Ismael turned the hubbub over BPM vs SOA into a discussion of top-down vs "middle-out." Both threads (including comments) are semi-instructive, but somehow in the course of things he challenged me to come up with proof that top-down (i.e. BPM implementation driven from the business model) has ever worked. The challenge came in the form of a double-dog dare, with the promise of a trip to Hawaii tacked on if I could come up with 3 top-down implementations that met his "
I've been focusing a lot of my publishing and marketing -- monthly column, 2006 BPMS Report, BPMS training -- in the past year through BPM Institute, which is owned by Brainstorm, the conference group, and now I'm thinking about next year. Which BPM portal do you think has the widest reach, most interesting stuff, is best to deal with, etc? Take a minute to vote in the poll in the blog home page sidebar.
Derek Miers called my attention over the weekend to two posts from the SOA blogosphere suggesting "bad blood" between BPM and SOA, framing it as the latest proxy war in an age-old struggle between business and IT. I suppose Derek, who doesn't blog himself (yet), wanted me to point out how ridiculous this is (or at least embarrass myself trying). Anyway, I'm taking the bait.
The original cherry bomb was thrown by Christoper Koch in CIO Magazine's blog, who described BPM vs SOA as "a new front developing in the war between business and IT," and Joe McKendrick on ZDNet quickly poured gasoline on the flames. Koch tries to set himself above the fray but tips his hand by centering the discussion on business's frustration with IT's lack of agility and concluding that SOA is more likely to foster agility than anything he sees from the BPM camp. Thus, like most discussions of BPM from the SOA world, he gets a few facts right but generally misses the point.
Agility is important, and SOA is all about agility, but agility is really IT's concern and not the central focus of business executives, nor is dealing with change the key objective of BPM. Better aligning processes with business goals; making processes faster, more efficient, and more reliably compliant with policies and best practices; making business performance more visible even when the process crosses organizational or system boundaries, and more actionable in real time... these are just as important as agility to business.
Also summaries of the roundtables. Check out this from OMG.
Richard Brown, an IBMer from across the pond, blogged recently about BPEL4People and took issue with my contention that it was too grandiose and after-the-fact to achieve wide adoption as a standard. He tracked back to my original post in February, saying I'm increasingly of the opinion that standardisation often occurs too soon and that major revisions are a reflection that the initial specs fail to anticipate potential problems or extended use cases.
As if we needed more evidence that BPM and SOA are uneasy allies, one of Steve Jones's SOA Anti-Patterns, widely praised in the blogs for their hilarious wit and insight, seems to me a perfect example of how some architects still view BPM's top-down approach as worst practice, not best. The "percolating process" anti-pattern is described this way:
The following is my latest column for BPM Institute:
You can?t attend a BPM conference or webcast nowadays without hearing how SOA provides the critical technology underpinnings of BPM software. And there is even a grain of truth in that statement. For example, most BPM Suites provide integration adapters that can introspect backend systems and turn them into process components that are, in an important sense, service-oriented: Regardless of the internal platform, programming API, or data model of the backend system, integration adapters can expose functions of those systems via XML parameters, perhaps even an actual WSDL, and allow the process engine to orchestrate them without code. That?s huge, really the key to making application integration more agile and enabling point-and-click composition of end-to-end process implementations.
But in the SOA world, that?s not really SOA.
Yesterday Gartner unveiled their magic quadrant for BPM Suites. For those unfamiliar with the format, it's a square in which the horizontal dimension represents "completeness of vision" and the vertical represents "ability to execute". Only BPMS products meeting Gartner's feature/capability checklist are eligible to compete. The evaluation is generally via a questionnaire and interviews and the result is a dot somewhere in the square, which is divided into 4 quadrants. The upper right "
