The future for many services will be cloud hosting. Services that are now hosted on on-premises infrastructure, will be able to be rebuilt and consume cloud architectures in new and innovative ways outside of the traditional data center. Imagine you’re tasked with overseeing that development of business services, how do you get there?
Not all organisations have the same requirements for cloud consumption, not all enterprises within an organisation have the same requirements for cloud consumption.
A cloud strategy should be developed in tandem with the business and include buy in across all divisions. That is not to say that all divisions within an organisation need to adopt the same approach, timescales or approach to cloud consumption. It does mean that the cloud strategy is agreed, understood and if necessary signed off across divisions.
If the strategy calls for re-architecture or developing new services for consume, then the level of business change required to be absorbed is significant. The opportunity for business disruption is high, adopting a cloud strategy uni-laterally will generate unexpected pain to the business and most likely draw any cloud progress to a grinding halt.
The cloud strategy should be forward looking and decoupled from the current environment. It should be describing the desired target environment.
Often overlooked is the operational strategy for cloud adoption. In the rush to reap the promised dividends of cloud consumption, the operational elements of an organisation may have been overlooked.
Simply put this strategy needs to answer some simple yet fundamental questions. How will workloads be protected? Restored? Secured? Accessed? Integrated? Generate Alerts? What capabilities need to be developed? What processes require definition and documentation in support of this?
Simply put, not every workload will be suitable for the cloud. Not every workload will consume cloud services in the same manner. At a basic level this is what happens during the discovery phase.
Further to simply labeling a workload as suitable or unsuitable, the discovery phase should focus on.
- Physical attributes
- Logical attributes
- Business Information and ownership
- Key contacts
Thought should be given at this stage to identify the most effective method of communicating and displaying the captured information to stakeholders. Considering that not all stakeholders will wish to see the information presented in the same way
Process and planning
Having identified strategies and discovered workloads, work on the process of migration. Consider that each workload being migrated may need to take a different path to cloud services.
Rather than creating an unwieldy document that tries to cover all approaches, consider breaking the ask down to multiple smaller documents that outline required approaches and a flow chart to identify where to use each one.
Consider during each process creation developing a proof of concept, where teams that will follow the process do just that. This will assist in refining adopted approaches with the goal to minimize unscheduled disruption.
Armed with the discovery knowledge planning can commence to sequence the migration activities. With consideration for business schedules, interdependence and required approach.
Having created the require strategies, planned and developed process all that remains is to execute these plans.
Best practice should apply with issues and lessons learned being captured during the process to allow fine tuning of approaches. The goal through the execution phase should be to make the migration events themselves to be boring. A boring migration event is generally a successful migration event!
Cloud services are constantly being developed. To think that once a workload has been migrated to the cloud the journey stops is shortsighted. Continually review the services being offered and how that aligns with the strategy.