Three ways Fedex is a metaphor for data integration
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.
Comments
2 Responses to “Three ways Fedex is a metaphor for data integration”
Leave a Reply
Hmmm …
to add to the confusion from the above example, when one wants to integrate n things, shouldn’t it be rather n²-n than n²? This can then be reduced to 2n when adding a central integration hub (n+1 things), or to 2(n-1)(is this what Ben was referring to with 2n-1?) when one of the initial things can serve as a hub. All this is with counting each direction separately.
OK. Let’s try this again, as it’s getting embarrassing.
n+1 things each point at n others. That should be n²+n, which is not the figure any of us used.
Or n things each point at n-1 others. That should be n²-n.
If n+1 things point at a hub and the hub points back at them, that’s 2n+2. If n things are doing that, it’s 2n.