November 2002

Aaron Kumove -- Managing Director, Horizon Consulting

We started last month with the bottom layer of the model, the Messaging Layer.  We discussed how adopting a common messaging model to allow applications to communicate with each other can lower costs, improve time to market and ensure a manageable, scalable and maintainable way to add strategic capability.

This month we will look at the next layer in the model, the Transformation Layer.  Having a common messaging model ensures that we can deliver information effectively, efficiently and consistently between applications.  It does not however ensure that the messages, once delivered, can actually be understood!  This is the purpose of the Transformation Layer.  

The best way to illustrate the purpose here is to liken it to a translator who mediates a conversation between two people who speak different languages.  For all practical purposes what we are generally talking about here is conversion and mapping of data between disparate formats so that the applications communicating do not have to worry about doing this.  (Otherwise we are back to “point-to-point” custom definitions, and we discussed the evils of “point-to- point hell” last month!)

For example, one application may refer to a customer by name while another may refer to a customer by customer number.  The Transformation Layer function that sits between these two applications ensures that information that is shared between these applications is actually understood as being relevant to the same customer despite the fact that the customer is referred to differently by each application.  

You may ask why don’t we just define them in the same way from the beginning?  The simple answer to this question is that in most organisations applications have been developed at different times by different departments and business owners with different drivers and information needs in the absence of a common standard.  

Even if we lived in an ideal world where every organisation had common internal standards, and if such common standards could accommodate all business requirements for data definition across applications, we would still need a transformation function to allow us to exchange information with external parties where we need to refer to common information.  While we can mandate internal standards, we generally cannot mandate them to other parties.  

With a common Messaging Layer and Transformation Layer in place we now have some basic building blocks in place to allow us to get some real work done.  We can effectively move information between applications and we can ensure that it is understood by all parties.

Historically, the Messaging and Transformation Layer functions have been delivered in the form of proprietary products from a number of middleware or Enterprise Application Integration (EAI) vendors, and of course these proprietary products don’t often live happily together.  That may be OK for internal use within a single organisation where you can standardise on a single proprietary standard, but it one wants to exchange information with other parties this presents problems unless they have adopted the same proprietary standards.  In addition, these proprietary products have generally been expensive.

Enter Web Services.

 Web Services, (which was discussed in previous issues), is looking like it will become the dominant common standard for Messaging and Transformation Layer functions.  Pretty much all of the EAI vendors (and application software vendors) are now providing Web Services interfaces in addition to their proprietary product interfaces.  
As Web Services takes hold as the dominant means to exchange and transform information the vendors of proprietary middleware products will be squeezed from the niches where they made their names.  i.e. messaging and transformation.  

They will be squeezed on two counts:
1. The overwhelming sensibility of a common standard which will break down the barriers of information exchange between proprietary products.
2. The price point and inherent margins at which Messaging and Transformation Layer functions can be sold.  Web Services will essentially take the margin out of being in this business.

Not surprisingly, the vendors of middleware products are migrating up the food chain as a once profitable niche becomes exhausted for them.

Next month we will look at where they are migrating to; a place where for the time being, and for the near term future anyway, margins will still be high.  

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