I've just finished up 4 new reports in my 2006 BPMS Report series: Lombardi TeamWorks, BEA AquaLogic BPM, EMC Documentum Process Suite, and Cordys Composite Application Framework. They should be going up on the BPM Institute website next week when the webmaster returns from vacation. The BEA report replaces Fuego; the others are new, bringing the total to 10, plus an overview report that explains the common evaluation framework and report format.
When you're deep in a hole of your own creation, the usual advice is to stop digging. But Assaf Arkin is not a slave to such conventional wisdom. He took a sound hammering on the comment thread to his original IT|Redux post where he states that BPMN should just be the diagram for BPEL 2.0, but he continues to dig in hard and reaffirms that process portability demands a common execution language, BPEL 2.
Paul Harmon of BPTrends weighs in on a worthy topic, how many perspectives do we need to describe a business process? He acknowledges that while "alternative approaches" like Role Activity Diagrams or the Flores-Winograd interaction model used by Action Technologies are useful in special cases, most of the time it would be better to standardize on a more conventional workflow perspective such as BPMN or UML Activity Diagrams. Sandy Kemsley expresses her agreement, while Derek Miers (in comments on BPMS Watch) has expressed the opposite view.
Unlike Sandy, I'm not "totally speechless," but on balance pretty surprised by today's announcement that IBM is buying FileNet for $1.6 Billion in cash. It's really about enterprise content management, but there are BPM implications. The ECM vendor landscape has been consolidating for several years now. There used to be 3 top-tier vendors -- IBM, FileNet, and EMC -- so now there are just 2. Usually M&A in the ECM space is about filling in a missing slot in the portfolio, like records management, imaging, media asset management, rights management...
This is different. IBM and FileNet both got started in CM via document imaging back in the 80s, and "fixed content" is still the strongest component of their respective portfolios, although FileNet tends to emphasize production imaging and workflow, while IBM emphasizes database and search architecture. EMC, the other competitor, has ramped up its own imaging and production workflow capabilities in the past year with considerable success (see my 2006 BPMS Report on EMC Documentum Process Suite when it goes up next week), so perhaps IBM is feeling the heat from that. Or beyond that, seeing the next generation of content management competition coming from database/infrastructure providers like Oracle and Microsoft, IBM is just bulking up.
Despite the inclusion of content management functionality in Gartner's checklist of BPMS must-include components, most BPMS vendors cannot even spell ECM. The few that can -- EMC Documentum, FileNet, Global 360, Pega, IBM -- generally had an ECM business long before they got into BPM. I've been thinking about it more lately as I finish up my report on EMC's Documentum Process Suite for the 2006 BPMS Report. And I see bits of it popping up lately in a variety of contexts:
After I posted re the piling-on Assaf Arkin was taking on IT|Redux over insisting that BPMN belonged to BPEL, the man himself posted a thoughtful response on BPMS Watch. I was waist-deep in real work at the time and didn't have time to think through an appropriate continuation of the thread, so I dashed off a quick response by email. That began an interesting out-of-band conversation that, if nothing else, narrowed the gap between the BPEL-si and BPEL-no positions, and shifted the debate from lofty analogies and name-calling to things reasonable people can at least discuss.
Even though I come off as the simpleton in the dialogue, I learned something about BPEL, so with his permission I reproduce it here. I haven't caved, but I think I understand the question better now. I'm hoping as the issues become more concrete, others can move the conversation forward more constructively.
[Here is my latest BPMS Watch column going up today on BPM Institute]
One of the core promises of BPMS is that it lets process owners on the business side model, monitor, and maintain their own process implementations. While chronically backlogged IT is hypersensitive to the charge that they take too long to respond to the changing demands of business, it still resists ceding to the business the power to maintain business process solutions themselves, much less build them from scratch. In fact, for many architects and developers the mere suggestion of business-driven implementation taints the whole BPMS concept. Yet business rule management systems (BRMS), facing similar issues, seem to have achieved a win-win for business-IT collaboration. How they?ve done it provides three valuable lessons for BPMS vendors.
Normally when the Ayn Rand references start flying, I head for cover. But since Phil Gilbert's rant on the futility of foisting an SOA primer on naive business managers tracked back to my post on what BPM on SOA would look like, I guess I'm obligated to say something. Phil's nominal beef is with the mere idea of a book called SOA for Dummies, which commits the sin (in his eyes) of equating SOA with web services and ESBs. The deeper issue, however, seems to be misappropriation by the SOA community of a value proposition that really belongs to something called Business Architecture, things like business-IT alignment, agility, reuse, etc. Business architecture, from his description of it, looks at business and IT together as an "organic" whole (with a slight top-down business-oriented perspective), rather than starting with IT infrastructure and then seeing what you can build on it.
So I guess he's sort of agreeing with my post (I can't tell), where I noted the inherent dissonance between BPM (top-down, business-driven) and SOA (bottom-up, IT infrastructure-driven). But he thinks that trying to explain technology to the business is a misguided approach:
While all BPMS vendors today mumble something about SOA, BEA Systems is one of very few that are making sense. They acknowledge that you can do BPM either with or without SOA, and that doing it without SOA is quicker and easier, but go on to say that as BPM deployments proliferate in the enterprise, doing it with SOA is ultimately better. And they provide software to do it either way. Quoting from CEO Alfred Chuang's August newsletter,
Today, as we work with customers moving to SOA and learn from their practical experience, it is becoming clear that although BPM can be effectively deployed without SOA, there is a strong synergistic benefit in combining BPM?s set of coordinated activities with the architectural benefits of SOA. ...
BPMS vendors love to throw a bone to SOA, and if you weren't paying attention you might even think that BPM on SOA was real. I've written at length about how BPM and SOA aren't enemies but natural allies, but they are allies with distinctly different goals and aspirations and mental models of the world. Kind of like America and France.
Following his post on the subject, I've been having a side conversation with Jesper Joergensen of BEA about what real BPM on SOA would look like. I admit I'm still trying to figure it out. Here's where I am so far.