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 (http://nyti.ms/9TIvGd) 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.” http://bit.ly/dCzVW1 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.)

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.

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”!

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?