Big corporations love uniformity: things are much easier to manage if they are all alike. But then they may also fail all at the same time, with catastrophic consequences. Remember the Great Famine in Ireland? The whole country was uniformly growing only potatoes, because they performed better than other crops, but then potatoes failed, and a million people died of hunger. Something similar, although thankfully not as tragic, can happen to a software company: the vendor of a widely used component may go out of business, be bought by a competitor, or change licencing terms in an unacceptable manner. If the company heavily relies on this one component for all its projects, the results may be devastating. This is especially true for closed source, paid components.

An obvious solution is to diversify: use certain component in some projects and its competitor in others (e.g. Infragistics vs DevExpress). However, this usually does not fly well with the top management, that perceives this as anarchy and waste of resources.

Another solution that I heard of was to wrap: some infrastructure group writes a layer around a heavily used component, and if this component has to be replaced, only this layer has to be re-implemented (one project), while the rest of the projects remain virtually unscathed. This solution is seriously considered and in fact is being implemented by some organizations.

However, personally I think this is not a solution at all: it’s an illusion of solution. Of course, the corporation must be really big to justify the expense of a dedicated infrastructure group, but let’s suppose it is big enough. Anyway, even with the best infrastructure group on Earth, the wrapper will

• Lag behind the original component.
• Have less features than the original component.
• May still be impossible to port to a new component when the need arises.

The lag problem is obvious: it takes time to write and test the wrapper. The wrapper by necessity will abstract away some features of the original. If it blindly exposed all the features of the original, it would be impossible to port to a different component with substantially different set of features.

But even with abstraction, unless the target component is chosen ahead of time, the wrapper may still be impossible to port to a new component without loss of functionality. The new component may not expose required features at all, or its interface may have completely different philosophy behind it. Creating a unified interface that works with both the original and the new components may be as difficult or even more difficult than writing either component in the first place.

So, I am quite skeptical about a wrapper idea, except for the cases when the wrapper introduces some radically new level of abstraction and thus becomes valuable in itself.