Last week Salesforce.com acquired DimDim. DimDim users have been given a cut-off date, with accounts starting to "die" on March 15th. The fourth question from last on the FAQ explains future API support - in short, it will be supported until the end of the user's subscription.
Bob Warfield over at the Enterprise Irregulars has an interesting take on Salesforce.com in his article "Dim Dim: The Risk of Being a Salesforce Customer". The article is interesting because it's not about Salesforce as much as it is a statement on the whole tech industry, which is experiencing a lot of consolidation.
Raise your hands... how many of you come from the enterprise integration space? You know that "spaghetti mess" called enterprise infrastructure?
That mess is being ported to the internet.
People more engineering oriented may object, but this API/integration technology differs only in scale/distribution to the fundamental API integration between co-located applications. The sort that we at TIBCO did back in the mid-90's.
What hasn't changed is our ability to know who's doing what to whom, figure out how to plan change with a standard discipline, and crack open people's heads so that we're not dependent on people to solve problems.
Let me rephrase. OpusGrid have figured it out... and we hope you'll let us know if you're curious about our offering. But, this isn't meant to be a sales pitch, but rather an educational piece on the risks of depending on API integration.
So, back to DimDim.
The resulting "near total shutdown of DimDim's service" (TJ Keitt at Forrester used that phrase, I like it) should scare the bejeezus out of any API developer.
Don't hide from the fear... embrace it. Use it as a justification for the following simple best practice:
All API use must go through an abstraction layer.
What do you gain by doing this? The next time an API "disappears"...
- You'll immediately know who in your organization is using it
- You'll know how they're using it
- WIthout any code changes, you can quickly reroute to an alternate provider
That last point is really important. Let me explain the impact.
Without any code changes means that without immediately impacting your release schedule and roadmap. It buys you time. Time to understand the impact. Time to implement the new API correctly. Time to ensure that you don't miss your own release deadlines, with the resulting potential of impacting revenue or customer satisfaction.
Turn the scramble to replace existing functionality into an opportunity to use past experience to make the next release even better... even when there's a service provider change involved.
Admittedly DimDim's a small piece of any enterprise solution. What if it were Salesforce that were acquired? Would you know who in your organization is coding agains their API's? Would you know what they're doing? If you tell them to stop, would you know for sure that they did?
Or, on the day it's cutoff, do you just deal with the emergencies reactively and miss the opportunity for constructive, planned obsolescence?