Transition into Operation

Note: This wiki is a work in progress, and may contain missing content, errors, or duplication.

---

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 datacenter, 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 hand off new solutions to operations at the completion of the transition.

3 Context Diagram

Figure 1. Context Diagram for Transition

4 Transition and Retirement Activities

The transition activities can be subdivided into three sets of activities: plan, execute, and release (or 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

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

5 Planning the Transition Project

The transition project starts with a management decision based on the organization’s 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 a solution transition strategy that allows the team to deploy, move, and then target the 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

5.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 is 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 risk-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 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 process, answering questions, and clarifying any possible drawback of delays of the project, before submitting the plan for approval.

5.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 solution into production, and retiring any components that need to be removed. This analysis occurs at several levels.

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

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 Chapter 12 ***what is the 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 of the country implies a business decision that involves many different unit areas, such as finance, marketing, legal, HR, and, of course, EIT. All of these 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 transition 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 of 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 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 datacenters 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, 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.

5.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, and backplane photos of devices that indicate the cabling, switch ports, and IP address tables to be allocated, reserved, and used by the solution. Operating system batch commands, scripting code, database instructions, storage volumes to use, and detailed working instructions to be followed by technicians during setup need to be written so that there no question about what needs to 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.

5.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 to use for the solution.

Scheduling must take into account constraints such as business freeze periods, especially those 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 datacenter organization that has its own schedule (or outsourced services with restrictions), including maintenance periods and times to perform 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.

5.3.1 Staging the Rollout

Some transitions are quite simple, such as adding a few servers to an existing server farm. Other transitions, such as deploying a new ERP system, are extremely complex, and it is difficult to anticipate all of 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 to before rolling out to 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 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.

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 problems throughout the enterprise.

5.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 of the scheduled events defined by the company for their daily operations; however, special attention must be paid to 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 vary depending on the organization. Freeze dates can occur during harvest times or during other quarterly processes. Typically, the transition team analyzes all of 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, sales people, and others.

It is important to accurately plan 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 it is a good practice to include it on the planning.

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

5.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 know 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 the 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, 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.

5.4 Risk Impact Analysis

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 datacenter fees.

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

5.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 any negative impact.

5.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 risks 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 possible 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, 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 personnel to evaluate the risk of the transition’s impact.

5.4.3 Cost Impact Estimation

Most EIT organizations pay support contract fees to suppliers for services, such as datacenter 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.

5.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 on 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 clarification 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 team comes up with an overall rating for the project.

Another factor to consider 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 to only 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.

5.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 service 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 clusters or redundant hardware devices where the right connection is critical to comply with architecture specifications and best practices.

6 Executing the Transition Plan

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

6.1 Managing the Transition

As mentioned in the planning phase, the rollout of the solution might occur in stages or 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.

6.1.1 Backup and Storage Management

Before the any major change is executed, run a full backup of all stored data, information, applications, databases, and network configurations that could change or be affected. 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 to recover the 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).

6.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 datacenter 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 involved in 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 access is required.

6.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, servers, and network devices quickly. Local resources can also help disconnect units from racks and transport the components to new locations. Similarly, it’s better to have personnel with the proper experience managing large databases or complex virtual machine configurations connected through 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.

6.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 early in the project to avoid misunderstandings and delays on the overall transition project.

6.1.5 Outage Management

It is crucial to communicate 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.

6.1.6 Resource Management

Contractors or third-party vendors hired only for the transition project, including SMEs, technicians, and electricians should be contracted in advance to ensure that all required 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. They need to have copies of all of 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 assigned task, 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. If this is not done promptly, it can generate security and access vulnerabilities. System auditors usually check active and non-active accounts of non-employees and off-boarding contractors.

7 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. Then the final results are evaluated, and the operations group formally accepts the solution.

7.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, and 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 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.

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

7.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), schedule a meeting to share experiences and review incident and issue reports, as well as any other report required by nature of the transition.

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

8 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 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 include 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.

9 Key Competence Frameworks

While many large companies have defined their own sets of skills for purposes of talent management (to recruit, retain, and further develop the highest quality staff members that they can find, afford and hire), the advancement of EIT professionalism will require common definitions of EIT skills that can be used not just across enterprises, but also across countries. We have selected 3 major sources of skill definitions. While none of them is used universally, they provide a good cross-section of options.

