There are so many choices out there today that we can no longer buy the simple item we need, no matter what that item is. When was the last time you were able to enter a store and buy a pair of jeans, just jeans, not “slim fit stonewashed low-waist” ones, but those plain original blue jeans?

<a href=<a href=

Andrei Migatchev" src="http://www.iweek.co.za/images/stories/2010/ANDREIMIGATCHEV.png" />But we are talking technology here, not clothing, so let’s get back to buying a piece of software that will enable us to integrate software. At the time of writing this, Google produced 8 million results for “software integration platform” and 7 million for “ESB”(enterprise service bus) - how are we supposed to know what it is we want?

The answer to that question can be very simple: we need a piece of software that will allow us to  integrate the various applications we have running in the organisation, as well as provide us with the ability to replace any of the applications we already have with something else in the future, should such a  requirement be presented to us.

But here is where IT gets stuck every time; various studies are performed, all the protocols current  applications use to communicate are listed, and all technologies, both hardware and software, that run  in the organisation’s infrastructure, are dissected. Further lists and assessments are made as to which applications could possibly be acquired in the future and which protocols would be supported by them.

We bury ourselves in reams of lists and reports on numerous integration platforms and tools, current supported protocols, messaging queues, web service standards, etc. Finally, we try to compare all these requirements with the product sheets we received from various software vendors. We’re only worried about technology and not the actual business needs.

ACTIONS SPEAK LOUDER THAN WORDS

History teaches us that no matter how long and hard we search, we always operate in a heterogeneous application environment. The search should be driven not only by fi nding a solution that will theoretically fi t the current technology stack and existing applications within an organisation, but also by adopting a
pragmatic approach that will answer the current business requirements accurately and efficiently.

This list of business requirements should be measured against the current or proposed middleware capability of an organisation, including delivery times and costs associated with delivering a sustainable
solution. The software functionality matrix described in the previous article should then be further  expanded to include business requirements and underlying technical infrastructure, existing or proposed.

DO IT RIGHT… BUT ONLY WHAT NEEDS DOING

Software integration is yet another service within an organisation and thus should be designed and used as such. We start building the integration capability a building block at a time as the business  requirements dictate, only anticipating immediate future needs and catering for them.

It is up to software vendors to provide us with a middleware platform that is scalable, robust and supports multiple technologies. And if it doesn’t, we always have a choice.