The promise of cloud computing is that you, the customer, don't ever have to buy another server, back up another disk drive or worry about another software upgrade. All those promises are true-and now there are multimillion-dollar companies without a single server closet. Cool.
Unfortunately, too often cloud applications and services are bought by people who really shouldn't be buying them. Sure, they may have the budget but that doesn't mean they necessarily have the training to make good IT decisions, let alone the discipline or skills in their underlings to actually execute a coordinated technology strategy.
I'm not criticising user-driven IT. The users should be driving. But, to make IT really work and scale, projects have to be done with skill sets and a focus that are rare in user departments.
My entire consulting firm is based on fixing cloud systems that have been put in quickly and managed haphazardly, if managed at all. (Not that I'm not trashing any one vendor here. This article applies to almost any serious cloud service.) This is a clear case of "pay me now, or pay me (much more) later."
With too many customers, system ownership is effectively set to null almost immediately after a cloud service or application is turned. After all, there's no hardware or software to manage. The service just runs itself. Why dedicate any staff?
That might look like a reasonable economy, but it leads to huge costs soon enough. Why? The system isn't the critical asset. The data is. The data in almost any cloud system is worth far more than whatever you pay on a monthly or even yearly basis. If your data gets gunked up or made meaningless, that could cost you a lot of profits-or even get you in some trouble.
Let's look at three lessons too many companies have learned the hard way by making themselves vulnerable in the cloud.
Lesson #1: The cloud never forgets
Since your data is valuable, you want it to be backed up and replicated for disaster recovery and failover. Any commercial-grade cloud service will be doing this for you. Fine.
Now, think about how the services do it. They have hundreds of thousands of users banging on the same server clusters. Their replication services that run on everybody's data have to constantly stream updates from the local disk array over to the remote disaster recovery site(s).
As this happens continuously, their replication has to be optimised for high performance, low latency and quick failover time. But it's nearly impossible to simultaneously optimise that service for ease of file purging.
So when you delete a record, that deletion won't be propagated to each and every version that was ever stored on the system. The record or file will disappear from view, but that doesn't mean it's been expunged.
Why do you care? Next time you go through a legal discovery process, the smart opposing council will hire a forensic expert witness to look through all the files and records you thought had been deleted. Have fun with that.
Lesson #2: Data in the cloud needs a steward
Since your data is always more valuable than the system that stores it, the data in the cloud needs a data steward. This isn't a system administrator; rather, it's a business analyst who can do the following:
- Say what data should and, more importantly, should not be stored in the cloud. This will help you avoid a discovery problem, a PCI audit, a HIPAA or FERPA or (name your favorite acronym) compliance problem.
- Be the custodian of the meaning of data. You know, little things such as "What's a customer?" or "What's the significance of an overdue severity 1 case?"
- Establish naming conventions and trees for files, directories and other hierarchical relationships, such as "parent account" vs. "operating division."
- Serve as the gatekeeper for imports and data that flows across systems, making sure that semantics don't get blurred and that pollution sources are filtered or corrected at the source.
- Develop the right procedures for backups, record merges or the creation of parent-child relationships. You wouldn't believe how many ways there are to get this wrong-and how many weeks of wasted effort can occur due to a well-intentioned error.
- Validate the results of reports, making sure the right variables have been used for filtering, grouping and rollups. Too often, different vice presidents base their decisions on totally different data, causing no end of confusion.
The good news is that data stewardship isn't a full-time job. The bad news is that the data steward has to have a pretty good range of political and technical savvy.
Typically, this is a position you should recruit for inside, rather than outside. If you can't find one person to do it, have a pair of people who are rotated into and out of the position no more often than once a year.
But data stewardship is only half the battle.
Lesson 3: Since the cloud replaces internal IT, it must be managed like IT
Users tend to think of a cloud purchase as a "solution." No more hard work until renewal time. What's going through their heads? "See, we skipped the need for IT and all that overhead!"
The moment they start to take a cloud system seriously, though, users want mash-ups, custom code and the capability to drag and drop items from the desktop. They want to integrate with other data sources inside and outside the company. Executives want reports and dashboards.
In other words, everyone will want the leverage and efficiency of an IT system. Those benefits only come when there's an architect and a "general contractor" working together, not just a "workman."
The irony is that the home turf for cloud vendors-small businesses and departments of larger companies-are the least likely to appreciate this. Large enterprises know that it takes time and discipline to properly exploit the cloud.
If all this comes as a surprise, let me comfort you with this. You're in good company. In my next article, I'll give you a quick self-assessment questionnaire to help you identify the first steps in your get-well program.
David Taber is the author of the new book, " Salesforce.com Secrets of Success" and is the CEO of SalesLogistix, an IT consultancy.
Follow everything from CIO.com on Twitter @CIO_Australia
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.