Cloud purists would argue that a true Cloud IT organization exclusively uses services (SaaS) and owns no software, let alone platforms or infrastructure. And if these purists started a brand new organization today, they might have a point, at least until their first takeover or merger. This not having an installed base, allegedly enabled God to create the world in six days, but just for the sake of argument, let’s examine what the responsibilities of our Cloud IT Manager would be in such a green pasture, pure SaaS environment.
First thing that comes to mind is the service or application portfolio. Our Cloud IT Manager will need to be involved with selecting which applications and services the organization will use. Not because he feels users need to ask him (he may feel that way, but the users most likely won’t) but simply because he will be held responsible for any associated risks. What if the vendor goes belly up? What if the vendor’s data center burns down? What if the vendor uses his market power to increase his prices beyond what is reasonable? Vendor Lock-in has plagued us for too long; let’s make sure we prevent Cloud lock-in while we still can. So if nothing else our Cloud IT manager will need to provide a disaster recovery and exit strategy for each application. Portfolio Management suddenly becomes his core business.
Now our Cloud IT Manager monitors the portfolio, he is also the best person to offer a catalog of available approved Cloud Applications (one recent and highly visible example of this approach is apps.gov). And of course our Cloud IT Manager will be involved with rolling out (implementing) new services throughout the organization. His portfolio perspective will help him oversee the project and program management of these organizational change efforts. Having a view of both the pipeline of new services and the catalog of available services enables him to calculate, manage and monitor the integral cost of these services. All is supported by ITIL processes like Service Portfolio and Catalog Management, that were further defined in the most recent incarnation of ITIL, but were basically already foreseen in earlier versions.
The next topic to discuss has been the core part of ITIL for years: Support. If our Cloud IT Manager’s organization uses ten different SaaS applications from five different vendors, does he want his users to go to each individual vendor for support, entering their issues in many different places. Apple reportedly offered 10.000 Macbooks to a corporate client with as recommended support procedure: “users visiting the Apple Store and lining up to talk to an Apple Guru on duty”. Would your organization be ready for that? Or do we keep first line support under one roof, either in-house or via a SaaS Service Desk.
But our Cloud IT Manager responsibilities do not stop here. If his organization uses CRM from one vendor and ERP from another vendor, our Cloud IT manager would be expected to connect or integrate these two. In fact: “connectability” may need to be the prime criteria for selecting these vendors in the first place. Balancing the need for integration with the risk of vendor lock-in becomes a core capability of our Cloud IT Manager. Connecting business processes across different (cloud and none-cloud) applications becomes essential (more about this later).
Aren’t we forgetting something? Yes, Security! Security (or Risk) is the most cited reason organizations are not going with the public cloud yet (one reason our upcoming Cloud Academy starts off with a session called: Security First!). Good old COBIT is very suited to be used as guidance here. Security should be seen in a broad sense, from defining users to data protection and disaster recovery. In many cases the specific solutions to address these concerns can itself again be cloud services. For example an identity service provider can offer a cloud service to define users and offer a single sign-on experience. Single Sign on across cloud services is something our Cloud IT Manager probably wants to provide, if only to prevent users from putting sticky notes with all their different passwords at the bottom of their keyboards.
Cloud Security also includes protecting the organizations data. A common concern is Data Loss Protection/Prevention (DLP). So far most known data loss incidents were caused by memory sticks or laptops going astray, not by Cloud providers being hacked, but better to be safe than sorry. But also good old backup and recovery need renewed focus in a cloud environment.
Talking about Security and Risk management brings us to something like “cloud escrow”. With traditional IT we get a compiled working copy of the software. In case the vendor goes out of business we can get a copy of the sources via escrow. This way we can still make changes to his software, for example for a new upcoming version of the underlying database or operating system. The typical timeframe between start and finish of such a procedure here is months.
How different for SaaS. If the vendor goes out of business today, the application stops working today. And even if the vendor has a service provider hosting the software, the curator (the new “owner” of the IP) may tell the hosting company to discontinue the service immediately in order to reduce cost or liability. May seem farfetched but there are examples of exactly that happening. To address this some SaaS vendors offer a copy off their working code and a regular backup of the customer’s data. That is all fine and good, but our Cloud IT manager better be able to recover the service in a reasonable time frame. Reasonable can vary from a couple of days to a couple of minutes.
It will be clear that our Cloud IT manager can only accommodate this if he has automated this procedure and tested it regularly! So do we still need a hibernating datacenter in the basement? Better not, as this would eliminate most of the cost savings from going cloud. We could cater for this recovery again by using the Cloud, for example by mandating that the cloud provider regularly delivers a set of tested images that can be automatically deployed on Amazon or another IaaS provider within an hour. The early adopter will need to negotiate this himself, while late adopters will have the benefit of this being offered as standard feature by the service vendor or by a third party. Having a good understanding of the portfolio (risks, cost, benefits, and criticality) will help our Cloud IT Manager to make the right decisions and set the right priorities.
So even with 100% SaaS our Cloud IT Manager still has an important role to play. But did we not say in the earlier part of this blog that with SaaS our Cloud IT Manager may not even be aware of which cloud applications the users are deploying? How can he monitor, manage and secure a portfolio he does not even see. There is no simple answer here. One aspect he could monitor however is his network. Appropriate network and security tooling could tell our Cloud IT Manager – by interpreting the network traffic – what URLs (applications) are visited or even what typical response times are.
In the distant future, however, it becomes more unlikely that users will be accessing all their applications via a corporate network as on the one hand application to application communication happens directly between virtual machines (bypassing the network) while users maybe no longer accessing their applications primarily via corporate network but more and more directly through public networks such as their home fiber connection or free wireless at their office campus or local starbucks or from the back of a commercial airliner. Would we require them to VPN first to the corporate network and then visit these applications from there? Not likely as this may significantly decrease speed and increase cost, especially with rich content like video and 3D. Or can we put something on their access device to monitor their behavior. Also not likely as these devices may be of the shelf iPhones or netbooks, with preconfigured and prepaid 3G access build in. Welcome to the wonderful world of consumerisation, a trend going hand in hand with Cloud Computing. More on this in a later blog.
In general one could say our Cloud IT manager may need to learn to use the carrot more than the stick. Simply blocking a service will less and less become an (accepted or viable) option. Off course our Cloud IT Manager can still set procedures and policies that users are asked to adhere to, like the US Army is contemplating with regard to “personal” and/or “off-duty” use of facebook and twitter. Or more forensically he could “follow the money” by asking accounting to monitor (credit card) payments to unapproved cloud service providers. A more positive approach is to make the use of approved services significantly easier, for example by offering a catalog of prepaid services, all under single sign-on. Also he can agree with any cloud providers he has contracts with to give (real time) insight into usage and service levels using standardized reports and reporting API’s.
In my next blog post: Conclusions on the role of the IT Manager: is a Cloud IT Manager also a more Lean IT Manager?
Tune Into The Cloud 
The concept of “SaaS data escrow”, where snapshots of the SaaS application are taken regularly and copies of the data kept either with a third-party cloud provider or onsite to ensure data availability, is rapidly becoming accepted and expected by companies large and small. The added benefit is the customer often gets enhanced reporting and analytics against their SaaS data as these capabilities are frequently limited within the SaaS application.
LikeLike