Why Cloud Adoption Fails

I wanted to write an article on why cloud adoption fails and how to avoid those failures.

First, I list and expound on the 6 major reasons I see cloud adoptions fail. I provide a way to fix each one and then, hopefully summarize into something that looks like I know what I am talking about; wish me luck.

Defining Failure

Let’s begin by setting some definitions, I am using the word “failure” which is intended to be a very definitive term. But my calculus for failure where cloud adoption is concerned may be a little different than yours. Do I mean that I am giving folks a pass who just manage to migrate to the cloud but aren’t able to take advantage of what it offers? In short, no; quite the opposite. In my book, failure to adopt cloud is reached whenever you fail at either of the two great battles of cloud adoption, 1) either getting to the cloud, or 2) operating efficiently in the cloud. In short, they give awards for half marathons but not for half cloud adoptions.

That’s right – I set the bar higher for one very simple reason. Read on . . .

Planning

There is a very old quote that goes something like this; If you give me 5 hours to chop down a tree I will spend the first 3 sharpening the axe.

?Now, strap yourself in for my best rhetorical “teenage billionaire buys hyper-car” analogy . .

Let’s say for the sake of illustration that a 15-year-old US billionaire buys a Lamborghini Diablo, it might be one of the best days of their young life. They take delivery of the car, the dealer explains everything about the car and the white-glove service plan that comes with it. They get all the paperwork explaining what they now own, the dealer hands the key fob to our fictitious billionaire, just before they leave. They open the door, climb into the highly appointed almost space-craft-like cockpit; hit the ignition and start it up. WOW. . . listen to that engine, and the awesome rumble of power when they press the accelerator. Only one real problem here, in no state in America can a 15-year-old legally drive. That’s right – they have the coolest, baddest, drive-way-ornament of any billionaire adolescent on the planet. But functionally, it’s almost useless.

My point for those still missing it is this, the newest, shiniest cloud available isn’t much good if you can’t use it. And by “use it”, I mean take advantage of what cloud offers in an expeditious way.

If you fail to plan correctly, you may find yourself with a nice shiny sports car in the driveway – that does you very little good. Read the rest of this article if you want to learn how to plan your cloud adoption with Rock-Star efficiency. Actually, Rock Stars aren’t exactly epitomized by efficiency but you get my point. This article should help you avoid the most common pitfalls – but won’t help you play The Met.

Inefficient or Inadequate Planning

Planning is one of the most effectual functions you will perform when headed for cloud adoption. Fail to do it or short cycle the effort – and you will likely reap some seriously bad results.

Plan your migration to the cloud very carefully, if you don’t have the expertise in-house, hire someone who does. Don’t set unrealistic timelines for the migration and don’t let extraneous forces pin you to a timeline that will hurt your migration.

Here is one of Lee’s basic rules – Never let any migration effort go beyond 12 months, 8 months is even more protracted than I like. The reason is this; by the time you reach those markers, technology will have made multiple revolutions. Choose only the migration tasks that you can execute in this time frame. Then, step back, and focus on the operational pieces of what you have already moved - to a point that makes everyone happy. This will help inform your next set of migrations. The ideal method for this would be to build in a feedback loop for each workload migrated – so that the process of migrate, integrate, operate, review. . . becomes a self-sustaining reiterative process.??This rule may annoy certain Fortune X, or Global 2000 companies, but it will allow you to bite off only what you can chew in 8 – 12 months. It also keeps your planning realistic. It will also teach you what you don’t know without producing corporate failures; the type of which – sours everyone on cloud adoption. All of these factors make it very expeditious to move smaller test or non-production environments first. The benefit of which cannot be understated.

If you followed my previous guidance you are now in a hybrid cloud environment. See my section on paying two mortgages.

Every rule is made to be broken. If a technically (or other) extraneous force means you have to lift&shift the “wholeschmittenverks” into the cloud before some looming disaster, then simply break my rule.?

A Tangent to Describe Tragedy

Tragedy #1 - Enthusiasm where cloud adoption is concerned is a precarious commodity, protect it at all costs. Everything else can be purchased, found, or developed. Enthusiasm, once quelled, can be dang-hard to near impossible to get back.

Tragedy #2 - The executive branch of your company has to be completely sold-out on cloud adoption. If they aren’t, find a new gig. Zoltar says “cloud adoption is not in your future”.

On a lighter note

