The 'why' and the 'how' of business processes

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.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @ITworld

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine