Our Microsoft Sales Rep for the Live@edu Cloud Computing offering ran a web conference for us a few days ago on the Wave 3 release of Live@edu. After the presentation I was feeling a bit shocked and depressed. I think I have moved into phase 4 of the “Denial to Acceptance” process. In the interest of helping my fellow Higher-Ed sys admins along in this process, I give you the following Cloud Computing Denial to Acceptance checklist, version 1.0:
- Denial:
- The systems administrator refuses to accept that Cloud Computing is real, or that it is relevant to him. He may feel that Cloud Computing is a “fad” or “passing trend”. He may believe that Cloud offerings are simply scams. He may labor under the false impression that her clients are unaware of Cloud offerings or do not want these services. He may initiate the deployment of a major new messaging or collboration platform in order to prove that Cloud Computing “has got nothing that we don’t got”.
- Anger/Resentment:
- As time passes, more executives start asking about Cloud Computing, and more clients start using the free Cloud offerings. It becomes impossible for the sys admin to remain in denial. In reaction, he lashes out with anger. He questions the intelligence of anyone who uses Google Apps. He goes off on rants about how much “Outlook sucks” and how “Outlook Live sucks even more”. He is deeply resentful of Cloud Computing providers for giving away for free the services he furiously has been trying to get funded for the past seven years.
- Bargaining:
- In this next phase the sys admin attempts to mitigate the effects of Cloud Computing though bargaining. She may offer to “put student email into the Cloud”, but insist that faculty and staff messaging cannot leave the school network for “security and regulatory compliance reasons”. She may sacrifice a few token applications to the Cloud (such as mail distribution lists or video conferencing), but insist that other Cloud offering are “simply not mature”. She may cite outdated versions of service agreements as proof of her convictions. She may request large sums of money to develop similar service offerings in-house with a more institution-friendly SLA.
- Depression:
- When it becomes clear that the Cloud is about to swallow his campus, the sys admin may become depressed and morrose. He may close the door of his office to conceal the sounds of his multi-hour World-of-Warcraft “lunch breaks”. He may stop development and maintenance on all in-house messaging and collaboration tools while asserting, “The service is dead already, what does it matter?”.
- Acceptance:
- When the decision is made to take advantage of Cloud Computing services, the sys admin either will revert back to step 1 (and most likely be fired), or move on the the final “acceptance” phase. At this time, she may actually get excited about the challenging of integrating Cloud applications into the school’s identity managment system. Countless hours will be spent debating the the merits of Python vs. Perl as the default language for scripting directory actions. Weeks will be spent researching and implementing federated identity management systems. Hundreds of blog entries will be posted lambasting the developers of the Cloud service and their refusal to adhere to “ieee 81516” or “rfc 2342”. Patches will be merged into various Web Services code trees. As the weeks pass, the sys admins life will return to normal. There will not be enough time or money for projects to be completed on time. Job secuirty will continue to be assured.
J. Greg's Brain Corral 