September 27, 2004, 10:29 AM — Business processes. We all have them. We all want to control them with technology to make them bigger, better and faster. Most of us like to envision a world where new business processes can be created in electronic form by Business Analysts working with high level design tools. In our minds' eyes, we see graphical environments where analysts can manipulate visual representations of a business process. They can drag and drop their way through a dialog that leads inexorably towards a big green button that says "Execute business process...".
I think it is interesting to peer a little closer into this vision and ask what exactly underlies the visualisation of a business process. To do this, I will invent a mythical twenty-first century soda dispensing machine. Our mouse wielding analyst is confronted with two use cases. Firstly, the need to capture the overall logic involving users inserting money, then choosing product and then the dispensing of the selected product. Secondly, the need to capture the logic involved in picking the optimal container size for bulk orders.
The first use case maps very nicely onto what is known as a state machine representation. Simply put, the soda machine starts out after booting in a "start state". As soon as money is entered into the slot, the machine transitions to a "getting money" state. From there, if the user presses cancel it transitions to a "give back money" state. If the user selects product and the money entered is adequate, the machine transitions to a "product dispensing" state. And so on and so forth. I think you will agree that a visualization of this state machine in terms of bubbles and arcs diagrams would make a good abstraction for our analyst to use.
The second use case smacks of math. It smacks of an algorithm, of control logic, of decision trees, of flowcharts. To illustrate, imagine that the process of determining the optimal container size required looking for the biggest number that divides two order sizes evenly. The algorithm for this was worked out by Euclid [1]
Compute highest common factor of A and B Let R = A modulus B repeat: If R is zero, stop Set A to the value of B. Set B to the value of R. The answer is B.
Now. How do we visually represent this to our business analyst? How do we give her intuitive, visual tools for crafting this sort of logic?
Beats me! I have seen lots of attempts, ranging from flow charts to decision trees and none of them seem to me to get close to a general purpose abstraction for the problem.
That in itself is worrying but is only part of the concern. The main problem is more subtle. Simply put, the state machine of the first use case maps so sweetly onto the problem that it acts as its own documentation. Any analyst or programmer could pick up the state machine and immediately think "Ok. I get it. It is states with transitions between states." In some sense, state machines - for problems that naturally map to them - encapsulate both the 'why' and the 'how' of a solution. From a total cost of ownership perspective, this is a wonderful thing.
The second use case however, brought us immediately knee deep into a thicket of math and boolean logic and loops and if/then/else shenanigans. We can concoct a visualisation of this that represents the 'how' of the calculation. Have we gained anything by doing so? I have my doubts. But the real problem is that no amount of visualisation of this sort of logic gets us any closer to capturing the 'why' as well as the how.
Perhaps there is some hard and fast law here that I cannot see. Some classification of problems that make them either suitable or not suitable for combined how+why visualisation. I would sure like to know what that line is because it would help determine when business process visualisation is really worth it and when it is not.
