Peter Schooff once again asks the provocative question: “Will case management eclipse BPM in importance this year?”

The answers were pretty interesting.  I guess I should first own up to my own:

Short answer : no.

More thoughtful answer : When people have trouble listing which products are ACM, and which are BPM, and which are both, the “ACM” tag has some work to do to eclipse BPM. Even as it grows, it is perceived as part of BPM, not separate.

Of course, BPM took a decade or more to come into its own. I don’t think it comes undone overnight.

It isn’t easy to fill in the white space.  It is harder to design a good software solution from scratch than to fix a bug in an otherwise working solution, or to design a small addition to a working piece of software. What if you could have tools that just help you right away, and then later infer the process (filling in the white space for you)?  That’s the promise of “process mining”.

Along those lines, Dave Brakoniecki tackles the idea of “inverting the process life cycle“, in response to a post by Keith Swenson on the subject:

Imagine a patient file or case. This is a favorite example in the ACM space since the expertise of the doctor defines the process or work to be completed. How useful to the doctor is a case management tool that has no information on the patient and no ability to schedule tests? Not very – all of the work would need to be done outside the tool and duplicated in the tool. Still, building integrations to the patient records and to the systems that organize blood work, for example, would be better done at design time than run time.

Even if this was possible at runtime, few doctors would be interested in doing it.

(incidentally, I think this is why something like IBM Watson is getting good airplay in medical / healthcare circles.  It has data and context on a subject domain)

So, a lack of preloaded or pre-integrated data seems like a problem. But supposing you have this pre-existing data, there are a small number of firms prepared to help you discover the processes you are already executing without realizing it.  It isn’t yet clear to me how big these services projects are (there aren’t any shrink-wrap solutions that require no services).

And Dave points out another issue:

In most organizations, what is problem with their Sharepoint deployment, their Lotus Notes application or that little Access database application they wrote three years ago? In almost all these cases, the problem is the same. End users were given a powerful and flexible tool without training and ending up building a system that is impossible to maintain but essential to the business.

I have seen many successful projects start from this position: The end users actually asking for more help in managing the technology so they can spend more time doing their jobs.

This is summarized nicely as “the Sharepoint Effect” in a previous post on this blog.  And I agree with Dave – many projects start exactly this way.

Then Dave gets into what might be an example of ACM in the wild – Basecamp.  Although it doesn’t bill itself as an ACM tool, one could argue that it is one, by accident.  In which case:

Perhaps the most important reason for the ACM camp to try and adopt a solution like Basecamp is that it would give them immediate mainstream legitimacy with tangible customers who have already inverted the process life cycle and will do it again next week. It probably also indicates the delivery model and price point required to disrupt the markets they are targeting.

I’m not sure the ACM vendors are prepared to be at those price points, however.

Keith makes some interesting points in his original post, not all of which are argued by Dave.  Certainly measurement before improving is A Good Thing.  We’ve been implementing “shadow processes” and listening to processes implemented in other systems for years, and using that data to inform our new process models.  But because we’re listening to real systems, we have to implement the broadcast or listening of those interesting transitions in the systems of record.

In short, there’s no magic bullet. But you can certainly do better by measuring twice and cutting once, as they say.  But we can do better than that. We can measure any number of times, and we can get more than one “cut” at the new and improved process by leveraging A/B testing to determine what actually produces the best results.

In a flurry of posts recently there’s another attempt to sever ACM and BPM.  It’s a strange urgency among some ACM advocates to separate it from the idea of managing business processes.

Keith misinterpreted my recent post on ACM/BPM – confusing product efforts by software vendors with implementation and execution efforts by business users.  Bruce Silver and I are speculating about whether “ACM” will really exist as a distinct market from BPM – and we both doubt it.  Keith is questioning whether doctors and lawyers should use BPMN.  A bit unrelated.

In another post, Keith attempts to put the wheels back on the track.  But Adaptive Process advocate Max J. Pucher notes that he sees a benefit to customers in a holistic solution – and goes on to advocate his own company’s approach:

Therefore I do not see a clear distinction between ACM and BPM, except that a BPMS cannot perform the kind of ACM user-driven processes that you describe so well. My recommendation of a homogenous system that does both really well is not only driven by my product orientation. Remember? I don’t have to sell what I have – I develop what empowers people!

I see it the opposite way: The only reason people have to keep ACM and BPM as independent functions are sales perspectives or BPM design or consulting skills that might become obsolete. From a business benefit perspective, a homogenous solution that also encompasses architecture, content and rules is the only thing that makes sense. Agree? Whether this is easy to sell or argument from an existing BPM mindset is a completely different story.

If it is a single solution, it really doesn’t matter if ACM and BPM are separate or the same.  It just matters whether you can solve the problem for the customer – or not.  Or if the customer can solve the problem for themselves – or not.  I believe Max’s firm is in competition (in a sense) with BPM vendors – because they’re both competing for a market around improving business processes.  Max’s competitive differentiators are related to the adaptive way his firm approaches this subject.  A company like IBM will pitch different differentiators for their product offering.  They may coexist in the market or within customers, or they may compete.  But so far this looks like one market to me. I might have more faith in BPMS based on my personal experience, than Max does – but in the wide angle view I see more agreement than disagreement in terms of what BPM is (versus what a particular product can deliver).

Jacob Ukelson proposes to call this area “knowledge process” instead of ACM.  I expressed a bit of my frustration with this distinction, though I generally sympathize with his frustration as well! -

As I mentioned on twitter, I don’t think the problem is that they got in the weeds on features. The problem is that ACM folks got too caught up in trying to prove that BPMS can’t do ACM – which is silly. Or worse, that ACM was superior/above/better-than BPM – which again, is just a silly argument to get into. Like arguing that BPM is better than SOA – they’re either complementary or competitive and if they’re not competitive than better doesn’t really have meaning.

Knowledge work is business work, last I checked. business people describe knowledge work as being part of their business processes. Fighting a definition battle that isn’t worth fighting. Go ahead and convince customers that they don’t have a sales process. That it is, instead, a sales knowledge process or a sales case management. Or that they shouldn’t apply process improvement techniques to aggregate outcomes.[...]

I keep hearing from people about what isn’t the answer… but not hearing much about what is  unless it is a plug for “read the book” or very high level – as you say – principles – which of course could just mean “use email”.

