When presented with the case, it is hard to deny the allure of moving your nuts and bolts computing to the cloud. Everyone knows the arguments; computing is a utility, not a USP. There's no need to own the burden of supporting a server room. With network edge issues solved, time to market is reduced. Be flexible against peaks and troughs. Just taking the reductions on CAPEX alone can be reason enough - well, for those without a large budget to spend.
So where is the problem?
The problem is that reported corporate experiences reveal that the journey is the destination. Unfortunately, many inexperienced organisations haven't found this out yet. In reality, it is the change in processes and skillsets that are beyond most organisations looking to get the most out of cloud computing. Moreover, the people that make the decision may not feel confident that they can foresee the sticking points that the IT operations department might stumble into.
It starts with a Proof of Concept (PoC)
Feeling optimistic, the enterprise leaders ask the IT guys to create a team to build a PoC. They choose to deploy one of those web analytics dashboards that they never quite got permission to use before. All goes well, and naturally, the developers are keen. However, after a successful demo, some caveats begin to appear:
Security integration - talking with an off-premises cloud provider poses various security challenges.
Network integration - related to security, issues can arise when working out how to use a public cloud with a corporate intranet.
Infrastructure as Code - the devs running the PoC project find it hard to work with the ops guys, who aren't used to treating servers as things to be described formally, then built up and torn down on a whim.
So, while minding these issues and adding a few extra people it is decided a successful project can be achieved.
The first project starts to drift
A project to transform a real piece of the estate is launched, with the hope of delivering some significant business outcomes. Everyone needs a successful result to allay their fears, but this is where the prevailing culture tends to take over. Old habits die hard, so early warning signs are ignored due to poor communication between the development teams and leadership. Simple tasks like allowing a single sign-on require considerable work to be carried out in the corporate directory. Some organisations even duplicate a service for "cloud-only", which is an obvious waste. Working out what needs integrating and securing causes friction similar to fiefdom. Bringing in third party specialists to help with automation is fraught because no working patterns for knowledge transfer exist.
Ultimately, the message coming back is for the need for transformation within the existing structures, which is not what leadership was expecting. As everyone else is going into the cloud, the message goes out to continue but this time with more realistic plans.
Results are underwhelming
So, finally, the project finishes but costs are five times higher and timelines are three times longer than forecast. This is put down to the amount of 'new' stuff that is being attempted but the heat from the friction of working against culture is the actual cause. The developers have worked out how to get around existing barriers but no one has started to put new structures in place. No one has even attempted the tough work of seeing which silos must be changed or replaced. Besides, there are no significant challenges to change testing procedures either.
It is expected that after a difficult conception the true capabilities of cloud services and tools will shine through. A new project is started and the first project is augmented but making changes to more services just unveils the same problems again. Parts of the enterprise don't see why they need to alter what they do. This time, a breach appears after deploying to production.
So what is going on?
An enterprise spends decades creating the processes, procedures, teams and skillsets which allow their business to operate. These practices are not loosely held and they permeate every part of the company. Tight relationships that were seen as essential at the time end up being impenetrable silos that no one wants to work with or across. There might have to be some key skills added to development teams to make the initial push to the cloud palatable. The question is how to get IT to adopt the cloud, not how to build one example cloud app.
The reason? A move to the cloud also changes the relationship that many actors have to code and infrastructure, so much deeper roots need to be dislodged. This leads to initial efforts at change beginning just outside critical boundaries in order not to cause waves. Hence, initial projects can actually hide problems.
By definition, transformations involve everyone changing their thinking, at all levels. For example, many hospitals spent years having outbreaks of infectious diseases like MRSA - even though simple measures such as careful hand-washing by doctors and nurses could control it. They could not physically see the problem, so many staff didn't believe that it was important for everyone to comply with sanitation regulations. Many believed it was an administrative issue. Similarly, if staff believe the cloud is stuff happening elsewhere, they are unlikely to be thinking about how they need to adapt.
One of the key problems is the speed of operation. The cloud allows tasks to be uncoupled from their traditional domains but these gains can never be taken advantage of if the organisation doesn't adapt. Many basic corporate services or permission changes require long communication with a shopkeeper/gatekeeper, even though we all live in the age of the serve-yourself supermarket. Email, that is intended to be a letterbox for broadcast communication, is hopeless for tracking dynamic workflows. Layers of hierarchy make otherwise simple steps quite intractable because this is 'safer', resulting in the possibility of speed and flexibility being undermined by legacy processes.
The upshot is that whatever the cloud appears to offer, it is only with a serious transformation can any gains be made and kept. Those vanguard projects to introduce new services to a company will prove worthless if they are not combined with a change in culture. Agile development. Automation everywhere. Infrastructure as code. Guidance, not enforcement. When organisations get this right, massive gains are achievable by getting your product to market faster than your competitors, resulting in happier customers.