Every business unit can benefit from a cloud strategy approach when CIO’s focus efforts that connect the cloud strategy with the business strategy in order to create design specifications, implementation and migration plans.
| Design Specification | Translation | Action |
| Executive Summary | Cloud team organigram, business drivers, challenges, risks and benefits.
|
Create an overall program plan. |
| Cloud Generic Baseline | Cloud definitions, service and layer categories, delivery models (private, public, hybrid, multi cloud), cloud adoption best practices.
If the required IaaS skills are insufficient and more training is required, the migration to the cloud will be delayed. |
Required skills, training and communication plans. Invest in IaaS skills first. |
| Business Baseline | Desired business outcome, detailed risks and benefits, data center strategy, cloud first strategy, where to consider cloud strategy (wave one, wave two). Cloud best strategy to align cloud to the business strategy. | Potential benefits to desired business outcome mapping.
Address and define potential resolutions for challenges and risks. Consider any issues that are unique to the enterprise. |
| Cloud Services Baseline | On demand and pay per use (when to consume), build operating model, hybrid operating model, how to secure, manage and govern hybrid models, comparison self-provider vs. vendor provider.
|
Define and verify roles in the cloud.
Analyze your pre cloud situation how resources were underutilized and overloaded such as backup time, patching, server downtime, change requests deployment, everything which hold up the day to day business processes as well. |
| Cloud Migration Strategies Baseline | 6R Migration Strategies: Re-host, Re-Platform, Repurchase, Re-architect, Retire and Retain.
|
Conduct migration strategies workshops using the 6R framework to understand the complexity, effort (time and cost) opportunities to optimize. |
| Financial Baseline | Pricing models, payment models, chargebacks, CAPEX, OPEX. | Define all options. Decide if a service is operating expenses. Define options for cloud contracts. |
| Cloud Principles Baseline | Cloud workloads, data strategy, cloud first, SaaS first (buy before build), best of breed (consider security and architecture questions) and cloud best (align cloud to business strategy).
Business case for public cloud vs private cloud, hybrid and multi cloud.
Enhance existing systems to the cloud (Oracle or SAP on premises -> Oracle or SAP cloud), security, fix and shift, lift and shift as a last resort, vendor evaluations. |
IT validation from above Business Baseline provided.
Cloud first: anytime you want to buy, build or enhance an application or system, validate against the cloud first principle.
Cloud best: instead of business follows IT, align the cloud to the business strategy.
Vendor evaluation: if you use Microsoft all over your company, it does not mean you must choose a Microsoft Cloud solution. |
| As-Is Analysis | Business and technical architecture and infrastructure, system inventory, custom applications characteristics, customizations of existing standard systems (i.e. Oracle EBS, SAP), use or evaluate tools (i.e. Panaya, architecture layers, total cost of ownership tools. | Produce assessment where you are today, i.e. inventory of systems based on cloud principles baseline above. |
| Security Baseline | Security principles, authentication standards, encrypted data, vulnerabilities in shared servers and system software used by public clouds, sensitive data, change vendor, data breach, loss of data, identity access management, define responsibilities. | Apply the findings from security principles to the security and cloud strategy. |
| Supporting Functions | Staffing, other strategies (business transformation, transitions, Global Business Services, Procurement simplification, etc.)
|
Align cloud with other strategies to avoid budget, prioritization and staffing conflicts. |
| Exit Baseline | Vendor contracts, SLA’s, terms and conditions, data ownership, data backup and restore, vendor lock-in, exit strategy by types of services in the cloud, DevOps issues, architectural impact, support handling.
The exit strategy is much more than just what is in the SLA defined and not about an accident during cloud operations. It is about the steps required when getting out of the cloud or changing the provider.
|
Define what-if scenarios when changing a cloud service provider / vendor.
Define KPI’s for when to change a vendor. Business case for transferring data from old to the new provider. Use of containers to avoid lock-in. Validate multi cloud scenarios. |
The cloud strategy is dominated by IT architectural and security issues. Companies need to pay attention to identify the roles and responsibilities and consider compliance issues.
For the vendor evaluation, companies need to do due diligence and references from those vendors. For example, if a vendor has a good security rating, you still need to hire security experts or train your IT staff or will those experts be provided from your vendor as a service? Who will do the installations of the new software, is the company or the provider?
If the cloud was a car, most vendors do not want to take responsibility on how to drive the car, they just provide you with the car. The how to drive it responsibility is with you.
As-Is analysis with systems and applications inventory
For each workload which potentially moves to the cloud you establish an inventory information addressing the following questions. Taking enterprise applications, data centers, API’s, gateways and the total environment, you will end up with hundreds of workloads.
- Owner of the workload, name, author, version.
- Does the workload stay at the company or at the vendor?
- Is the workload high value or low cost? Consider size/cost with low, medium and high.
- Is the workload critical? Consider with low, medium and high.
- Vendor with specific information such as on premises only, next release SaaS only, etc.
- Virtualized?
- Data and security requirements.
- Integration requirements.
- Sequential (stability, reliability) or exploratory (agility, flexibility) mode?
- Performance criteria.
Is the workload well behaved, overprovisioned or unpredictable?
- Well behaved workloads are applications and systems which can be estimated with a high accuracy such as Enterprise Applications, cost effective systems, hardware and data centers.
- Overprovisioned workloads are increasing or high volume of demands during the year which require consideration during the as-is analysis and application inventory exercise.
- Unpredictable workloads are networks, gateways, firewalls, connections, nodes, API’s, etc.
In addition to the as-is analysis and the application inventory, you need to think about your backlog of enhancements and change requests. Based on you outcome from your as-is analysis you can decide whether the enhancement or change request will be better deployed when the workload moved to the cloud.
Last considerations relate to any strategic decisions and plans which impact your inventory. For example, if the company decided to close data centers within the next 3 years, you can use the as-is analysis and inventory above to determine the appropriate actions and start building your cloud migration plan including new skills required such as Data Center Infrastructure Management (DCIM) tools when moving to a hybrid cloud.