So, you have decided you need an integration strategy? Good for you! Welcome to the burgeoning enlightened-but-worried club.
Next step? Pick an integration architecture. A thrilling roller coaster ride through the world of buses, tiers, hubs, brokers, and switches.
Next step after that? Pick a platform for your integration platform to run on.
Does this last step seem perfectly reasonable to you? Or did it, by any chance, cause a bright orange flash of doubt to ricochet around your mental apparatus?
Here is the issue. You need a way of allowing all your heterogeneous applications to talk to each other. You do that by putting in place a *homogenous* integration layer. e.g. a .NET integration strategy, a J2EE integration strategy and so on.
It sounds like an exception to the rule doesn't it? The integration part of your infrastructure ends up being tied to one platform. Yet it exists precisely to allow other parts of your infrastructure to work together regardless of platform.
So how come the very raison d'etre of the integration machinery does not apply to itself? You may or may not find this odd. A lot depends on whether or not you feel uneasy or re-assured by exceptions that serve to prove general rules. I am in the latter camp. Exceptions worry me.
The real world manifestation of the phenomenon I'm talking about is best seen in the concept of an integration "adapter". Crudely speaking, an integration framework, integrating N different platforms, will have N-1 platform adapters. That is, one for each platform that is not the platform that the integration framework itself is running on. The N-1 is a consequence of the fact that it does not need an adapter to talk to itself.
The whole concept of 'adapters' is a key marketing tool for integration vendors. Integration system X will run on platform Y and all other platforms will be supported via the magic of adapters. The adapter game is played with strong visual images that feature one platform planted firmly 'on top' of all the others or 'in the middle' of all the others which are visually relegated to subservience in the diagram.
A non-technical (and somewhat depressing) interpretation of the adapter diagram could be titled "owning the customer". You may like to think that the integration system you have bought will lower your dependance on any one platform. However, you may find that thanks to the adapter game, you are now in fact more tightly wedded to one platform than you were before you put in your integration infrastructure in place.
Does integration have to be this way? Is it necessary for one platform to dominate? I think the answer is no. Take the Web for example. What is "on top" in the Web architecture? What is "in the middle" of the Web architecture?
Nothing. Interesting, don't you think?
The Mahayana Buddhist tradition has a view of the world known as the 'view of substantial emptiness'. In this view, all things are empty as a consequence of the transience of all things. It is the very emptiness of all things that allows new things to constantly come into existence. Everything is connected to everything else (dependent origination), without any concept of something being "layered on top" or "in the middle".
The Web feels like that to me. Things come and go. New things crop up in their place. Everything moves, all the time... And yet, the Web is clearly a 'platform'. We talk of developing 'for the web' and 'on the web'. Is the Web a platform on which you could place an integration strategy? Yes. If not, the whole web services roller-coaster is heading for a brick wall.
When we look at Web Services based integration architectures what do we see? More often than not, we see deja vu all over again. We see buses, and tiers and hubs and brokers and switches. We see things on top and things in the middle. Oh, yes, and we see adapters, lots of adapters for all the unfortunate platforms that are subservient to the master platform.
It seems to me that one of the real value propositions of the Web as an integration platform is that there is nothing on top, nothing in the middle. The Web does not carry with it a requirement for any one brand of hardware or software. All that is required to be part of the Web is to agree to a set of document exchange protocols most notably HTTP.
So why then do we see so many diagrams for Web Services based integration strategies that have one brand of hardware/software on top or in the middle with everything else relegated to adapter-land?
It is an attempt, it seems to me, to neutralize the very thing that makes the web intriguing as an integration platform - there are no adapters, there is nothing on top, nothing in the middle.
Something to meditate on perhaps.