All this week (URL to Day 1), I am dissecting an IT horror story from a friend of mine, whose IT team turned on archaic archiving for their cloud-based mail service … and hopefully gleaning lessons from it:
“Change Control” is a very lofty term that makes most IT folks roll their eyes:
– Some think about how Change Control slows down the IT changes that they want to make
– Others recall when someone didn’t do Change Control — and they and their organization paid for it
Simply put, Change Control should be part of every IT process, no matter how large or small. It comes in four easy steps:
1) Back up what you are about to change
2) Test the backups to ensure that you can roll it back. Note, if you regularly back up your data, then (1) might be presumed, but you should still explicitly do (2) before you invoke anything.
Here’s why. My daughter is currently learning in school that most stories come down to one of three scnearios: “Man vs World” … “Man vs Others” … and “Man vs Self.” Ignoring the gender, the IT/data protection variation of this is:
Man vs World = Fire/Flood/Disasters/System-Failures
Man vs Others = Those silly users who delete or overwrite data, where IT still has to save the day
Man vs Self = DBA’s that import bad data, Server admins who patch without testing, or any other IT person who clicks a checkbox. They did it to themselves, but others will suffer alongside them.
Continuing on with four easy steps to Change Control:
3) Test what you plan on implementing with a small portion of your users. Sometimes those are real tests, meaning that you actually implement the change to a few users who know that it is coming and are willing to help you validate your plan. Other times, “testing” is simply to consult with other IT stakeholders or experts to ensure that everyone agrees with the intended change. This will help you avoid unforeseen effects.
4) Over-communicate before you click the check-box. In smaller companies, this can be a simple email blast. In larger companies, perhaps just to managers or department heads. But nothing reduces IT Satisfaction faster than surprises. As a friend of mine often reminds folks, “Surprises are for birthdays.”
Notice that nothing listed above has to do with email services, archive technologies, servers vs services, or any other infrastructure specific scenario – it is IT 101:
- Back your stuff up
- Test your ability to restore
- Be careful when changing anything — i.e. “Do no harm”
- Over-communicate
That being said, once you go to Software-as-a-Service (e.g. Office365), you will discover far fewer options to back up your data (rule #1). It’s why EMC bought Spanning Cloud … and why Backupify will inevitably get acquired … and the other traditional backup solutions are all exploring how to back up those SaaS platforms – because your data still needs to be backed up, even if it lives in a cloud.
Check back tomorrow for part 3 of this week’s series – Why use AaaS to archive SaaS?