Estimating Interface Development Effort in EAI Projects

Recently, I had been assigned the task of reviewing and improving the effort estimation in developing interfaces in EAI projects. I had tried this in the past but with little success.

To understand the problems in estimating EAI projects, we would need to understand how EAI projects are implemented. The following two approaches are largely followed in the development of EAI projects:

• Directly using Off the Shelf EAI products
• Building and using frameworks on top of EAI products

When developing directly using EAI products, the problems are that each product comes with its own unique set of components to define an interface. For instance, an interface in IBM's WBI InterChange Server would largely be built using

• Connectors
• Business Objects
• Maps
• Collaborations

where as in a project that uses Mercator (now WebSphere DataStage TX) and IBM WebSphere MQ, the interface would be composed of

• Adapters
• Type Trees
• Maps

We could roughly equate Adapters with Connectors, Business Objects with Type Trees and Maps with Maps at an architecture level. Collaborations, though are absent in Mercator. However, at an implementation level, the differences are too much to be left unconsidered. For instance, Business Objects are totally based on XML while Type Trees are not. Maps in ICS allow for extensive custom code to be written while in Mercator, only limited custom code can be written using the in-built scripting language. The absence of a component (Collaboration) also makes a great deal of difference. These are scenarios using only two of the many products available in the market. When we consider all available EAI products it becomes uncomprehensible.

The framework approach involves building a layer over the EAI products in order to add commonly required features and reduce development effort. The aforementioned problem applies to this situation too, as there is no standard way of defining an interface leading to frameworks that are specific to EAI products.

So, in order to arrive at a standard way of estimating EAI interface efforts, the product vendors need to define interfaces in a standard way. They should decide and agree that an interface would consist of standard components, for example, Adapters, Message Sets, Maps and Message Flows that would in turn be built of standard units, e.g rules, parameters etc The competion among the vendors would then be on providing the best components and the best server. Till then, interfaces would remain kludges and estimating their development time, unreliable.