Barely a Year Old, and ACM is Dead

Scott Francis
Next Post
Previous Post
(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?

Tags:

  • Scott, thanks for reacting so promptly and wisely. Obviously, my title was chosen to be provocative. It is meant as a wakeup call. To remind all that we aren’t here to discuss acronyms or monikers. What I see lately is the senseless debate of who does ACM in what way and no forward looking direction. Where are we going with this any why?

    ADAPTIVE is not about markets or products but like with AGILE, which was clearly rooted in governance, to define an approach or paradigm, which is clearly rooted in an architectured model infrastructure.

    Obviously, i am not tryng to establish a fiefdom (this is really too funny) but define what I see as a business need in the realm of ADAPTIVE. I know that while vendors argument against my propositions, their R&D departments are busy trying to create the functionality I am talking about.

    I do however not agree that analysts are covering ACM, they aren’t covering ADAPTIVE either. They stick with dynamic or context-aware or else. Not one analyst has yet properly recognized that ADAPTIVE is about process-embedded goals and outcomes, linked to business strategy and architecture.

    Clearly, like with all my posts there will be the reaction that suits the reader’s own preferences. From ‘I told you so’ to ‘Max is a traitor to ACM’ you will find it all. Truly, I couldn’t care less. I had to say what I had to say.

    Thanks again for the consideration and feedback.

    Max J. Pucher

    • Hard to followup that comment! The fact that you don’t care what people think or don’t limit what you say on that basis is part of what makes your posts and comments so interesting (and, often, surprising).

      I think the comparison of your use of “adaptive” to “agile” gives me a better sense of what you’re trying to get at reinforcing adaptive (and, why it therefore isn’t about a fiefdom, from your perspective).

      Thanks for the note, as always! I really appreciate your commentary-

      scott

  • Pingback: Tweets that mention Barely a Year Old, and ACM is Dead » Process for the Enterprise -- Topsy.com()

  • The reason why I think we need step out of the shadow of the BPM umbrella is because, to most businesses, analysts etc BPM = BPMS. This means designing processes in a flow chart fashion, thats too rigid and not the case for APG, ACM or plain old Case Management type implementations…

    I also find it funny that most people who go on about ACM etc is BPM, often try to put distance between BPM and workFlow, when in reality, BPMS is more workFlow than anything else…

    Max’s definition of ACM really doesnt fit into BPMS as we know it, so having distinctive “terms” to seperate implementations or the way we tackle the same problem is a good thing. After some discussions with Max online re APG and his definition of ACM, its clear in my mind that ACM is “too restrictive” a term to get across his thoughts and ideas. ADAPTIVE seems a far better fit, and as such I wasnt surprised to read this blog at all…