I think the ACM discussion has been useful in that it reminds people that BPM shouldn’t be just about automation and eliminating human work. But to me, separating ACM from BPM is a bit like saying that what’s good for the goose isn’t good for the gander- that some work (usually whatever work we envision ourselves doing) isn’t subject to the same general rules as the work others are doing. My work is creative, but their work is not. My work is knowledge work but their work is routine.

I promise you, all work that involves people involves creativity, passion, skill, energy, pride – or the lack thereof. Our goal should be to reduce the mundane and routine, and allow the people to focus on the creative and expressive and decisive. We could argue over ACM vs. BPM or just agree that BPM and ACM are two slices of bread in the same loaf.

Just because I don’t use a BPMS to tie my shoes doesn’t make it knowledge work.  Nor does it mean it isn’t a process.

Keith has posted a summary of his notes from Forrester’s BPM Forum – great read and good insights into several topics – in particular he has a great writeup of Derek Miers’ session on designing your BPM engagement program around the customer experience:

He draws a correlation between process maturity and focus on customer experience. Maturity level 1-2 cost reduction is the top category (74%). Level 2-3 customer experience is the biggest. levels 3-4 and 4-5 customer experience remains high but value innovation becomes most important. Waste elimination remains that the same levels at all levels. The “ah-ha” moment was that if at level 2-3 you don’t focus on customer experience improvement, you will never get to level 3-5. (Survey is mostly business people, not IT – Forrester/QPC business process maturity survey)

Looks like a great day of sessions, but I agree with Keith that 7:30am is inhumane in any timezone.

Keith Swenson just put out an interesting blog post on Self-Organizing Business Networks- there’s a focus on what makes for enterprise social software, and what the “social” part really means.  But this particular bit caught my attention:

Most current systems are built in such a way that they require a technically knowledgeable person to make these reconfigurations.  I am NOT suggesting that we simply open these capabilities up to business users.  Instead, I am suggesting that the system should be built from the very beginning to allow this kind of change; so these changes are safe for users to do.  It needs to be easy as well.  A system that requires coordinated changes in multiple places (such as adding a network user, and adding them to access control) is going to be difficult and error prone.

Directionally this is right – it isn’t about exposing business to the complexities of IT administration, it is about writing software, apps, or mediums that don’t require such technical reconfigurations.

There’s an argument that says the world is too complex for humans to understand.  Further, that by thinking we understand cause-and-effect, we’re doomed to act in ways that have unforeseen (usually negative) consequences.  It is a really interesting debate, and informative on the more than two sides represented.

Personally, I found myself rejecting this notion as useful.  Not that the notion of complexity isn’t useful – but letting it paralyze you is not useful.  When it comes to running your business, simplicity is more powerful than complexity.  A combination of relatively simple interactions has more power than a complex single interaction.  Simple interactions are more replicable, more scalable. I would focus more on enabling “emergence” than disabling decision-making by leaders.

Simplicity and abstraction go hand-in-hand.  The iPad has a significant amount of complexity baked in – from the hardware, to the software, to the production processes that lead to its creation, to the design processes that lead to its conception.  But to me, it is just a glossy glass enclosure that responds to my touch.

Does my touch cause the apps to do what they do?  Actually, it doesn’t matter whether touch is causal or not – it is, at minimum, so highly correlated between action and reaction that it feels like causation.

And that’s what we should be striving for in our businesses – that our actions would achieve the results we’re looking for – will feel like causation – though there may be a complex choreography and it may not be driven top-down.

There was a truly fantastic quote in the original HBR article:

“If you want to build a ship, don’t drum up people together to collect wood and
don’t assign them tasks and work, but rather teach them to long for the endless
immensity of the sea.”

- Antoine de Saint-Exupéry

Sometimes simple is best.

Not that long ago, one of the prime examples given by Keith Swenson in support of the “ACM approach” was a medical example (picture Dr. House examining the really-out-there cases) – check out the comment stream from this post for background.  Jacob Ukelson and I, not long after, proposed a way to think about ACM and BPM approaches in a complementary fashion – where ACM is concerned about an individual case, whereas BPM is concerned about the aggregate of all “cases” or processes.  I used Keith’s medical analogy to make my point.

From twitter (thanks @elliotloh), I ran across this PBS story on a Denver Hospital that fairly well proves my point with respect to hospitals. There’s video, but I’ve quoted a few passages below.  First, what was the outcome of this focus on aggregate quality of care?

DR. PATRICIA GABOW, Denver Health and Hospital Authority: What that translated to at Denver Health last year is that 213 people walked out of here alive who would have been expected to die. So, that makes the statistic into a very personal aspect for people who, in fact, lives were saved.

Think about that – 213 people alive today that statistically, would have passed away at the average hospital.  And they’re not cherry-picking the patients and doctors, as the following passage demonstrates:

DR. DONALD BERWICK, Center for Medicare and Medicaid Services: They are getting levels of performance that most of the rest of us in health care can only envy. The vast majority of their patients are either uninsured or Medicaid patients. They deal with a very, very stressed population. And they are proving that that kind of care isn’t just kind of good enough. It can be the best care — actually, the best care in the country. They are showing the rest of us what’s possible.

But was this process improvement effort really goal-driven? (emphasis added in italics):

BETTY ANN BOWSER: One of Berwick’s chief goals is to reduce hospital-acquired infections in the next two years.

Was this really anything at all like a BPM project? Well sure it was, absent the BPMS software (emphasis added):

BETTY ANN BOWSER: CEO Gabow wanted a cultural change, so she brought in a team of efficiency experts from the business world and asked how they solve problems.

Out of that grew adoption of the Toyota automobile production system’s Lean principles, to eliminate waste, fix problems, and promote constant improvement.

WOMAN: So, as a group, we’re going to process-map it. We’re going to identify your waste. We’re going to pick part those defects.

It sounds pretty familiar, doesn’t it? And they looked at process times, steps, measurement, alerting -  not the checklists a doctor might operate from, or a nurse, but the systemic approach to the overall care-giving processes:

SELEEM CHOUDHURY, Denver Health: People come in and they are sick. And when they are sick, we need to see them as soon as they arrive upon — you know, upon arrival.

And so we had to reexamine our process. We got Post-it notes — we put them on the wall — from every single aspect, from walking through the door, to seeing the nurse, to going through registration. And we had up to maybe two hours’ wait to be seen for that process. And just by making some simple changes, we cut that wait time by half.

(It does pain me a bit to see that they had to resort to post-it notes rather than software…)

