Enough of this "Departmental BPM"

Scott Francis
Next Post
Previous Post
I think nearly everyone thinks it was a mistake for IBM to position Lombardi as being “Departmental BPM” as a way to explain how it fits within their BPM offerings.  The proof that it is a mistake is the flurry of blog posts from competitors slamming Lombardi’s offering as being “only departmental” and unable to scale (and using the Savvion acquisition as further excuse to return to this argument about Lombardi as well). Dr. Ketabchi of Savvion is quoted by Jason Stamper’s blog:
Second, we made sure our BPM is enterprise BPM — Lombardi, Metastorm and those others are departmental BPM. Our BPM is event-centric and supports event-centric patterns, decision-centric operations, case management and so on
And there were shots from Appian and Cordys.  And then this from Pega’s Alan Trefler:
Clearly, departmental-focused BPM companies stalled during the recent tough times. Is it okay to finally say that departmental BPM is not able to satisfy growing customer needs for real business change? Frankly, the best evidence comes from the acquiring company itself, which sees only tepid growth from the Savvion buy, forecasting only an additional $20M in revenue and 2 cents of profit…
I understand the positioning going on, for sure.  However, Savvion was bought for considerably less than Lombardi (final #’s will, I’m sure, be revealed in an IBM release or 10Q). And both Lombardi and Savvion were smaller than Pega in terms of revenue, but this ignores Pega’s history as a company before they rebranded themselves as BPM – they were a larger company before they started throwing BPM out there as a market they were in. Still, I think the down-market positioning of Lombardi (and Savvion) as “Departmental” BPM isn’t really fair.  This is “marketing” positioning by IBM, and not a reflection of what Lombardi has been doing for the last 10 years – and if it is a go-to-market strategy to spread the use of BPM bottom-up, that’s not necessarily a bad thing.  But if you consider major financial institutions running their entire loan process through Lombardi’s BPM “departmental” then so be it.  If you consider running all order-to-cash through Lombardi as departmental, so be it. There is a difference between marketing and technology and product. Are there departmental solutions abounding? of course.  Are these spreading within the organization?  yes.  Lombardi’s toolset makes it possible for a department to solve problems because Lombardi’s software does not require a team of 20-50 people to get deployed – a small team with a small amount of IT cooperation can get a process up and running very quickly.  However, that isn’t to say that these processes can’t grow and scale – or that enterprise-level processes aren’t addressed – and at BP3 we’ve worked on some of the very biggest of these deployments. I hope IBM/Lombardi will address this positioning once the acquisition is complete, I think it is hurting the BPM market to have the technology denigrated unnecessarily.  Of course, as a solution provider, we’re happy to use any software package to address our customers’ process problems, including Pega’s (or Savvion/Progress, or Appian, etc.).  But as a firm that isn’t a software vendor, we’d like to see the competition accurately represented and portrayed.  Not all technology is equal, but this department vs. enterprise stuff is really just marketing fluff, with no basis in fact.
  • But Scott, this is the whole point, by keeping BPM at the level where the punditocracy keeps it, anything can be said, any argument can hold.

    The day you guys will finally look for a unified model behind BPM, the day you will finally understand how BPM works, that day all these stupid and useless discussions will stop. There is no “unpredictable”, “departmental”, “incidental”, “accidental”, “emotional” … you name it … BPM. Until that day, anyone and their brothers, sisters, cousins and aunts, any little startup for that matter, can claim they are doing the best BPM there is and they can label it any way they want.

    You would think that intuitively human activities in relation to information, goods and services all operate under the same principles? No, that would not occur to you? What is so specific about Enterprise? Department? Cases? that would justify something different?

    Let me take another example, mostly ignored by the BPM leaders and the punditocracy at large. When I wrote the papers that are referenced in the BPMN spec in 2002, I used the following argument (being the editor of the ebXML BP specification): why would you think B2B interactions would introduce a discontinuity at the business process level? yet, this is what BPMN (and XPDL, WfMC, BPEL…) suggests, as soon as there is a B2B boundary, the “process” stops at that boundary? Why is that so? Let’s say Company A buys Company B? The boundary has disappeared, so all the sudden, processes don’t have discontinuities any longer? right… As you can see, no matter where you look, the corny vision of “executable BPMN” is flawed, deeply and totally flawed. BPMN has its place, but executable BPMN doesn’t. BPMN is not a programming language, it is not a definition, it is a representation. As long as you and others will perpetrate the exec BPMN fallacy, we will stay where we are today, nowhere.

  • But Scott, this is the whole point, by keeping BPM at the level where the punditocracy keeps it, anything can be said, any argument can hold.

    The day you guys will finally look for a unified model behind BPM, the day you will finally understand how BPM works, that day all these stupid and useless discussions will stop. There is no “unpredictable”, “departmental”, “incidental”, “accidental”, “emotional” … you name it … BPM. Until that day, anyone and their brothers, sisters, cousins and aunts, any little startup for that matter, can claim they are doing the best BPM there is and they can label it any way they want.

    You would think that intuitively human activities in relation to information, goods and services all operate under the same principles? No, that would not occur to you? What is so specific about Enterprise? Department? Cases? that would justify something different?

    Let me take another example, mostly ignored by the BPM leaders and the punditocracy at large. When I wrote the papers that are referenced in the BPMN spec in 2002, I used the following argument (being the editor of the ebXML BP specification): why would you think B2B interactions would introduce a discontinuity at the business process level? yet, this is what BPMN (and XPDL, WfMC, BPEL…) suggests, as soon as there is a B2B boundary, the “process” stops at that boundary? Why is that so? Let’s say Company A buys Company B? The boundary has disappeared, so all the sudden, processes don’t have discontinuities any longer? right… As you can see, no matter where you look, the corny vision of “executable BPMN” is flawed, deeply and totally flawed. BPMN has its place, but executable BPMN doesn’t. BPMN is not a programming language, it is not a definition, it is a representation. As long as you and others will perpetrate the exec BPMN fallacy, we will stay where we are today, nowhere.

  • JJ –
    once again I find half your argument agreeable and the other half I can’t relate to. To the first part, I think we’re in agreement that “departmental bpm” is not a real differentiator (unless you’re talking about how you’re going to license something – it isn’t an interesting BPM or technology differentiator).

    Just focusing on areas of disagreement: Where the boundaries of the process are, are entirely up to the modelers and the business. Many of the processes I worked on in BPMN were cross-organizational. So I don’t see why you claim that BPMN says you have to stop at organizational boundaries (and I do mean, separate corporations, not just departments, etc.). Perhaps that was the intent of the BPMN spec writers but if so that intent has been thrown out the window by modelers :)

    Of course it is *easier* to build processes within your 4 walls than to build process outside your corporation because you need cooperation from the other firms to participate in your process (in some fashion), but that’s not a problem with BPMN, nor even a problem with executable BPMN.

  • JJ –
    once again I find half your argument agreeable and the other half I can’t relate to. To the first part, I think we’re in agreement that “departmental bpm” is not a real differentiator (unless you’re talking about how you’re going to license something – it isn’t an interesting BPM or technology differentiator).

    Just focusing on areas of disagreement: Where the boundaries of the process are, are entirely up to the modelers and the business. Many of the processes I worked on in BPMN were cross-organizational. So I don’t see why you claim that BPMN says you have to stop at organizational boundaries (and I do mean, separate corporations, not just departments, etc.). Perhaps that was the intent of the BPMN spec writers but if so that intent has been thrown out the window by modelers :)

    Of course it is *easier* to build processes within your 4 walls than to build process outside your corporation because you need cooperation from the other firms to participate in your process (in some fashion), but that’s not a problem with BPMN, nor even a problem with executable BPMN.

  • I get it – there’s a lot of discussion by some about plopping a BPMS into any IT environment and expecting it to just hum in the background while a lot of activity goes on in spite of it. Active Endpoints are talking about scalability and the necessity of standards-adherence when it comes to using BPMS as an essential component of IT. This blog from Active Endpoints clarifies: http://www.vosibilities.com/bpm/when-using-a-bpms-be-sure-to-insert-the-correct-fuel-into-the-right-tank/2009/04/20/

  • I get it – there’s a lot of discussion by some about plopping a BPMS into any IT environment and expecting it to just hum in the background while a lot of activity goes on in spite of it. Active Endpoints are talking about scalability and the necessity of standards-adherence when it comes to using BPMS as an essential component of IT. This blog from Active Endpoints clarifies: http://www.vosibilities.com/bpm/when-using-a-bpms-be-sure-to-insert-the-correct-fuel-into-the-right-tank/2009/04/20/

  • Great analogy on that blog post about fuel vs. car – who cares what the fuel is, its what the car can do that matters :)
    “Like gasoline, BPEL is a commodity. An important one, but nobody buys a car based on the smell of the gas — they buy it for what it allows the engine to do.”

    Great line. And actually relevant too. Thx for linking it –

  • Great analogy on that blog post about fuel vs. car – who cares what the fuel is, its what the car can do that matters :)
    “Like gasoline, BPEL is a commodity. An important one, but nobody buys a car based on the smell of the gas — they buy it for what it allows the engine to do.”

    Great line. And actually relevant too. Thx for linking it –