CTO Articles
Published in IT World
E-Business in the Enterprise – May 25, 2004
When modelling business processes, upside down is the right way up
By Sean Mc Grath
One of my all time favorite ideas in problem solving is from the Hungarian mathematician George Pólya[1]. It is known as Pólya's Inventor's Paradox. It comes in many forms but the easiest is this:
Simplify by solving a more general problem.[2]
In my day to day work in commercial IT, I find a variant on this aphorism more appropriate:
You will need a solution to the more general problem. You will end up doing a costly rip and replace to get it, unless you address it now.
At a micro level, on a project by project basis, engineering teams must make choices between so called 'point solutions' and more general solutions to specific problems. This choice is an everyday occurrence and features the usual tense troika of time, cost and quality.
Point solutions are quicker to implement but brittle in the face of change. More general solutions are longer lived but more costly to create. This is the classic paradox of commercial software engineering.
At a macro level, I think it is interesting to look at computing revolutions (instances of pandemic rip and replace!) which can be seen as shifts from point solutions to general solutions.
Graphical user interfaces are a good example of the phenomenon. The point solution to a user interface assumes that the actions of the user can be completely driven by the application. i.e. the programmer gets to decide how big the data entry screen will be, what data will be entered into it, what order it will be entered in and so on. In this model, an application takes over the computer, drives the user interface and works in isolation of any other application.
The heyday of application-driven interfaces were the early days of personal computers. Classic applications like Visicalc. Classic programming languages like Clipper. Eighty columns, twenty five lines and block flashing cursors. In user interface terms, these were the days of the modal dialog[3]. i.e. a mode of interacting with the user in which the application, not the user, is in charge and dictates the tempo of the human computer interaction.
Along came graphical user interfaces with their WIMP[4] interfaces. All of a sudden, developers had to contend with screens (windows) that could change size at any time. Not only that, but users could press pretty much any button, any menu item, at any time. In user interface terms, these were the days of the modeless (also known as non-modal) dialog[5]. The heyday of classic user interfaces like the Apple Lisa and classic applications like HyperCard.
In order to tame the GUI programming beast, developers had no choice but to adopt a more general solution to user interface design. Instead of assuming they had control over the screen and the user interaction, they had to yield control to an over-arching window manager. They had no choice but to become reactive rather than proactive in dealing with user interaction. In geek terminology, they had to adopt an event driven[6] style of programming.
In the early days of this costly upheaval, it was not uncommon to hear the phrase "upside down programming" used around the water cooler to describe event driven programming. The reason for this description is that event driven programming really does involve turning the modal programming style on its head. Instead of driving the dialog with the user, the programmer creates a large set of "handlers" for particular types of 'events'. i.e. a mouse click, resizing of a window and so on. Having set up the handlers, the programmer needs to hand control over to the window manager part of the graphical user interface. From that moment on, the program needs to be purely reactive, not proactive in dealing with the user.
I am describing this as a more general solution because it works just fine when the total number of applications is one. It works just fine if the user never resizes the window, never pastes anything in from another application and so on. If you have written your program to work "upside down", it will also work right way up. If you see what I mean. The more general case works fine in the special case. Pólya Rules OK.
These days of course - especially to programmers in their twenties -upside down programming is seen as right way up programming. They most probably have never seen a system that does not have a graphical user interface. To them, the more general problem of graphical user interfaces, is the standard problem.
Now let's turn to something closer to the heart of commercial IT -modelling pan-application business processes. The point solution to stitching together application X and application Y into a business process involves the programmer driving the integration. First application X is invoked to do something. Application X must respond quickly so that application Y can be invoked to do the next part of the business process - otherwise the business process fails.
In this model, the programmer drives the business process onward, dictating the tempo which applications must follow. There are numerous terms used to describe this approach but my favorite is 'temporally coupled'. Applications must work in lock-step with each other for business process to function as they should.
This is a point solution. Why? Because it only works well when all the applications underfoot are under your control and (preferably) on the same physical network. Under those conditions, temporal coupling is manageable. Costly but manageable. The more general case of course is where not all the applications are under your control and not all on your local network. Web Services on an Extranet or the Internet for example.
To handle the general case of Web Services owned and hosted by other organizations, with the varying quality of service that that entails, programmers need to take a different approach to pan-application business process modelling. Instead of driving business processes programmatically, they need to deal with the fact that they are no longer completely in control. Web Services respond at different rates, they may not be up all the time, they will produce garbled data because somebody changes something without telling you and so on.
How to proceed? The answer is to turn your business process upside down. Just as you did a decade ago with graphical user interfaces, change the way you look at the problem to be reactive rather than proactive, event-driven rather than procedural. Put reliable messaging with persistent message queues between your disparate applications. Program business processes so that they move forward in response to events in a time independent fashion. Make the steps in your business processes temporally decoupled from each other.
To many, this "upside down" way of viewing business processes will seem alien. I remember feeling the same way about upside-down programming of graphical user interfaces. I got over it. The business process people will need to get over it too.
In years to come, I firmly believe that all business process modelling will be done in the more general, event-driven model. A model in which applications integrated on a fast, reliable local network is seen as just a simple, special case of the more general, event driven solution.
Will we see the same sort of 'rip and replace' we saw in case of the shift to GUIs? That is a good question. I think wholesale rip and replace can be avoided as long as the evolution to the general model is well thought out and incremental. Key to that is a thorough understanding of temporal coupling and a root and branch review of what parts of your applications need to be temporally coupled and which do not.
For organizations without an existing pan-application business process modelling strategy, now would be a good time to look closely at the general solution. Are you one of those companies we are constantly told about that is making great headway with Web Services behind the firewall? If so, I suggest you taken a close look at the amount of temporal coupling implied by your model. Remember: upside down is the right way up.
[1] http://www-gap.dcs.st-and.ac.uk/~history/Mathematicians/Polya.html
[2] http://www.ccs.neu.edu/research/demeter/adaptive-patterns/AOP/IP.html
[3] http://www-106.ibm.com/developerworks/usability/library/us-cranky12.html
[4] http://www.webopedia.com/TERM/W/WIMP.html
[5] http://www.jefraskin.com/forjef2/jefweb-compiled/humaneinterface/summary_of_thi.html
[6] http://www.ferg.org/projects/ferg-event_driven_programming.html