But what is driving this change? A change to Medicare payments – tying them to efficacy and safety rather than just performing a service.  This is going to force hospitals to re-examine how they provide care and think about how to serve patients more effectively.  Of course, we can bemoan the fact that it takes a financial incentive to drive this change in quality of care, but maybe we should take improvement at face value, whatever the driving force behind it.

I missed this post from Keith Swenson the other day, as he responds to Anatoly’s post on ACM.

Keith cuts to the chase:

Anatoly Belychook asks the question: “is ACM a Paradigm or a Feature?” I could not resist responding because I like the post, and his logic is flawless, but it is based on false assumptions.  I think there is a lesson here on why so many BPM experts feel the way he does.

First, his summary of Adaptive Case Management (ACM) is one of the best I have seen.  There is no doubt that Anatoly understand the motivations behind ACM.

What he does next is quite surprising; he analyzes whether ACM meets certain requirements of BPM.  That is the flaw in his thinking: there is no reason to believe that ACM should meet the requirements of BPM.  Many BPM experts  start with an assumption that ACM should have BPM-like features, and then move on to conclude that ACM is really just a type of BPM.  Those wanting to understand the subject should be wary.

Hm.  I would have phrased this differently- it isn’t that Anatoly’s assumptions are wrong – its just that the exercise Anatoly takes on is looking at how to satisfy BPM-style problems with ACM-style claimed feature-sets.  Anatoly would state it differently: How to satisfy enterprise level problems his customers are asking him to address, with ACM-style claimed feature-sets.  And, to consider whether you can solve enterprise style case management problems without paying attention to key issues of architecture, data entities, process architecture, etc.

The comments section reveal a very interesting discussion between Keith and Anatoly – well worth reading (thankfully BPM and ACM posts do not get cluttered with 100′s of comments like tech crunch articles!).

In one of his comments, Keith wraps with:

Hopefully this clarifies my point: while ACM capabilities may be a feature of a BPMS, ACM in general is not JUST a feature of a BPMS. To say the latter would be misleading.

Given that ACM describes an “approach” rather than a technology, of course this is true.  Likewise, BPM capabilities are not just a feature of a BPMS… I’d consider this a tautology.  I think what Anatoly was exploring is whether ACM software will survive as a standalone / separate market, or whether it will be collapsed with BPM software as a market. (Thus, feature vs. paradigm)

I might be projecting my own impressions onto his writing, however.

Interesting conclusions in Keith’s post, first this bit:

• BPM needs process architecture, ACM has no such need
• In BPM the person who designs the process needs to be a data architect, but in ACM these are different roles.  The person who designes the “process” does not need to be a data architect.
• BPM needs strong capabilities for integration, but in ACM there is little or no need for field-level integration.  ACM can work well with documents,  reports, and links to other application user interface.

And Keith asks: isn’t this enough to make it different?  Well, in technical terms, no.  But in terms of “approach”, yes. You can implement (and I have implemented) processes that required no “architecture”, “data architecture”, nor “integration”.  Typically those aren’t the kinds of processes people pay consultants to help them develop however, so I haven’t worked on that many of them. But it is definitely a different approach to start with the assumption that you won’t do these things.

Keith wraps with:

BPM systems will gain ACM-like features, but few doctors, policemen, and lawyers will use that.

Social Business Software like Jive, SharePoint, Quad, Chatter, and Connections will gain ACM-like features as well, and will be far more successful than the BPM systems, because those are systems that the doctors, policemen, and lawyers will use.

How funny.  I end up agreeing it is a feature of something, just not a feature of BPM.  :-)

I, too, find it ironic that Keith finally agrees ACM is a feature of something else (from a technical perspective)!  I think, by extension, ACM can be considered a (potential) feature of BPM.  And Keith may be right- that doctors, policemen, and lawyers will be using one of these other products (SharePoint? I doubt it) – but I wouldn’t jump to the conclusion that they won’t see BPM in their lives given all the government investment in process that’s happening.

Update: the discussion has moved to ebizQ now, thanks to Peter Schooff.

The argument over what a process is continues.  As well, the argument over what is BPM and what is ACM.  Two articles recently on the subject.  First, Michael Poulin argues that all process is structured, and that ACM is not about process at all, but about managing the unknown or unexpected:

ACM is not about process management due to the absence of the process, it is rather about a management of consequences of unpredicted events, which itself is very important business task.

Well, look.  It is an interesting attempt to define ACM – it just happens to be a different definition than all the other ACM thought leaders have been using as an operating model.  Maybe the ACM folks will take up his definition – maybe not (I feel that, as someone not classified as a proponent, I shouldn’t be the one to define the term.  Though I did suggest what I think ACM is about, vis-a-vis BPM, at one point… and at an earlier point).

Then Keith Swenson weighs in – and seems to largely agree with Michael’s discussion – I think for two reasons: first, it has a very narrow interpretation of process, and second, Michael provides justification for arguing that even well-understood processes may not be as well-understood as people think (and therefore perhaps they need to be re-examined as being ACM!):

He says “But, wait a minute, do we know what/why we do things? Do we really know the logic of our actions?”   Truth is, we do thing[s], and then later rationalize why we did them.  However, it is not clear that that rationale is in fact the cause of the actions.

So, now the argument seems to be that we’re just rationalizing a set of actions after the fact, rather than contemplating a plan in advance. The ability to see the structure and organization of what we do is a good thing – a key organizing attribute of businesses and people.  Somehow Keith has made this sound like a deficiency instead of a beneficial attribute (it might not have been his intent, but that’s how it comes across). Being able to describe a complex interaction as, instead, a smaller set of high-level actions, is a huge benefit to humanity’s ability to understand the world.  And the fact that BPM leverages that capability is hardly a deficiency, for example.

Moreover, Keith uses an art metaphor:

When an art student first attempts to draw an outdoor scene involving a tree, they commonly will start by drawing a line around the tree.  That line does not exist in reality, but it is a construct of the mind which automatically classifying what you are seeing.  The tree “looks” separate from the surrounding, because we understand that the tree is a separate entity from the mountain behind it.  The art student must “unlearn” this habit of drawing in the borders between conceptual things.  Such unlearning is not trivial.

There is a fair amount of “unlearning” when learning to draw (or paint).  But there IS a process for sketching landscapes, versus sketching portraits.  Growing up, I observed that my sister could take a picture of something and sketch a photo-realistic copy of the same thing scaled up or down in size (I thought that was quite amazing, being the little brother).  It was hardly assigning method to the madness after the fact – she had a plan before pencil touched paper.  There were even a standard bag of tricks for incorporating or correcting any mistakes.

