Bruce Silver Weighs in on Metaphysical Questions

  • November 7, 2011
  • Scott

Bruce Silver, never one to shy from a debate, weighs in with a post I largely agree with:

The question is BPM part of case management, or is case management part of BPM? is a metaphysical one.  I think, however, it is a proxy for the real question, can a BPMS do a good job with case management, or do you need a special dedicated tool?  It’s obvious that if a single offering could provide both, users would prefer it over separate dedicated offerings.  And it’s equally obvious that it can be done, although it’s fair to say that the offerings may not be good enough yet.  Back in 2005, people said you needed separate BPM platforms for human workflow and integration processes.  It was just a matter of time, and not that long a time.

In one paragraph, I think Bruce has succinctly cut down 90% of the noise:

  1. This is a metaphysical question. In a practical sense, who cares.
  2. To the extent that people care, it is because they’re substituting this metaphysical / philosophical question for a practical one: “Can a BPMS do a good job with Case Management?” (or ACM)
  3. Everyone understands customers would like to have one tool that does both. And makes breakfast.  Thus the fear and uncertainty and doubt about this issue among software vendors.
  4. Anyone who can code worth a lick can see that it can be done. But as Bruce says, there’s a lot of room for improvement on most of the tooling out there.
  5. History suggests the ultimate answer.

He then moves on to discuss how a case might be different from a process.  Overall a great read.


Related Posts
  • August 9, 2017
  • Scott

Next week we're hosting Driven 2017, our annual conference for customers and our own team to explore the lates...

  • August 9, 2017
  • Ariana

First Steps with Blockchain from BP3 on Vimeo. Andrew Paier discusses blockchain in an enterprise setting. ...

  • August 2, 2017
  • Krista

Data.World is a promising startup in Austin with the goal of building the most meaningful, collaborative, and ...

  • Scott, I think you say it perfectly when you say “Anyone who can code worth a lick can see that it can be done.”

    Case Management, however, is for people who are not programmers.  The doctors, lawyers, judges, detectives, nurses, salespeople, and others who want to manage cases, will NEVER use BPMN.  BPMN is a programmers language and I agree will work fine for programmers.  Case management is for case managers, who are knowledge workers not programmers.

    Please see the full write up at:

    • Keith, you’re misunderstanding my post (and Bruce’s).  I’m not advocating that doctors, lawyers, etc. use BPMN or program.  Nor have I ever advocated that.  I’m arguing that BPMS software vendors (programmers) can easily replicate ACM functionality written by ACM vendors (programmers).

      Knowledge workers should never have to be more than occasional programmers (referencing an excellent post by John Reynolds on the subject) – which they already do when they interact with spreadsheets and email rules and 

      In this post, we are talking about the people who build the tools. Like Fujitsu. Like IBM. Like Appian. Like Pega.  As a few examples.  My point (and Bruce’s) is that it seems probably that the market picks one tool (called BPM) to answer the whole spectrum from automation, to human-facing, to “ACM”. 

      • I am not sure I have misunderstood the post – but I am happy to discuss more if you wish.

        For the record, and I would like to be very very clear on this point.  I have NEVER said that any particular vendor could or could not produce ACM software.   In fact, I have pointed out many times that there are notable vendors that have products that include capabilities of both ACM and BPM, sometimes packed into the same suite.

        I understand quite well that you and Bruce are taking the position that the market will choose one category for the “spectrum.”  My position is precisely the opposite: that these markets are distinct.

        Arguing that there is overlap in capability is a flawed argument that leads to the wrong conclusion.  It is like arguing that you can make a car that is also a boat.   One can easily argue that it makes more sense to have a single product category (the amphibious vehicle) than two (the car and the boat).  Such amphibious vehicles have been produced in the past — but they are neither good boats nor good cars.  It is not the capabilities that define a product category, but the audience.  The car is best when optimized to be a car.  The boat is best optimized as a boat.  Even if the engine is 100% the same.

        A better example is the “word processor” and the “spreadsheet”.  If you write down the capabilities, you will find that there is a large overlap in functionality, and a “spectrum” of usage.  Years ago many people did predict that this would be met by a single category (remember Lotus 1-2-3, or Ashton-Tate Framework?)  Those did not, in the end, win the market.  It happens that Microsoft makes both an excellent Word Processor and Spreadsheet, and sells them together in MS Office.  But they remain distinct products which are used by different people for differing tasks.

        I completely agree that vendors will offer a suite with BPM-like and ACM-like capabilities.  But I believe that a single unified offering — like the car that is also a boat — will not succeed in being successful in either.   They must be distinct products.   You believe the opposite.  Time will tell.  Hold your position, and in a few years we can compare notes.

        • Keith, thanks for the corrections – I’m guilty of muddying the water between the singular and the plural (its hard to keep each person’s views on ACM separate – and my language around this got a bit lazy).

          This is the core argument: “I understand quite well that you and Bruce are taking the position that the market will choose one category for the ‘spectrum.’  My position is precisely the opposite: that these markets are distinct.”

          Which ties into the analogy you made – a car and a boat.  The question isn’t whether you should build an amphibious vehicle. The question is whether they are really cars and boats, or two types of car.

          Example:  Phone, and MP3 player, hand-held gaming devices, and GPS.  Everyone assumed these were different categories of device.  And then the iPhone came out.  And it turns out, they were all just apps on top of a good handheld, touch-based computer.  We just didn’t know it yet.

          So you might be right that these are separate markets-  and my hypothesis that it is one market may be right.  The real question comes down to whether customers (companies) buy both BPM and ACM solutions, or just one or the other.  If it is just one or the other, then it is one market, right?  If they largely buy both, it is two markets until substantially all of the vendors offer both or sell them as a package.

          (much as word processors and spreadsheets were separate markets until Microsoft sold them as a suite, that created one “office productivity application” market). 
          Thanks for patiently re-explaining this to me – really helps my understanding of why we’re in disagreement – we just have different hypotheses (or positions, if you like) that we think are true.

    • Is there a case study of a doctor, judge, lawyer, nurse, using an ACM software product produced by a software vendor that is billing itself as being in the ACM market? And is there such a case where the company is not also a BPM vendor?

      • Does the company that produces the software have to “claim” that it is ACM, or is is sufficient for me to identify it as having features consistent with ACM?

        • You’ve cited examples consistent with ACM before – I’m interested in a company that self-identifies as ACM.  I think those are the most interesting cases to look at to understand how the market might evolve on the “enterprise side”.  Mind you, consumer-inspired tech may be winners (twitter, yammer, something like these tools).  But that’s a separate series of blog posts 🙂

  • Pingback: Lamenting Definitions » Process for the Enterprise()