Several months ago, I started thinking about the parallels between spreadsheets and the BPM industry. Several of my customers had been asking me about which features of AquaLogic BPM that "non-technical business users" will be able to use and which features will require IT involvement. This is certainly a fair question because one of the core tenets of BPM is to give more independence to the business in defining their process applications. I had been hoping to finish that post this weekend. But, while researching, I found that another blogger had just made a post on the exact same topic. I guess there really are no original ideas. :-) :et me comment on the posts I found first and then follow that up with some of the post I've been working on.
The post I found was from Keith Swenson of Fujitsu responding to Tom Baeyens of jBPM. In short, Tom was arguing that analysis and implementation cannot be unified. That a "non-technical business user" may visually map the process, but that there will always be an implementation of the process activities under that process model. Tom says that "most often, there will have to be some custom code tied to the process either as node behaviour or as actions which are hidden from the graphical diagram." He also asserts that an a process model designed in an executable language (specifically BPEL) is less flexible for analysis purposes, asserting that BPEL has a level of specificity that the business analyst will not care about. I don't want to put words in Tom's mouth, but he was generally being skeptical of the mainstream BPM vendors and their claims of having business users develop their own applications
Keith responds by using the spreadsheet analogy as a counterexample. Specifically that when spreadsheets were invented they allowed business users to develop their own "applications" that previously required the intervention of IT. That even though Excel isn't a typical 3GL development language, it has been a critical tool for business in developing applications. (Keith specifically cites Sarbanes Oxley compliance and report generation as examples of applications which have been largely supplanted by Excel spreadsheets.) Keith says that BPM is similar. For a specific kind of application, specifically process centric applications, the spreadsheet enabled business users to be self-sufficient.
Obviously, since I had already been thinking of the metaphor, I agree with Keith'about the similarities between BPM and spreadsheets. And I generally frown on Tom's idea of creating artificial separations between analysis and implementation in BPM. The process model is the implementation.
I would take this metaphor one step further, however. Think about the way that enterprises use spreadsheets. There are many different ways spreadsheets are used. "Non technical users" have no problems using a spreadsheet. According to Joel Spolsky, a former program manager of Microsoft Excel, most Excel users were just keeping track of lists. One of the nice features of a spreadsheet is that simple things are simple.
But, of course, spreadsheets are actually quite complicated pieces of software. In addition to the simple "take the value from this cell and add it to this cell" basic usage there are all kinds of functions for gathering information from databases and web services, parsing text, validation, complex math, lookup tables, and conditional logic. Not to mention all of the features related to slicing and dicing the spreadsheet data including pivot tables, goal seeking, analysis, and reporting.
My experience is that a lot of departments have a few complicated spreadsheets that they have developed that solve specific problems related to that department: forecasting sales, calculating bonuses, reporting on field offices, etc. Most of the spreadsheets are pretty complicated. They were created by some "power user" that figured out how to use all of those conditional logic functions and hacked together a solution bit by bit over the years. I've also seen many enterprises leverage spreadsheets for core business processes, with spreadsheets developed by professional programmers using a combination of Excel's built in functions and Excel's macro language: Visual Basic for Applications.
So, which functions of Excel can a non-technical business user use? It depends on the user. The majority of users can't really use anything other than basic cell operations. But there are certain business users will learn the skills needed to access more functionality. But even for the "power user" some features (like database integration and Visual Basic) will require IT involvement. It's also notable that even though the average department can create their own spreadsheet, creating something that is easy to use, styled appropriately, and "customer ready" will often require user interface specialists.
It's the same with BPM. Some users are never going to care about anything other than the high level model and the key performance indicators. Others will learn how to create their own forms and business rules. And integration and complex rules will probably require IT. And it's also important to note that some BPM applications will require IT (or user interface specialists) just because of testing and QA. No one wants a compliance spreadsheet that works most of the the time or a order tracking BPM process that works most of the time.
More on this on Wednesday, when I'll discuss how well the BPM industry is addressing the needs of business users and Friday when I'll discuss what lessons (good and bad) we can learn from the spreadsheet industry.