Keith Swenson’s article on the fallacy of flexibility makes a good case for lean software development and the Lean Startup:

This article is about software design, and makes the case that flexibility for flexibility sake should never be your goal.  There is a very delicate balance between design and implementation in order to provide both usability and capability when it comes to software.  Flexibility is often held up as a axiom, but flexibility should be provided only to the extend that it is actually needed by the end user.

I’d put it slightly different: flexibility should be provided to the extent that it is either less work, or actually providing value to the end user.  In that order.  If the absence of doing something yields flexibility, that’s good.  But if you design your software to solve hypothetical situations that have yet to manifest, you run a real risk of overdesign (and over-engineering).

Keith goes on to document a set of rules to keep software simple and maintainable, including removing outdated functionality.  You could sum these up as minimizing technical debt (or in BPM, process debt). The less debt you incur, the more maintainable (and less costly) your code base will be going forward.  The more debt you retire, the better, generally speaking (but, there are trade-offs to retiring debt).

The key insight:

What I am trying to say here is that our normal intuition about the value of designing up front is wrong most of the time when it comes to software because it is not like a physical production process.

So true.  Great read, I recommend anyone technical read the whole article.  If you’re not technical, you might want to read it anyway – it will give you insight into how much the flexibility ideas of your technical staff are costing you.

Great blog from Keith on his Q&A on being a Software Architect.  In particular I liked his answers to the last two questions, but I’ll just quote the second-to-last:

3. What advice can you share with others in or entering into this profession?

Prepare to be misunderstood by the public.  Most people mistakenly believe that programming and system architecture is a kind of manufacturing where basic requirements are input, and the code is produced in a left-brained factory-like way.  Software development is more like the fine arts than it is manufacturing.  A great programmer is better compared to Michelangelo than to Henry Ford.  The reason is that every day the software developer creates something brand new that has never been invented before.  Once that puzzle is solved, it never needs to be solved again.  There is no repetition.  Contrary to public perception, software development is an extremely creative, right-brained activity.   The clearest evidence for this dichotomy is that struggle for acceptance of an Agile method for development of software.  Those who understand software development know that an Agile approach is key to good software, but traditionally trained management is very uncomfortable, and want instead to run things like a manufacturing plant.  My advice is to learn everything you can about the Agile approach, and avoid organizations that do not employ it.

I truly wish that journalists would understand that software “engineering” is a creative endeavor.  If journalists understood and wrote about it, I feel confident more non-software-engineers would have a better appreciation for what “programming” really is.  I think if more people understood the creative element, you’d see less “outsourcing” of software development to people you’ve never met or talked to.  You’d want to meet the artist before you commission the work, no?

Adam Deane’s recent post about Keith Swenson’s blog was quite interesting to me.

Keith has been blogging on BPM for the last 4 years.
The first couple of years were mainly around notations, standards and development.
The next year had an emphasis on BPM best practices.
His last year of blogging concentrates on ACM – Adaptive Content Management.

Personally, I found the articles on BPM best practices – the most interesting to read.
Clever observations and recommendations. They were also articulated very nicely.

I’m not a notation kind of guy, so the debate around standards and acronyms wasn’t exactly my cup of tea (XPDL,BPAF, BPDM, Wf-XML, BPMNEL, WYDIWYE and … IJKLMN)

I’m not a notation guy either… but I found myself sucked into some of these debates anyway! Sometimes you just can’t help it.  People often criticize the notation, when the real problem is the specific implementation of the notation that they’re working with. (This same thing applies to people criticizing a space, like BPM, when the real complaint is with specific tools).

Of course, the part that really jumped out at me was almost buried at the bottom:

And I must admit that his latest obsession with ACM has got me a bit baffled.
I haven’t a problem with the ACM concept, but I do have a worry about the approach.

I agree with Adam that Keith’s most interesting work (to me) was regarding BPM best practices.  I find the discussions on ACM too theoretical – with nothing practical to separate ACM from BPM in a meaningful sense (only in a theoretical and etymological approach).

Keith Swenson says BPM makes the workplace more stressful:

It is really quite simple: in the workplace there is a mix of routine work and knowledge work.  Routine work is repeatable and predictable in pattern.  Knowledge work, however, is different every time and makes us think hard about what to do for this particular situation.  Routine work can more easily be automated with a BPMS.  Therefor, the mixture of work is shifting toward having less routine work, and more knowledge work.  Automate work never results people becoming idle.  Business being always competitive, people are expected to keep busy with whatever most needs to be done, and that is increasingly knowledge work.

I like the straw man Keith presents (you should read it all).  But it isn’t BPM making work more stressful – it is competition that does that.  Capitalism and competition.  BPM is just one of the tools we use to address that competition.  We don’t blame the nail gun for making construction more stressful – we blame the competitive pressures that cause the need for speed to be so great.

Phil gave the keynote at BPM 2010 yesterday, and Keith Swenson had the early coverage ready before EOD yesterday.  In this talk, it sounds like Phil has continued his main themes (since I can remember) of making BPM more and more accessible to the business.  As he often put it in the past, the IT folks are a small minority of the total population in a business (2%?), and “we want to focus on the other 98% of the people in the business”.

Every year this theme gets some tuning, based on technology and cultural developments.  This year the stats were updated a bit:

For every one 1 java programmer developing applications, there are 5 IT people supporting the technology infrastructure, to support the work of 240 business people.  Tools to date have all focused on the 6 people.

And the suggested general direction is evolving to include the idea of “following” elements of the business.  I’ve used the follow feature in Blueprint, and love it – sometimes simple features are compelling.  But I’d like to see “follow” functionality throughout the IBM Lombardi BPM solution – within the Lombardi Edition authoring environment, as well as in the run-time environment.

It sounds like Phil also took some shots at the standards effort behind BPMN.  This isn’t new – Phil has long been a proponent of having a standard, and having a standard storage for the notation.  But he’s also expressed his frustration in the past that the folks working on the standard were getting bogged down, taking too long, and getting too far into the weeds.  Fair criticisms that I think Keith and Bruce Silver and others would echo (including myself).  I’m glad to have BPMN, but I hope the standards folks take some time off and let it bake.

The central argument (quoting directly from Keith’s blog):

