Creating an Enterprise-Wide Cloud Strategy – Considerations & Benefits

What is a strategy?


“a plan of action designed to achieve a long-term or overall aim”. A Strategy involves setting goals, determining actions to achieve the goals, and mobilising limited resources to execute the actions.

A good Cloud Strategy is…

  • Specific
  • Timely
  • Prioritised
  • Actionable
  • Tailored

Note – A strategy is different to organisations requirements, which can change over a period of time.

Best practice is to define your strategy is to maximise the benefits you achieve.

The following items can be considered when creating your cloud strategy (Source: NetApp Research recommendation)

  • Categorisation of your workloads: Strategic vs Operational (goals may change over time)
  • Determine which cloud type fits the workload: Type of cloud will be most efficient and cost-effective for delivering that workload (public, private & hybrid)
  • Prioritise workloads for initial projects: Non-critical applications/smaller workloads

Benefits of a Having Cloud Strategy

An enterprise-wide cloud strategy provides a structured way to incorporate cloud services into the IT mix. It helps make sure that all stakeholders have a say in how, when, and where cloud adoption occurs. It can also offer advantages that you may not have considered. Below are some of the typical benefits (source: NetApp research).

  • Maximise the business benefits of the cloud. cutting costs, improving efficiency, increasing agility, and so on—and those benefits increase when there is a clear cloud strategy in place.
  • Uncover business benefits you might otherwise miss. One frequently overlooked advantage of the cloud is the ability to accelerate innovation. By moving certain functions to the cloud, IT can speed up the process of building, testing, and refining new applications—so teams can explore more ideas, see what works and what doesn’t, and get innovative products and services to market faster.
  • Prepare the infrastructure you’ll need. A well-thought-out cloud strategy provides an opportunity to consider some of the infrastructure needs of the cloud model up front rather than as an afterthought.
  • Retain control in an era of on-demand cloud services. An enterprise-wide cloud strategy can help your business maintain control of how cloud services are purchased and used so that enterprise governance policies and standards can be managed and enforced.

How to avoid a cloud strategy that fails

  • It’s a way to save money: The danger here is that cloud computing is not always cheaper. Services that can be effectively outsourced to “the cloud” to save money are often highly standardised commodity services that have varied demand for infrastructure over time. Cloud computing can save money, but only for the right services.
  • It’s a way to renovate enterprise IT: Not everything requires speed of deployment, or rapid scaling up or down. Some services require significant and unique enterprise differentiation and customisation.
  • It’s a way to innovate and experiment: Cloud computing makes it extremely easy to get started and to pilot new services. The challenge for enterprises is to enable innovation and experimentation, but to have a feasible path from pilots to production, and operational industrialisation.


In summary, cloud computing does not have a single value proposition for all enterprises and all services.

Recommendation: A cloud computing strategy should include these three approaches,

  1. Define a high-level business case
  2. Define core requirements
  3. Define core technology

and organisations must probe where they can benefit from cloud in various ways.

This will help drive enterprise IT to a new core competency, away from solely being a provider of services, and toward being both a provider and a broker of services delivered in a variety of ways for a variety of business values (Hybrid IT)

Sample cloud decision framework

simple decision framework- cloud.jpg


Make you cloud strategy a Business Priority. The benefits are real, but don’t make your move to the cloud until you’ve made a serious commitment to creating an enterprise-wide cloud strategy. The time you take to formalise your strategy will pay off in higher cost savings, better efficiency, more agility, and higher levels of innovation.

Research shows that companies with an enterprise-wide cloud strategy are far more successful at using the cloud to reduce costs, improve efficiency, and increase business agility than companies without such a strategy.

I hope you find the above information is useful.

IT Service Management (ITSM) & Operations – Overview of the Availability Management Process


