In a recent eBook, Gartner highlighted a handful of pervasive myths about the cloud: from “the cloud isn’t secure,” to “pure cloud deployments are the only viable option,” to “you can start implementing cloud technology without a strategy.” Left unexamined, these myths—and myriad others like them—can all easily set new infrastructure investments up for failure. At the same time, they’re not all equally pernicious.
From our perspective, the idea that you can dive into a cloud deployment without a defined strategy is the most worrisome of the bunch. Why? Because it’s simply not accurate. Successful cloud migrations and modernization efforts require more than just a strong will—they require technological expertise, they require buy-in from multiple touchpoints in and out of the IT department, and they require a clear roadmap with measurable metrics for success. Without those critical elements, you run the risk of a costly, ongoing boondoggle. Rather than reining in costs and powering a more modern, responsive technology stack, you’ll find yourself throwing good money after bad to solve problems that could have been avoided at the outset.
In other words, you need a documented cloud strategy. And what form should that strategy take? One option is to create a cloud strategy document.
1. Summary, Vision, and Outcomes
A cloud strategy document is pretty much what it sounds like. It’s a place for you to give an overview of how the cloud factors into your enterprise’s ongoing strategic initiatives, how you plan to get there from your current IT deployments, and what decision making heuristics you’ll use along the way. This shouldn’t come from a CIO’s head sui generis, but should instead be informed by discussions with stakeholders across multiple departments, plus cloud experts who can give detail to the exact ins, outs, and pitfalls that accompany each phase of the cloud lifecycle.
The purpose of getting all of this information into one document is twofold: to gain buy-in for your cloud migration plans, and to use as a touchstone throughout the process. There’s no way to cover everything that will happen from the word “go,” but you can create something that will help your colleagues to coalesce around your vision of digital transformation, making it that much more likely that your projects will come off and you’ll be able to modernize your stack while keeping costs under control.
So, fittingly, the first section of the cloud strategy document will start with a high-level summary of the project, what the aims of the project are, and how you plan to implement and measure the effects of the relevant changes. This include a sketch of your current IT landscape, your vision for the future of your stack, and a brief rundown of how each strategic initiative relates to corporate goals, plus the way the cloud factors into those initiatives and goals.
This is your chance to get everyone on the same page, so be sure to define your terms (you might lay out the difference between public, private, and hybrid clouds, the different cloud service models, NIST definitions of various technical terms, and more) and hammer home what you consider to be the most important points and the guiding principles that you’ll rely on as you move ahead.
2. Workload Inventory
In the next section of the document, you give a more detailed plan that covers the cloud migration on a workload by workload basis. Step one is to develop an inventory that lists out each and every workload within your existing technology stack. For each workload, you’ll want to give a full rundown of the costs and billing, the relevant vendor, the owner, any security and compliance requirements, plus a general rating of how suitable it is for the cloud. Something with unpredictable swings in data consumption or extremely seasonal processing needs (e.g. supply chain planning software for an automaker) could be a good fit for the cloud, whereas a stable, predictable application might be fine as-is, provided it’s appropriately provisioned.
All of this should be done with an eye towards categorizing each workload in terms its long-term migration status. Depending on how each workload slots into the larger framework, you might take one of a few paths in terms of application migration strategies:
- Rehost, i.e. “life and shift” the application to the cloud with minimal changes;
- Replatform, or make some alterations to make sure you’re gaining the benefits of your chosen cloud service;
- Refactor, i.e. make significant changes to the application before you migrate it;
- Phase out, meaning that you don’t see a future for that application going forward.
There might also be workloads that you see no reason to change, or applications that need to be replaced with a similar offering from a new vendor (either in the cloud or not), or applications that need to be rebuilt from scratch. Denote these workloads as well. Based on the information you collate here, you can begin to set priorities for what will be migrated in what order.
3. Cloud Governance
You need a strategy for how you’re going to get from your current IT status quo to the cloud-enabled future—whatever that means to you—but you also need to give thought to how you’re going to make decisions once your cloud applications are up and running. Especially when it comes to cost management, you’ll have to take a proactive approach throughout the entire lifecycle of a given deployment, including monitoring your usage on various instances, tracking the performance of your applications, etc. This brings us to cloud governance, which is perhaps the biggest and most daunting part of the cloud strategy document. This can and should include tentative answers to a whole host of different questions:
- How will different datatypes be classified, and how will those classifications be defined?
- What regulatory concerns apply to which datatypes, and how will they be addressed?
- What is your disaster recovery plan, and how does it vary by application, datatype, etc.?
- What is your data security or application security threat model, and how will that translate into specific policies?
- Do certain datasets or datatypes have to reside in particular geographies (e.g. because of GDPR requirements)?
- What cost control levers do you have across your deployment, and who owns them?
- Are there particular policies in place for incident management, change management, capacity management, etc.?
- What are the basic principles and structures of your desired cloud architecture?
You’ll want to provide as much detail here as possible, again so that others can use the document as a reference in the future. This will potentially require deep dives into the minutiae of everything from billing structures to new regulatory restrictions. If you don’t have the in-house expertise to handle all of this—and most businesses don’t—this is section is a prime opportunity to bring in a cloud expert who can help inform your governance and architecture decisions. Already at this stage of the process you might be thinking about who, exactly, will be doing what with regards to the modernization project, and how you’re going to stretch your capacity to cover all of the work—if that’s the case, it doesn’t hurt to be proactive about involving future migration and management partners.
4. Roles and People
Speaking of capacity: one of the most important steps here is to figure out who’s going to be responsible for what, and where the gaps are in available capacity and existing expertise. Start by listing out all of the roles (e.g. CIO, infrastructure manager, etc.) and giving a brief sketch of what they’re going to be responsible for. Ideally, the steps you’re taking throughout your digital transformation will give IT more of an ability to actively create value for the company as a whole, and your document should reflect your current thinking on that score, i.e. what your vision is for the futures of your different teams.
On a practical level, you’ll want to be sure that a number of specific responsibilities are accounted for and assigned to particular teams or individuals, e.g.:
- Who’s in charge of cloud vendor management?
- Who’s in charge of change management?
- Who owns which assets?
- Who’s in charge of incident response?
- Who owns the budget levers that we discussed above?
In all likelihood, your exact answers here will adapt and change over time. The goal as you’re putting an initial document together is just to make sure that nothing flies under the radar. The last thing you want is to make the switch to Azure and realize several months later that your bills have skyrocketed because no one has been managing unused instances.
5. Technology Roadmap
In this final section, you get a little bit deeper into the questions of implementation and integration that will define your actual cloud journey on an ongoing basis. This is where you’ll lay out the different project milestones, metrics for success, and criteria for completion. Even if you’re only undertaking a small fraction of your larger digital transformation, you’ll want to be explicit about what the priorities are for migrating different applications and workloads and what dependencies exist between them.
This section can also include your technical or budgetary requirements, your funding sources, and your initial assessments of prospective cloud providers. Ideally, this can work as a jumping off point to create tactical plans for the actual migrations—which will involve translating this high-level work into the thousands of individual tasks that comprise even a small migration project. Here, you’ll start to get a sense of what the gap really is between your internal capacity and budget realities and the amount of work that needs to get done.
Learn More About Intertec's Cloud Solutions:
Intertec’s teams have hands-on experience in developing and migrating applications on leading cloud platforms. In addition to design and development, we provide a complete range of application testing, deployment and ongoing support services, including managing physical infrastructure and offering outsourced DevOps teams. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here!