Citing an IBM study of customers, 2.5% of the processes are complex,  22.5% are somewhat complex (less than 200 steps),  75% are not complex at all.  This last category is done today by excel over email..  At Banco Espirito Santo the complex processes impact zero people,  moderately complex effects 2000 people, and the non complex effect 8000 people.  This organization has moved forward to allow business users to be “100% empowered to automate the non-complex processes”.  If your business is based on people (and there are very few companies today that are not) where is the value being delivered by your BPM?   Everyone is way too focused on the really complex processes.  IT was clear he felt that is what lead BPMN standards astray, and this research crowd should be mindful not to fall in the same trap.

BPM is a cultural issue, not a technical one.

(Neil Ward-Dutton focuses on the same part of Keith’s summary, with an emphasis on the cultural).

Keith comments that Phil stopped short of prescribing a solution to empowering business users to increase the support for business work… but I think he’s priming the pump.  He’s giving us a sense of what we’re missing today.  But if I know Phil, he has people working on it right now.

The future is focusing on the “B” in BPM – not the “N” in BPMN – and the vendors that can offer the most compelling solutions are going to reap substantial rewards.

So I couldn’t attend the recent ACM tweet jam live, as I was, well, working. But there were quite a few people participating, and reading the summaries after the fact, I can’t help but feeling a bit underwhelmed.  So much energy has been spent attempting to separate ACM from BPM that I find it kind of ironic when the same criticisms would come full circle.  As Max J Pucher and others have noted, it is difficult to get consensus on a definition of BPM… but it is *also* difficult to get a consensus on the definition of ACM (I can already, almost, hear Max throwing up his arms and sticking with his non-acronym moniker “adaptive process” – no argument from me).  Keith’s summary of the tweet jam lists 6 definitions, but I bet there are more.  Personally, I don’t mind a surfeit of definitions, it is part of the human condition that you can’t get unanimity on things like this.    One of them was “all knowledge work”.  Well, This sounds a bit like BPM – covers just about everything.  Strangely, sometimes people think knowledge work is the only kind of work that doesn’t follow a predefined process.

Next, there’s the justification of “why all the buzz now?”.  These answers are the least reassuring.  Such as this one: “only today limitation of pre-defined BPM became clear. People look for another solution to knowledge mgmt”  Seriously?  BPM has been evolving for 10+ years and only just now, someone says “aha! it is limited! we need another three-letter-acronym!”  Pardon me for being a bit cynical, but I think anyone in the BPM space doing implementation was quite aware of both the limitations and possibilities.  Or this one: “Workflow and BPM is arguably ‘low hanging fruit’ – ACM is harder to get to, which is why it is of interest only today.”  Unless this author was equating BPM with BPEL, this argument misses the mark. BPM is hardly low-hanging fruit, which is why it has taken so long to mature as a market.  Arguably ACM is easier to achieve in many respects because you don’t need to build much of the infrastructure required to support BPM – and you may not be designing as much up front.  Trust me, the “do anything you want” process looks pretty simple in BPM tools… And the supporting technologies for knowledge work are relatively inexpensive.

However, another comment hits closer to home: “The integration vendors hijacked BPM: took a detour. now we see the need to use a diff kind of BPM”  I agree with this statement more than I disagree.  To the integration vendors, business process management was a checkbox feature in their integration stack.  But it needed to be front and center, because it is the new platform for getting process work done in the business.  I believe what people are calling ACM belongs there as well – front and center.  I am just not as convinced that it is a separate product category from BPM, as opposed to part of what BPM should have been doing all along (and for some vendors, exactly what they were doing all along under a BPM flag).  I am going to keep reading and listening to see if new information changes that outlook for me.

One comment was very interesting to me: “More like all vendors saying they do it.  Suddenly all do it – without changing their products.”  The question I have is – is it because they’re just putting out marketing spin, or is this because ACM, as defined, is already (mostly) addressed by existing products?  I wonder if the fact that everyone is so easily claiming to do ACM is because… so many vendors already do ACM… as defined by the chief proponents of ACM.  If that’s the case, then ACM really is about marketing from a software vendor point of view, and about the “approach” to “knowledge work” for those responsible for implementation of solutions (people in my business).

There was a considerable concern that the terms “ACM” and “Case Management” mean nothing to buyers.  I would agree. Buyers don’t seem to differentiate what case management would do that is different than this thing they’ve finally gotten around to tackling called BPM.  Still if a buyer is familiar with case management, it is a good idea to speak their language.  And if a buyer wants BPM, speak their language as well.

There was another section of tweets about what, exactly, constitutes knowledge work.  This gets a little ephemeral to me.  This is sort of like asking someone whether a job is creative or not – most people think they’re own job is very creative and unpredictable, but that all these other people in the organization are doing “routine work”.  A big US magazine “offshored” an issue of their magazine to India once, as an experiment to learn, for themselves, whether journalism could also be outsourced like other work.  They’re “startling” conclusion was that journalism was a particularly local and creative endeavor that could not be offshored (couldn’t see that coming, could we?).  They thought offshoring was only applicable to “rote” work like software engineering, call centers, etc.  Well, I have news for those journalists, writing code takes plenty of creativity.  And some call center work does too, based on the teams I’ve worked with.  So what is the magic creativity threshold that makes work offshorable?  Or, in the case of knowledge work – how much knowledge makes it knowledge work rather than “routine work”?  Difficult to put a gold standard on that one, and I’m not sure it is useful to do so.  These generalizations will only get you so far.

Finally, there is a section referencing “GOOD EXAMPLES OF SPECIFIC WORK THAT ARE SUPPORTED BEST BY ADAPTIVE CASE MANAGEMENT?”  (not my emphasize, it is the author’s emphasis)  The majority of these examples are hypothetical and theoretical.  Not work that is currently being implemented by ACM tooling or ACM-supporting vendors.  Taking each one in turn, I’d just point out that I haven’t seen these in the wild yet:

• Putting the decision of a board of directors to action. No predefined process, but the work must be done.  I don’t recall seeing the press release covering this one, or why ACM would replace the conference call for this.
  
• underwriting of life insurance. Insurance companies are using purpose-built software for this (COTS), and augmenting with things like BPM.  I’d like to hear if anyone is using an ACM “product” that is not also a BPMS to do their insurance underwriting.
• mortgage origination would benefit (just went through a painful one).  Ok, another “hypothetically mortgage origination is a good fit”.  But it turns out, BPM software is already the brains behind several major mortgage origination processes for major lending operations.
  