In many cases ITSM Availability Management Process is overlooked due to other frontline processes such as incident, problem and change management. I have provided a summary of this availability management process and significance below. I hope that the information is useful for your organisation in order to define and implement the process.


  • Availability management has to ensure that the delivered availability levels for all services comply with or exceed the agreed requirements in a cost-effective way and enables the business to satisfy its objectives.
  • Provide a range of IT Availability reporting to ensure that agreed levels of Availability, reliability and maintainability are measured and monitored on an ongoing basis.
  • Create and maintain a forward looking Availability Plan aimed at improving the overall Availability of IT Services and Infrastructure components to ensure existing and future business Availability requirements can be satisfied.


  • Designing, implementing, measuring, managing and improving IT services and the components that are used to provide them.
  • Services and processes:
  • Business processes
  • Future business plans and requirements
  • Service objectives, current Service Operation and delivery
  • IT infrastructure, data, applications and the environment
  • Priorities of the business in relation to the services

Industry Good Practice for this Process

Avialability mgt process.jpg

Availability management is part of service design and it is one of the critical process because the reliability of a service or component indicates how long it can perform its agreed function without interruption.

Activities – Reactive (Executed in the operational phase of the lifecycle)

  • Monitoring, measuring, analysing and reporting availability of services and components
  • Unavailability analysis
  • Expanded lifecycle of the incidents
  • Service Failure Analysis (SFA)

