Your company is going to the cloud model. Typically, you'll read articles like this that include the phrase “it’s a question of when, not if.” But we're past that point. Your company is going to the cloud - now. Congratulations!
Of course, your cloud implementation could be internal, public, or some hybrid of the two. Maybe, like many companies, your cloud implementation inlcudes moving to Software-as-a-Service for things like office applications and IT ticketing. According to Gartner, SaaS is the largest segment of the global cloud market, forecasted to grow 22.2 percent to $73.6 billion by the end of the year. The broader global public cloud market is forecasted to grow 21.4 percent this year to a total of $186.4 billion, with infrastructure as the fastest-growing segment projected to hit $40.8 billion, up 35.9 percent, according to Gartner data.
[ Read our related article: Multi-cloud vs. hybrid cloud: What’s the difference?
No matter your organization is moving to the cloud, no matter the scope, you are sure to encounter some blockers along the way - the most common of these being security, procurement, and inertia. Let's explore how to combat what I call the Three Horsemen of The Status Quo – and turn naysayers to advocates.
1. The security chasm
Change is scary, perhaps especially for security teams. A little reassurance can go a long way in turning your security team into your biggest cloud advocate.
Their primary argument against the cloud is probably a perceived lack of control. When systems are run in a data center using rack-and-stack machines, there is a natural control point for security. However, once people can request new instances without a ticket, things appear to become less controlled. Your security team needs to be involved in setting and enforcing policies for using your cloud providers' services.
For example, you may have a standard OS image that security wants users to always choose. It's easy to have blessed machine images that are the only choice in starting instances. Moreover, you may have standards with network connectivity. Your security team can enforce those standards on every compute instance in the cloud.
The point to enforce with your security team: Moving to the cloud will provide more control surfaces for them, not less. Of course, they should be a part of the move to the cloud so that they can set those policies in place programmatically and not manually with tickets.
If you’re requesting someone else to start cloud instances so that they meet standards, you’re doing cloud security wrong. Instead, requested instances should automatically meet standards when started.
2. The procurement quandary
For your procurement team, cloud can be a nightmare. For decades, procurement teams have created systems to manage and lower costs. Moving to OpEx from CapEx, for some procurement, is as life-changing as using electricity instead of whale oil. Sure, electricity is neater, easier to manage, and cheaper, but you already have an entire process set up to buy whale oil. Making that change is very difficult.
To better manage this challenge, procurement teams should be brought in as early as possible in the migration process so that they can provide input. Much like the security team, change is just as scary and difficult for procurement.
But money is money. The cloud team must work closely with procurement to make sure that purchases in the cloud are attributed to the right budget code and managed. Also, metrics and KPIs must be shared freely so that they can observe and realize the promised cost savings. This is an opportunity to turn a non-technical naysayer into an advocate by sharing a win.
[ Don't miss out on savings – or get surprised. Read also: How to avoid cloud sticker shock. ]
3. The spikes of inertia
Conway’s Law states that a system will follow the lines of communication in a company and not what is best for the system. Similarly, we have created systems and processes to manage our system lifecycles. From procurement to development, to releases, to ongoing management, many moving pieces will need to change.
For example, if you have a manual process to manage a database schema update to match an application release, your system will come to a screeching halt under the weight of 1000’s of new, smaller database servers. That process should become automated. However, there will be a small but vocal minority that will push back against automation. Typically, the phrase “That’s not how we do it here” will be stated and repeated. Often.
Thus, your task will be to ask “Why?” Like Toyota uses “Five Whys” to identify the root cause of a failure, you will need to ask, “Why do we do it like that?” five times. For example, the DBAs will state they need to review SQL scripts prior to deployment. Of course, questioning why that cannot happen during the development cycle will be crucial to moving past the inertia of existing processes. You will need to ask why several times to get the root cause of pushback.
Improve processes, don't just move them
Remember, moving to the cloud is about improvement, not replacement. If you are going to maintain existing processes, be it security, procurement, or approval, all you are doing with cloud migration is moving from your servers to someone else’s servers.
Cloud should be about injecting agility and flexibility into your current IT offerings for your partners, employees, and customers.
[ Learn the do’s and don’ts of cloud migration: Get the free eBook, Hybrid Cloud for Dummies. ]
