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

Summary

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.

Benefits

  • 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

Summary

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.png

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

Summary

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

 

Summary

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

Summary

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.

checklist.jpg

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.

 taylor.jpg

 

Thank you……..

Major Incident Management – Inputs and Outputs

Definition

A major incident is an incident that results in significant disruption to the business and demands a response beyond the routine incident management process.

The Major Incident Management Process applies globally to all Customers and includes Incidents resulting in a service outage.  This process is triggered by Incidents directly raised by Users or via referral from the Event Management Process, which are classified as Major Incidents in the Incident Management Process by the Service Desk.

Entry Criteria

Major Incident Management Process commences when an Incident has been identified and recorded as a Major Incident in the Incident Management Tool by the Service Desk.

Inputs

The inputs to the Major Incident Management Process include:

  • Incidents identified as Major Incident from the Incident Management Process raised directly by Users or generated via referral from the Event Management Process.
  • Knowledge Management Database (known errors/ existing resolutions/ accepted workarounds)
  • Details of impacted Configuration Items (CIs) from Configuration Management Database (CMDB)
  • Major Incident Assignment Scripts & Organisational Major Incident Communication Process

Exit Criteria

The Major Incident Management Process is complete when:

  • Major Incident is resolved or self-resolved and the Incident record is closed with a workaround/permanent resolution. In case of a workaround a Problem record will be raised for Root Cause Analysis and permanent resolution.
  • Incident is downgraded and routed to the Incident Management Process for resolution.

Outputs

The expected outputs from the Major Incident Management Process are:

  • Successfully implemented Change through the Change Management Process.
  • Problem record raised in Problem Management tool for Root Cause Analysis (RCA).
  • Priority downgraded Incident routed to Incident Management Process for resolution.
  • Restored Service.
  • Updated Knowledge Base/Known Error Database.
  • Closed Incident record with accurate details of the Incident attributes and the steps taken for resolution.
  • Notification through various channels (email, call etc.) on the initiation, resolution process and closure of Major Incident to various stakeholders.
  • Updated Daily Operation Report.
  • Accurately recorded service and/or component outage details (e.g. start, end, duration, outage classification, etc.).

Key Activities

  • Major Incident identified from Incident Management Process
  • Assign Incident to Incident Resolver Team
  • Notify Resolver & Organisational Incident Management Teams
  • Service Restoration
  • Notifications and Communications
  • Conduct Investigation & Diagnosis
  • Resolution
  • SME inputs
  • Develop Resolution/Workaround
  • Resolution Type (Permanent)
  • Root Cause Analysis
  • Change Record
  • Confirmation of Status of Incident
  • Daily Operations Update
  • Closure of Incident

Summary

It is very important to establish a Major Incident Management Process in conjunction with Incident Management, Problem Management, Change Management and Communication Management processes. A key process in ITSM to restore service in the event of a major incident.

Cloud Operations Model and Project Stream – Considerations

Background

Cloud operations stream is responsible for designing and operation of the cloud model for the project and BAU activities. This stream is primarily responsible for people, process, tools and information. The model can change as the organisation’s requirements and type of business.  

Aspects Cloud Operations Model

Below is an example of key aspects that we need to consider when defining Cloud Operations Model.

aspects 2.jpg

Cloud Operations Stream  – High Level Approach

Below is an example model for how to track a cloud program operationally.

track ops cloud.jpg

Cloud Operations Stream – Governance

Below is an example model for cloud operations stream governance, which can be used to guide the operations stream.

Cloud ops Gov.jpg

Summary 

Hope you found some of these aspects and considerations mentioned above is useful. Thanks

ITSM – Service Catalogue – Summary

Definition

  • The Service Catalogue represents a trusted record of the services provided by Information Technology (IT), its default capabilities, measures and primary means of access and provision.
  • It is the means by which we articulate WHAT we manage and measure. It is the hidden power of how we set the customer’s expectations and exceed them.
  • It can provide an essential medium for communication and coordination among IT and its customers, and should distinguish between Business Customers (the ones paying for the service) and End Users (the recipient of the service).
  • If CMDB is the system of record for what IT did, then the Service Catalogue becomes the system of records for what IT does.
  • ITIL recommends the development of a Service Catalogue as the first step in the Service Level Management (SEM) process.

Why Service Catalogue is Required?

Show the value of Information Technology (IT)

  • For IT to be fully successful, IT needs to be strategically aligned to the business and positioned as a key enabler in achieving successful outcomes for the organisation.
  • It is not enough for IT alone to consider itself successful at what it does. IT needs to provide real value to the organisation that directly achieves business outcomes that the organisation wants to achieve and should be able to deal with the ever changing needs and demands of the organisations and their customers.
  • IT should also be capable of demonstrating how it provides business value to the organisation to ensure that IT is positioned within the organisation as a core strategic asset.

