Is your cloud strategy 3D-ready?

While the TV and consumer industry is getting ready for its next wave of innovation called 3D, the IT industry has been going through a similar three dimensional transformation. Let’s have a closer look at this 3D journey of IT and how a good cloud strategy should support all three dimensions. And don’t worry; you won’t need to wear funny 3D glasses to read this blog.

This post was originally published as a column on ITSMportal

Cloud computing is not the first innovation to hit IT – although the amount of hype and blogs seem to indicate otherwise - ever since the first computer got carried into the building all the way to the latest generation of tablets, the way we use IT, the things we use IT for and IT itself has been changing profoundly. We can classify these changes along three dimensions: Extending IT’s reach to new users and into new functional areas, Abstracting problems so they can be managed at new conceptual levels and Sourcing solutions from specialists where it makes sense.

Dimension 1 - Extend your reach

Traditionally the computers and applications that IT managed were used exclusively by employees. For example general ledger and inventory systems were accessed by the bookkeeping and manufacturing departments. This exclusivity has long gone. Applications have extended their reach and are now directly used by customers, by employees of partners and subcontractors and in some cases our applications reach out directly to suppliers or even suppliers of suppliers. This extension of reach has made IT a lot more time critical. Any failure can directly impact the customers’ experience.

In some cases the line between what is the business and what is the supporting application is even blurring completely. For many people banking is their home banking application, the service the travel agent provides is an application to book tickets and hotels and Telco’s run software to connect people. More and more the digital process is the becoming the business process itself.

Extending the reach of applications also has a severe impact on who should be given access to our systems and applications. From a ‘simple’ list of employees with their roles and responsibilities we are moving to a situation where the list of potential users is endless. Security is becoming less about keeping people out and more about enabling the right people to do the right things with decisions about who and what are allowed taking place at increasingly granular levels of detail and subtlety.

The inherent network orientation of cloud computing provide a natural fit for enabling “extend your reach”, but “extend your reach” goes beyond having more and different people accessing ITs’ applications. It is also about extending into completely new application areas. Recent examples are convergence of traditional data processing based IT with voice and video and ventures into “big data”, where analysis of volumes of information - traditionally to large or too diverse to sensibly process - leads to new insights and advanced levels of optimization. These applications go far beyond the “traditional business IT” applications that essentially were limited to capturing and processing administrative facts about business processes, with processing that seldom became more complex than adding and subtracting and the occasional multiplication. Cloud computing can help IT extend into these new, more complex, areas.

Dimension 2 - Abstraction - IT moving up in the food chain

When IT first started, companies could not buy computers, they had to build their own. Later on computers could be bought but they did not come with any applications or even an operating system.  Customers were expected to build these themselves, first in assembler, later in higher level languages, while nowadays many complete standard software applications are readily available. The point is that IT for years has been moving to higher levels of abstraction to enable them to move from extremely detailed technical work to higher level tasks.

Abstraction is basically the mechanism that makes modern IT possible. If we would still be required to manually manage every transistor on a modern chip, every register in a CPU or every disk in a content management system, IT would never get around to actually helping the business.

Abstraction occurs in programming, hardware and management. In programming we went from assembler via 3GLs and 4GLs to modern Object Oriented languages, where abstraction basically is the core concept. In storage we went from addressing blocks and spindles to disks to NAS or even content management systems. Similarly virtualization allows us to abstract from the underlying (detailed) physical implementation to a more standardized high level representation. And also in IT management we abstracted from managing individual components such as network, storage and processing to managing at higher conceptual levels such as services (ideally using some kind of service model).

Automation providing Abstraction

Abstractions have been around forever (in fact any spoken language can be seen as an abstraction describing underlying realities) but in IT they are often implemented through automation. We enable users to abstract to the higher level by “automating” all the tasks they traditionally had to execute at the lower level. Traditional programming was all about memory management, higher level languages take care of this automatically. Traditional data-processing was about running hundreds of sequential jobs across many sets of data in the right sequence, workload automation suites automated this away. SOA (Service Oriented Architectures) offer services that perform complex tasks “as a service” automatically. These automated services free the developer from having to manage or even understand the internal workings of the service he uses.

Automation is the engine that enables the user to manage processes at a higher, conceptual level. Having the right conceptual model is essential to success. Conceptual models come in many shapes and forms. A file system is such a conceptual model, so is a database. Programs, applications and services are another example of conceptual models covering different levels. A good conceptual model is close to the reality the user wants to manage and allows him to specify in the appropriate level of detail what the solution needs to do. Appropriate is the key word here. Assembler language does not provide a good model to implement General Ledger or CRM systems, but could be appropriate to define operating systems or microcode.

Appropriate cloud abstraction models

