An integration model for the next economy

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 we can deliver information effectively, efficiently and consistently between applications. It does not, however, ensure 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 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 shared between these applications is actually understood as being relevant to the same customer, despite the fact 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 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 all parties understand it.

Enter Web services

Web services looks as though 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. That is, messaging and transformation. They will be squeezed on two counts:

The overwhelming sensibility of a common standard that will break down the barriers of information exchange between proprietary products.

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 – a place where, for the time being, and for the near term future anyway, margins will still be high.

Aaron Kumove is managing director of Horizon Consulting. He can be contacted atakumove@horizonconsulting.co.nz