• architectural design.  So is there a market to sell ACM to architects? The architects I know have pretty specialized software…
  
• investigations, audits, contract and RFP management.  Sure, in theory this is true. But there’s already specialized software for these things as well.  And BPM vendors already has proven deployments in these areas.  So the question I have is: while these may be a good fit, is ACM differentiated or just another good fit? Are there existing deployments not by a BPMS vendor?
  
• I’ve seen examples of adaptive case management ideas applied to patient care, might ACM be especially useful there? Why?  Hm.  ACM “management ideas”.  Well truly, this is getting the order of operations backward.  The patient care practice has certain management ideas.  ACM advocates see similarities to what they think are good ACM practice, and therefore look to patient care as an example of what ACM could do well.  I’m not aware of any ACM patient care deployments (yet).
  
• Interior design every activity is art until order confirmation structured prc.  I don’t see interior designers being a big market for ACM, regardless of product fit.
  
• merger of United and Continental. In theory only.  They did it the old fashioned way, I expect. And as noted in other posts, I think companies that really do mergers, will have fairly organized processes (e.g. Cisco).
  
• Disaster Relief for Haiti.  Again, in theory only. And not exactly a market, so much as a need.
  
• Responding to Oil Crisis in gulf.  In theory only. And when it comes to *preventing* the crisis, so far all signs point to the people on the rig overriding (ACM style) the prescribed safety procedures (BPM style procedures) in pursuit of goal-oriented management (extreme pursuit of profit and cost-cutting)… but wait… Drucker’s Goal Oriented management was supposed to be a Good Thing… problem is, you still have to set *the right goals*… This is the problem with these analogies, the break down under any skeptical scrutiny.  Real deployments of real software will expose the real strengths and weaknesses of the ACM approach and tooling to support it.
  

Finally, a parting thought, I believe this is quoting Max J Pucher:

“ACM is not anarchy – it is empowerment! Authority, Goals and Means to accomplish those goals.”

Empowerment should be the goal of any good BPM or ACM solution, I think.  Enablement, and Empowerment. Great thought to close with.  And sometimes just one nugget like this makes reading the whole train of a tweetjam worthwhile!  Thanks Max, and tahnks to Keith Swenson for taking the time to try to capture some of the session for posterity (or at least, those of us who couldn’t attend).

So Jim Sinur really opened a can of worms the other day with his missive on BPMN, literally calling for it to burn baby burn – nothing like a gentle start like that to initiate a moderate discussion of the finer points of BPMN.  I couldn’t help but respond both within his blog as well as on our own blog.  I feel like Jim is letting the business off the hook – as he puts it – they don’t care about process, and they’re too busy making money to worry about process.  I think this is a cop out.  There is a comment thread on Jim’s blog that I’d recommend reading for the follow up discussion, and the original “burn baby burn” statement got walked back somewhat.

But the debate didn’t stay contained there.  Keith Swenson chimed in, taking advantage of the opportunity to pile on BPMN.  I can’t accept the black-and-white approach he is taking to the discussion, and so of course we had a bit of back-and-forth about whether BPMN is appropriate for no one in the business (his contention) or at least some people (my contention).  I was challenged to name people within the business who read or write BPMN, which was quite easy to do, because this is the kind of stuff we do every day for work.  I think the comment thread on his blog, and on Jim’s, or incredibly telling.

But there was also a great post from Neil Ward-Dutton on the subject, that captures my perspective perfectly:

Or – in other words perhaps – surely it’s not too much to ask non-IT participants in BPM initiatives to take a little time to learn some fairly straightforward modelling technniques?

From our case study work here I think what Scott is saying leads to a sensible, middle-ground answer – which is, that the applicability of BPMN depends on a number of factors; saying that BPMN (especially BPMN 2.0) either is, or is not, suitable for “the business” is too simplistic and black/white. It’s like saying Cloud Computing is the future of IT. Firstly it supposes that we have to talk about BPMN as an all-or-nothing proposition; secondly it supposes that “the business” is some kind of homogeneous organisation with one set of skills, experiences and inclinations.

I literally could not have said this better myself. He goes on to make another important point I agree with:

At the same time, though, there’s significant evidence to suggest that a core subset of BPMN symbols are absolutely usable by business analysts with experience in high-level analysis and design and provide great results in terms of delivering a common language across multi-disciplinary teams. I’ve come across many BAs who know and use (aspects of) BPMN as part of their armoury. They’re not “IT people” – they have business backgrounds and they work in line-of-business departments.

Great read from Neil.

In the comments on this one, Keith takes a nice shot at my assertion that understanding just a few BPMN shapes will allow you to read someone else’s thoughts on a process, or to communicate your own basic processes to others:

Also funny is the comment that learning six (or 7) shapes means that you understand the non-trivial interactions between those shapes at run time without needing the programmer’s insight into how systems function. That would be a little like saying that learning 26 letters makes you a Shakespeare, or able to read all western European languages. (But I must avoid use of similes since this apparently is sometimes confusing.) BPMN certainly is useful is some situations, it simply isn’t useful in all situations.

For the record, I don’t find Keith’s “similes” confusing at all.  I find them inaccurate, misleading, and misrepresentative.  And when we turn the analogy on its head, I think that proves how pointless they are.  In practice, when people read Shakespeare they’re usually in school and get help from cliff’s notes, teachers, and fellow students.  Not unlike those working with business processes and BPMN … and other tools (six sigma, lean, value stream, etc.  ).  Once again, I’ll point out that analogies are illustrative, they simply don’t constitute proof or refutation.

Jakob Freund of Camunda commented on Keith’s blog and summed up a reasonable reader’s interpretation of both Jim’s post and Keith’s post:

I think the main problem is that in both blog posts (Jim and yours) this very important distinction between “all” business professionals and “business (process) analysts” was not made. Analysts are not programmers but very often part of a business department, therefore a subset of “business professionals”. To throw all “business professionals” in one pot judging there skills in working with BPMN (or whatever) makes a good headline, but does not say anything useful.

Furthermore, there has not been made any distinction between “creating” and “reading” BPMN diagrams, and between the extremely different grades of complexity a process diagram can bear (please excuse my bad English).

But those are exactly the parameters you always have to look at when judging modeling approaches (no matter whether they are control flow – based, grids, prosa or what ever).

