Barely a Year Old, and ACM is Dead
- February 15, 2011
- 4 Comments
(Editor’s note: I’ll just apologize now for the sensational title)
Well, actually, Max J. Pucher is declaring ACM dead, and Adaptive as the worthy successor to ACM (“ACM is Dead! Long live ADAPTIVE!“). But the article overall is curious – because it marks an official departure from the ACM camp that Max has been alluding to in comments on various blogs and forums for months. Paraphrasing, he’s tired of fighting over the definitions of three letter acronyms, and tired of compromising and watering down the definition of the terms to suit all the various vendors who want to play in the space.
As he writes:
There was never a doubt that we all live in the ‘BPM State’, but we have different ideas how to govern it. Many ACM proponents feel that a lesser definition will allow to include more aspects and more vendors. That is a mistake. Opportunistic coalition governments of many different small fractions ALWAYS collapse sooner than later. I feel that we have missed the opportunity of truly advancing process management with the limited ACM approach. Dynamic Case and Process Management are now seen as like definitions to ACM. But it is not just about ‘unpredictable’ work items, but about a more globally encompassing technology approach that is linked to business architecture and strategy. I defined what I saw as relevant for business – and not as market segments or product categories – shortly after the ACM acronym was chosen in a post on Adaptive Processes. But so be it. I rather be Brutus and end this senseless debate to focus on what businesses truly need.
I think he has a point. ACM has been defined thinly (broadly?) enough that it could mean Twitter or Yammer (or nearly any social tech). Or it could mean Blueworks Live, or Appian. Or Asana. But Max is pushing for a more definitive take on something – and giving up on redefining BPM and ACM per se – he’s going with the Adaptive moniker or paradigm:
What cannot die is the ADAPTIVE paradigm, that – much as the principle ideas of freedom and democracy – will continue to guide those who do believe that people empowerment is the way forward. Those who believe in strict governance, because they can’t believe that people can govern themselves with a limited set of guiding rules, will have to learn the hard way. The dynamics of natural evolution will create the tension that will eventually break the chains of rigid processes.
In principle I agree with Max that empowerment is the right answer. But even “people empowerment” has different interpretations to different people – I’ll admit that although I read all of Max’ posts, I still don’t know what Isis Papyrus does, in detail. I just know the principles that Max has in mind that his product(s) support. (That’s probably better than knowing a set of functionality without knowing the foundational principles, however!) Interestingly, in Jacob Ukelson’s lists of risks of ACM failure in 2011, I don’t think fraying of the ACM community was one of them.
A Cautionary Tale of Two Names
Of course, any “name” runs risks. Working at software companies I often observed code names being assigned to releases. The code names meant something to the people who hear them – but the problem is, they often meant two different things to two different people. The release name implied particular features, initiatives, and bugfixes. The names became a shorthand for the functionality. What’s that? Waiting on support for Linux? That’s in the kubrick release. In the future, you just equate “kubrick” with “Linux” (and myriad other features that might be included).
But the product engineering team often has no such mind-map. The code name just ties to a release date. The exact set of final functionality is subject to change until code freeze. But this difference in understanding what a name means, presents all kinds of problems. One person thinks that because kubrick is shipping next week, they’re getting Linux support, and doesn’t even think to ask if it is still in, as it might have seemed like the defining feature of the release. But the developer just knows that kubrick is shipping, thinking nothing of Linux, and doesn’t even think to mention that Linux support was dropped a month or two ago in favor of a localization effort.
When the release comes out, you can imagine what happens.
One can argue that everyone should be looking at the release plan, which is frequently updated, to see the latest “in-out” of the release- but this just isn’t in everyone’s daily work routine. One can argue that engineering should communicate each change to the whole company – but when should that communique happen? Often these decisions are made and rescinded over a short period of time – and some of the changes are so minor that announcing to the whole company amounts to spam. It’s a challenge, but one that has to be managed to avoid these misunderstandings. And a good point of discipline is for Engineering to note use this codename shorthand for anything other than features that can not be dropped from the release.
What Does this have to do with ACM? or BPM?
My thought is simply that we have, already, an “all encompassing three letter acronym”. Its BPM. As Max says, we all live in a BPM state. The question is how to get the most out of it. Some say ACM. Max says “Adaptive”. I’d like to talk about it in more granular terms that defy a single phrase to rule them all. Because I fear that if Adaptive becomes the term du jour, the vendors (of which Max’ company is only one) will again butcher the usage and the meaning beyond recognition, or at least, beyond consensus.
I just think all of our energy is better spent focusing on solving problems for customers, regardless of what labels analysts and vendors apply to the work and to the products. I think I’m actually agreeing with Max on this, if I understand his posts correctly. I hope the broader community that lives within this BPM state will agree as well.
It looks like I’m not the only one who feels this way, as the Process Cafe’s Gary Comerford writes:
There appears to be a move in the BPM world to create a whole new substrata of ‘process management’. Max Pucher appears to be one of the leading members of this cadre and – like so many before him – he tries to establish a little niche ‘fiefdom’ which he can call his own. Andrew Smith from One Degree has posited Adaptive Process Guidance (APG) as a new paradigm too. Forrester have created Dynamic Case management
And bravo to them for doing that.
But here’s the problem I have: Why seek to split the capability of BPM down into different acronyms or niches when we don’t fully understand BPM as it stands at the moment?
Indeed. But the lure of a fiefdom is just hard for software vendors to resist (especially after a round of acquisitions). I’m not sure that that is what Max is trying to do – but the general tendency is there in nearly every marketing or PR release you see from a software vendor (“the leading <fill-in-a-narrow-intersection-of-attributes> vendor in the world”). Define things narrowly enough and you can be #1. But I prefer the approach a company like Apple uses. Sure, they could define their market as “touchscreen smart phones” in which they likely dominate in share. But they define the market much more broadly. It encourages them to set higher sights.
Is ACM dead? Not in the way you might think from the title. There is an avid community promoting the acronym, and the methods, that ACM acts as a catch-phrase for. Many an analyst paper and a vendor product announcement will discuss ACM for many moons to come. I guess the question is how much wind is behind the sails?