Difference between revisions of "Transition into Operation"

From EITBOK
Jump to: navigation, search
(Created page with "<h2>Introduction</h2> <p>Transition consists of a set of processes and activities that release new solutions into an EIT environment, replace or update existing solutions, rem...")
 
Line 11: Line 11:
 
<li>Effectively handoff new solutions to operations at the completion of the transition.</li>
 
<li>Effectively handoff new solutions to operations at the completion of the transition.</li>
 
</ul>
 
</ul>
<p>'''Figure 1. Context Diagram for Transition'''</p>
+
<p>'''Figure 1. Context Diagram for Transition''' ***add figure</p>
 
<h2>Transition and Retirement Activities</h2>
 
<h2>Transition and Retirement Activities</h2>
 
<p>The transition activities can be subdivided into three sets of activities: ''plan'', ''execute'', and ''hand-off''. Each of these phases contains a sequence of tasks that involve strategic, decision, and support groups as shown in the figure below.</p>
 
<p>The transition activities can be subdivided into three sets of activities: ''plan'', ''execute'', and ''hand-off''. Each of these phases contains a sequence of tasks that involve strategic, decision, and support groups as shown in the figure below.</p>
<div id="figure_flowchart"></div><p>'''Figure 2. Transition Flowchart Diagram'''</p>
+
<div id="figure_flowchart"></div><p>'''Figure 2. Transition Flowchart Diagram''' ***add figure</p>
 
<ul>
 
<ul>
 
<li>'''Plan''' &mdash; In this phase, the transition team becomes familiar with the requirements and technical design of the solution or retirement. The team then creates detailed plans for the project that allow the transition to occur without negatively affecting the business. The team also evaluates the risks and impacts of the solution, and identifies mitigation techniques to handle any negative impacts.</li>
 
<li>'''Plan''' &mdash; In this phase, the transition team becomes familiar with the requirements and technical design of the solution or retirement. The team then creates detailed plans for the project that allow the transition to occur without negatively affecting the business. The team also evaluates the risks and impacts of the solution, and identifies mitigation techniques to handle any negative impacts.</li>
Line 23: Line 23:
 
<h2>Planning the Transition Project</h2>
 
<h2>Planning the Transition Project</h2>
 