Traditionally conceptual models for new technologies closely resemble the old reality; remember how the first cars closely resembled carriages, but without the horses. The driver seat would be really high because he traditionally needed to be able to see over the horses ass. And even though the automobile had no horse anymore; the seat was still high up. Cloud computing is also still in search of the appropriate conceptual models to be managed through. Traditional datacenter management was about provisioning and starting and stopping servers and configuring networks. When using a private cloud to run applications a conceptual model around servers may be too detailed, a more appropriate model would be based on services not underlying machines.

In a similar fashion the industry will have to find conceptual models to manage the use of SaaS and PaaS cloud offerings. Initially people will try and manage these in the same was as we managed in house applications and development platforms, but over time we may move to higher more appropriate levels of abstraction. An interesting development here is the Service Measurement Index (created by the SMI consortium in cooperation with Carnegie Mellon University and hosted at cloudcommons.com) that aims to abstract the provided application services into a number of core characteristics that enable management at a higher abstraction level.

Dimension 3: Source - Divide and Conquer

The third dimension that IT has transformed itself along over the years is the sourcing dimension. As IT organizations moved on, they started to subcontract, outsource, offshore, procure as a service more and more tasks they traditionally did in-house.

To some extend abstraction and sourcing are related, they both result in the organizations not having to perform certain task themselves. But the two dimensions also tend to reinforce each other. The external providers perform their specialization at such scale that they are best equipped to automate their services up to a next level of abstraction. Many organizations that outsourced their service desk operations found that the provider rapidly moved from a Chinese army approach - where they processed millions of tickets manually - to offering automated remediation and self-service to make the support process more efficient. In-house teams simply did not have the time, skills or scale to set this up.

Sourcing also means letting go of control, no longer being able to step in and fix things yourself in case things go wrong. As a result any sourcing strategy should include an exit and a fail-over strategy. One CEO became acutely aware of these sourcing risks when he read about several companies ceasing service to Wikileaks. He asked his IT department how dependent they were on the IaaS (Infrastructure as a Service) vendor they sourced their capacity from. His IT department - always game for a good challenge - took up the gauntlet and 48 hours of non-stop programming, gallons of diet coke and tens of pizza boxes (containing cheese and salami, not CPU’s) later they had created the ability to automatically move their complete operations to another IaaS provider. Given the criticality of today’s IT from a business and personal perspective, every organization should consider such a divide and conquer strategy. By dividing the workload across multiple vendors or storing a shadow backup copy of critical data at an alternative vendor they can arrange instant failover and prevent themselves from being locked in.

Of course cloud computing has a distinct sourcing angle. In fact so much that many people see cloud computing basically as just another form of outsourcing. But the attractiveness of cloud computing is that it can further IT along all three dimensions. Extending ITs reach to new users and into new functional areas, abstracting problems so they can be managed at new conceptual levels and sourcing solutions from specialists where it makes send.

Such a 3D Cloud strategy enables you to Extend, Abstract and Source Your IT, something us acronym crazy IT folks maybe should call EASY IT.

Audits and Certificates Won't Erase Cloud Security Concerns

In every cloud survey, security consistently comes out as an inhibitor to cloud adoption. Even though this has been the case for several years, many feel that it is a temporary barrier which will be resolved once cloud offerings get more secure, mature, certified, and thus accepted. But is this indeed the case or do we need another approach to overcome this barrier?

During a recent cloud event, two speakers from a large accounting and EDP auditing firm took the stage to discuss the risks of cloud computing. While one speaker dissected the risks for both consumers and providers of cloud services, the second speaker discussed the various certifications and audit schemes that are available in each area. They acknowledged that with the currently available certifications, not all risks were covered, but their envisioned remedy was even more comprehensive certifications and audits. Now, this may come as no surprise given the speakers' backgrounds, but more "paperwork" simply won't address what IT pros are really worried about. Let me try and explain my thinking, including how the recent WikiLeaks events influenced this.

Security is often cited as a concern with regard to cloud adoption. My view is that the apprehensions are more the fear of losing control (not being able to restore service when needed), not primarily the fear of losing data. Fear of losing data can be addressed by cloud providers through implementing security solutions as described in various posts on the CA security management blog, but fear of losing control cannot.
The big difference between traditional IT and cloud computing is that cloud computing is delivered "as a service." With traditional IT we bought a computer and some software. In case it did not work we could fix it ourselves (sometimes a firm kick would suffice). No matter what happened (good or bad), we were the master of our own destiny. And even with traditional outsourcing, we often told the outsourcer "what to do," and in many cases "how to do it." If push came to shove and the outsourcer really screwed up, we could -- at least in theory -- still say "Move over, let me do it myself."