I guess it just comes down to this: BPMN is quite useful.  It is even useful to people most of us would consider as “business professionals”.  But there are other quite useful tools in our business process management space, and there’s no reason not to use each one when appropriate.  I also recommend as practical reading, this post on practical application of BPMN by Jakob on his own Camunda blog.  I liked how he closed his last comment:

cheers from my customer’s office in Germany (currently introducing BPMN in a 80k-people company, and huh, it works for Business people, but it’s bloody hard work to make that happen  ).

Similarly, as I was writing on the same comment thread, I was about to head in to visit my customer, which also uses BPMN to communicate broad requirements between business stakeholders and IT.  Regardless of what the theory says, the practical reality is our customers’ businesses are using this stuff.

The merger of two airlines has been used as an example of something BPM is not well-suited for, that ACM would be well-suited for.  I gave this argument a bit too literal a reading, based on Keith Swenson’s response (thought exercise vs. demonstration).  But having worked on quite a few BPM projects that were born of mergers (not the act of deciding to merge, but the after-affect of the merger), I found this article on the Wells Fargo and Wachovia merger to be just the kind of external, public information I was looking for to better explain my own views about how mergers happen – and the fact that there really is method (dare I say, process) to the madness.  When you are a big financial institution, or a big tech company (e.g. Cisco), you don’t do just one or two acquisitions in your history.  You might do one or two acquisitions a quarter.  Not all of them will be as big as Wachovia of course… These institutions are constantly reinventing themselves through acquisitions and spin-offs and joint ventures. Any time you do something so valuable, so often, you’ll want to understand it as a business process.

So how do you handle something massive like Trust conversions from Wachovia to Wells Fargo?

This year, Wells Fargo and Wachovia completed one of the biggest trust conversions ever; 81,000 trust accounts and $150 billion in assets were transferred to a common platform. Wells Fargo is now one of the largest U.S. trust providers in the U.S. with 233,000 accounts and $1.3 trillion in assets.

There was a big analysis effort to understand the processes operating at both firms, and to pick and choose best practices from both. After that they modeled these processes, simulated some of them, and implemented.  Some interesting ancillary benefits:

Another benefit is that the use of business process modeling helps the business and IT people communicate with each other. Instead of exchanging Word documents about requirements and technical specifications, where each side typically had trouble understanding the other, they’ve transitioned to graphical process models where both parties can look at the diagrammed process flow and exceptions. Watkins says this has saved thousands of hours of time in writing requirements documents and interpretation time for the technology developer.

So… is BPM low hanging fruit or was it hard work?  Sounds like it was hard, but valuable, work.  Is Wells Fargo really committed to BPM?

“Processes are pervasive whether you’re facing your customer or in the back office, and there’s been a recognition over the last couple of years among business leadership and IT that we should start focusing on more opportunities around process improvement, where we can leverage BPM technology we already own,” he says. “We’ve trained more than 400 people on BPM technology and technical standards like BPMN (business process modeling notation) as a common language for communicating process improvement,” he says.

Well, what do you think?

Keith Swenson has announced a case management mentor meeting (or ACM Mentor Camp) following the BPM 2010 conference, at the same venue:

The “Adaptive Case Management Mentor Camp” has just been announced.  This will be a meeting of minds for people interested in learning effective techniques for using case management for knowledge work.  It is right after the BPM 2010 conference, at the same venue, symbolically representing ACM as the next thing after BPM.

I think it is a great idea to put something like this together – these informal gatherings are often more valuable than more formal conferences – the only danger is conference burn-out!  At BP3, we’re looking forward to bpmCamp in Austin.   Sadly, I can’t make BPM 2010 this year unless my schedule changes, and therefore I also can’t attend the ‘camp.  Its a great gathering of people, definitely recommend attending to anyone who can make it.  Keith argues that the symbolism is that ACM is the “next thing after BPM” – but I’d argue it also supports my point of view – the same vendors, practitioners, and customers are going to be interested in BPM and ACM…  Keith and I just draw different conclusions about what that means for what will be defined as the “BPM” market.

The Death of Google Wave is interesting.  We’ve written about Wave before, several times, but in particular when SAP put out its “Gravity” demonstration.

The official Google Blog blames the closure of Wave on a lack of user adoption:

But despite these wins, and numerous loyal fans, Wave has not seen the user adoption we would have liked. We don’t plan to continue developing Wave as a standalone product, but we will maintain the site at least through the end of the year and extend the technology for use in other Google projects. The central parts of the code, as well as the protocols that have driven many of Wave’s innovations, like drag-and-drop and character-by-character live typing, are already available as open source, so customers and partners can continue the innovation we began. In addition, we will work on tools so that users can easily “liberate” their content from Wave.

So, there’s a bunch of open source code, it looks like, that partners and customers might leverage.  But most of us, I think, would prefer to just use a finished product.  There are many other unofficial takes, here and here are two examples.  I had a few others linked, but no need – you can find such commentary easily!

When Wave was announced last year, I spent some time discussing with others what it meant for BPM.  Some thought it was a game-changer, some thought it was a non-event.  The thing that became clear to me: collaboration tools like this are going to tend toward being free, or extremely inexpensive.

Starting last fall, the discussion in BPM circles had often turned to “ACM” (A variant on Case Management).  Some in BPM circles would call this unstructured process. Some would call it “chaotic” or unpredictable processes/work.  Keith Swenson and colleagues even penned a book about managing such unpredictable work.  Google Wave was, to this crowd, a great example of where “knowledge work” is headed – into collaboration spaces, not into BPM software.  To me, it was just proof that email and lightweight project management tools were not going away.   If Google Wave accomplished anything, it showed:

1. Separating yourself from email divorces you from a knowledge worker’s daily routine (some might say, process).
2. If it isn’t trivial to involve the right people in a collaboration, then users give up
3. Collaboration is going to be free or nearly free.  Even if it has pretty amazing features.
4. It is really hard to do a “big bang launch” successfully.  It makes me even more impressed that Apple seems to pull this off with such regularity.

So what does it mean for BPM?  Not much.  Wave was never really about structured interaction, it was about ad-hoc interaction.  Although ad-hoc interaction is important to a good BPM strategy, no one (maybe except for SAP) was really leveraging Wave for this.  If they were, they can probably leverage the open source bits to get a jump on the development effort.  For the ACM crowd, its both good news and bad news.

First, the good news:

1. A free competitor to your products, supported by a major software company, has gone away.
2. Hm. I think that’s it.

The bad news:

