CSD - cloud strategy document (This is a DRAFT until it isn't!)

Key assumptions of this document

• A documented and agreed-upon cloud strategy is the foundation of successful cloud adoption. Documenting the strategy early can significantly increase the pace of progress.
• The disruptive nature of cloud forces decisions that have internal political implications. Such decisions require consensus that can be achieved by the consensus agreement of stakeholders contained in our cloud strategy document.
• An effective cloud strategy document focuses on why cloud is being adopted, on immediate concerns such as cloud risks and on the key principles that govern cloud adoption.
• Documenting success metrics, even at a high level, helps with tracking progress and determining the success of the subsequent cloud implementation plan.

Process

• Draft and circulate this cloud strategy document as soon as possible, even if some details are incomplete or wrong. Early feedback from stakeholders will help us set the right direction from the start.
• Separate cloud strategy from implementation. We’ll focus on which decisions are essential to move forward with cloud adoption and follow up with separate implementation and policy documents.
• This document is intended to seek agreement, not to impose decisions. Stakeholder objections and identified risks with solid arguments and mitigation strategies will be used to craft this document.
• We will modify the cloud strategy document if we fail to progress or are struggling to hit our success criteria. EG our initial strategic plan might be too ambitious or require additional perspectives.

Things we could/should include in this document.

What have we done so far

• Adopted git as our revision control system
• Adopted a cloud first policy
• AWS is our preferred cloud service provider
• Fun fact: first cloudtrail record 2016-12-07T20:23:01Z
• Adopted cloud formation as preferred deployment method for aws resources
• Aggregated AWS billing in cloudability
• Provided AWS accounts within a central organization
• Encouraged and supported technical resources to gain AWS technical skills
• Engaged AWS in MAP and started MRP but have balked several times
• Allowed adhoc migrations driven by app owners
• Provided ops support to app teams to use devops to migrate existing applications to refactored cloud native services.
• Engaged contractors to build turn key solutions to existing applications
• Created an AWS infrastructure team

First pass at CSD

Application Discovery and Dependency Mapping

A reliable list of current applications, and ideally all of their interdependencies, is critical for maximizing chances of success in an overall cloud migration strategy. The old IT adage “garbage in, garbage out” applies to planning cloud migrations. Moving forward on a major transformation project without a plan to get high-quality data will significantly increase the chances for failure or disruption.

Why do we use Cloud?

We use cloud services to free us from drudgery and low value tasks so we can focus on delighting customers with useful products that are:

• cost efficient
• secure
• agile
• dynamically scalable
• highly available
• magical (looking at the likes of athena, glue, lambda, ssm, config, security hub, etc)

We are cloud native

New products should be designed with cloud native services by default as the preferred solution.

We are well architected

All products should make use of an initial and periodic Well Architected Guide

We are excellent

We will create an initial cloud center of excellence that will oversee the adoption of cloud services to facilitate:

• Alignment of stakeholders through common goals
• Consensus on business drivers and success criteria
• Identification of key concerns and removal of barriers
• Development of a Minimum Viable Cloud (MVC)
• Gap analysis of enterprise readiness for cloud adoption
• Usable and operational cloud platform on AWS
• Adoption of cloud resources at scale
• Migration of 3 applications
• Reusable architecture as code

COE coverage

• analytics (data)
• architecture
• development
• finance
• networking
• operations
• security

COE members are required to be:

• bold
• result oriented
• customer focused
• able to influence
• experimentation driven

We automate

All products will be deployed using infrastructure as code and automation.

We own

All products will be owned by drum roll... A product owner.

We observe

All products will publish a minimal meta data set that allows us to assemble a global inventory of what we run where and how.

We are never done with the treadmill of improvement

devsecops