When something is delivered as a service, there is no equipment to kick and we no longer can say "Move over, I'll do it myself." We likely won't even be allowed to enter the room where the equipment is located or get access to the underlying code and data. If your biggest customer (or your boss, or the boss of your boss) is on the phone screaming at you, that is not a position many people want to find themselves in. And believe me, showing all the certificates and audit reports that your vendor accumulated and shared with you, will not quiet them down, even assuming that the vendor at that moment is doing its best to fix the problem. But what if the vendor has made a conscious decision to discontinue rendering the service - as seems to be the case with WikiLeaks?
Now you may feel your organization would never do something that would warrant or even cause such behavior by your vendor. But what if a judge ordered your vendor to discontinue the service? Something that can happen and has happened, sometimes because of really small legal technicalities or unintended incidents like a server sending spam or an employee collecting illegal content on a company server. Google and other mail providers have been ordered to cease mail services to both consumers and business, and have complied. Sure you can go to court and appeal, but will that be quick enough?
For each "as a service" service we will need to evaluate what is reasonable risk and what to do to remedy the unreasonable risks. What is reasonable will very much depend on the type of industry. In the following examples we look at scenarios of the service not working (outage), and the data being stolen. Some incidents the business may hardly notice, others can be severely inconvenient, but others could jeopardize overall business continuity (not being able to invoice or missing a deadline on a project with severe penalty clauses).

• Email: If email is down but phones, instant messaging, text messaging and maybe the occasional fax are still available, then a few days outage may be reasonable (for some companies). Provided we get all of our email back at the end of the outage, regardless of whether we moved to a new provider or the old one finally got it fixed or switched us on again. With regard to theft: nobody likes their personal conversations discussed in public (see again the WikiLeaks example) so measures like encryption, digital signing, using SSL and working with reputable (OK, let's call them certified) vendors are in order.
• CRM: This system tells us what our sales team has been up to. Before we implemented CRM (fairly recent in many cases) we had limited insight into sales activities, so it seems reasonable that a week of outage is fine (again, depends on your industry). With regard to theft, these are often records about people, so legal and privacy requirements apply, not to mention that you may not want this data to show up at your direct competitor.
• Invoicing, order intake, reservation management: Very much depends on the industry, but for some industries a single hour of outage at the wrong moment can already mean bankruptcy. In this case, you probably want to have a hot swappable system, preferably at two different "as service" vendors.
• Project management: Depends; if you are a system integrator with penalty clauses or an innovator rushing towards a product launch, it may be critical.
• Bookkeeping: Depends (before end of month closing?).

I could go on and on, but I'm sure you get the point. For each service that you would consider moving into the cloud, you have to determine the importance, criticality and impact of disruptions (I am sure you do this all the time for all your services ;-)). This exercise may actually save you lots of money. Most services are not under-provisioned but over-provisioned. In case of doubt, IT tends to move services to the more secure, more reliable, more failover equipped platform. A famous example is the company that was running its internal employee entertainment Tour de France betting system on a hot swappable dual everything nonstop system.
Next, for each service you must determine what a reasonable recovery period is, and how to implement it. It could be simple source code escrow (with the right to keep using the code) and a failover contract with a nearby infrastructure provider. Or it may require having a fully up-to-date system image ready to provision within an hour. For other scenarios, you may be running two instances of your service or application, in parallel at two separate service providers on different grids, different networks and in different jurisdictions. And for some you may not bother. It's like insurance: most people insure their house against fire (as they could not overcome the financial impact if it burned down) but many do not insure their phones or cars against theft of damage (as they can afford to buy a new one if needed without going bankrupt, even though it may be "severely inconvenient"). There is also a case of being too cautious.  I remember at my first employer, the bookkeeping department of the local plant would travel separately to the annual company outing (two by train and two by car), even though we had 12 factories located within a hundred miles, each with four bookkeepers. I am sure we would have closed the books somehow in case of a travel mishap.

Hopefully most of the services currently running in the cloud (CRM comes to mind) fall into the "severely inconvenient" category. If they are business critical, you hope the companies have a plan B that allows them to move these jobs quickly to another cloud if the need arises.  To be able to do so easily, we will need two things: Standards that enable more portability than we have today, and automation tools that allow us to do this "semi-auto-magically." Our accountant friends may claim you also need certifications on both the primary and the backup vendors, but I am sure these will remain in the desk drawer when push comes to shove.A final thought on assuring your services in the cloud.  On the insurance front we see that many people do not insure their house against natural events such as earthquakes, first because it is often not possible or affordable, but also because -- as my father used to say -- "if heaven drops down, we will all be wearing a blue hat." Imagine if a video on-demand provider is the only one still running after an earthquake, how much good would it do them? In other words, it is all about being pragmatic.

P.S.  During my economics study, at some point you had to decide whether to major in accounting or in IT. Guess what the more pragmatically inclined folks chose? ;-)