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 other side 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 quintessence 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 spreadsheet 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.
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.
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.
What started a comment on this post grew to a full blog post 🙂
I agree to a point that BPM modeling should become more spreadsheet like. But I also believe that it is essential to have a tool which enables this business user design to enforce the typical IT controls around review, versioning and deployment, to ensure that the final product works as the business user intended.
If Fujitsu (for example) can get the modeling tools to the level of usability of Excel then this could pose a significant threat to the more programmer oriented tools offered by the like of IBM to support their large services organizations.
By the way, I linked to your post at: BPM modeling as easy as a spreadsheet
but I don’t think Blogger does trackbacks so you would never know it!
David Ogren has some insightful comments on this topic at Spreadsheets and BPM Part I.
Pingback: BPMS Watch » On Spreadsheets, Clean Handoffs, and a Dinner Bet
Your analogy works for single-user applications built on spreadsheets, but starts to fall apart when considering multi-user, complex application solutions. Users have tried to build these using spreadsheets and the results have usually been disastrous, with the birth of unmaintainable, undocumented monster spreadsheets where the fundamental logic used to make critical business decisions is oft-times totally wrong.
There is a place for more IT-oriented tasks such as testing, QA, data integrity, performance, reliability, security, auditability, correctness and such.
It’s not a black and white issue. Sure, BPM can be used by some business users, for some situations, but for many scenarios that is not desireable nor practical. As with most things in life (and technology), the final response is “it depends”.
As a pragmatist, who is quite fond of BPM, I think the answer lies somewhere between this post and Tom’s response, and the interesting part is not the final destination (which is what the discussion seems to be about), but how we approach the journey, since the history of programming/IT is about successive higher level abstractions replacing lower level constructs.
As with many new approaches, I believe a crawl/walk/run approach is a wise course for most organizations and that IT and Buiness need to collaborate during the journey that BPM tools and technologies are going to take us on.
My 2 cents worth.
I completely agree, and I don’t mean to imply that all programming will eventaully be done in Spreadsheets. Clearly professionally developed applications will continue to thrive, and the same is true in the BPM space. I point out only that there there is a huge number of relatively simple applications that are being implemented in a spreadsheet. I believe the analogy holds true in the workflow space: there are a huge number of relatively simple BPM applications that could be created by business users if the UI is done right, but not all BPM applications will be developed this way.
Found your blog through a post on TheServerSide. Would love to catch up. Please drop me an email when you have a chance:
edwin.khodabakchian AT oracle.com
khodabakchian AT yahoo
Looking forward to connecting back!
Where I work, millions of orders are placed every day through thousands of sales people in several dozen countries, 6 timezones and it’s all done on a single Excel spreadsheet! There are several other spreadsheets for inventories at several hundred warehouses, invoices, ship notices, cancellations, back orders, etc. In order to reduce overhead, we’ve placed the Excel spreadsheet on a public folder visible to the world and allow customers and vendors to update it.
We also have a wide range of bridges for purchase. There’s one connecting Brooklyn with Manhattan that I can offer at a very competitive price.
Pingback: ECM-BPM Corner » Archives » Processus métier et application Excel, même combat ?
Can business users make thier own workflow applications, well yes they can. My girlfriends father who is an accountant with zero programming training created a simple 3 or 4 step BPM application using Kontinuum. I think the key word here is simple. Programmers are more likely to see the problems a little bit differently and their concerns of maintainability, reuse etc would not be at the forefront of the mind of a business user. This would mean that as workflow systems tend towards greater complexity the non-programmer would create a less and less cost effective solution.
As for the first question of Business office workers will never program software well they are already doing so. Not only in excel type applications but also in creating BPM applications.
Another counter arguement is that the application is purpose built. Well every language was built with a purpose. Take C and Prolog. Built for different purposes. Are neither of them programming languages? If you submit that they are because ultimately they could achieve all the functionality of the other albeit in an often convoluted way well then couldn’t a BPM system deliver such functionality albeit in a more convoluted way?
As a final though some people have said that 3gl is not programming. OK why? Because it is to easy? Because you dont have to type? The important part of programming is logic. If you can deliver to a computer that same logic through dragging and dropping something as opposed to typing it out what should it matter. If not then isn’t 2gl not programming either? Should we real programmers go back to binary?
Pingback: Can business users make their own Workflow/BPM Applications « Workflow Blog
keep it simple stupid, use excel. I totally agree!
but, how to learn to people how to go through the documentation, how to write it, how to test the application they are using?
nevertheless,your post is maybe an evidence that the majority of the human needs are basic, don’t you think?
Pingback: BPM is not Software Engineering « Go Flow
Pingback: Is the BPMN/BPEL Debate a Dead Horse? « Go Flow
Pingback: Keith Swenson’s Blog – On Collaborative Planning « Adam Deane