Plenty of companies offer “acceleration” packages that purport to get your workloads to the cloud in short order. These are generally OK as long as they “work” and give you a view into what migrating and operating your entire fleet might look like. It is highly unlikely that every workload in your fleet will be considered a “candidate” for these acceleration programs. Reason being is they generally have to migrate workloads that are “low complexity” to meet the accelerated timelines they promise.?If you are an older enterprise, the bulk of your fleet will likely NOT be defined by this same categorization. In fact, the longer you have been in business – the more I can guarantee - they won’t. A company’s growth over time is directly related to the number of workloads that will fall outside of the “low complexity” category. In other words, the longer you have been in business and running IT – the more “high complexity” workloads you are likely to have.

Defining Terms

A “Low-complexity” migration generally references moving monolithic applications with only a few external dependencies. These dependencies are connections to services that the application needs in order to do its job, or operate normally.

High-complexity workloads conversely are highly interconnected to numerous external services and the applications typically need all of these “dependencies” in order to function.

It should go without saying that a startup company with a few terabytes will have a much easier time adopting cloud than a 40-year-old enterprise. One reason; time tends to cause every application in a data center to develop dependencies. Generally speaking, the older an application is the more dependencies it will have.

On the upside, companies who offer these acceleration programs are typically very good at what they do – they couldn’t offer them otherwise. Consider this scenario: So now that these consultants are in your environment, done all the migration planning, got all the needed security access, built/know all the prerequisites, done all the setup, and have started moving workloads, it’s likely you will NOT want to unplug them. The odds are much higher that you will pay them to migrate at least some portion of your entire fleet. So choose carefully. And remember, the higher complexity workloads will take longer to migrate.

In any case, before you have ever moved a single workload, begin planning how you will operate in the cloud. Trust me, this second job is infinitely harder – and goes on in perpetuity.

If you had good luck with the folks you hired to migrate those first workloads – maybe you ask them how to do the operations side of things. Or maybe you think – hey, we operated pretty well in the data center – how much different could it be in the cloud? Don’t fool yourself, operations in the cloud have fundamental similarities to operating on-premises – but that’s where the similarities end. Everything in the cloud is based on a different paradigm, meaning that much of what goes into your detailed day-to-day operations is going to be different.

Paying Two Mortgages

Also don’t be misled, migrating to the cloud for a protracted (typical for a larger enterprise) period of time means you are living in two houses, i.e. paying two mortgages. And by the way, if you choose to do your own migrations, then your IT department’s workload has just more than doubled.?Unless your company is at the pinnacle of planning and execution, pay someone to either help or actually do your migrations. For large enterprise this rule is mandatory. For smaller companies this rule can be bent.

I will give you a scenario that I have seen play out time and time again, enterprise A starts its migrations, full of the vigor and elevated expectations of getting to the cloud. A year later, they realize how hard it is just to migrate, they may even have reorganized sections of their business, burned a bunch of capital, or hired a third party for migration work. They have partial success migrating only to find out that operating in the cloud is even harder than migrating. This has caused many an enterprise to consider Hybrid cloud a much more viable option. That’s not necessarily a bad thing – but it speaks to the difficulty some folks have just getting away from the data center practices we have been building for generations. Not wanting to add insult to injury, I won’t say Hybrid is a forced compromise, but sometimes it is.

How To Fix It

So, what’s the answer? That great philosopher Jack Sparrow once said - The only rules that really matter are these: what a man can do and what a man can't do!

Hybrid as a forced compromise may be the better part of valor. Meaning seriously, that numerous years of packing around technical debt which didn’t seem to matter in the data center has caused us to think twice about picking all this stuff up and moving it to the cloud. Which (combining tech-debt and cloud) most would rightly consider analogous to putting a nice three-piece suit on a pig. Nothing against a dapper pig mind you.

I know technical debt is a current IT-world “boogie-man”, and entirely antithetical to what cloud stands for. But, you didn’t accumulate it overnight, don’t be surprised if it takes more than one night to get rid of it. The point is to start, and don’t stop. Retiring tech-debt should become a natural progression in the cloud – as you learn to take advantage of what cloud offers.

Most large enterprises cannot flip a switch and be running in the cloud overnight. So like I have said many times before, Hybrid cloud becomes a pretty compelling intermediate step in getting to that final mile of cloud adoption.

Most thinkers would consider this ample ammunition for a migrate-as-fast-as-you-can motif.?I don’t like removing a client’s options, based on non-intrinsic motives, no matter how lauded by some of my colleagues. But getting past the migration hump and on to the longer-term operational work does have compelling value. ?As long as you understand that migrating to the cloud is only half the battle. If you do decide to throw down the lift&shift gauntlet (i.e. ReHosting), make sure you take into account some refactoring, reconfiguring, right-sizing, etc. in the target environment. Don’t forget to plan for this – because it will take up time, know-how, and money. When you move images out of a data center they will have to be reswizzled a bit to get them past the initial functional testing phase.?At a bare minimum the hypervisor and I/O drivers will have to change to fit the target cloud platform. This is pretty straight forward and many 3rd party migration products and the cloud vendors themselves will have options to help you get the images up and running.?If you do follow a ReHosting pattern, don’t imagine this is the end. You will still have to get these newly-reborn images into your operational process – and this can be daunting.?You will have to get them setup for monitoring, logging, alerting, end-point scans, backup, patching, security hardening, etc. Bite this off in workable chunks, work quickly, use an Agile methodology and set short range MVP (Minimum Viable Product) goals. Then do an ample amount of testing before you move to production, continue to test and improve your OI (Operations Integration) processes.

