Middleware – first or last choice?

(5 votes, average: 4.60 out of 5)

 Loading ...

I was involved in giving a Siebel Demo to some clients few days back and had an interesting conversation regarding Middleware while presenting the demo.

Client had an assumption that having implementing integrations using middleware will result in reduced complexity and increase manageability and doing the same integration with web services will result in increased complexity and will be difficult to manage.

I was really surprised to hear this but I believe this is a general assumption with business users. It seems like they think middleware to be of some kind of component that requires just one time effort to setup and one time investment. Once it is setup then you don’t need any effort and integration in future will need minimal effort to achieve.

This assumption might be true in theory but it is rarely true in real projects. I believe with introduction of middleware we just transfer the effort and complexity on middleware rather than actually reducing it. Let me try to explain this with example:

Let’s assume that we need to send data from Siebel to 3 external applications. Each external application expects a different XML for same information.

Approach 1:
We create 3 web services each generating a different XML and send it to 3 different applications.

Approach 2:
We use middleware and send XML to middleware. Middleware will transform the XML and send to different applications as per the requirement.

In the first look it seems that middleware is indeed simplifying the integration but let’s consider the following points in detail

Failure Points:
With Approach 1 we have just two failure points, Source – Target and it is easy to find out error as Web Services are synchronous but with middleware in picture we have 4 failure points Source – Middleware and Middleware – Target.

Cost:
Web Services are industry standard and uses HTTP, SOAP and XML there is no additional cost except from the effort of developing it but middleware will have additional license fees and other associated costs

Effort Reduction:
On the contrary to general belief we are not actually reducing the effort to develop this integration we are just passing the effort to Middleware. So, now instead of putting in effort in Siebel somebody will be putting effort in Middleware to develop the integration.

Manageability:
Approach 2 definitely makes integration more manageable in Siebel but we are introducing complexity in Middleware, which means instead of Siebel, Middleware will be difficult to manage.

All the above points show that there is nothing that we are gaining by introduction of middleware.
Please note: I am not saying that using middleware will never help. I am just trying to emphasis the fact that usually that is not the case.

If we go back 5-7 years when SOA standard was not well developed and Siebel integration capabilities were still developing, Middleware was first and probably the only choice at that time.

But today with so many integration strategies at our disposal, (EBC, Symbolic URL, VBC, Web Services) I think Middleware should be our last choice for integration.

What do you think???