Gartner has a new BPMS Definition. Next Step: Business Operating System

  • April 28, 2010
  • Scott

Adam Deane noticed a change in Gartner’s BPMS Definition:

If you compare it to previous BPMS definitions by Gartner (for example in last year’s Magic Quadrant for Business Process Management Suites), you will see two major additions:
1. Document and content management.
2. Inline and offline simulation (instead of just simulation)

Good catch.  Of course, we shouldn’t be surprised that the definition of “what’s in the BPMS box” would change over time – I expect that soon it will be a given that several other features (even products, or market segments) should be included in the BPMS definition.  Why? Because too many people view BPM (or BPMS) as the the future “Business Operating System” (in the 90’s, I think most people viewed ERP as the operating system for the business… ).  Rightly or wrongly, that puts a lot of things under the umbrella.

The real progress will be when the technology becomes so good it is transparent to the business, so obvious it is as if it works by magic (see Arthur C Clarke: “Any sufficiently advanced technology is indistinguishable from magic.”).

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 ...

  • Pingback: uberVU - social comments()

  • “Puts a lot of things under one umbrella” – so does that make it look like the one I have at

    The term Business Operating System sounds techie, I prefer Business Operative Platform, techie nonetheless, but still 🙂

    – Ashish

  • philgilbertsr

    Scott, all this is very troubling. It just shows that the architects and IT-driven people are still controlling the message. Now I know all analysts say “we're looking out for the business” but they all come from IT companies. It's their background… therefore it must be some additional technology that's really needed to “finish” BPM, right? This notion that BPM becomes seen as “the operating system of the business” hugely misses the point. If that gains credence, then we all should just pack up and go home. It only logically would follow that “everything is BPM”. And if BPM is everything, then, like ERP before it, it becomes nothing. BPM isn't OS X (or Windows), it needs to be iTunes.

    I see this happening everywhere these days. Gartner keeps expanding the technologies that “define” BPM. Forrester thinks “strategy maps” are a beacon of clarity… just days before they are exposed on page 1 of the New York Times ( for what they are: a distraction. OMG keeps adding nonsense to BPMN to satisfy the 0.1% edge cases, driven by folks who need to model some godforsaken perfect abstraction. They should disband the BPMN group and say “job well done, now go on home and use today's spec for a few years and then we'll reconvene to see if we really need to complicate things.”

    Instead, there's a cobble industry that has to be fed… and the way to feed it is to keep “adding features.” Rather than thinking deep about how to do what we already do, just better, it's easier to create new features we “need.”

    The shame in all this is that what gets lost in all this scope creep is the original goal, the original promise: BPM technologies should focus on reducing the technical barriers to the definition, creation and maintenance of business information. Instead, we seem to be paying for the Original Sin of BPM which was to focus on BPEL (or BPML before it) as anything to do with any of this. We defined BPM properly, then the industry and some of its early proponents corrupted the delivery.

    A focus on features comes at the expense of a focus on the importance of the “how”. BPM isn't about new features… sorry to tell all you CTOs out there but there is nothing new in BPM. It's workflow and rules and forms and data (structured and unstructured). This isn't rocket science. The beauty of BPM, though, is that it's about HOW existing technical capabilities can be exposed to a broader audience, an audience more directly connected to the business outcomes than ever before.

    It's unfortunate, but I guess for most people it's easier to say “add another thing you need” than it is to truly understand something fundamental to BPM, like, say, “HOW do you version artifacts in a way that's easy for less technical people to understand?”. Versioning is something everyone can do… so the interesting question isn't “do you allow versioning” but, rather, HOW do you expose this core capability so that it is accessible to a broader audience and can scale technically. It's interesting, I've been to so many analyst meetings where the analyst says “you say this is unique but your competitor does this too. Not nearly as easy, but they will still score the points.” They're missing the point. I can create any application with Java and a database that I can create with a BPMS… the difference is in the how.

    This is important because the how translates into lower costs and better outcomes.

    Same with authoring execution-oriented processes (the core of BPM), or deployment. Same with re-usability of assets and repository management. All of these things seem rudimentary and they are, functionally. But to do them elegantly, in a way that is accessible, is very difficult. In fact it's so difficult that most vendors simply don't do the design work required to make something simple. It's like managing digital songs… you can do it with a file system… but a lot more people can do it a lot more powerfully in iTunes. The technology IP of Apple is much less interesting than the design IP…

    One of my objectives while spending time in this industry is to help stop this madness. Just as I was a voice against BPEL which, to this day, has nothing to do with BPM, I also say: “Inline and offline simulation” has as little to do with 99% of the BPM projects as, say, BPEL. To even worry about it is ridiculous if it means you are taking time away from worrying about how to do what we do even better. If a large company has, say, 20,000 BPM participants today, why isn't it 40,000; or 60,000? I assure you, it's not because the processes aren't getting simulated. It's because what we already do is not yet easy enough. (Note: I'm picking on this simulation thing because you mentioned it… but I could point to several “requirements for a BPMS” from any number of analysts that miss the mark.)

    If BPM is going to succeed, we need to wrest its definition away from the analysts and vendors, and start looking to the people we're supposed to be serving: real business people at real customers and their IT servants. So I'd like to see a change to Gartner's requirements that doesn't mention anything at all about features, but, rather, it focuses on USE. Something like: “Minimum requirements for a vendor require 20 verified references of companies with cross-functional business and IT teams delivering projects routinely in less than 6 months between deployments with documented improvement using a commercial BPMS”. Now THAT'S BPM! I would wager that there aren't 5 companies on the planet that would meet those requirements. (I loved, for example, a recent BPM keynote where the presenter said, basically, “yeah, it took us over a year, we used waterfall, and it was 30-40% over budget, but we think this BPM stuff is great.” Wouldn't it actually be great if it looked and smelled like a BPM project, with rapid iterations and fast deployments, as opposed to a 1-year IT development project?)

    Anyway, I think if we start looking at actual adoption and the barriers to adoption then I think we'll find that much of our BPM industry is missing the boat. Our customers don't need new features, they need for all of us to deliver the features we've already got so they are easier to use. Fortunately for our Lombardi customers, they've already got the easiest to use, most powerful BPM platform on the planet. And also fortunate for them… we're not finished yet.

    (Full disclosure: IBM's Lombardi product supports “inline and offline” simulation as do probably a dozen other modelers at IBM. But the point is that after a decade in BPM and having seen hundreds of customers deploy thousands of process applications, not one needed simulation. Not one. In fact, the only useful simulations I have ever seen were developed by architects and simply confirmed what the business had already told them about their broken process… that is: it simply delayed getting to the truth. BPM is not about sending a man to the moon… it's about making sure the approval to say “launch” is given correctly and with authority. This doesn't often require simulation, just alignment and transparency.)

  • “Our customers don't need new features, they need for all of us to deliver the features we've already got so they are easier to use. ” Phil, I couldn't agree more with this statement. Thank you for taking time to respond on our blog. I've often found myself in debates about what BPM can do well (or not) and I find often the disconnect is that the other party hasn't (yet) had experience with a product like Lombardi. Even so, don't be surprised that I will continue to advocate for improvements in ease of use on the IBM Lombardi platform as well!

    The key is not that features and functions get added, but that they get integrated in such a way as to create a unified experience that makes sense to users and augments what users already needed to get done. I keep going back to that Arthur C Clarke quote – we're not there yet, but we've certainly made progress in the last 10 years. Many miles to go yet.

    I hope my comment about “not being surprised” isn't also perceived as advocating the inclusion of everything, it just isn't surprising that analysts are changing (and expanding) the definitions.

    I have some similar tensions about the recent discussions regarding case management (or ACM). A lot of the processes I've worked on over the years would best be described as case management processes. To me, ACM describes a problem set or domain, not a technology set (so far). BPM also appears to describe a domain.

  • I was being facetious when I said “Business Operating System”, to point out how things will keep getting added to the blob that is BPM 🙂

    Your umbrella chart is quite amazing, Ashish! 🙂 I think BPM is a fine enough “term” for what we do. As I've said before many times, I think it isn't the complexity of each thing we do in BPM that makes it interesting, it is the dance of all the little things that come together to yield a great process implementation. A “good” BPM product should make that as transparent as possible, as close to magic as possible.

  • philgilbertsr

    Scott, I completely agree with you on both main points above: 1) Lombardi, although the easiest to use, has a ways to go. We are investing more in design each year, and this is continuing. And I would say that about 75% of our designers' time is spent refining existing concepts. “Going deeper”.

    And 2) ACM… Arrgghhhh. Again, you won't hear real business people say “wait, this is a case management problem.” They simply want their processes to be easy and transparent… and to handle the various types of information that flows through them. And instead of making access to technology solutions easier, we insert new complexities (modeling paradigms, tools, you name it).

    If it weren't so detrimental to our customers getting on with business, I might laugh.

  • Glad you liked my representation Scott. Well, it's just that, a representation! I liked the way you put it – “the dance of all the little things that come together to yield a great process implementation”!

  • Glad you like it 🙂 It is part of how I respond to people who ask me questions like “what makes BPM so interesting” (or hard, or challenging, etc.). It goes back to a basic thesis I have that it isn't that any one thing is hard: it is knowing which of the many simple things you should do next. And it is having the emotional maturity to prioritize things that create value for the business, over things that are just interesting/fascinating from a technical perspective.

  • Phil explained perfectly why such expansion doesn't make sence from business perspective. I believe it doesn't make sence from pure technology standpoint either.

    Let me try to prove it as a theorem:
    1. The demand of new features, functions, modules is ever-growing.
    2. BPMS vendor following the expansion strategy should add modules to their product (ECM today, something else tomorrow) to meet this demand.
    3. The best pure-play vendor of a given technology (best-of-breed) outperforms the all-in-one (a.k.a stack) vendor on the long run. Simply because the winner was selected from a long row of competitors.
    4. When this advantage becomes obvious the all-in-one vendor acquires the pure-play.
    5. After the acquisition the all-in-one vendor must refactor (i.e. reengineer and rewrite) the big portion of acquired product and significant portions of the modules they already have or it won't be an all-in-one type of product.
    6. The all-in-one vendor is growing and growing, rewriting and rewriting the code and at some point it inevitably doesn't have enough resources to do that any more. Whatever resources it has, it's just a matter of time. Aren't IBM and Oracle already there?

    The epic battle “Best of Breed vs. Single Vendor” is over: the latter has left the battlefield.

    The only alternative is interconnected, loosely-coupled architecture. Every module (e.g. ECM or BRE) can be purchased and used standalone yet using them together gives substantial benefits. Doing other man's job (second-class ECM in BPMS or rudimentary workflow in ECM) is blamed as bad practice. Interfaces and open standards are pre-requisites.

    Too good to be true? But look, isn't this what SOA promises? Do we still believe in this promise? Are we ready to translate this belief to the customers?

    ERP didn't become the single business operating system. Is it the problem of ERP (which is a fuzzy concept indeed) or the concept of a single operating system is wrong?

  • Pingback: Process for the Enterprise » Blog Archive » “Simplifying” a Complex World()

  • Pingback: What’s your approach ? | IT :: redux()