Cloud computing is a-coming, especially for the sites making their migrations off of the HP 3000. But even if an application is making a move to a cloud solution, shouldn't its information remain available for other applications? Operational systems remain mission-critical inside companies that use things like Salesforce.
To put this question another way, how do you prevent the information inside a Salesforce.com account to become a silo: that container that doesn't share its contents with other carriers of data?
The answer is to find a piece of software that will extract the data in a Salesforce account, then transform it into something that can be used by another database. Oracle, SQL Server, Eloquence, even DB2. All are active in the community that was once using TurboIMAGE. Even though Salesforce is a superior ERP application suite, it often operates alongside other applications in a company. (You might call these legacy apps, if they're older than your use of Salesforce. That legacy label is kind of a demerit, though, isn't it?)
Where to find such an extraction tool? A good place to look would be providers of data migration toolsets. This is a relatively novel mission, though. It doesn't take long for the data to start to pile up in Salesforce. Once it does, the Order Entry, CRM, Shipping, Billing and Email applications are going to be missing whatever was established in Salesforce initially. The popular term for this kind of roadblock is Cloud Silo.
It reminds me of the whole reason for getting data migration capabilities, a reason nearly as old as what was once called client-server computing. Back in the days when desktop PCs became a popular tool for data processing, information could start out on a desktop application, not just from a terminal. Getting information from one source to another, using automation, satisfies the classic mission of "no more rekeying."
It's a potent and current mission. Just because Salesforce is a new generation app, and based in the cloud, doesn't make it immune to rekeying. You need a can opener, if you will, to crack open its data logic. That's because not every company is going all-in on Salesforce.
"How do you get stuff in and out of Salesforce? It not something unto itself," says Birket Foster. "It's a customer relationship management system. It's nice to have customer data in Salesforce, but you want to get it into your operational systems later."
You want to get the latest information out of Salesforce, he adds, and nobody wants to re-key it. "That started in 1989," Foster says, "when we tried to help people from re-keying spreadsheets." For example, a small business data capture company, one that helps other small businesses get through the process, needs a way to get the Salesforce data into its application. Even if that other app is based in the cloud, it needs Salesforce data.
Silos are great for storing grains, but a terrible means to share them. The metaphor gets a little wiggly when you imagine a 7-grain bread being baked -- that'd be your OE or Shipping system, with data blended alongside Salesforce's grains of information. The HP 3000 once had several bakery customers -- Lewis Bakeries (migrated using the AMXW software, or Twinkie-maker Continental/Interstate Brands -- which mixed grains. They operated their mission-critical 3000s too long ago to imagine cloud computing, though.
Clouds deliver convenience, reliability, flexibility. Data migration chutes -- to pull the metaphor to its limit -- keep information floating, to prevent cloud silos from rising up.