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.

Software Architect Bootcamp Book Notes

I was browsing through the book Software Architect Bootcamp by Malveau and Mowbray and noted down a few interesting points.

Rule of Three

• A single design occurrence is an event
• Two design occurrences is a coincidence
• Three design occurrences is a pattern

Classic Reference Model for Consulting Intervention

• What is the problem?
• What are others doing to contribute to the problem?
• What are you doing to contribute to the problem?

Components Vs. Objects - Principles of Components

• Encapsulation
• Polymorphism
• Late binding (composition during design time)
• Safety (e.g. in Java, memory safety is guaranteed through Garbage Collection)
• No inheritance - delegation (invocation) is used instead

Publish Subscribe with Ack

In a past project, we had implemented a "new EAI pattern" - Publish Subscribe with acknowledgement. How this was different from the regular Publish Subscribe was that all the subscribers would acknowledge the receipt of the message to the publisher, adding another layer to "guaranteed" delivery - a cross between Request Reply and Publish Subscribe patterns. The usage scenario was, while sending master data from a Source of Record to all subscribing systems, the receipt of the data was to be ensured as it was functionally critical.

I am not too convinced that this is indeed a new pattern as publishers in the Publish Subscribe pattern, need not be aware of the subscribers. But in this case they would have to be.