What if the Cloud *Evaporates*?
♫Some sunny day-hey baby
When everything seems okay, baby
You’ll wake up and find out you’re alone
Cause I’ll be gone
Gone, gone, gone really gone…♫
Lyrics and Music by Don Everly and Phil Everly, recorded by The Everly Brothers.
The ABA Journal today published an article “Get Your Head in the Cloud” which states:
The early indications from ethics authorities are that storing client data in the cloud does not violate ethics rules, as long as the lawyer took appropriate steps to safeguard the information from inadvertent or unauthorized disclosure.
While I agree about taking ‘reasonable precautions’ with regard to security around the data (which depends on trusting your cloud provider to stay current with regard to appropriate security precautions) the article does not address one issue which I think has not been addressed by the cloud providers.
The question is: what happens if the cloud provider vanishes? Most would say, “No problem – we have a copy of our data with a third party ‘safe harbour’ data warehouser as arranged by the cloud provider before they vanished.
Assuming that you can then access your data…there is the issue of what do you do with that data? I assume that you will end up with a comma-delimited data set which presumably can be imported into Excel or such similar product.
But the data that you end up with will be a series of Excel spreadsheets…a ‘flat file’ database as it is known. But most cloud datasets will be relational databases that have as their utility, the links that exist between the data points. Those relational datasets depend on the marriage between the data and the proprietary application that brings that data to life. Unfortunately, one-half of that equation – the proprietary application – has just vanished with the disappearance of the cloud provider.
How do you recreate those linkages to make the data useful to you? Or how much $$ will you have to pay to have this dataset imported into a competitor’s product that contains the full relational value of the data? And the consequential question: How long can your office wait without full access to the information contained in your data? After all, the cloud provider vanishing would be equivalent to a 911 hit on your business. Does this not raise potential malpractice concerns should you miss a filing data or court appearance as a result? The cloud provider is judgment-proof at this point – you are left on your own.
ABA TECHSHOW takes place this week in Chicago. I will be looking to the different cloud providers and see what they have designed to handle the possibility that one day they may be gone, gone gone…really gone…
Sensitive to this real worry, Google has set up the Data Liberation Front that aims to make it easy, or easier, for people to get their data out of Google. It’s worth tracking their work if you use the G-cloud.
This raises an interesting point. Although many SaaS vendors (including myself) could never imagine going belly up it is inevitable that many SaaS vendors will in fact do just that. Why? Because so many offer the same functionality, features or lack thereof that they will struggle to keep their clients.
The signs are already there. An example is how many CRM services can there be? At last count nearly 30. They have all dropped their prices recently and some have already gone belly up. It isn’t because they are flourishing that they drop prices, but because they are struggling to capture new clients. When you have a lot of choices all offering the same thing what will be the result? You don’t have to guess.
When considering a SaaS vendor you should not only look at how viable the company is but how much of a chance do they have to survive. It has nothing to do with how much funding a SaaS vendor has but how many NEW clients they can attract and keep. The SaaS vendors that provide the best value to feature ratio and can differentiate themselves from everyone else have the greatest chance for success.
Frank Rivera CEO
HoudiniESQ
Being left with only flat files where your systems rely on a relational database would be a problem, but when would that occur? I can’t think of any major database system that categorically fails to provide for replication of a database.
Surely the extra step of ‘dumbing down’ data as it is replicated from the live site to a third party would be both wasteful and harmful, and would thus be an option that few, if any, would buy? A more typical scenario should be that back-up data is organized just like the live operational data (though it may not be directly useable on an ongoing basis where it is stored).
After the primary cloud location fails, to maintain or resume operations there might be a lot of work to do (e.g., moving the ‘safe harbour’ data to an operational site, pointing your applications to the new location of your relational database), but having to rebuild the relations in your relational database should never be necessary.
Owen:
Your comment, in my opinion, fails to consider one point: What application will you use to open that replicated database?
Databases are not easily transported from application to application. In most cases you need to *export* the data from one application and then *import* the data into another. It is equivalent to translating from German into Italian.
For example, exporting data from Amicus Attorney into TimeMatters, for example, is a non-trivial undertaking.
When an SaaS provider dies, you also lose the ability to do an export. The best that you can hope for is to get a series of comma-delimited files that can be brought into Excel or another program, since that is a file that *can* be read by another application. It is not a given that you will be able to take a comma-delimited file or series of files and just bring that data into another application and have all the links preserved in the process.
Regards,
Dave
Thanks for responding, Dave; and thanks for covering the topic in the first place!
It looks like we are addressing two different but related points.
My point was not that switching applications will always be easy or instantaneous, but that a specific step you described, the manual recreation of the relational model, should be unnecessary. I have never heard someone say that they created a back-up of a relational database if they failed to capture its relational structure. Any purported back-up that omits such relations is simply incomplete.
Your point regarding the useability of the back-up, and the implied difference between backing-up a database and backing-up operational capabilities, I agree with unreservedly. Having only a full replica of your CRM database available when your SaaS CRM provider fails is unlikely to give you the capabilities of that SaaS’s user interface. A gzipped SQL replication script will not make it easy to look up a client’s email address. (But it will capture the relational model!)
While it might take some work to get data from one mission-critical application to a replacement—and I think this is the critical point from a business-continuity planning perspective—that work can and should be done before the first SaaS fails. Such preparation, or at the very least planning, is a necessary part of any good back-up.
Transferring data from one entity to another is the same regardless of whether you’re dealing with application software or a SaaS cloud application. CSV or SQL text based files are the exchange format of BOTH offerings. If a firm doesn’t like Amicus and wants to switch to TimeMatters, text based files are exactly the export import strategy that would be required. So this isn’t a valid argument for or against the use of SaaS services. It’s an argument against EVER switching to a new offering.
Another point, not only are most application software also using relational databases, but they are not nearly as open with firm data. At best, those products will offer a CSV export, which may or may not be accessible to automated backups. How many applications have we seen with proprietary locked DB formats?
Frankly, if a SaaS provider is offering firms the ability to backup their data locally, then moving that data to multiple geo-locations (protecting against local disasters, earthquakes, etc.), as well as automating copies of that data to a third party holding company… chances are they’ve already exceeded the data protection most firms are receiving in an application environment.
What kind of data do you have in the cloud? All of mine is stored in widely-used and recognized formats (e-mail, calendar, etc.). And since I have local copies, this is a non-issue. As it should be for anyone using the cloud.
Red Herring.
Sam:
There are many cloud offerings (legal case management and accounting programs for example) that have proprietary formats…as well as a host of other applications.
I agree when you are using common applications such as email the format should not be a real issue. But when you are using more technical applications, the transportability of the data is a real issue.
Steve: Moving your data from one proprietary database format to another is non-trivial. I have tried to do so between two legal case (practice) management products and it is not for the faint of heart. Imagine if you run into difficulties…if you have the old application still on your computer, you can always go back. But if you were on the cloud..and the cloud vanishes..there is no going back. You are stuck unless and until you can get the data into another application – which means you are now at the mercy of a consultant who will be charging by the hour with no guarantee of success.
Cheers,
Dave
Dave, I understand your point. But the best anyone can ever expect is to get their data out of an application or SaaS product in a CSV or .sql backup file. It may not be trivial to migrate, but without it firms would be stuck with a data re-entry project.
Again, this isn’t a ‘cloud only’ issue. There are many situations when applications cease to operate. And if an application software company goes out of business, you are likely prevented from EVER upgrading your OS. Plus, there’s no guarantee firms can get their data out of the application to even do an import.
Simply put, any software or SaaS provider going out of business means the firm MUST chart a new course. At that point, I’d rather have a readable & importable .csv file than any other format, and especially over a proprietary locked down data file.
Dave is absolutely correct.
Moving data from one PMS to another is non-trivial and his concern is totally valid. We do the uninformed an injustice if we make it seem like nothing could ever go wrong and when it inevitably does you still have your E-mail and calendar data elsewhere so you will be fine.
Firms use a PMS’ to track and store far-far more data then just E-mail and events.
You would have to expect to be down several days at minimum even with a professional services consultant on hand. Not to gloat but to put things in perspective…
A large part of our business is data migration services from all the SaaS products and nearly every desktop PMS product you could imagine to Houdini.
We have the ability to deliver to our clients their entire database with relational links intact. Anyone can connect to this portable database with free tools like TOAD or inexpensive tools like DBVisualizer. Even with this portable database and these tools you still need someone with knowledge of the target PMS to do the import. CSV files are always a last resort.
If your SaaS vendor goes out of business it won’t be painless.
I don’t think the cloud will evaporate just many of its vendors. Dave’s point is make sure you understand what you face if your SaaS vendor goes belly up. A valid point and concern. Just my 2 cents.
Frank Rivera CEO
HoudiniESQ