9.1 Skills Framework for the Information Age

The Skills Framework for the Information Age (SFIA) has defined nearly 100 skills. SFIA describes 7 levels of competency which can be applied to each skill. Not all skills, however, cover all seven levels. Some reach only partially up the seven step ladder. Others are based on mastering foundational skills, and start at the fourth or fifth level of competency. It is used in nearly 200 countries, from Britain to South Africa, South America, to the Pacific Rim, to the United States. (http://www.sfia-online.org)

SFIA skills have not yet been defined for the this chapter.

9.2 European Competency Framework

The European Union’s European e-Competence Framework (e-CF) has 40 competences and is used by a large number of companies, qualification providers and others in public and private sectors across the EU. It uses five levels of competence proficiency (e-1 to e-5). No competence is subject to all five levels.

The e-CF is published and legally owned by CEN, the European Committee for Standardization, and its National Member Bodies (www.cen.eu). Its creation and maintenance has been co-financed and politically supported by the European Commission, in particular, DG (Directorate General) Enterprise and Industry, with contributions from the EU ICT multi-stakeholder community, to support competitiveness, innovation, and job creation in European industry. The Commission works on a number of initiatives to boost ICT skills in the workforce. Version 1.0 to 3.0 were published as CEN Workshop Agreements (CWA). The e-CF 3.0 CWA 16234-1 was published as an official European Norm (EN), EN 16234-1. For complete information, please see http://www.ecompetences.eu.

e-CF Dimension 1	e-CF Dimension 2	e-CF Dimension 3
B. Build	B.4. Solution Deployment Following predefined general standards of practice carries out planned necessary interventions to implement solution, including installing, upgrading or decommissioning. Configures hardware, software or network to ensure interoperability of system components and debugs any resultant faults or incompatibilities. Engages additional specialist resources if required, such as third party network providers. Formally hands over fully operational solution to user and completes documentation recording all relevant information, including equipment addressees, configuration and performance data.	Level 1: Removes or installs components under guidance and in accordance with detailed instructions. Level 2: Acts systematically to build or deconstruct system elements. Identifies failing components and establishes root cause failures. Provides support to less experienced colleagues. Level 3: Accounts for own and others actions for solution provision and initiates comprehensive communication with stakeholders. Exploits specialist knowledge to influence solution construction providing advice and guidance.

9.3 i-Competency Dictionary

The Information Technology Promotion Agency (IPA) of Japan has developed the i-Competency Dictionary (iCD), translated it into English, and describes it at https://www.ipa.go.jp/english/humandev/icd.html. It is an extensive skills and tasks database, used in Japan and southeast Asian countries. It establishes a taxonomy of tasks and the skills required to perform the tasks. The IPA is also responsible for the Information Technology Engineers Examination (ITEE), which has grown into one of the largest scale national examinations in Japan, with approximately 600,000 applicants each year.

The iCD consists of a Task Dictionary and a Skill Dictionary. Skills for a specific task are identified via a “Task x Skill” table. (Please see Appendix A for the task layer and skill layer structures.) EITBOK activities in each chapter require several tasks in the Task Dictionary.

The table below shows a sample task from iCD Task Dictionary Layer 2 (with Layer 1 in parentheses) that correspond to activities in this chapter. It also shows the Layer 2 (Skill Classification), Layer 3 (Skill Item), and Layer 4 (knowledge item from the IPA Body of Knowledge) prerequisite skills associated with the sample task, as identified by the Task x Skill Table of the iCD Skill Dictionary. The complete iCD Task Dictionary (Layer 1-4) and Skill Dictionary (Layer 1-4) can be obtained by returning the request form provided at http://www.ipa.go.jp/english/humandev/icd.html.

The information is not available for this chapter yet.

10 Key Roles

Common ITSM roles:

• Application Developer
• Change Advisory Board (CAB)
• Change Manager
• Configuration Manager
• Emergency Change Advisory Board (ECAB)
• Knowledge Manager
• Project Manager
• Release Manager
• Test Manager

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

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

11 Standards

ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology – Service management – Part 1: Service management system requirements

IEEE Std 828™-2012, IEEE Standard for Configuration Management in Systems and Software Engineering

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