It occurs to me that there are three reasons why Federal Express, aka Fedex, is a great metaphor for data integration.
At least one of the three reasons was anticipated by Gaurav Dillon, so I’ll just quote Ben Horowitz’s paraphrase:
SnapLogic uses a Federal Express approach to integration. Rather than integrating systems directly, all versions of all products integrate to a canonical format (Memphis for those of you following the metaphor), reducing the number of total integrations from n2 to 2n-1.*
*Oh, hell; see the comments below. Actually, there’s a small error it that; it should say that n2 is reduced to “2n,” assuming you’re integrating n+1 things and counting each direction separately. Venture capitalists always reduce things further than they should, most famously in the case of participating preferred stock. But I digress …
The second reason is that Fedex didn’t actually stick by that model. When Federal Express started operating in 1973, all packages it shipped indeed passed through one central hub. More recently, as tracking technology has advanced, Fedex opened many more paths that packages can take to get from one destination to another.
Similarly, I doubt many large enterprises will ever really find it best to integrate all data through a single hub, just as today they never store all data in a single Grand Unified Central Database.
For the third reason, consider FedEx’s most famous promise — overnight delivery. Well, a lot of customers don’t truly need their packages delivered that fast; but overnight (or more recently two-day) delivery is a great guarantor of whatever latency SLA (Service-Level Agreement) they really do require. Similarly, enterprises can have a very broad range of latency requirements for data integration — and the simplest way to meet your latency SLAs might be by delivering data faster than it actually is needed.