I like point out really nutty ideas, even when a lot of people have spent a lot of time investing in them. This one is about expectations.
About 15-20 years ago, a great many companies starting investing in "Business Process Management" because of the opportunities to remove some really inefficient behavior. Along came the nerds, and we created pretty languages for describing business processes, and we started telling the business that once business processes are described using these languages, then you can push a button and "viola" the process becomes automated.
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.
Why do we say such things?
Perhaps because we know what a bad idea it is for software developers to write so much crappy code?
Yes, we want to get rid of expensive IT developers and replace them with something less expensive. Yes, we want to speed up the development of software that is custom to the business. Yes, we want business software to reflect the unique processes of the business.
But we cannot do it with visual business process modeling languages.
The reason is that BPM languages model HUMAN behavior. The things that "become code" are indicative of COMPUTER behavior. We have to be 1,000 times more explicit with computers than with humans. So we need to develop 1,000 times as much code for computers as we do for humans.
There are times when it makes sense to use BPEL for automation. But it is not a long list, because we have an abstraction that is a very long way from the code. We can automate a small number of situations where coherent activities, in sequence, are performed entirely by computer. Certainly, we want these situations to increase. But the overall impact on the cost and quality of IT-developed software is minimal.
And if we are not addressing the cost and quality of IT software… why even discuss BPM automation?
If the hype for BPMN is it gets rid of IT developers, and some people believe it, then I would get the heck away from those people, because they are going down in flames and you don’t want to get burned too.
From what I have seen, BPMN (especially paired with BRMS) can automate common aspects of process control (and spit out errors for people to look at), so that developers are freed up to work on new and uncommon parts, rather than writing common parts over and over again.
As to who should use the BP tools, its not inherently the users, it is whomever has the aptitude for it, and they will be found in both the business and IT. The eventual results produced by BP tools still have to be tested implemented like any other IT component, so it will never be completely independent of IT.
Hi David,
We are in violent agreement. 😉
That last paragraph is key. If you can automate something in a process, you have written software. If you write software, you must TEST it.
People who hype automated BPM often neglect to mention that.
— Nick
Nick Malik ????? , ??? ????????????? ??????-????????? ?????? ????????????????? ?????? ?? ???????? ??
Nick Malik ????? , ??? ????????????? ??????-????????? ?????? ????????????????? ?????? ?? ???????? ??
Nick Malik ????? , ??? ????????????? ??????-????????? ?????? ????????????????? ?????? ?? ???????? ??
Our comment on this post is at: http://tinyurl.com/vosibilities-071008.
Apparently, I ticked off Bruce Silver .  In case you haven’t heard of the fellow, as I had not,
15 – 20 years…hmmm I remember building automated processes in the late 1970s for the now defunct Rockwell International NAAD. At the time we started with a new fangled graphical convention called IDEF0.
Several dozen Aerospace and Defense contractors worked with Darpa’s Dennis "Wiz" Wiznosky to model how a corporation worked from a process standpoint. At that time several of us were investigating how to make the graphical language executable. We did have some successes. However….
What we found were the interesting points in BPM was that those processes that lend themselves to automation are those that are fairly well defined. No Duh. Thoise that required some form of judgement did not easily get encoded until the decisions, alternatives and criteria were made explicit.
As corporations now try to automate knowledge work processes, they’re finding out the same lessons learned in the 70s which fostered investigation into AI in a big way for a while.
That is not to say you cannot automate K.W., it just takes a lot of work to understand it and make it explicit enough to do so. During 2000 – 2005, I spent a segnificant about of time rationalizing and defining a Marketing Process for a major corporation, enough so they could semi-automate mcuh of it. Due to the size of the corporation the pay-back was significant. Was it completely automated; no, is it perfect; no. But this computered aid marketing process does work today rather well, enough that other corporations have purchased both the process and the tools to use in their own organinzations.
Does the system enable changes to the process by end users –yes and without learning C++, Scripting Language, etc.. however, that is only within a narrow range of changes which is really nothing more than workflow and routing. Eventually systems will enable more flexiblity and capability in BPM, but it will take a while before we "approach" the dream of LOB staff building processes without IT staff.
It sounds, Bruce, like you pretty much agree with me. I wasn’t aware of that particular effort, but I’m not surprised by it. My timeline was referring to COTS products, but many large companies invested in interesting ideas, and it sounds like you had a great opportunity to work with a legend. I’m green with envy.
What I am hearing you say is this: the stuff that you can automate with tools is well-defined stuff, because automation requires a great deal of detail.
The point that I was trying to make, and that I’ve been fairly roundly attacked for in other blogs, is that the stuff in a business process model, in BPMN especially, is not greatly detailed, and that is INTENTIONAL, GOOD, and USEFUL.
I’ve come up with all kinds of analogies to explain why there are different things here: process descriptions intended for human beings, and visual languages intended for computers… and that bundling them together in a single software product sets untenable expectations. They don’t appear to be working, alas.
It’s good to hear from someone who’s ‘been there.’ Thank you for contributing.
— Nick
Nick,
I’ve been very fortunate to work with lot’s of legends; Dennis "Wiz" Wiznosky, John Zachman (Enterprise Architecture Fame), Jerry Weinberg (IBM 360), Hans Witt (SMS) etc.. Maybe you’re forest green now.
During my time the little contributions I’ve made –MSF (Enterprise Architecture Planning), Rapid Economic Jusification, Conceptual Architecture for Active Directory, I.T. 1st Goveranance Model for Microsoft, etc.– and through working these different areas I’m still amazed at the over-reaching statements various technologist profess, especially when it comes to areas that attempt to take over human activities that have judgement hidden in them. BPM is just such a area.
Kudos to Andrea Westernein on her blog about the disjoint between the work that people do and business