December 2002

Aaron Kumove -- Managing Director, Horizon Consulting

We have looked already at the two lowest layers of the model, which provide us with the means to deliver messages and to transform them so they are intelligible to all parties.  I also made the assertion that the Web Services paradigm is going to commoditise these lower layer functions.  In part, because of this, many vendors of integration products are focusing their efforts further up the model, on the actions that are taken as a result of these messages and the larger business processes that these messages form a part of.

The third layer in the model, the Rules layer is concerned with what action to take as a result  of a message being sent.  i.e. who should it be sent to and under what circumstances?  For example:

• We could have a rule that says if an invoice received by Accounts Payable is less than $50, issue an electronic funds transfer upon receipt. 
• If the invoice is between $50 and $100, issue an electronic funds transfer upon receipt, but also update the product management system to indicate that this is an unusual size of order for this kind of product. 
• If the invoice is greater than $100 do not pay; e-mail a manager for manual intervention/approval and mark as “pending” in the Accounts Receivable system.

This is where the Process layer of the model comes to the fore. 

At the Process layer you graphically represent the parts of an overall business process, typically by drawing flow chart representations.  Each element in the flow chart represents combinations of operations defined at the Rules layer, which we manipulate as we write a flow chart.  The advantages in this approach are as follows:

• We put business people in greater control of their operations by giving them the ability to represent what they want in a business friendly manner.  While not yet an entirely “code free” exercise, we give business people the ability to participate in process design with less reliance on technologist to make it happen.  Today the state of products at the Process layer is not such that a business person can design and implement processes without some coding assistance from a technologist to actually make it happen.  That is where these products are moving to however over the next few years.
• By packaging up units of Rules into graphically represented icons on a flow chart, we can re-use whole units of decision by merely selecting from a palette of pre-defined graphical objects which encapsulates a number of rules.  Over time as we develop more applications this way we will build up a larger repository of graphical process elements such that application development may become more akin to assembly than manufacture. 

In an ideal world a Business Analyst will develop an application largely by dragging and dropping flow chart elements and combining them to create a new business process or modify an existing one.  That ideal world is not yet upon us.  The product capability at the Process level, while evolving very rapidly, is a few years away from being at the level of complete abstraction from the underlying technology that I am referring to. 

But, that is the direction we are heading and it promises to change the way we develop and manage applications. 

Aaron Kumove -- Managing Director, Horizon Consulting

Read Past Issues

Horizon Consulting is a leading provider of successful strategy and management implementation services for knowledge economy organisations.  Our clients are world leaders in obtaining strategic advantage through eBusiness and Information Technology. 

Horizon Consulting PO Box 2252, Wellington, New Zealand; Tel: 64 4 939-9944; 
Email: service@horizonconsulting.co.nz