October 2002

Aaron Kumove -- Managing Director, Horizon Consulting

Let’s start at the bottom of the model with the messaging layer. 
A problem faced by many organisations is the difficulty in sharing information for cross-functional purposes between disparate applications developed independently of each other over time to serve “stovepipe” functional needs.  The “traditional” way to solve this problem has been to build discrete point to point connections between applications on a “one-off” basis to solve a particular tactical need at a given time.  In isolation this works just fine much of the time.  The problem arises however when the number of applications grows and hence the number of “one-off’ point to point connections grows.  The growth rate of point to point connections far exceeds the growth rate in the number of applications in such a scenario and can quickly become expensive and inefficient, if not verging on unmanageable!  To make matters worse the way in which these point to point connections are built can vary widely such that there is no consistent method employed to design and build these connections.  i.e. higher support and maintenance costs due to increased complexity and the need for a broad range of skills to keep this all hanging together.  This is illustrated as follows:

With five applications in the example shown we have ten point to point interfaces (assuming information only needs to travel in one direction, and this is unlikely to always be the case.  If information needs to flow bi-directionally then the number of interfaces is 20).  The number of point to point connections can be predicted by a simple calculation: n*(n-1).  This means that the growth in the number of applications, and interfaces between them proceeds as illustrated in the table below.
 
 

Applications	Interfaces
2	2
3	6
4	12
5	20
6	30

As the number of applications grows linearly the number of interfaces between them grow geometrically!  In no time we end up in “point to point hell” or “spaghetti junction”! 
OK.  So what?  Isn’t this what we pay technical people to manage for us?  Well, the point of this is that organisations that travel this path are paying more than they must to keep this kind of architecture running.  More in development and integration costs, more in the number of people required to support this model, more in resolution of faults and more in training to support the myriad of interfaces of different types. 

The biggest cost however is in the lack of strategic flexibility as the number of point to point connections grows.  Each new addition becomes a little harder to accommodate than the previous one as there is continually more to integrate with.  Time to market suffers, timeliness of fault resolution suffers as diagnosis becomes ever more difficult, and investment leverage and scalability suffers as we continually build “unique” point to point solutions that are often not re-useable within an organisation or between business partners.

Surely there must be a better way to do this . . .

The solution is to stop connecting applications directly to each other.  If we broker these connections we can solve a number of problems.  We can drastically reduce the number of connections we build and we can also standardise the connections to reduce complexity. 

Note that in this case, with five systems we now have only five interfaces, each talking to a broker, rather than connecting applications directly to each other.  Since each application talks only to a broker each interface is also consistent with the rest. 
Why is this an improvement over the point to point scenario?  Fewer interfaces of a consistent nature equates with: lower development and integration costs, reduction in management complexity, reduction in maintenance costs, improvements in fault diagnosis and resolution, and reduced training and staffing needs.

The bigger win is however in the strategic flexibility that this architecture affords.  Reduction in complexity and adoption of a consistent integration model allows for faster time to market, greater scalability to accommodate new business initiatives and business partners, and ease of change. 

Next month we will examine where Web Services fits in this kind of scenario and look further up the five layer model to understand the benefits that can be built on top of those derived from a consistent messaging layer.

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