A major tip to winning here is to send an expeditionary force into the land you want to possess. Learn how to live there; operate, automate, and take advantage of the terrain. This initial venture will tell you more that you can fathom about operating in the cloud – don’t fail to do it. (What are all the things you will learn? That’s another article.)

Cultural shift

A lot of very smart people have underestimated the impact on the cultural fabric of a company headed into the cloud. To say that cloud is a disruptive force is like saying water is wet.

The basic IT department has been enduring change for the majority of its life, so the idea of cultural change as it relates to people’s social behaviors – is not the monster in the room here. What frightens people is the technical shift and its subsequent impact – “our security model used to look like this – now it looks like that”. A very scary proposition if your title has the word “security” in it. These same sort of macro-cultural trimmers will happen to some degree in almost every IT specialty/department – throughout your company.

It’s a natural human tendency to fear the unknown and to resist change. When the mysteries of cloud become generally less opaque and more transparent, these fears subside.

Prior to this, I have focused on the personal aspects that make cloud a little scary to some. But there is a much larger daemon here and that is the corporate ability to work cross-functionally. Where cloud design, migration and operations are concerned, everyone has to work with everyone else. DevOps was literally born out of this need. But it’s not just Development and Operations that have to work together, it is Security, Networking, Purchasing, Finance, Operations, Support and others. Almost every department in your organization will be impacted in some way.?I have seen dozens of organizations both large and small attempt cloud adoption, and a company’s ability to work cross-functionally is the biggest killer of cloud adoption.

How To Fix It

A major responsibility of a Cloud Center or Excellence (CCOE) should be a training program that focuses on taking away the uncertainty of what cloud will bring to the organization, and to address the impact of cloud in every department.

I know, I know; you all hate CCOE’s – that’s because you pick the wrong people and take on the wrong tasks and make everyone mad at you. The concept is still good; just stop doing it wrong.

Ok, where was I . . .

Don’t just give your people training material and turn them loose. Of course, some will learn with that strategy -?but some won’t. They have to understand the strategic goals for the company where cloud is concerned, but also what the personal impact will be. It’s up to the CCOE to take the corporate direction, and create a good training and certification strategy, then make sure everyone knows what it is and how “they” (everyone in the IT and ancillary departments) will be impacted.

Focus on closing the cloud skills gap in your IT departments, Security, Infrastructure, Operations, Finance, etc.

Don’t just take along a few select folks where cloud training and development is concerned. There has to be at least a path for everyone in your organization.

Not everyone will come along for the ride – don’t try to make that part happen, just give everyone a chance and a clear path.

And finally; actually correcting a company’s ability to work cross-functionally usually requires new blood and new organizational structure. (This can be very tricky; you may have to wait for the book to get an answer to this one.)

Technical Skills Gap

Inefficient or inadequate focus on understanding a company’s technical skills - and ultimately their cloud-skills gap, is a critical step in cloud adoption. In short, you can’t take steps to fill those gaps if you don’t know they exist, and you won’t know that – if you aren’t looking.

Having the technical skill-sets you need to make your cloud adoption a success will take mainly two forms. You can grow (or fill) your in-house technical skills or you can pay someone to provide those skills for you. Keep in mind where that second scenario is concerned, once you stop paying them – they typically leave. Even if you select option 2 and pay consultants to fill the needed technical gaps for a time, you will still have to develop some level of in-house cloud expertise unless you intend to outsource this to a consultancy in perpetuity.

How To Fix It

The first step is a clear-eyed evaluation of the internal cloud skills you have. Not just whether your folks know how to make cloud work or not – because at least some should already be on the cloud learning curve in this day and age. If your internal IT teams are up on everything in cloud, count your lucky stars. If they are not, the real questions are can they learn it, and how fast? The “fast” part goes directly to your company’s timelines in getting to the cloud, and becoming proficient there. If not fast enough, hire experts or move your time lines back.

Filling the skills gap