To support the above, it will be good for IT to develop a Service Catalogue that defines the scope, characteristics and costs of available services and products, and allows for better management of the IT environment as a whole.

The basic requirement to do all this is to have a clear definition of the services the IT organisation provides, the components and resources that make up the service, and the associated costs for these services.

SC image 1.jpg

Why Service Catalogue is Important?

SC2.jpg

Service Catalogue Types and Recommended Construction Approach

The two types of Service Catalogues are records based and actionable based.

SC3.jpg

Characteristics of Different Views

SC4.jpg

Attributes of a Service Catalogue

An effective Service Catalogue should be:

  • Constitutive – what IT does and does not, and on what terms.
  • Actionable – provides the means by which IT and its customers coordinate and conduct business.
  • Governing – conditions and controls defined in the Service Catalogue are integrated into the service delivery processes.

An ideal Service Catalogue should have the following six attributes:

  1. User-Relevant Services – A Catalogue that users understand
  2. Accessible Service Description – Speaking the customer’s language
  3. Objective Performance Accountability Metrics – Setting clear performance goals
  4. Actionable Pricing Information – Helping customers understand their costs
  5. Consumption Management Tips – Not all costs are created equal
  6. Adoption Facilitation Mechanisms – Reading like a best seller

Service Catalogue – Format

  • Service Catalogue can be a simple list in Word or Excel document, or as comprehensive as installing specific tools designed to create formal Service Catalogues.
  • The catalogue should contain items that are visible to customer, and additional information that used by service delivery team to ensure smooth delivery. Items visible to customer include:
    • A description of the service
    • Disclosure of any perquisites or required services
    • Approval levels

sc5.jpg

Service Catalogue – Links to the Different Elements within IT Service Lifecycle

sc6.jpg

Tips & Challenges with Implementing a Service Catalogue

sc7.jpg

Recommended Implementation  Approach

Phase One – Build foundation

  • Start with simple
  • List all Service Management services containing key attributes and in customer perspective
  • Availability of Service Catalogue via selected media

Phase Two – Deploy

  • Detailed and comprehensive
  • Expand attributes to the most popular Service Management services in customer perspective
  • Service Catalogue document control
  • Marketing – Service Catalogue

Phase Three – BAU

  • Review, improve and expand Service Catalogue

 

Hope you found these useful.

Proactive Problem Management – Benefits and Considerations

IT Service Management – Proactive Problem Management

The goal of Proactive Problem Management is to prevent Incidents by identifying weaknesses in the IT infrastructure and applications, before any issues have been instigated.

Benefits

PPM.jpg

  • Greater system stability – This leads to increased user satisfaction.
  • Increased user productivity – This adds to a sizable productivity gain across the enterprise.
  • Positive customer feedback – When we proactively approach users who have been experiencing issues and offer to fix their problems the feedback will be positive.
  • Improved security – When we reduce security incidents, this leads to increased enterprise security.
  • To improve quality of software/product – The data we collect will be used to improve the quality.
  • To Reduce volume of problems – Lower the ratio of immediate (Reactive) support efforts against planned support efforts in overall Problem Management process.

Considerations

  • Proactive Problem Management can be made easier by the use of a Network Monitoring System.
  • Proactive Problem Management is also involved with getting information out to your customers to allow them to solve issues without the need to log an Incident with the Service Desk.
    • This would be achieved by the establishment of a searchable Knowledgebase of resolved Incidents, available to your customers over the intranet or internet, or the provision of a useable Frequently Asked Question page that is easily accessible from the home page of the Intranet, or emailed regularly.
  • Many organisations are performing Reactive Problem Management; very few are successfully undertaking the proactive part of the process simply because of the difficulties involved in implementation.
    • Proactive Problem Management to Business Value
    • Cost involved with Proactive vs. Reactive Problem Management
    • Establishment of other ITIL processes such as configuration Management, Availability Management and Capacity Management.

 

Proactive Problem Management – FAQ

Q – At what stage of our ITIL process implementation should we look at Implementing Proactive Problem Management?

  • A – Proactive Problem Management cannot be contemplated until you have Configuration Management, Availability Management and Capacity Management well established as the outputs of these processes will give you the information that is required to pinpoint weaknesses in the IT infrastructure that may cause future Incidents.

Q – How can we performance measure and manage?

  • A – Moving from reactive to proactive maintenance management requires time, money, human resources, as well as initial and continued support from management. Before improving a process, it is necessary to define the improvement. That definition will lead to the identification of a measurement, or metric. Instead of intuitive expectations of benefits, tangible and objective performance facts are needed. Therefore, the selection of appropriate metrics is an essential starting point for process improvement.

 

Proactive Problem Management – High Level Process Diagram

PPMP1.jpg

Summary

Implementing proactive problem management will require an agreed uniform approach specially when multiple managed service providers (MSPs) involved with an organisation. Hope you found this useful.