Activities – Proactive (Executed in the design phase of the lifecycle)

  • Identifying Vital Business Functions (VBFs)
  • Designing for availability
  • Component Failure Impact Analysis (CFIA)
  • Single Point of Failure (SPOF) analysis
  • Fault Tree Analysis (FTA)
  • Risk Analysis and Management
  • Availability Test Schemes
  • Planned and preventive maintenance
  • Production of Projected Service Availability (PSA document
  • Continuous reviewing and improvement



  • Business information, organisation strategy, financial information and plans
  • Current and future requirements of IT services
  • Risk analysis
  • Business impact analysis
  • Service portfolio and service catalogue from service level management process
  • Change calendars and release management information


  • Availability management information systems (AMIS)
  • Availability plan
  • Availability and restore criteria
  • Reports on the availability, reliability and maintainability of services


In summary, ITSM Availability Management measures three important aspects: how long a service can perform without interruption (Reliability), how quickly a service can be restored when it has failed (Maintainability) and how effectively a third party supplier deliver their services (Serviceability). These three aspects are key performance measures in ITSM availability management. Availability Management has to be discussed at the design phase of IT Service Management. Hope you found the above information useful. Thanks

IaaS Application Migration – Go Live Decision Responsibility Model, High Level Run Sheet and Change Management Life Cycle

Go Live Decision Responsibility Model

A go-live decision model helps to assign accountability to key project stakeholders in order to make decision to proceed with go-live on an agreed date or not. Below is an example responsibility model that will guide to create a required decision responsibility model.


High Level Run Sheet

run sheet is a list of procedures or events organised in progressive sequence to execute the required agreed outcome. Below sheet is an example that can be used as part of application migration to cloud.

run sheet.jpg

Change Management Life Cycle

The objective of change management in this context is to ensure that standardised methods and procedures are used for efficient and prompt handling of all changes to control IT infrastructure, in order to minimise the number and impact of any related incidents upon service (ITSM Best Practice).

In this context, below is a simple change management practice model that can be used to control all changes to IT infrastructure in an IaaS application migration.

change mgt.jpg


Hope you found these examples useful for your application migration to assist and complete transition.


IaaS Application Migration – Governance, Escalation & Warranty Period Model

What is Governance and Escalation Model – IaaS Application Migration Project

A governance model is the mechanism used by the project management to translate the elements of the governance framework and policies into practices, procedures, and job responsibilities within the boundary of the project. An escalation plan is a set of procedures set in place to deal with potential problems in a variety of contexts. Example: Project team need to reach out a key stakeholder in the program to make a decision of a go-live/roll-back.

Why Governance and Escalation Model is important

  • To understand clear direction
  • To make key decisions
  • Clear roles and responsibilities
  • Stakeholder visibility and assistance
  • Escalation path is defined to assist
  • Budget tracking
  • To track the delivery of project

IaaS Application Migration Project Governance Model

Below is an example of a governance model.

iaaS Gov.jpg

Application Migration – Escalation Matrix

Below is an example of an escalation matrix, which is helpful to escalate from those 3 levels when required.

IaaS - Escalation matrix.jpg

Application Migration – Incident Management Process

Typically, the IaaS project will use the existing incident management process but will provide project support assistance if required to resolve an incident related to new migration or roll-back. These activities occur during post go-live warranty periods or when an application is rolled back but caused an incident.

IM process.jpg

Application Migration – Telephone Conference Details

It is important to provide telco details to jump on conference calls. These are for technical and non-technical management and resolution activities.


Warranty Period – Definition


  • Provision of IaaS project resources to provide assistance to the BAU teams, in the event that incidents require support and or resolution for an agreed period of time. By definition BAU teams can constitute application teams, vendor A and vendor B infrastructure teams.
  • A warranty entails an obligation to eliminate any defects in the operation of a product directly related to production workloads and as a result of project activity. During the warranty period the project must fix all defects within the agreed time limit, provided that the following conditions are met:
    • evidence of system issue(s) is given;
    • agreement that the issue occurred due to a project activity;
    • no unwarranted interference with the migrated application;
    • application feature is covered in the requirements.

Application Migration – Warranty Support Activities

Typical warranty period activities can be,

  • Warranty support from project will be provided at least minimum of 14 days of application being successfully migrated or the period agreed by steering committee / IT owners.
  • Project team will update Service Desk with newly migrated application details prior and post application being migrated.
  • Project team will be available from 8am post migration day, to provide support if required, including to participate in warranty meetings.
  • Project team will assist to resolve migration related incidents during the agreed warranty period.
  • Project incident queue will be created via <TOOL> to direct required project support to incidents. These incidents will be clearly tagged by BAU team to separate from other BAU incidents to assist IT scorecard.
  • TOOL group needs to be monitored after a cutover during warranty period.
  • Existing incident management and major incident management process will be followed, project team will be notified by BAU team to participate if required.
  • A change freeze period is agreed before and after migration with application owners.
  • If significant changes are expected to resolve an incident due to project activity, the effort/Charges will be absorbed by the project team.
  • If required, project team will participate in the Daily Operational Forum.
  • Go/No Go – at agreed point of no return after successful cutover and during warranty period, rollback/fix forward will be performed if pending issues. Final decision maker will be the sponsor, while the contributors are Project, Service Delivery Team and IT owners.


Go/No Go – Decision 2 (During Warranty Period) – Criteria for Consideration – Rollback/Fix Forward


Exit Criteria – Warranty Period

Example of exit criteria’s when we exist warranty,

  • All critical issues have been resolved.
  • All project related incidents have been updated/resolved.
  • All necessary and required knowledge and documentation have been updated.
  • Evidence of testing details available from testing tool.
  • IT Owners sign-off obtained.
  • BAU acceptance obtained for migrated applications from organisation’s SDM


I hope that above examples are useful to your project to create an effective governance, escalation and warranty period model. Thanks.

IaaS Application Migration Principles and Process – Consideration

What is IaaS Application Migration

Application migration is the process of moving an application program or set of applications from one environment to another. This includes migration from an on-premises enterprise server to a cloud provider’s environment or from one cloud environment to another. In this example, Infrastructure as a Service (IaaS) application migration.

It is important to consider some migration principles to guide your application migration that will allow to complete your transition successfully. At the same time, having too many principles can impact the overall delivery of the transition. Having a right balance is important. Hopefully, the below example principles will help to structure and customise your organisation’s application migration principles.

Application Migration Principles

apps migration principles

Server Migration Principles

Apps server migration principles

Database Migration Principles

Database migratyion principls.jpg

Testing Principles

Testing principles.jpg

Application Migration ProcessApps migration

Application Migration Process – High Level Process Flow

apps migration process flow.jpg


I Hope you found these useful. These are examples and varies that are according to organisational strategy, priorities and internal processes.



IaaS – Application Migration Management Tracker

What is IaaS Application Migration

Application migration is the process of moving an application program or set of applications from one environment to another. This includes migration from an on-premises enterprise server to a cloud provider’s environment or from one cloud environment to another. In this example, Infrastructure as a Service (IaaS) application migration.

Application Migration Management Tracker

Having a visual IaaS application migration tracker, helps to clearly identify all dependencies and blockers to manage your end to end migration tracking. In addition to the project plan, this artefact will help to manage daily stand-ups and accurate weekly status reporting.


  • Clear visibility of current status
  • Ownerships/accountability
  • Assist escalation
  • Clear overall status
  • Lead time to CAB and preparation times
  • Allows time to agree and test key firewall/network configurations
  • Assist go/no-go decisions
  • Cutover communications
  • All dependencies
  • Warranty period tracking
  • BAU sign-off
  • Decommission of old systems if required

When to use and why?

  • Daily stand-ups
  • Go-no go meetings to take clear next steps and accountability
  • Risks and issues preparation and mitigation steps
  • During change advisory board (CAB) meeting to provide accurate report to obtain approval to implement
  • Traceability to tick and progress BAU activities and preparation of operational support activities

Application Migration Approach

Apps migration.jpg

Example of IaaS Application Migration Tracker

Below is an example which may assist your application migration tracking in detail.

  • Application list
  • Quarterly timelines
  • Clear ownerships
  • Migration tracking sub tasks
  • Warranty tracking sub tasks
  • Current status
  • Final status

IaaS - Application Migration Tracker - Example

IaaS Application Migration Tracker


Hope this example helps but it can be customised as per organisational processes and priorities. This tracker can also be used on non-complex applications and complex application migration. Thanks.

IT Service Management (ITSM) – Continual Service Improvement (CSI)Process and Approach

Continual Service Improvement (CSI) Process

To define specific initiatives aimed at improving services and processes, based on the results of service reviews and process evaluations. The resulting initiatives are either internal initiatives pursued by the service provider on his own behalf, or initiatives which require the customer’s cooperation. (from ITIL).

Continual Service Improvement (CSI) Purpose, Goals and Objectives

  • Continually align IT services to changing business needs
  • Identify and implement improvements throughout the service life cycle
  • Determine what to measure, why to measure it and define successful outcomes
  • Implement processes with clearly defined goals, objectives and measures
  • Review service level achievement results
  • Ensure quality management methods are used


Continual Service Improvement (CSI) Values

  • Enables continuous monitoring and feedback through all life cycle stages
  • Sets targets for improvement
  • Calculates Return on Investment (ROI)
  • Calculates Value on Investment (VOI)

Business Value of Measurement

Consider the following factors when measuring process or service efficiency.

CSI 1.jpg

  • Why are we monitoring and measuring?
  • When do we stop?
  • Is anyone Is using the data?
  • Do we still need this?

Metric Types

  • Service metrics
  • Technology metrics
  • Process metrics

Continual Service Improvement(CSI) Supporting Models and Processes

  1. Plan-DO-Check-ACT (PDCA) Model
  2. 7-Step Improvement Process
  3. Continual Service Improvement Model

1. Plan-Do-Check-Act (PDCA) Model

PDCA 2.jpg

2. 7-Step Improvement Process

CSi 7 step process.jpg

3. Continual Service Improvement Model

CSI model.jpg

Key Takeaways

  1. Once you have implemented a new process, tool or an event – Plan for improvement. As the end users will expecting the next levels of service
  2. Obtain feedback from end users, always encourage them to do so.
  3. Plan it, Do it (Implement), Check it (assess, metrics) and act (take actions to align or rectify)
  4. Always look to improve you service, through benefit, cost, risk and strategy


Hope you found it useful to implement your CSI journey.

Cloud Operations – Key Service Operation Principles – Consideration

Below are some good IT Service Management Operational Principles to consider when migrating applications into Cloud.  These will help to align your operational goals and organisation’s strategic initiatives.

Principle #1

Organisation’s IT Service Management will govern and lead all IT services utilising strategic processes and technology enablers based on industry best practices.

Implications / Outcomes

  • The selected process and technology will be fit for purpose
  • Suppliers and Service Partners will be required to integrate with strategic processes and technologies
  • Process re-engineering including training will be required
  • Everyone uses or integrates with a central platform
  • Process efficiency through effective process integration
  • Reduced operating cost
  • Ensures contestability of services for Organisation

Principle #2

Contestability between IT Service providers is a key outcome for service management across IT@Organisation, where it does not have a negative impact on the customer experience.

Implications / Outcomes

  • Avoid vendor lock-in
  • Requires strategic platforms
  • Sometimes greater complexity
  • More ownership of process by Organisation
  • Better cost outcomes through competition
  • Improved performance, incumbent advantage is earned
  • Access to innovation
  • Access to capacity

Principle #3

The Organisation’s IT operating model will be based on the principles of Customer-centricity (Organisation’s business and IT), consistency and quality of service and continual improvement of process maturity.

Implications / Outcomes

  • More extensive process integration
  • Possible constraints – cost, time, resources, agility
  • Additional internal expertise
  • Governance as a focal point
  • Continual improvement
  • Improved process alignment with business alignment
  • Quantitative, demonstrable benefits
  • Improved customer satisfaction

Principle #4

Organisation will retain and own all IP for Organisation’s Service Management knowledge assets and processes.

Implications / Outcomes

  • Strong asset, capacity, knowledge management
  • Service provider governance
  • Improved internal capability
  • Service provider independence
  • Reduced risk
  • Exploitation of skills and experience gained
  • Encourage self-healing culture

Principle #5

Changes to existing Organisation processes and procedures will only be made where those changes are necessary to deliver benefits from the Cloud platform.

Implications / Outcomes

  • Vendors adapt to Organisation’s processes
  • Existing process needs to be critically assessed
  • Reduced exposure to risk
  • Reduced levels of disruption
  • Faster adoption of new processes through familiarity
  • Faster Implementation due to less change

Principle #6

Before beginning process design, ownership of the process and its outcomes, resource availability, cost benefit analysis and performance measurements will be defined and agreed.

Implications / Outcomes

  • Ownership of process is known
  • The process is appropriately resourced
  • Alignment of activities with desired outcomes
  • Improved process effectiveness
  • Reduced risk of failure
  • Resourcing cost



Please note that there will be practical implications to organisation’s service management processes (typically – incident management, problem management, capacity management, service restoration, change management, configuration management and release management). Also these are some of the good principles to consider and can be customised as per organisational strategy and priorities.


IT Service Management (ITSM) – Process Maturity Evaluation

ITSM Process Maturity Evaluation

Why are we doing this?

It is useful to measure Service Management process maturity for a number of reasons:

  • To understand the strengths and weaknesses of existing processes.
  • As a guide to planning continual process improvement.
  • As a mechanism to measure the impact of process improvement activities.

What is it?

The Process Maturity Evaluation is a method of assessing the current state of Service Management processes and procedures, it needs to:

  • Have the right balance between detail and effort.
  • Be flexible enough to be applied to any Service Management Process.
  • Capture input from all stakeholders, not just Service Management.
  • Deliver actionable information to drive improvement.
  • Can be used to drive Continual Service Improvement.

How does it work?

  • Using a set of standard process maturity questions, we assess the current state of each process/procedure, evaluating 9 aspects of maturity (typically these are pre-requirements, management intent, process capability, internal integration, products, quality control, management information, external integration and customer interface. These may vary depending on organisation types and priorities), grading on a scale from 0-5.
  • Based on this we then identify and execute a process improvement plan to address the maturity issues that we have identified.
  • Using the same approach, we re-evaluate process maturity to measure the improvement achieved and to identify the next cycle of improvement.

Process Maturity Evaluation Cycle

process maturity cycle.jpg

Sample Process Maturity Questions and Model

process questions example

Sample Process Maturity Evaluation Results (Visuals)

process maturity example.jpg


ITSM process maturity questions can vary depending on organisation types and priorities and also the baseline questions can be changed to track improvements based in initial scores. Hope you found this useful.


Standard Operational Checks for IT Service Management Processes – Once Implemented

Why Operational Process Checks are Required in Service Management?

  • In order to sustain and measure how effectively we are executing our processes, we require to have process operational checks once implemented.
  • This will allow us to identify inefficiencies and subsequently to improve the current Service Management processes.
  • These checks will also provide input into Continual Service Improvement (CSI) Programme.


Operational Checks for Service Management Processes – Once Implemented

Ops checks SM.jpg

Standard Guidelines

  • The operational process checks will be managed by IT Service Management
  • Through process governance meetings, agreement can be established on who will update a section of a process or the whole document.
  • IT Service Management will need to be involved in all process governance meetings.
  • IT Service Management will conduct an internal audit on all Service Management processes at least once annually.

Review and Measure at Regular Intervals

It is very important that IT Service Management reviews all processes and measurements at least once every year to make appropriate changes to obtain their target IT and business goals.



Thank you……..