1. If you were counting on convincing users to leave email to use your product for knowledge work, it is time to change gears.
2. If you were expecting that being good and free was good enough… Maybe it isn’t.  Although Wave was panned in the press, it really was pretty good at what it did, though perhaps it tried to do too much.
3. If you were expecting to charge a lot of money for general-purpose collaboration software… I think those days are over.
4. If Wave was your favorite example of how ACM was really relevant to what people are doing… time to find a new example.

Silver lining:

1. Collaboration software for very specific purposes will live on (aka process modeling, or services like tripIt).
2. Some of Wave’s features will likely get absorbed by Gmail.
3. Some of Wave’s features will likely show up in other products.

I think Keith Swenson summed it up best for the ACM folks on Twitter:

“nooooo. It can’t beeeee. :-( RT @jpmorgenthal: Google waves goodbye to Wave: http://bit.ly/bg3ixC”

Well, fans of Wave and its approach were bound to be disappointed.  I saw quite a few more comments on twitter with a more positive spin on Wave being shut down.  Google found Wave squeezed inbetween email and all the other things we do in life.  It apparently couldn’t live on its own.  I’m not sure the future of ACM, per se, is anything different.  Yes, the ACM proponents will have their analogies, and they sound compelling.  And we could even agree that a large percentage of work is not addressed by BPM today, or by, more specifically, structured process.  But what ACM proponents fail to mention is that even less work is currently addressed by purpose-built ACM software.  It *could* be, but isn’t.  It is still likely to be addressed by email, project management tools, telephone, hallway conversation, and more email.

Note, I’m not arguing against ACM as a description of work, I’m just looking at the software market and not seeing it as an independent market, yet.  Willing to be proven wrong.  And I think there are a couple vendors that have the right strategy or tactics, but we’ll see if they can execute.

Working on a longer collaborative post on ACM and the marketplace.  Watch this space.

Recently Bern Ruecker’s article on “A Collaborative Approach for Real-World BPM” appeared in InfoQ. It is a good read, with much I agree with and just a few things I don’t.

We have been working in the business process management (BPM) space for years already, and it is very interesting to see the recently growing attention for it. Catalysts for this interest may be the growing maturity of the tools, the new 2.0 version of the BPMN standard, better understanding caused by more publications or improved preconditions for BPM approaches, to name only a few of the most important developments within BPM.

Couldn’t have said it better myself. Bern goes on to criticize tools that they’ve worked with:

Vendors offer more and more high-sophisticated graphical tools, which promise automation of business processes without any coding or even developers; however, we see a problem with these “traditional” vendor centric approaches: They don’t deliver on these promises!

Agreed.  But of course, most vendors don’t promise “no code” – but they do often claim that someone less than a true “developer” can deliver the solution.  In my experience, while these tools do enable personnel with less technical training to participate in the process development effort, there is no such thing as someone “too technical” for a BPM project.  Good technical help is important in any project involving information technology.  He goes on:

Without naming the concrete tool, which wouldn’t be fair since most of them share the same basic problems, a colleague had to implement an easy process with a small web GUI. The tool introduced an own magic Drag and Drop GUI designer, which seemed to be handy in the beginning, but when we almost finished the project, there were some small data validation requirements in the form, which the magic tool wasn’t designed for. In an attempt to get around these limitations, we spent more time futzing with the designer than we needed to implement the entire GUI in plain JSF, which we did in the end anyway.

I can understand his feeling here.  However, I have worked with at least one tool that has such a drag-and-drop GUI designer.  It is great for prototyping UI, as it requires no code to marshal data into and out of the the process context on the server.  There is also a validation framework that does just about everything imaginable for validation (but, admittedly, this validation framework is something only experts on the platform would know about).  There’s also an option to validate forms after submitting (in the event that validation can only be accomplished with server-side checks or more complicated business rule evaluation).   My concern with the statement above is, though it may be true for a single tool – a good understanding of the BPM software being employed, combined with good understanding of requirements, and with healthy value-based prioritization of work – should allow one to avoid rewriting the entire GUI in something like JSF.  Of course, in Bern’s specific situation it may have been necessary, but I believe that on the whole we’re better of leveraging the baked in capabilities of a BPM suite rather than writing custom interfaces in JSF (or other UI tech).  The exception being, if the customer is already an expert in the custom interface technology (already using JSF in their organization? great).

We, as BPM practitioners, have to keep in mind that it is not about the technology we’re most comfortable with, it is about technology our customers can consume, maintain, nourish, and build on.

Bern goes on with another anecdote:

For another customer, one developer told me, “It took more than two days to try to model some special requirements, which he could have written in Java directly in half an hour!”

I’ve heard this thousands of times.  9 out of 10 times, the developer is wrong, or missing the point.  Once in a while, they’re right.  But the point isn’t to bury the business model in Java code (wrong), or to put what should be Java code into the business model (missing the point), it is to use the model to represent what is significant to the business process, and to use code to represent (primarily) what isn’t.

Another customer tried to get transactions and stateful services running, which unfortunately required calling services as Web services. After experimenting with WS-Addressing, WS-AtomicTransaction and trying to patch several frameworks, he basically gave up and dumped the whole BPM tool.

I wish I knew which tool so that I can avoid it!  A decent BPM tool should include good coverage of web services scenarios.  And a Java API.  Bern’s article is a cautionary tale of products that don’t live up to the promise of BPM.

Bern goes on to argue that a BPM tool should be making the developer’s job easier, not harder.  While that may be true, I think the framing is wrong. The framing we would use is that a BPM tool should allow a model that accurately portrays the process to the business and also accurately represents the execution context required to run the process.  If it is harder for the developer to provide visibility to the business, that’s secondary to producing something that has high-fidelity between business model and IT reality.

Bern goes on to describe a solution that he calls “Camunda Fox” – which pulls together various other technology, including JBoss, jBPM, Signavio, and a glue layer created by Camunda.  It seems like a reasonable approach for a very technically competent team to tackle – especially a team that is intimately familiar with the technologies in question.  But it is a model-transforming approach with several inputs and outputs.  And this approach isn’t going to address the needs of a smaller business or smaller team that doesn’t have these technical skills, nor the budget to pay outside consultants to build and leverage this glue – I think Bern might argue that the “simpler” BPM tools won’t address these customers well either.  As Bern says, Camunda Fox isn’t a silver bullet, but it addresses projects that are pretty Java development focused.

I prefer to use BPM tools with a model-preserving approach (as described by Keith Swenson) because it is a higher fidelity mapping of business process to running software.