Cloud consultants can be a great way to get your entire organization past the cloud learning curve. Because you will be paying for their time, make the most of it. The idea being not only to get their expert knowledge but to disseminate that knowledge into your organization as proficiently as possible. So much so that once they are gone, your in-house team’s knowledge has taken a huge leap forward. This may put somewhat of an extra burden on the consultants, in that they need to become trainers – and some may not fit this role too well. Make sure before you hire them. Likewise, make sure that any technical collateral is left behind when they leave and that it has been reviewed and is understood by the right folks in your IT teams.

Next, focus on training. Try as you might, the consultant method will always leave holes. The CCOE needs programs designed to bolster your internal team’s cloud knowledge. ?Most in your organization will recognize the personal and intrinsic value behind cloud training. Alas, some will not. Try to tie cloud education and certification to IT employee performance reviews. This means getting HR involved so tread lightly. Know it may be an uphill climb but typically pays off big.?

The companies that have success in the cloud training and education part of their cloud adoption journey tend to win big and keep winning in the long run.

Gaps in the board room

Based on all the Gartner and tech-think-tank reviewers, the current corporate board room is focused heavily on cloud adoption. Lack of focus at this level is rarely the issue. The problem can become creating a realistic vision for what cloud should be in an organization, and then disseminating that vision to the company at large.

Other board level issues that arise are an unwillingness to make strategic decisions, incorrect or un-informed decisions, taking too long to make decisions, or not pushing the appropriate level of authority down to subordinates in order to allow them to make decisions.

If your C-Suite folks are not on-board with cloud adoption, find another job. But if your mid-level managers don’t believe in it, you are in for a long bumpy ride. I have heard it said; “People don’t work for companies; people work for people”.

Last, but certainly not least, is the dreaded-unrealistic-expectations often placed on subordinates from the board room. This usually comes from a lack of understand about “how” things work in the cloud or the realities of what the enterprise can and cannot do.

Finally, there is just the run-of-the-mill poorly managed organization. When cloud is applied to this entity, it tends to illuminate the organizations short-comings like nothing else.

How To Fix It

Ah, I can’t give this one away for free, you will have to wait for the book, pay someone, or figure it out on your own. Suffice to say, most problems with cloud adoption don’t arise from the boardroom. It’s worth noting that when the folks upstairs make a mistake, the ripple can be devastating.

Lack of Automation

Any organization that is either unwilling or unable to automate nearly everything they encounter in the cloud is likely to slog through migrations, but will really bog down when it tries to operate in the cloud. Cloud and automation are symbiotic cousins – they need each other more than peanut butter needs jelly. Yeah, like that!

When I use the word “operate”, I am typically referring to operational efficiency. While cloud may share certain overarching operational patterns with on-premises operations, the detailed functionality of operations in the cloud is an entirely new paradigm.

Because cloud is built to be automated and scaled, not automating anything and everything you can is essentially a step backward.

Here are two major stalwart examples where automation should be applied in the cloud – incident response and provisioning. Of course, there are dozens of others but I wanted to start with these.

Imagine having an automated (incident) response that could restart an offline service or put a security control back in place after inadvertent removal.?How about a fleet of containers or cluster nodes that get provisioned automatically when needed, then decommissioned when the need subsides? Automated processes like these should become rote; almost perfunctory in the cloud.

Poor Vendor choices

Last, but not least, is the decision making process that ties your organization to any number of cloud providers. Make these choices correctly and your cloud experience will be one of achievement and success. Make these incorrectly and you will suffer commensurately.

Since this last one is not indigenous to the cloud, I leave you to your own devices. Choose wisely.

Conclusions

Pardon me – I am going to get a little inconclusive.

For the large enterprise, hybrid cloud may seem to some like a forced compromise; so what! Oft times a forced compromise is life telling you to do what you can do now and do the rest later.?There are all sorts of negatives to having two mortgages (living in the cloud AND the data center), but if it can work for a while, it may teach you a lot about what it takes to be successful in the cloud. Just don’t get comfortable in this world. A large enterprise has some advantages over a start-up – one of those is money. Take advantage where you can. But remember, the goal isn’t to stay in your hybrid state too long. It should be buying you time to get your act together and completely move into the cloud. Or, move everything that makes sense today. Or, if refactoring or rearchitecting is your migration pattern of choice, hybrid will buy you some time. Use it wisely.

As you can see cloud adoption has a lot of moving parts so there is plenty of opportunity to foul things up big-time. Consider this article a synopsis of the items I have seen with the greatest ability to make or break your cloud adoption journey. It is also my effort to advise you on how to side-step them.

DISCLAIMER: Lee Smith is a cloud architect with Amazon Web Service (AWS). The content provided in this article is solely the opinions of Lee Smith. It does not necessarily reflect the views and opinions of Amazon Web Service. Lee Smith is not an official spokesperson of AWS.

?