Go Flow

Business office workers will never program software! - or will they?

There is an interesting tension in the undercurrents of the high-tech industry. On one side you have vendors that make bold statements about the productivity that will result because all office workers will be able to make applications by themselves. On the otherside you have the insider cognoscenti who chuckle at the thought of untrained people attempting to do more than the simplistic examples offered in the flashy demos.

Programming, after all, is hard. It takes years of training. You need to understand obscure context-free grammars. You need to learn a technique of analysis to identify a sequence of steps that can be executed by a machine one after another to produce in the end the desired results. And then there are all the techniques used to allow code to reusable, or maintainable, so you don’t end up with a pile of spaghetti code that costs so much to maintain, but not quite enough to rewrite. Many people see this as the quitessence of “programming” and the only way to produce an application.

Business User Programming is Widespread Today

What do you suppose is the single most popular application development platform today? Java? Visual Basic? How about Excel? I would bet that there are more Excel spreadsheets than there are VB applications. I know for sure that there are more people who know how to make an Excel spreadheet than people who can write a VB application.

But that’s not programming! No, not in the sense of a traditional 3GL. But Excel can be used to create very useful applications that in the past used to require programming. In a very real sense, those Excel users *are* programming and creating applications. Spreadsheets have largely replaced many areas that used to be handled by “report writing languages”.

Excel is not as ‘general purpose’ as a 3GL. That also is correct. It is a special purpose programming environment that is useful in a business setting. In short it allows a business user to create certain types of business applications without having to learn how to program in the traditional sense. I have been told that a majority of the Sarbanes-Oxley compliance applications that exist today are implemented in Excel.

What has this to do with BPM?

It is quite clear that office workers in general will not be installing Visual Studio or Eclipse and start making BPM applications. But, they won’t need to in order to make executable business processes.

Many of the true “Human-BPM” environments allow a business user to draw a picture of the sequence of steps that are required, describe those steps in a spoken language, write simple formulae to determine who the activity gets assigned to, define a set of variables to hold the values, and to be able to execute that process immediately. Interstage BPM is one such product. No programming, in the traditional sense, required. But the business user is actually programming an application in the same way that creating an Excel spreadsheet is programming an application.

Many people are confused by this. These people start from the assumption that if you are going to make an application, there will have to be some traditional 3GL programming. As such, they look at the diagram, but dismiss it as a picture that a programmer will use to make the real application.

Many others look at the business process design environment as if it was development environment for 3GL programming, and they look to have all the normal thing that those environments bring.

Finale

Some people claim that business users will never be able to program business process applications. Tom Baeyens blogged about this recently in his entry “About BPM miracles and what you can expect in real life“. He argues that “Analysis and implementation cannot be unified”:

Whether software development though a programming language like Java or wether it is developed through processes in an executable process language doesn’t change the fact that a translation has to be made from the analysis over software requirements to an executable software model. The fact that it is graphical doesn’t change a whole lot in that respect. A process developer has a set of process language constructs and needs to come up with a process that is a solution for the software requirements.

…You can analyze or you can implement, but you can’t do both at the same time.

Tom is clearly in the camp of people who simply start from the assumption that you have to, at some point, program your application in a 3GL. He uses this as an axiom, and builds the rest of his conclusion from that.

I disagree. Consider how Excel has allowed people to directly construct the application. They put in a few numbers, then a few formulas. Before too long, they have a spreadsheet where numbers can be entered in one place, adn answer appear in other places. The “searching for how things work” (which is what Tom defines analysis as) is completely integrated in the implementation of the final application.

Why can’t the same be true for BPM? Why can’t we simply draw a sequence of step, describe them in English, assign them to people with simple formulas, define a number of variables to hold values in, and have a working application? Will it be any possible application? No. But this type of programming could cover a wide range of applications that are needed today.

There is a strong business need to take BPM out of the software development lab. Organizations of all types need basic coordination support, and Human BPMS can provide this. But just like those users who got tired of waiting for R&D to code up those reports turned instead to VisiCalc to do it themselves in 1980, so also will the business users turn to BPM tools that allow them to implement the application directly, without traditional programming.

Postscript

Tom Baeyens makes many good points elsewhere in his blog, so I recommend his site in general as a good source for BPM discussion ideas.