Apparently, I ticked off Bruce Silver. In case you haven’t heard of the fellow, as I had not, Bruce is a consultant who makes his living providing training on BPM tools and his advice on BPM products. At least, that’s the impression I got from reading an interview with him on the webzine ebizq.net. What made this particular industry insider upset? Well, I was willing to point out that the BPM emperor was wearing a thong 😉 and that is bad for business.
[note to readers: I made a few updates to this blog entry about 12 hours after it was first published. The text added is enclosed in braces.]
Sorry, Bruce. I do wish you the best of luck in your business, but I don’t agree with you.
Automated BPM is a useful and, at times, valuable tool. To be clear, by “automated BPM,” I’m referring to any modeling environment where a [business] user can create a visual model that represents a process (assumably a business process), where that [business] user can, from that environment, “implement” that process in such a way that it will execute. I include a wide swath of tools in this description.
So let me repeat: Automated BPM can be valuable. There are times when it clearly makes sense. For those times, and for those companies, I’m sure that you will provide excellent services, and I wish you the best of luck.
However, the problem with BPM is this: [with the exception of the most trivial of workflow applications], the number of situations where that value rises above the cost and complexity of using BPM are comparatively small, compared to the other situations faced by most IT departments. As a result, any IT department that wishes to delay an investment in [automated] BPM, because they need to first invest in data security, or network reliability, or application integration, or improved business efficiency, or better user experience, is well advised to do so, because most of those things will provide more value, in both the short and long term, than automated BPM.
Why do I say this? Because the conditions needed for automated BPM to provide significant long-term flexibility are difficult to produce. It’s like growing rice in a desert. You can do it, if you try. You can set up some land, truck in sufficient topsoil, pipe in huge amounts of water, plant trees to protect your fields from sandstorms, and bring in labor that understands the growing of rice to tend to the crops. You can do all that, and maybe you can sell some rice. Not many do it.
The conditions in most IT shops are comparable to the desert. Information, even in the age of SOA and WOA, is still mostly hidden in silo apps, and functionality is still tied in to tightly coupled business systems where a ‘call from the outside’ will most often invoke complex ‘downstream effects,’ whether you want them or not. Creating an environment where BPM is a good thing, where true flexibility is achieved, requires creating the fertile soil, and plentiful water, and ample shade, and skilled workers. That is a worthwhile investment, for the companies with the wherewithal to make it, but not for everyone.
Any company or consultant that fails to point this out is making an error of omission. Show me a vendor [of this kind of tool] that is NOT making that error.
So, Bruce, I’m sorry to be the person who points out that your market is valuable, but not earth-changing. Don’t fret: The world still needs rice.
Nick,
Setting up strawmen and knocking them down seems to be your game. I never said BPM was earth-changing or the answer to any particular set of problems. What I said was that BPM vendors and consultants were not claiming – as you said – that their tools allowed business users to create process implementations themselves, without IT involvement. It’s a common refrain from those who don’t know better, and you were just being the ditto-head. Yes that’s the kind of thing that ticks me off.
But here you have changed the story, removing the business user part. I think you are now saying that any implementation built from a graphical design tool – I believe you mentioned BPEL before, so that would mean for example IBM WID and Oracle BPEL Designer, or any other graphical orchestration tool – are rarely valuable. That doesn’t tick me off at all (and certainly not bad for business), although I think it’s incorrect. But if you were more direct in that charge, without associating it with the BPM ‘cult’, you would have many more people than me on your case.
Hello Bruce,
Sorry to respond on my blog. I didn’t want to write an entirely new blog entry for this discussion.
You are right in that you did not say that BPM could solve a particular problem. You did not say anything at all. You responded to my prior blog post with the notion that I mischaracterized BPM. (The term you used: swift-boating).
You then went right to name calling, and, as your response here suggests, you have yet to stop. I’m sure that, if you disagree with me, you can find it in your heart to discuss that disagreement like an adult. Can we agree on civility?
So let’s look at what I said:
“According to the ‘true believers,’ we can give end users one of our pretty languages (BPMN or BPEL) and they will write their own software, and we can fire all the IT developers.”
If I get you right, these people don’t exist.
If I start naming names, I’ll name pretty much every mid-level solution. I would not include IBM, SAP, Microsoft and Oracle. Honest brokers there. Then again, doesn’t IBM make a good bit of money selling services that go along with their products? Don’t Microsoft partners do the same thing? Being easy to use has it’s downside. If we remove the notion of ‘removing IT from the picture,’ then the argument quickly expands to nearly every vendor that claims to automate a business process.
But leaving in the notion of ‘non-IT folks,’ we still have most of the mid-market BPM tools.
The best aspect of the BPM software market is the most honest part: we use the tools to enable us to communicate visually, simulate some processes, and provide opportunities to exercise best practices in process design. Why? to change the things that PEOPLE do. That’s valuable… but that’s not automation. That’s analysis.
Somewhere along the way, the industry started to say that we can take an analysis tool, describe a non-trivial business process (beyond simple workflow), and automate that process.
Look at any marketing site for a BPM suite: “We help you to model processes. We have the best automation engine. We use the term ‘business process’ in the name of the product.” Implication: Tool XYZ can automate any business process. Is it a leap? Perhaps. It is easy to draw this conclusion? yes. Is that intentional? You betcha.
Honest answer: we can write some small amount of software. In narrow domains (like Workflow), we can even take a generic solution and apply it hundreds of times to similar problems.
But tools cannot automate more than a tiny fraction of business process.
Still think I’m wrong?
I expect that you do.
I’ve found that anytime I use any wording with a religious connotation (such as "true belivers"), a harsh attack usually shows up in response ("swift boat", etc).
Call me crazy, but I agree with both of you. And I don’t see a strong contradiction. You both value BPM. You (Nick) are just pointing out that there are many other things that, in your opinion, provide greater value to the average IT dept.
I also think the desert analogy is spot on (mostly). I think we’d be slightly more accurate if we defined that desert as Antarctica. 😉
Yes Nick you are wrong. (And you really should at least track back to <a href="http://www.brsilver.com/wordpress/2008/07/05/will-the-bpm-swiftboating-never-cease/">my post</a>.) But I apologize for directing the namecalling to you personally, as you are just one more person repeating what I think is a bogus charge (hence the ‘swift-boating’ and ‘ditto-head’.) Your aspersions are more indirect, e.g. ‘true believers’ and suggesting that I post just what is ‘good for business’.
So let’s be civil and review the bidding. You first said that ‘automated’ BPM – let’s use the term of art common in the BPM world, which is BPMS, as you are ok with analytical process modeling tools – allows business users to create executable processes. That’s false, and I challenged you to produce evidence that anyone was making that claim, which you did not.
Next, you backed off from that and said even allowing IT involvement, building solutions using BPMN and graphical BPEL tools amounted to growing rice in the desert, i.e. a fool’s errand. I said if you made that charge more forthrightly, e.g. in comment on my blog instead of here, I suspect you would find many would disagree with you. Including your own employer once they get Oslo out the door.
And in this latest you actually expose where your logic runs off the rails. Vendor says we help you model processes. Yes I agree they say that and they do. Vendor says we have the best automation engine. Yes they say that, and they all can’t be ‘the best’ but so what? Vendors use ‘business process’ in the name of the product. Oh my, guilty as charged. Then "Implication Tool XYZ can automate any business process", with emphasis on the any. No that’s incorrect, vendors are not making the ‘any’ claim as you mean it, and IT buyers are not so dopey to think that.
So it comes down to a numbers game. You say BPMS only addresses a ‘tiny fraction’ of real-world problems. I agree it’s a fraction, but think it is not a tiny fraction, and that you are simply uninformed about it. Since you seem to write a lot about BPM, I think you should get better informed about BPMS. My reports are free on BPMInstitute.org.
And if I were to finish this in your style, I would add… but I bet you won’t.
Touche’ Bruce
I have read many of the articles at BPMInstitute and will continue to do so. I accept any suggestion to learn more, as I am always learning. Thank you for being civil. I endeavor to do the same.
Your playback is interesting. Perhaps if we had started with a little more logic and a little less emotion, we both would have seen common ground sooner.
I know that you feel that I have not met your challenge to "show me the people saying these things." To be fair, I’ve been involved in online discussions, of one kind or another, for over 15 years now (back to Compuserve days). No challenge of that kind EVER ends up with either side actually learning or changing position. So I did not take you up on it.
I hope you don’t emerge from this exchange thinking that there are no people making that claim. However, if I find citations for you, or draw that implication for you, then there is no value in it for either of us. I encourage you to look around and see for yourself if that implication exists, directly or indirectly, in the words of industry vendors, consultants, and service providers. I can open the door. It is up to you to walk through.
The reality is that it is impossible to truly automate a business process. The tools allow us to remove a little waste, sometimes to great effect, but the overall coverage of automation over an enterprises processes is small. The modeling part is valuable. The analysis part… done by humans… is the part where the tools really produce value.
I kinda think Evan is the middle ground here. We both care about BPM, just from different viewpoints.
— N
Nick,
Its really quite surprising to me that you’re in the BPM space and only now finding out about Bruce Silver. I’ve known about him for more than 5 years now (one of the first names I learned about when I got involved in BPM).
Your assertion that there is a lot of kool-aide drinking going on really misses the mark, in my opinion. BPM really has quite little hype compared to market segments of the boom era (CRM, ERP, content management, EAI, etc). BPM practitioners as a whole are a pretty modest bunch who make pretty modest claims. I think if you went to a few analyst conferences you would see that.
Like Bruce, I don’t know anyone claiming that business users are going to replace IT with BPM tools. I’m sure that over the last 15 years someone has said that. But please, point us to a current citation from say the last 12 months. It really isn’t Bruce’s job (or mine, or anyone else’s) to do this homework for you. It is your point, if you wish for people to believe it, you need to provide the evidence. Its the internet, if you can’t find the claims with a quick google and reference them then… maybe they aren’t out there? or, at the very least, there aren’t any people of note making this claim. Certainly not any of the analysts at Gartner or Forrester, or the independents like Bruce (and others). Nor the consultants in the space… Nor the vendors that I keep up with…
I think you also miss a key example of software diagramming turning into executable code (though, like BPM, the users are not "business users")… CAD design software for VLSI design of chips… when this software hit the market it reduced the demand for EEs dramatically. Big productivity boost. But, there are more EEs working now than ever… why? because the cost of a new/custom chip was greatly reduced so lots of chip ideas that wouldn’t have gotten attention now became worth doing.
I see BPM the same way – in the ocean of processes out there, the really big ones are served by "packaged apps" (i use the quotes for a reason) provided by big vendors (oracle, sap, microsoft, etc). But there are lots of processes that may never have good packaged apps to describe them, or which cross boundaries between several packaged apps… BPM software makes the addressable space of process applications much larger, given the same $ spend.
To your point about IT projects (network infrastructure) being more valuable… wow. I’ve rarely seen an ROI analysis on network projects, or security infrastructure. So many projects in IT have no concept of what the ROI will be. But BPM projects often have a firm grasp of ROI before they start, because you can assign cost to the process steps, and understand how process changes will affect that cost. And then you can measure the ROI when you’re done, in a way that you never can with these other types of projects… In fact, Gartner cites the average ROI for BPM projects as being 15% per year, ongoing. That’s not bad. If I could get that out of my stock portfolio I’d take it 🙂
As for "its impossible to truly automate a business process"… I would submit to you that it isn’t a process if there isn’t a human involved – at that point it is a program 🙂 So in that sense, you’re right. if you’ve 100% automated something, it never should have been a process to begin with, or else, you’ve made a very big mistake 😉 Having said that, you might choose to automate something with a BPMS, that in the end is really just another program described by a processing tool.
Personally, to relate to the MSFT world, I think it may help to think of BPMS as the Visual Basic for business processes… the analogy works for many of the folks I talk to. They get that the business users don’t want to be VB experts, but that they can see some quick prototypes of UI and flow, and they can even do some modeling (equivalent to UI layout) themselves if need be. But IT will take it over the production finish line…
Speaking as someone who has participated in at least 100 production process rollouts… I think you’re under-estimating the benefits of BPM when you pair good process analysis with good process implementation…
Hi Scott,
Surprised or not, it is what it is. It is not like Bruce Silver’s work is published in two dozen process modeling books. From a quick scan of Amazon, I found zero books by Mr. Silver. He appears to have a solid analysis and consulting practice, back to days at Giga with a solid foundation in workflow back to Wang. However, as an analyst in BPM, his work is orthogonal to mine. He could well be the best known person in the analyst community and that does not mean that I would have run across him, as I do not need a BPM analyst.
Bruce is clearly a passionate guy, and has been doing this a long time. Credit.
Your chip example (VLSI chips) is interesting, and if I were worried about losing my job, I’d be all over it. I’m not. The place where that example breaks down is that VLSI modeling is, essentially, programming in silicon. That you can translate from a diagram to ‘code’ is not surprising. We’ve been able to do that with UML modeling tools for a few years now. This is a very different thing than suggesting that a business process model can, or should, capture sufficient information to translate directly to code. The entire notion (of going from a business process model directly to code) only works if there are huge amounts of ‘supporting assumptions’ (and software) that the modeler finds useful. In VLSI, those assumptions are built in to molecular physics. Oh, that life in a business were so simple.
Your argument about BPM software making more processes addressable doesn’t connect. I don’t follow your logic. Sorry.
As for BPM and ROI: I agree that improving a business process can demonstrate tangible value. No argument there. I agree that automation of a couple of steps in a process can demonstrate tangible value. Why else would Microsoft be writing process execution systems? You will notice that I include investment in improved business efficiency.
What I disagree with is the notion that BPM tools automate business processes. BPM tools orchestrate a specific number of finite activities, when developed by a technical individual. That orchestration can be valuable.
In addition, BPM modeling tools can be used to develop models of the business processes (to any level of detail) and apply simulations and rules and validations and all kinds of useful analysis.
The problem I have is that these two things are very very different from one another, and most suites make every effort, explicitely or through subtle means, to obscure that fact.
Years ago, I heard a good story about "my umbrella." My umbrella is cool. It is better than most people’s umbrella. When pouring rain, I can stay completely dry. I can include others in my ‘dryness.’ While we are covered, we can even listen to music. We can travel from place to place at high speeds.
Would you buy an umbrella like this? How about if that umbrella costs $25,000? What if that umbrella is a Mazda 6 Sedan?
Moral: you can put together many capabilities in a single package, and typically one of those capabilities will provide the lion’s share of the value. That is normal. But should we label it by another name? Should we take a "small" capability (like listening to the radio, or orchestrating activities) and use it to drive the decision to purchase? If I don’t need a car, should I buy one to stay dry in the rain?
We agree that business processes cannot be completely automated.
What we don’t agree upon: pouring the capability of ‘activity orchestration’ into the same bucket with process modeling, applying a generic name (the commuter’s umbrella), and then claiming innocence when someone points out that someone may get more value by taking the bus.
Nick –
it turns out the interesting technical bits you are referring to can be written in the context of a process model, and the process model can execute those technical bits at the appropriate times in the process. some people call this automation, some call it orchestration, some call it something else – i don’t really care so much about the terminology.
when people in the BPM market talk about "automating" (or "executing") with BPMN-driven models, they are talking about an execution environment that can do simulation and analysis, but also can execute. how is that possible? because the execution of these steps is either implemented at lower levels of abstraction within the tool, or integrated with the bpms via various SOA techniques (or even old-school techniques). Maybe this isn’t what you mean when you say "automating" or "executing" a BPMN process. And maybe that gap in terminology is what causes you so much frustration. But I think if you spend more time reading work by people like Bruce Silver, Sandy, and others, you’ll understand what the terms mean in the context. Not what they mean at Microsoft, but what they mean in the BPM market. I have implemented such solutions myself, using a bpmn-compliant model as the first several layers of abstraction, and ultimately drilling down to an implementation layer as well. The BPMN notation all by itself doesn’t describe enough detail to "execute" but in combination with obvious extensions found in these BPM Suites, you’ll have plenty of details for the BPM engine to execute. (and yes, designing these details correctly requires someone with the right skills).
you can tell me my car won’t get me from point A to point B, but if I drive it work every day, either I’m crazy or you’re wrong 🙂 People are driving these BPM cars all the time. they work. However, I’ll grant that not all BPMS solutions are created equal at this stage in the game – from an implementor’s point of view, the market is still quite differentiated. Even if the market doesn’t perceive that difference yet.
sorry, re: more processes being addressable…
a good BPMS package makes it more efficient to model and execute a Business Process. more efficient than what? more efficient than just writing code to do the same thing, in someone’s IDE. the BPM IDE if you will is a productivity enhancer, reducing the cost of implementing a process and understanding the process in order to implement it, thus making more processes worthwhile to invest in.
An example. Say I could save 1 gallon of gas a day if I spent $1000 on improvements to my car. well, gas has to get pretty expensive before this looks like a good investment. its actually about there at $4/gallon 🙂 But what if I made the cost of those improvements $500… wow, now the price of gas can be a lot less and it is still worth it to make the investment. Its that whole ROI calculation. There are many processes with an R… but that R has to be greater than the I required to implement the improvements or the process. if you reduce the size of I, more processes become "addressable" because they become worth doing. That’s why I raised the example of VLSI / CAD software. your UML example is good as well…
2 cents
scott
Hi Scott,
Thank you for the detailed explanation of your intent when you say that BPM software makes things more reachable.
I think we are still talking about two different things. You are using a visual modeling environment to write software. I don’t have any problem with that. I have a problem will calling the models "Business Processes." They are not.
I think you misunderstood my "umbrella" analogy. If you had understood it, you’d say that "people are driving these BPM umbrellas to work every day."
Microsoft has not altered my perception of BPM. Microsoft, as a company, disagrees with me and agrees with you.
My reality is intact. The BPMS software industry has told people to buy $25,000 umbrellas (made by Mazda) because they keep you dry. I’m simply pointing out that it’s a car. The value is as transportation, not the ‘umbrella-ness.’ Reading the work of other ‘umbrella sellers’ will educate me on the way to use the ‘umbrellas’ to haul a boat or drop Grandma off at the airport, but it won’t change the absurdity of the situation.
We should have visual programming languages. I’m all for that. I object to calling the programs "BPM models."
— Nick
And as a follow-on… The value of BPM tools is often cited, especially in SOA circles, as flexibility. Using a BPM suite, we can call SOA services in a flexible manner. Now, we can change processes around far less expensively.
I’m a proponent of that myself… but it’s rice farming. I agree, if you are in a nice, fertile, well-watered area. But, if you are standing in the desert, perhaps you shouldn’t be deciding on rice farming.
And if you don’t have a SOA infrastructure with services that are well designed, loosely coupled, and using a flexible and extensible canonical model, then you are not in a good place to get flexibility out of a BPM solution. It becomes ‘just another visual programming language.’
— N
Nick,
your definition of what is a business process is just different than everyone else i work with. that’s okay. now i understand where you’re coming from.
i did understand your analogy, but my point was that you’re telling me we’re driving umbrellas to work and i’m telling you they’re cars 🙂 in other words, in a (admittedly lame attempt at humor) way, i was trying to point out that who am i to believe – you or my lying eyes? you tell me that i have mistaken my car for an umbrella. i’m looking at it and thinking no, i’m pretty sure its a car and it is meant for what i’m using it. and it works great.
SOA circles cite "agility" because they are further from the ROI. BPM circles cite "ROI" because they can actually figure out what it is. SOA != BPM, though the two are highly complementary.
thanks for the clarifications, Nick – even though I have to disagree with some of your statements, I feel a lot of the disagreement stems almost entirely from definition of terms – and given that, not much to argue about 🙂 there is a benefit though to using the terms as others use them, rather than using your own definitions… its easier to get to the point of the argument or to communicate more clearly.
scott
Hi Scott,
I ran my understanding of the term ‘business process’ and ‘business process model’ past a couple of Enterpise Architects… and no one disagreed with me. Probably because I took the terms from the Workflow Management Coalition, which is pretty close to a ‘solid standard’ for BPM terminology.
Your earlier statements agree with me too.
Methinks you are still looking at the problem through BPM-colored glasses. Alas. we will have to agree to disagree.
I’m not telling you that your car is an umbrella. I’m telling you that the industry is selling $25K umbrellas to people, and telling them to use the umbrellas to stay dry… and also to drive around in them.
The lie is not ‘your lyin’ eyes.’ It is the term Business Process Automation. It is basically an oxymoron.
I don’t know why my statements are so difficult for you to understand. A business process model is a description of the activities of various actors (depending on the level of abstraction). It is not intended for writing software.
Writing software with that language creates a lie: that we can describe a business process, and automate it.
Creating a model that can be converted to code is programming. It is not business process modeling. Different people, different work, different measurables, different timing. Calling this duck a dog doesn’t make it stop quacking, and it confuses the other dogs.
— N
I have nothing of substance to add to the BPM discussion other than to say thank you for the entertainment! It is nice to see the other IT people have passionate discussions about their beliefs and understandings about a subject!
btw, i get my definitions from OMG… and i agree, i’m looking at the world with bpm-colored glasses, just as you’re looking at the world with anti-bpm-colored glasses 🙂
it isn’t understanding your statements that is hard nick, its agreeing with them 😉 and when i (or someone) disagrees, you change the premise of the original argument. if you’re argument from the beginning was simply that BP Automation is an oxymoron, I don’t think you’d get that much disagreement if you define things well. Sure, its an oxymoron if you consider a process to be something that includes people (this is kind of like the turing test – if it can be programmed then it is not a process… ) however, that doesn’t change the fact that the spaces inbetween those people can be automated (moving data from one person to the next, in context of the process), and that this movement can be modeled quite well with BPMN, and then actually automated. Often people refer to this movement as "orchestration".
Perhaps you don’t see any value in that portion of the BPMN transition to executable model, but having done it many times, I can tell you there is value to it in my experience. Your mileage may vary. in the meantime, my crop of rice is doing just fine, desert or no 🙂
Goodness me! I’m almost lost for words. I have a few general comments:
1. BPM as a management system is still in its infancy.
2. BPM as an integrated suite of application software is still in its infancy as evidenced by the turmoil in the vendor camps. If BPMS’were easy to build the major vendors would have built there own instead of buying anything that shows promise.
3. What we are tring to do is get our executives to take a more informed view of their business so that they can formulate effective strategy and align the stratgey to the enabling processes. We’re doing this with a model-driven approach.
4.These processes have to be deployed. The biggest problem we have is process standardisation or the lack of it (shadow or ghost processes). Orchestration or automation provides some help but its not perfect (see 2 above).
5. Our intention is not remove the need for IT people. We need more alignment and engagement between business and technology (going both ways)so we can improve the design and execution of our business processes.
Hello brianfrew,
You get no disagreement from me.
It was enjoyable, coming back to this thread after a couple of weeks to re-read the flurry. We spent most of our time arguing over the tiniest details, yet agreeing on the major points.
Funny, that.
Isn’t it always true, though, that the people who care the most about something are the ones who sometimes get into a toss-up over words?
Now, to get back to my process modeling…
—N
Kudos to Andrea Westernein on her blog about the disjoint between the work that people do and business