<p>The transition project starts with a management decision based on the organizations priorities and goals, established during strategic planning (see [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance]). This decision includes the scope of the project, resources, technology, budget, and expected outcomes that are often determined as part of a change initiative (see [http://eitbokwiki.org/Change_Initiatives Change Initiatives]). Thus, transition planning is done in parallel with solution acquisition and construction activities.</p>
 
<p>The transition project starts with a management decision based on the organizations priorities and goals, established during strategic planning (see [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance]). This decision includes the scope of the project, resources, technology, budget, and expected outcomes that are often determined as part of a change initiative (see [http://eitbokwiki.org/Change_Initiatives Change Initiatives]). Thus, transition planning is done in parallel with solution acquisition and construction activities.</p>
<ul>
 
 
<p>The transition planning team focuses on a number of activities, including: </p>
 
<p>The transition planning team focuses on a number of activities, including: </p>
<li>Understanding the business and technical requirements for the solution</li>
+
<ul><li>Understanding the business and technical requirements for the solution</li>
 
<li>Analyzing the business and technical requirements for the transition</li>
 
<li>Analyzing the business and technical requirements for the transition</li>
 
<li>Assessing the business and technical risks of altering the operations environment, and coming up with ways to mitigate those risks</li>
 
<li>Assessing the business and technical risks of altering the operations environment, and coming up with ways to mitigate those risks</li>
Line 47: Line 46:
 
<p>The two teams work together to deploy an integrated a functional EIT solution and hand it over to the teams in charge of operations. If maintenance activities are required, the configuration management team hands over the sources for alteration (see [http://eitbokwiki.org/Construction Construction] ***correct link?).</p>
 
<p>The two teams work together to deploy an integrated a functional EIT solution and hand it over to the teams in charge of operations. If maintenance activities are required, the configuration management team hands over the sources for alteration (see [http://eitbokwiki.org/Construction Construction] ***correct link?).</p>
 
<p>A description of each layer and the involved activities help explain why the layered approach is often used:</p>
 
<p>A description of each layer and the involved activities help explain why the layered approach is often used:</p>
 +
<ul>
 
<li>A '''business layer''' change impacts the whole or a key part of the organization. Opening a new branch office outside the country implies a business decision that involves many different unit areas, such as finance, marketing, legal, HR, and, of course, EIT. All the areas need to coordinate with a single focus, which is owned by management. A business layer transition automatically cascades to the layers below, generating different transitions projects (such as application, data, and infrastructure), creating a program management effort coordinating several projects rather than a simple project <br />Business transition changes are typically governed by a change advisory board (CAB) that consists of senior management, enterprise architects, and project managers. The project management members participate during strategic discussions, providing input on project management best practices, and information learned from previous projects. All this work impacts the rest of the layers, because a single business decision usually cascades to affect many business units.
 
<li>A '''business layer''' change impacts the whole or a key part of the organization. Opening a new branch office outside the country implies a business decision that involves many different unit areas, such as finance, marketing, legal, HR, and, of course, EIT. All the areas need to coordinate with a single focus, which is owned by management. A business layer transition automatically cascades to the layers below, generating different transitions projects (such as application, data, and infrastructure), creating a program management effort coordinating several projects rather than a simple project <br />Business transition changes are typically governed by a change advisory board (CAB) that consists of senior management, enterprise architects, and project managers. The project management members participate during strategic discussions, providing input on project management best practices, and information learned from previous projects. All this work impacts the rest of the layers, because a single business decision usually cascades to affect many business units.
 
<li>'''Data & information layer''' changes impact enterprise data and information assets. These transitions involve projects including those that modify databases, data structures, SQL programming and stored procedures to be released and deployed into production. A data transition project can impact business applications, which require code updates or database configuration changes to establish the connection between the applications and the data. As a result, these projects are often overseen by the same group that oversees the business layer modifications. Note that all data and Information transitions must adhere to data management and data governance guidelines.</li>
 
<li>'''Data & information layer''' changes impact enterprise data and information assets. These transitions involve projects including those that modify databases, data structures, SQL programming and stored procedures to be released and deployed into production. A data transition project can impact business applications, which require code updates or database configuration changes to establish the connection between the applications and the data. As a result, these projects are often overseen by the same group that oversees the business layer modifications. Note that all data and Information transitions must adhere to data management and data governance guidelines.</li>
<li>Changes to the '''software application layer'' can impact all software applications, programs, and database platforms. The release or retirement of an application can involve the coordination of several teams including web designers and data programmers in charge of connecting the applications with live databases. <br />The application layer team needs to have a members with the technical skills required to release, refresh, and update live software platforms. </li>
+
<li>Changes to the '''software application layer''' can impact all software applications, programs, and database platforms. The release or retirement of an application can involve the coordination of several teams including web designers and data programmers in charge of connecting the applications with live databases. <br />The application layer team needs to have a members with the technical skills required to release, refresh, and update live software platforms. </li>
 
<li>Changes to the '''EIT infrastructure layer''' affect infrastructure facilities, such as data centers and computer rooms. They involve the installation, refresh, and decommissioning of hardware including mainframes, servers, cabling, storage, security, and telecommunication components. The EIT infrastructure transition team incorporates network and hardware experts with the infrastructure skills required for planning, configuring, and setting up the EIT infrastructure architecture solution. <br />For this layer, the infrastructure team formulates architectural models of the modified Infrastructure to understand how best to integrate new hardware components or remove old ones. The team looks to standardize network topologies, to upgrade hardware components, and to monitor, configure, and support best practices. Coordination with server, database, storage and backup and security teams is typically required. The team might also run vulnerability tests on components and set up security procedures to be in compliance with corporate policies and procedures. </li>
 
<li>Changes to the '''EIT infrastructure layer''' affect infrastructure facilities, such as data centers and computer rooms. They involve the installation, refresh, and decommissioning of hardware including mainframes, servers, cabling, storage, security, and telecommunication components. The EIT infrastructure transition team incorporates network and hardware experts with the infrastructure skills required for planning, configuring, and setting up the EIT infrastructure architecture solution. <br />For this layer, the infrastructure team formulates architectural models of the modified Infrastructure to understand how best to integrate new hardware components or remove old ones. The team looks to standardize network topologies, to upgrade hardware components, and to monitor, configure, and support best practices. Coordination with server, database, storage and backup and security teams is typically required. The team might also run vulnerability tests on components and set up security procedures to be in compliance with corporate policies and procedures. </li>
 
</ul>
 
</ul>
Line 96: Line 96:
 
<p>Each company has its own method for evaluating the three subareas to enable the calculation of an overall risk evaluation. Some organizations rate each one of the risk areas from very low to very high risk, maybe on a 1-5 or 1-10 scale. An even number of risk levels is often used to avoid a value in the middle that doesn’t really give decision makers a positive or negative view of the risk. A “mid” value makes go/no-go decisions more difficult. </p>
 
<p>Each company has its own method for evaluating the three subareas to enable the calculation of an overall risk evaluation. Some organizations rate each one of the risk areas from very low to very high risk, maybe on a 1-5 or 1-10 scale. An even number of risk levels is often used to avoid a value in the middle that doesn’t really give decision makers a positive or negative view of the risk. A “mid” value makes go/no-go decisions more difficult. </p>
 
<p>The overall calculation is based upon guidelines that come from strategy and governance decisions. In the best of all situations, a simple equation can calculate the overall risk:</p>
 
<p>The overall calculation is based upon guidelines that come from strategy and governance decisions. In the best of all situations, a simple equation can calculate the overall risk:</p>
<p align="center">'''Total Project Risk Impact = BIA + TIA + CIE'''</p>
+
<p style="margin-left:30px">'''Total Project Risk Impact = BIA + TIA + CIE'''</p>
 
<p>Using this simple calculation facilitates the understanding, management, and prioritization of the transition queue in a straightforward way, and at same time, facilitates the decision-making. </p>
 
<p>Using this simple calculation facilitates the understanding, management, and prioritization of the transition queue in a straightforward way, and at same time, facilitates the decision-making. </p>
 
<p>In reality, the decision process is more difficult. The CAB team supporting the transition often holds a meeting to get clarifications and justification of the risks analysis reports from each stakeholder group. The decision authority often considers experiences from past transitions, team skills, and the corporate knowledge of what needs to be done for success. At the end, the CAB comes up with an overall rating for the project.</p>
 
<p>In reality, the decision process is more difficult. The CAB team supporting the transition often holds a meeting to get clarifications and justification of the risks analysis reports from each stakeholder group. The decision authority often considers experiences from past transitions, team skills, and the corporate knowledge of what needs to be done for success. At the end, the CAB comes up with an overall rating for the project.</p>
Line 170: Line 170:
 
<tr valign="top">
 
<tr valign="top">
 
<td style="background-color: #58ACFA;"><font color="white">'''Transition Level'''</font></td>
 
<td style="background-color: #58ACFA;"><font color="white">'''Transition Level'''</font></td>
<td style="background-color: #58ACFA;"><font color="white">'''Stakeholders''</font></td>
+
<td style="background-color: #58ACFA;"><font color="white">'''Stakeholders'''</font></td>
 
<td style="background-color: #58ACFA;"><font color="white">'''Resources'''</font></td></tr>
 
<td style="background-color: #58ACFA;"><font color="white">'''Resources'''</font></td></tr>
 
<tr valign="top">
 
<tr valign="top">

Revision as of 21:18, 4 November 2015

1 Introduction

Transition consists of a set of processes and activities that release new solutions into an EIT environment, replace or update existing solutions, remove a solution or component from service, or move EIT components from one location to another. Examples of transition include the installation of a new software application, migration of an existing hardware infrastructure into a new location, a refresh of key business applications with new software, or decommissioning a data center, hardware, or network devices.

Retirement is a special case of transition. It is the set of processes and activities associated with the removal, withdrawal, or decommissioning of solutions from an EIT environment. Although one might try to distinguish retirement activities from deployment activities, the two processes are extremely similar in many respects, although one adds to the EIT environment and one subtracts from it. In addition, deployment and retirement processes often go together in a single deployment project — the deployment (transition) of a new EIT solution into the environment as well as the retirement of an old EIT solution. Therefore, this chapter covers both deployment and retirement related activities under the term transition, pointing out the differences between the two project types when they occur.

To start a transition process, the EIT team creates a plan and submits it to the appropriate decision makers. The decision makers may ask a change advisory board to evaluate the proposed change for risk and unintended consequences, and advise the transition (change) manager of their findings and recommendations. When the decision body approves the plan, they fund the project in accordance with strategic guidelines and priorities. In addition, operations approves the schedule, carefully evaluating outage windows (time without service), the go-live dates, and the retirement dates. At the same time, the accounting and procurement teams evaluate the budget and approve the required purchases.

2 Goals and Principles

  • Effectively plan and manage the successful transition (release from development or acquisition functions, to deployment, relocation, replacement, removal, and decommissioning) of approved EIT solutions (products and services) without negatively impacting the live environment.
  • Ensure a common understanding of the organization’s handoff or retirement processes among affected organizations and stakeholders to ensure that involved participants can collaborate successfully.
  • Effectively assess the risk and impact of releasing, relocating, replacing, deploying, and decommissioning EIT solutions that combine software applications, utilities, hardware, and network components.
  • Plan, execute, and evaluate the results of pilot projects to allow for adjustment that can reduce the risk before the full solution rollout.
  • Effectively handoff new solutions to operations at the completion of the transition.

Figure 1. Context Diagram for Transition ***add figure

3 Transition and Retirement Activities

The transition activities can be subdivided into three sets of activities: plan, execute, and hand-off. Each of these phases contains a sequence of tasks that involve strategic, decision, and support groups as shown in the figure below.

Figure 2. Transition Flowchart Diagram ***add figure

  • Plan — In this phase, the transition team becomes familiar with the requirements and technical design of the solution or retirement. The team then creates detailed plans for the project that allow the transition to occur without negatively affecting the business. The team also evaluates the risks and impacts of the solution, and identifies mitigation techniques to handle any negative impacts.
  • Execute — In the second phase, the team executes the plan. All levels of the solution are deployed or retired, as specified, and appropriate personnel are trained. Typically there is a pilot of the project to test the solution in the eventual operations environment, identify any unforeseen issues, and refine the solution, as necessary. It is also common to have a phased rollout of the project that starts in one location or with one group of personnel, and then propagates throughout the organization.
  • Release — When the decision body feels that the solution is stable and ready for general release, the Transition team hands the solution over to operations, they announce the release to the appropriate audience, and they review the project and collect the lessons learned.

In the rest of this chapter, we describe these three phases in more detail.

4 Planning the Transition Project

The transition project starts with a management decision based on the organizations priorities and goals, established during strategic planning (see Strategy and Governance). This decision includes the scope of the project, resources, technology, budget, and expected outcomes that are often determined as part of a change initiative (see Change Initiatives). Thus, transition planning is done in parallel with solution acquisition and construction activities.

The transition planning team focuses on a number of activities, including:

  • Understanding the business and technical requirements for the solution
  • Analyzing the business and technical requirements for the transition
  • Assessing the business and technical risks of altering the operations environment, and coming up with ways to mitigate those risks
  • Elaborating solution transition strategy that allows the team to deploy, move, and the target solution to or extract target solution components from the operating environment without negatively impacting operations
  • Evaluating the training plan and adding components as deemed necessary
  • Creating a schedule for the transition activities
  • Creating a detailed plan document with all the pertinent information
  • Submitting the plan to the decision authority for authorization to start the project

4.1 Reviewing Business Goals and Requirements

By the time the EIT solution has progressed to this stage, the business and technical requirements should be well understood and documented. The goal of the transition team is to review the goals and requirements so that they can roll out the solution into the enterprise.

At times, the transition team needs clarification about the requirements the solution is meant to implement. That is why a change advisory board (CAB) comprised of stakeholders such as business owners, managers and PMO members are directly involved in the transition planning process. Enterprise architects, solution architects, program managers, and SMEs are also often asked to assist the team. They can help with the business and operational risks analysis activities, and they can explain the existing dependencies between products and services currently in operation as well as dependencies existing between components planned for the transition into the live environment.

If new hardware or software needs to be purchased from a vendor (see Acquisition and Construction), it is important to meet with these contractors to avoid conflicts with existing warranties, and to identify the proper steps and guidelines to protect the organization’s investment. Accounting and procurement teams sometimes are often involved to manage the relationship with the vendors. The operations group is another important participant in transition planning sessions, because they receive the solution in production and need to be ready to accept the responsibility when the solution is ready.

Any stakeholder or senior manager impacted (positively or negatively) should participate in the planning, answering questions, and clarifying any possible drawback of delays of the project, before going to submitting for approval.

4.2 Architecting the EIT Solution

The team analyzes and elaborates the technical approach so that it can be deployed successfully. This group augments the already existing design and technical notes to facilitate field technicians with configuring and setting up the components needed to release the ITC Solution into production, and retiring any components that need to be removed. This analysis occurs at several levels.

4.2.1 Transition Layers

Transition architecture, planning, and execution can be guided using the standard enterprise architecture (BIAT) layer model (see Enterprise Architecture). The figure below shows our adaptation of the diagram for this discussion.

Each layer typically has its own decision authorities and technical teams that work on the transition plan. For example, an infrastructure transition team might provide expertise on server clustering and virtual network (VLANs) architecture, switching, and routing. The application transition team might write code to interconnect business applications with existing databases.

Figure 3: Transition Layer Diagram ***add figure

The two teams work together to deploy an integrated a functional EIT solution and hand it over to the teams in charge of operations. If maintenance activities are required, the configuration management team hands over the sources for alteration (see Construction ***correct link?).

A description of each layer and the involved activities help explain why the layered approach is often used:

  • A business layer change impacts the whole or a key part of the organization. Opening a new branch office outside the country implies a business decision that involves many different unit areas, such as finance, marketing, legal, HR, and, of course, EIT. All the areas need to coordinate with a single focus, which is owned by management. A business layer transition automatically cascades to the layers below, generating different transitions projects (such as application, data, and infrastructure), creating a program management effort coordinating several projects rather than a simple project
    Business transition changes are typically governed by a change advisory board (CAB) that consists of senior management, enterprise architects, and project managers. The project management members participate during strategic discussions, providing input on project management best practices, and information learned from previous projects. All this work impacts the rest of the layers, because a single business decision usually cascades to affect many business units.
  • Data & information layer changes impact enterprise data and information assets. These transitions involve projects including those that modify databases, data structures, SQL programming and stored procedures to be released and deployed into production. A data transition project can impact business applications, which require code updates or database configuration changes to establish the connection between the applications and the data. As a result, these projects are often overseen by the same group that oversees the business layer modifications. Note that all data and Information transitions must adhere to data management and data governance guidelines.
  • Changes to the software application layer can impact all software applications, programs, and database platforms. The release or retirement of an application can involve the coordination of several teams including web designers and data programmers in charge of connecting the applications with live databases.
    The application layer team needs to have a members with the technical skills required to release, refresh, and update live software platforms.
  • Changes to the EIT infrastructure layer affect infrastructure facilities, such as data centers and computer rooms. They involve the installation, refresh, and decommissioning of hardware including mainframes, servers, cabling, storage, security, and telecommunication components. The EIT infrastructure transition team incorporates network and hardware experts with the infrastructure skills required for planning, configuring, and setting up the EIT infrastructure architecture solution.
    For this layer, the infrastructure team formulates architectural models of the modified Infrastructure to understand how best to integrate new hardware components or remove old ones. The team looks to standardize network topologies, to upgrade hardware components, and to monitor, configure, and support best practices. Coordination with server, database, storage and backup and security teams is typically required. The team might also run vulnerability tests on components and set up security procedures to be in compliance with corporate policies and procedures.

4.2.2 The Architecture Document

The resulting architectural document, sometimes called the technical design for the transition, should include all hardware and software relationship diagrams, backplane photos of devices that indicating the cabling, switch ports, and IP addresses tables to be allocated, reserved, and used by the ITC solution. Operating system batch commands, scripting code, database instructions, storage volumes to use, and detailed working instruction to be followed by technicians during setup need to be written so that there no question about what needs o be done. Checklists help technicians follow steps, and forms help technicians gather relevant information such as serial numbers, OS versions, IP addresses, and application versions for each of the components to be configured and released into the production environment.

4.3 Creating the Schedule

For a complex transition project, scheduling is often difficult. It needs to take into account not only the technical work being done, but also the enterprise’s calendar. It is often at this point where the team discusses the type of rollout that will occur for the solution.

Scheduling must take into account constraints such as business freeze periods, especially ones related to finances, taxes, and in some companies, seasonal periods, because those periods can impact the transition plan calendar.

Some companies also have a formal data center organization that has its own schedule (or outsourced services with restrictions), including maintenance periods and following specific processes. In this situation, coordination is necessary to elaborate a risk analysis list and to determine the best transition timeframe. The tasks shown in Figure 2 describe the transition flow.

4.3.1 Staging the Rollout

Some transitions are quite simple, such as adding a few servers to an already existing server farm. Other transitions, such as deploying a new ERP system, are extremely complex, and it is difficult to anticipate all the potential issues of integrating the new solution components into the existing environment. When the rollout is complex, the team often schedules a staged rollout — that is, only part of the rollout happens at any given time. When the initial part of the rollout is stabilized, another stage of the rollout is started. The staged rollout progresses until the entire solution is completely in production. Staged rollouts can happen along two different dimensions: by functionality and by location.

When the staged rollout occurs by functionality or component, the team might rollout particular hardware components before others and before the software. For software transitions, the team may decide to deploy certain functions and establish their stability before adding other functions. Possibly only a partial integration with existing applications or databases may occur until the basic functionality is stable. This tactic can reduce the risk of negatively effecting live operations until you are sure that base-level components are operating appropriately.

When the staged rollout occurs by location, the team often picks a particular location to deploy the solution before other locations. When the solution is stable in the first location, the team deploys the solution in other locations. This type of staged rollout not only reduces risk, but also reduces the number of personnel required for the rollout, because a single rollout team can literally travel from location to location, gaining experience (and often speed) as they go. This tactic also reduces the training time associated with the rollout team for global rollouts. <p>Staged rollouts can be called beta tests or pilot tests in some organizations. In all cases, the goal is to reduce risk, catch errors, and refine the solution before it causes havoc throughout the enterprise.

4.3.2 Freeze Periods, Outages, and Go-Live Dates

When selecting the time and day to perform a transition, it is very important to consider all the windows of time defined by the company for their daily operations schedules; however, special attention must be paid to the company freeze periods.

Financial freezes are those specific weeks and months when the entire company is focused on accounting, finance, tax, sales and inventory systems, and managers need to attend to external auditors and shareholders. Many companies prohibit EIT from making changes, installing new components, or decommissioning any piece of software or hardware related to affected systems during these periods of time. The reasoning is to avoid losing or damaging financial information that might have negative legal, tax, or company image implications.

Freeze periods very depending on the organization. Freeze dates can occur during harvest times or during other quarterly processes. Typically, the transition team analyzes all the different outsourcing and operations freeze dates to consolidate a complete timeline that can facilitate the creation of the transition schedule. If done well, the resulting timeline can effectively communicate the effect of the transition upon business owners, procurement, contractors, marketing and sales people and other.

It is important to plan accurately the time (minutes, hours, days) that systems are going to be made unavailable for service. Making changes in infrastructure or software applications sometimes requires the shutdown of other services or equipment, and management needs to know if their end users and customers could be impacted by these outage periods. Even a reboot of a server is considered an outage and is a good practice to include it on the planning.

Go-live, cutover, and retirement dates need to be planned and agreed to weeks beforehand. The goal is to avoid business conflicts and to have required technical resources and management ready to act, if any issue appears.

4.3.3 Scheduling the Training and Certification Program

Every transition plan should include a plan for the training sessions and certifications required to ensure that end users, technicians, and stakeholders are well informed about and able to use the new or updated EIT solution.

The training programs for users and most technicians should already have been developed during the acquisition or construction activities. The transition team needs to verify that the training is ready and needs to understand whether it has already been delivered or how long that training takes so that they can schedule it accordingly.

Timely training is extremely important. Users and technicians need to be trained before the solution arrives at their desk. When certifications are required for use of the new solution, the training schedule becomes even more critical. It needs to account for not only the training, but also for exam practice Q&A sessions so that the participants can pass the examination on the first try and before the new solution is available.

Note that the training program for the operations staff that will take responsibility for the deployed solution might need to be expanded or modified during the project. It is often the case that adjustments are made to procedures, settings, and configurations during the rollout. In addition, a good deal of the information about troubleshooting occurs during the rollout phase. As a result, the operator training is often modified during the project, and anticipating this eventuality needs to be part of the plan, and the modifications must be documented in the training materials.

The training plan and schedule need to be included as part of the transition plan so that the transition team can have a better understanding of the interdependencies with personnel training.

4.4 Risk Impact Analysis

<p>As mentioned above, understanding the risks associated with adding, changing, or removing components from live operations is a critical part of the transition plan. Those impacts and risks might be trivial; however, they can also affect the entire enterprise, customers, and vendors. So, careful consideration is in order.

Risk impact analysis evaluates the transition impact from three perspectives:

  • Business impact analysis (BIA) looks at the effects of the target changes to or interruptions of the business, whether they are contractual, legal, operational, or financial.
  • Technical impact analysis (TIA) looks at the effects of the target changes on the current production environment from an architectural and engineering point of view. This analysis examines the complexities of adding, modifying, and removing hardware, software, and data on the entire technical environment.
  • Cost impact analysis (CIA) estimates the cost of the project from all perspectives, including the engineering cost of the transition along with training, certifications, licenses, network appliances, hardware upgrades, and data center fees.

These three risk evaluations are used to determine an overall risk impact evaluation for the project.

4.4.1 Business Impact Analysis (BIA)

One of the main concerns when moving an EIT product or service into production is to estimate how the change ,might impact customers, end users, and stakeholders. Business impact sessions focus on managing the risks of the transition that might impact the organization at strategic, tactical, and operational levels. In essence, the analysis evaluates the change as if it were a business transition.

Not only does the team analyze the potential business risks and impacts, it determines mitigation strategies, and sets up communication processes with stakeholders that reduce or eliminate negative impact.

4.4.2 Technical Impact Analysis (TIA)

The technical impact of a transition depends on the size and interconnectedness of the different devices and applications. The analysis team discusses technical risk and creates a risk list associated with the hardware, software, and network components that could be negatively affected by the changes.

Relationships and dependencies between EIT assets are defined and evaluated as points of failure. Potential mitigation techniques are identified and analyzed during these sessions. For example, the group might examine the technical impact of installing utility software on a particular dedicated server. Or, they might analyze a hardware upgrade for a server farm with redundant clusters, an uninstall of a database engine, or an uninstall of some virtual machine applications, or the risks of exceeding power consumption limits. The technical impact analysis requires experienced practitioners in several areas including support people to evaluate the risk of the transition’s impact.

4.4.3 Cost Impact Estimation

Most EIT organizations pay support contract fees to suppliers for services, such as data center hosting, Internet access, hardware devices, operating systems, database engines, ERPs, CRMs, antivirus support, and other components. When a new EIT solution is going to be moved into production or an existing EIT solution is removed, the transition team needs to present the transition costs and steady-state production costs to accounting, procurement, and other concerned parties to avoid fiscal surprises. Note that in the case of a retirement, these departments need to be notified of reimbursements or cost savings. Accounting and procurement teams can contact the suppliers and let them know about the upcoming payment changes.

A detailed list of software and hardware components to be installed or decommissioned with their associated costs must be created. Asset management systems make it easier to collect information about hardware models, quantity of processors and cores, server OS versions, database engines, ERP, CRM and applications software licenses. Then it is relatively easy to make calculations about the total cost of the project.

4.4.4 Total Risk Impact Calculation

Each company has its own method for evaluating the three subareas to enable the calculation of an overall risk evaluation. Some organizations rate each one of the risk areas from very low to very high risk, maybe on a 1-5 or 1-10 scale. An even number of risk levels is often used to avoid a value in the middle that doesn’t really give decision makers a positive or negative view of the risk. A “mid” value makes go/no-go decisions more difficult.

The overall calculation is based upon guidelines that come from strategy and governance decisions. In the best of all situations, a simple equation can calculate the overall risk:

Total Project Risk Impact = BIA + TIA + CIE

Using this simple calculation facilitates the understanding, management, and prioritization of the transition queue in a straightforward way, and at same time, facilitates the decision-making.

In reality, the decision process is more difficult. The CAB team supporting the transition often holds a meeting to get clarifications and justification of the risks analysis reports from each stakeholder group. The decision authority often considers experiences from past transitions, team skills, and the corporate knowledge of what needs to be done for success. At the end, the CAB comes up with an overall rating for the project.

Another factor that needs to be taken into consideration when determining the overall risk of a project is the level of maturity of the organization. Mature organizations have well-understood institutionalized processes, policies, and activities in place for transitions, including change requests, external support, testing teams, audits, and compliance validation with general policies and security guidelines. Mature organizations are usually better at dealing with risk and employing mitigation techniques; therefore, they can (and will) take on riskier projects.

Some organizations decide only to approve very low-risk projects, but any organization’s risk appetite should be established during strategic planning, and the transition team should follow those guidelines when making their decision.

4.5 Creating the Transition Plan Document

The completed plan integrates all the documents and results for analysis sessions created during the planning session. The final plan often includes following sections:

  • Information about the alignment with the enterprise’s strategic plan
  • Scope of the solution to be released (architecture)
  • Detailed technical design of the solution’s deployment including a list of components to be modified and in-place components that are attached or otherwise potentially affected
  • The release, test, training, and deployment activities for moving the EIT solution (product or service) into the live environment
  • The backup, uninstall, decommissioning, archiving and disposal activities to remove a product or serviced from the live environment for retirement projects
  • The project schedule that includes planned freezes and outages, point of no return milestones, and crosscheck points with stakeholders
  • Personnel resources (staff, technical, contractors, and management)
  • Roles and responsibility assignment for operations staff, technical staff, and stakeholders
  • Non-personnel resources required to execute the plan
  • Training program content, certifications, and staffing
  • A risk impact analysis section that covers business, technical, cost, and identified risks and mitigation strategies associated with the project
  • Approval and change request processes
  • The technical design of the solution updated for the transition as well as the training program details
    In infrastructure projects, some companies include diagrams and photos of the backplane providing a detailed explanation of the cabling to be used on each hardware device, especially with having clusters or redundant hardware devices where the right connection is critical to comply with architecture specifications and best practices.

5 Executing the Transition Plan

When the transition plan is approved, the transition team can execute the plan. There are a number of activities that occur in this phase, as described in this section.

5.1 Managing the Transition

As mentioned in the planning phase, the rollout of the solution might occur in stages or it might occur as one piece. Part of the execution phase is to manage the planned rollout.

Large transition projects often require a team (often known as a command center) to coordinated the project. The mission of a command center is to coordinate the technical, operations, and procurement teams, to keep executives and stakeholders aware of the project status, to make cross-functional decisions, and to manage the budget and resources required to meet the goals of the project. Whether or not a command center is needed, it is necessary to designate a project manager to manage the project.

It is the responsibility of the project manager (or command center staff) to ensure that the transition into the live environment is successful, secure, on time, on or under budget, and that it meets all quality standards. All the team members should be aware of the transition project scope, the resources assigned, and the task schedule to avoid project delays and access issues that require assistance from other groups.

5.1.1 Backup and Storage Management

A good practice is to run a full backup of all stored data, information, applications, databases and network configurations that could change or be affected before the any major change is executed. A snapshot of a retired EIT solution is especially important, because it enables a rollback to a previous state, in case of a disaster recovery situation. If there is a backup, the organization’s disaster plan can be activated if need be to recover data, or the configuration management team can rebuild the latest working version of an application from the definitive media location.

Another complementary task to perform is the recovery testing procedure. An example can be to restore the recently removed version in temporary servers in order to practice the restoration task. This helps to test and ensure that restoring techniques and procedures are working as expected and under the disaster preparedness strategic guidelines. These tasks are crucial to develop and test to comply with auditing guidelines (see Disaster Preparedness).

5.1.2 Access Management

The transition team needs to ensure that all transition personnel have access to the areas where they need to work. For example, if a badge is required to physically enter a data center or computer room, getting approval from security officers might take several days. As a result, the team needs to make requests for access in advance to avoid delay. It is also important to request system administration access to the hardware and logical devices touched by the project well in advance of the actual need.

The team needs to think through access needs that occur both during regular business hours as well as after hours. Sometimes a quick discussion with security early in the process can ensure that all the paperwork is in place before the access is required.

5.1.3 Managing Complexity and Minimizing Unexpected Changes

Bringing all the teams together with local contacts inside the facilities during the transition of a highly complex environment is a good practice. This meeting can help the teams find the rooms, the servers, and network devices quickly. Local resources can also help unscrew units from the racks and transport the components to new locations. Similarly it’s better to have the right experienced people managing large databases or complex virtual machine configurations connected through a SAN external storage devices having the right people involved minimizes the risk of slow responses to detected errors and slow decisions or responses to other non-planned steps. Always bring the right people with the right tools.

5.1.4 Change Request Management

It is critical to have a control list of all the change requests submitted to all teams during the transition phase. Special attention should be given to those that require formal approval from authorities such as the CAB or PMO decision boards. Let’s say that during the testing phase there is a request to change some rules on the router so that a particular group can have access into a certain group of systems. The security infrastructure team needs to analyze the impact of the change on the access throughout the organization. To proceed with the change, a security risk impact analysis should be performed and the organization might require that the analysis be submitted for approval of the request. In some organizations, the analysis and approval process takes time. So, it is a good practice to talk with these teams earlier in the project to avoid misunderstandings and delays on the overall transition project.

5.1.5 Outage Management

It is crucial to communication all anticipated outages with technicians and stakeholders. They need to be informed several times to remind affected users that the facilities are not available. See the appropriate section in Operations and Support for recommendations about notifications.

5.1.6 Resource Management

Contractors or third-party vendors hired only for the transition project, including SMEs, technicians, electricians, as well as other should be contracted in advance to ensure that all the access and permissions (physical and logical personal security items) are in place in time. Temporary remote access is a common practice used for this type of temporary resources, and they need all the relevant documentation and reference material before execution of the transition plan starts. All these on-boarded resources need to be well-organized, well-trained, with access validated, assigned, and approved prior to arriving at the facility to perform their assigned tasks.

After the transition project is finished or the resource has completed the task that it was assigned to do, it is important to submit the requests that release the resources, collect badges, access keys, physical and logical security tokens, and remove server and database access. Not doing this promptly can generate security and access vulnerabilities. System auditors usually check active and non-active accounts of non-employees and off-boarding contractors.

6 Handing Off to Operations

When the pilot is over and the team determines that all the components are ready and the staff is trained, the solution is released into production and is handed off to the operations team, the final results are evaluated, and the operations group formally accepts the solution.

6.1 Handing Over to Operations

The transition levels diagram implies that each level needs specific documentation related to the type of EIT solution as it is moved into production. Documents, troubleshooting techniques, testing results, QA references, and a list of acceptance criteria established in the release criteria should be adopted as a reference for the operations group.

Training of the operations support team should already be complete with special attention given to new Infrastructure, hardware, or software platforms. The team should be ready to take over the operations of the solution.

The operations team should review the list of operational risks and the set of workaround techniques available for incident management purposes. If an incident needs to be escalated to a more skilled technical team, the command center can provide an assessment and address the request for specialized resources. The command center might need to approve funds for outsourced resources, purchases of new software licenses or hardware stuff to solve issues or mitigate risks for the transition.

It is not uncommon for the handover to occur after a period of joint operations, where the transition team and the operations team work side by side. This overlap ensures that the operations team’s training is complete and that unwritten information makes it into the hands of operations.

6.2 Announcing the EIT Solution Release or Retirement

A set of formal and informal messages to users, technicians, and stakeholders to announce the release of the new EIT solution should be distributed as the solution is coming online and at its cutover to operational status.

The release announcement is often done with several different kinds of media. For example, the organization might send shareholders and executives a formal brief communication. For management and other business units inside the organization, the organization might create a user brochure and publish it on the intranet. For internal EIT teams, a diagram with related components and a description some of the features is a good communication option.

Often organizations do a survey to gather feedback and measure the perceived value of the new solution from clients and end users. This feedback can often be used to show that the solution has met its business objectives.

6.3 Monitoring and Stabilizing the EIT Solution

Monitoring and stabilizing a new EIT solution is more reactive than proactive. The operations team should monitor the new systems, attend to any incident that arises, and resolve it as soon as possible.

The main objective of this activity is to create mechanisms that provide real-time event monitoring of key components, while sending status alerts during the release and beyond.

Giving daily reports to the transition project owner regarding the health of the EIT solution is a sound practice. At the end of the stabilization period (one or two weeks is common), a meeting is scheduled to share experiences and review incident and issue reports, as well as any other report required by nature of the transition.

6.4 Closing the Project

Like any project, a transition project needs to be closed according to the policies and procedures of the organization. In some organizations, a document with the operations acceptance checklist, lessons learned collected during this session, and results of any surveys are included.

In organizations using a CAB team, a change request to close the transition project is submitted to the CAB team for evaluation. Then, during next CAB session, the board members evaluate the completed transition, and confirm that all requests sent to different teams are now closed. A discussion can arise regarding the lessons learned shared and collected by the team and stakeholders, and the transition project owner can then officially close the transition project.

Gathering a final detailed list of components (configuration items) added or removed during the process is key to maintain an updated configuration management database (CMDB). [1] The operations team can then take full control and manage all the different components when the new/updated EIT solution is in the production environment.

Any detailed troubleshooting and workaround techniques created for a transition (including a retirement) should be formulated and recorded into the incident database to be used by operations team during steady state.

7 Summary

The transition knowledge area consists of a set of practices, processes, and activities that assist the organization with the successful insertion (or removal) of EIT solutions into the production environment. The overall process can be divided into three main phases: plan, execute, and release. Each phase can involves different personnel and has it own set of artifacts. As with any project, designated decision bodies are responsible for the management of the project. They provide the funds, set priorities, and approve the required resources.

The planning phase produces a transition plan for the new solution. The execution phase executes the plan and moves the solution into the production environment. The release phase hands over the EIT solution to the operations team and helps them stabilize the solution in the production environment. Final steps includes the announcement of the new release in the production environment and a final meeting to ensure that all the objective are met and that all the lessons learned are collected for reference by future projects.

8 Relevant SFIA Skills

Note also that SFIA has introduced some “profiles”: https://computer.centraldesktop.com/itbok/file/31608104/

9 Roles

The table below shows the four levels of the transition category model: business, data and information, software application, and hardware infrastructure transition.

You can find the roles at https://computer.centraldesktop.com/itbok/folder/3156969/#folder:3895640

Transition Level Stakeholders Resources
Business levelStrategic decision people, top management, C-level officers, regulatory authorityEnterprise architects and risk mgmt, project management office (PMO), experienced team lead engineers
Data and information levelStrategic decision people, top management, C-level officersEnterprise data architect and modelers, data manager, data stewards, database administrators
Software application levelTactical/operational business decision participants, business owner, application owners, application contractorsSolution architects, data mgmt, business analysts, user experience team, quality and multiplatform application and utility programmers subject matter experts (SMEs)
Hardware EIT infrastructure levelServer owners, data center administrators, security and risk operations teams, infrastructure contractors, internet and cloud service providersInfrastructure solution architects, cloud services, data center and operation management, procurement, release mgmt, network, security, server, storage devices specialists

10 Standards

While ITIL itself has not been established as an international standard, most of it is reflected in the ISO/IEC 20000 series.

11 References

[1] Configuration management system (CMS) and configuration management database (CMDB). ITIL Service Transition. OGC 2007. Service Transition Processes. Service Assets and Configuration Management 4.3.4.3 Configuration Management System p. 68-69.