Transition into Operation
|
Contents
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.
- 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 vendors (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 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 (VLAN) architecture, switching, and routing. The application transition team might write code to interconnect business applications with existing databases.
The two teams work together to deploy an integrated and 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).
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 accepted project management 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 supervises 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 accepted 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 architecture 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 is 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 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, the rollout happens in increments. 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 roll out 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 affecting 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 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 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 risk 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 approve only 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 the 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 recommended 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 coordinate 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 on temporary servers in order to practice the restoration task. This helps to test and ensure that restoration 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 the security office 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 in 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 to 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 in 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 (for 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 the relevant documentation and reference material before execution of the transition plan starts. All these on-boarded resources need to be well organized and 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, test 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, 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 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 reports 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 the 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 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 the 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 its 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 objectives are met and that all the lessons learned are collected for reference by future projects.
9 Key Maturity Frameworks
Capability maturity for EIT refers to its ability to reliably perform. Maturity is measured by an organization's readiness and capability expressed through its people, processes, data, technologies, and the consistent measurement practices that are in place. See Appendix F for additional information about maturity frameworks.
Many specialized frameworks have been developed since the original Capability Maturity Model (CMM) that was developed by the Software Engineering Institute in the late 1980s. This section describes how some of those apply to the activities described in this chapter.
9.1 IT-Capability Maturity Framework (IT-CMF)
The IT-CMF was developed by the Innovation Value Institute in Ireland. This framework helps organizations to measure, develop, and monitor their EIT capability maturity progression. It consists of 35 EIT management capabilities that are organized into four macro capabilities:
- Managing EIT like a business
- Managing the EIT budget
- Managing the EIT capability
- Managing EIT for business value
The three most relevant critical capabilities are service provisioning (SRP), the technical infrastructure management (TIM), and solutions delivery (SD).
9.1.1 Service Provisioning Maturity
The following statements provide a high-level overview of the service provisioning (SRP) capability at successive levels of maturity.
| Level 1 | The service provisioning processes are ad hoc, resulting in unpredictable EIT service quality. |
| Level 2 | Service provisioning processes are increasingly defined and documented, but execution is dependent on individual interpretation of the documentation. Service level agreements (SLAs) are typically defined at the technical operational level only. |
| Level 3 | Service provisioning is supported by standardized tools for most EIT services, but may not yet be adequately integrated. SLAs are typically defined at the business operational level. |
| Level 4 | Customers have access to services on demand. Management and troubleshooting of services are highly automated. |
| Level 5 | Customers experience zero downtime or delays, and service provisioning is fully automated. |
9.1.2 Technical Infrastructure Management Maturity
The following statements provide a high-level overview of the technical infrastructure management (TIM) capability at successive levels of maturity.
| Level 1 | Management of the EIT infrastructure is reactive or ad hoc. |
| Level 2 | Documented policies are emerging relating to the management of a limited number of infrastructure components. Predominantly manual procedures are used for EIT infrastructure management. Visibility of capacity and utilization across infrastructure components is emerging. |
| Level 3 | Management of infrastructure components is increasingly supported by standardized tool sets that are partly integrated, resulting in decreased execution times and improving infrastructure utilization. |
| Level 4 | Policies related to EIT infrastructure management are implemented automatically, promoting execution agility and achievement of infrastructure utilization targets. |
| Level 5 | The EIT infrastructure is continually reviewed so that it remains modular, agile, lean, and sustainable. |
9.1.3 Solutions Delivery Maturity
The following statements provide a high-level overview of the solutions delivery (SD) capability at successive levels of maturity.
| Level 1 | There is ad hoc use of solutions delivery methodologies. EIT solutions are typically delivered with wide variations in quality, schedule, and cost expectations. |
| Level 2 | Basic solutions delivery methodologies are defined and applied to a limited number of EIT solution projects, which are beginning to meet expectations, but variations in quality, schedule, and cost still occur. |
| Level 3 | Standardized solutions delivery methodologies are applied to most EIT solution projects, enabling many of them to regularly meet expectations for quality, schedule, and cost. |
| Level 4 | Comprehensive and flexible project delivery methodologies are applied to all projects, enabling most projects to meet expectations for quality, schedule, and cost. |
| Level 5 | Solutions delivery methodologies are continually analyzed and refreshed. Solutions delivery expectations for quality, schedule, and cost are nearly always met. |
10 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 three major sources of skill definitions. While none of them is used universally, they provide a good cross-section of options.
Creating mappings between these frameworks and our chapters is challenging, because they come from different perspectives and have different goals. There is rarely a 100 percent correspondence between the frameworks and our chapters, and, despite careful consideration some subjectivity was used to create the mappings. Please take that in consideration as you review them.
10.1 Skills Framework for the Information Age
The Skills Framework for the Information Age (SFIA) has defined nearly 100 skills. SFIA describes seven levels of competency that can be applied to each skill. However, not all skills 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. SFIA 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)
| Skill | Skill Description | Competency Levels |
|---|---|---|
| Asset management | The management of the lifecycle for all managed assets (hardware, software, intellectual property, licenses, warranties, etc.) including security, inventory, compliance, usage, and disposal, aiming to protect and secure the corporate assets portfolio, optimize the total cost of ownership and sustainability by minimizing operating costs, improve investment decisions, and capitalize on potential opportunities. Knowledge and use of international standards for asset management and close integration with security, change, and configuration management are examples of enhanced asset management development. | 4-6 |
| Benefits management | Monitoring for the emergence and effective realization of anticipated benefits (typically specified as part of the business case for a change program or project). Action (typically by the program management team) to optimize the business impact of individual and combined benefits. | 5-6 |
| Business process testing | The planning, design, management, execution, and reporting of business process tests and usability evaluations. The application of evaluation skills to the assessment of the ergonomics, usability, and fitness for purpose of defined processes. This includes the synthesis of test tasks to be performed (from statement of user needs and user interface specification), the design of an evaluation program, the selection of user samples, the analysis of performance, and inputting results to the development team. | 4-6 |
| Change implementation planning and management | The definition and management of the process for deploying and integrating new digital capabilities into the business in a way that is sensitive to and fully compatible with business operations. | 5-6 |
| Change management | The management of change to the service infrastructure including service assets, configuration items, and associated documentation. Change management uses requests for change (RFC) for standard or emergency changes, and changes due to incidents or problems to provide effective control and reduction of risk to the availability, performance, security, and compliance of the business services impacted by the change. | 2-6 |
| Configuration management | The lifecycle planning, control, and management of the assets of an organization (such as documentation, software, and service assets, including information relating to those assets and their relationships. This involves identification, classification, and specification of all configuration items (CIs) and the interfaces to other processes and data. Required information relates to storage, access, service relationships, versions, problem reporting, and change control of CIs. The application of status accounting and auditing, often in line with acknowledged external criteria such as ISO 9000, ISO/IEC 20000, ISO/IEC 27000, and security throughout all stages of the CI lifecycle, including the early stages of system development. | 2-6 |
| Information content publishing | The evaluation and application of different publishing methods and options, recognizing key features, including open source and proprietary options. The management and tuning of the processes that collect, assemble, and publish information, including in unstructured and semi-structured forms, for delivery to the user at the point at which it is needed. The management of copyright, data protection, and other legal issues associated with publishing and re-use of published information and data. | 1-6 |
| Learning and development management | The provision of learning and development processes (including learning management systems) in order to develop the professional, business, and technical skills required by the organization. | 3-7 |
| Learning assessment and evaluation | The assessment of knowledge, skills, and behavior by any means, whether formal or informal, against capability and qualification frameworks such as SFIA. The evaluation of learning or education programs against defined outcomes. | 3-6 |
| Learning delivery | The transfer of business and technical skills and knowledge and the promotion of professional attitudes in order to facilitate learning and development. Uses a range of techniques, resources, and media (which might include eLearning, online virtual environments, self-assessment, peer-assisted learning, simulation, and other current methods). | 3-5 |
| Learning design and development | The specification, design, creation, packaging, and maintenance of materials and resources for use in learning and development in the workplace or in compulsory, further, or higher education. Typically involves the assimilation of information from existing sources, selection, and re-presentation in a form suitable to the intended purpose and audience. Includes instructional design, content development, configuration, and testing of learning environments, and use of appropriate current technologies such as audio, video, simulation, and assessment. May include third-party accreditation. | 4-6 |
| Penetration testing | The assessment of organizational vulnerabilities through the design and execution of penetration tests that demonstrate how an adversary can either subvert the organization's security goals (e.g., the protection of specific intellectual property) or achieve specific adversarial objectives (e.g., establishment of a covert command and control infrastructure). Pen test results provide deeper insight into the business risks of various vulnerabilities. | 4-6 |
| Release and deployment | The management of the processes, systems, and functions to package, build, test, and deploy changes and updates (which are bounded as "releases") into a live environment, establishing or continuing the specified service, to enable controlled and effective handover to operations and the user community. | 2-6 | </ tr>
10.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, see http://www.ecompetences.eu.
| e-CF Dimension 2 | e-CF Dimension 3 |
|---|---|
| B.3. Testing (BUILD) Constructs and executes systematic test procedures for ICT systems or customer usability requirements to establish compliance with design specifications. Ensures that new or revised components or systems perform to expectation. Ensures meeting of internal, external, national, and international standards; including health and safety, usability, performance, reliability, or compatibility. Produces documents and reports to evidence certification requirements. | Level 1-4 |
| B.4. Solution Deployment (BUILD) 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-3 |
| D.9. Personnel Development (ENABLE) Diagnoses individual and group competence, identifying skill needs and skill gaps. Reviews training and development options and selects appropriate methodology taking into account the individual, project, and business requirements. Coaches/mentors individuals and teams to address learning needs. | Level 2-4 |
| E.7. Business Change Management (MANAGE) Assesses implications of new digital solutions. Defines requirements and quantifies business benefits. Manages deployment of change taking into account structural and cultural issues. Maintains business and process continuity throughout change, monitoring the impact, taking any required remedial action and refining approach. | Level 3-5 |
10.3 i Competency Dictionary
The Information Technology Promotion Agency (IPA) of Japan has developed the i Competency Dictionary (iCD) and translated it into English, and describes it at https://www.ipa.go.jp/english/humandev/icd.html. The iCD 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. (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 corresponds 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.
| Task Dictionary | Skill Dictionary | ||
|---|---|---|---|
| Task Layer 1 (Task Layer 2) | Skill Classification | Skill Item | Associated Knowledge Items |
| Transition design (transition design) |
Design and transition of service | Service transition methods |
|
11 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
Other key roles are:
- Communications Manager
- Deployment Manager
- Operations Manager
- Problem Manager
- Solution Management Team
- Transition 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 management, 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 |
12 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
13 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.
