Chapter 10
Technology and Implementation Considerations for Planning, Protection, and Optimization
The following ITIL Intermediate exam objectives are discussed in this chapter:
The generic requirements for technology to assist service design- The evaluation criteria for technology and tooling for process implementation
- The good practices for practice and process implementation
- The challenges, critical success factors, and risks related to implementing practices and processes
- How to plan and implement service management technologies
- The consideration for implementing technologies in supporting the processes within planning, protection, and optimization practice, in particular, designing technology architectures
This chapter brings all technology and implementation requirements together to define the overall requirements of an integrated set of service management technology tools to support the processes in planning protection and optimization. The same technology, with some possible additions, should be used for the lifecycle stages of IT service management (ITSM)—service strategy, service design, service transition, service operation, and continual service improvement—to give consistency and allow an effective ITSM lifecycle to be properly managed.
Tools can help the service management processes to work more effectively. They should allow large amounts of repetitive work to be carried out quickly and consistently. Tools also provide a wealth of management information, leading to the identification of weaknesses and opportunities for improvement.
The use of tools will help standardize practices and both centralize and integrate processes.
We are going to consider the generic requirements for such tools. It is important that the tool being used support the processes, not the other way around.
Generic Requirements and Evaluation Criteria for Technology
We will begin by considering the generic requirements for technology to support service design, which for IT service management means IT service management tools. In this section, we look at a number of these requirements, which we would expect any good integrated toolset to offer.
The first two requirements are self-help functionality and a workflow engine.
You should be able to recall from the discussion of the release fulfillment process that we explored the option for dealing with requests or simple incidents via self-help functionality. This might be restricted to the logging of requests and incidents, or it could allow them to be tracked and updated throughout their lifecycle. The advantage to providing a self-help facility is that requests and incidents can be logged at any time, and this process is not dependent on service desk staff being available to answer the phone. This helps the service desk manage high volumes of calls if the less urgent ones are handled via a self-help, self-logging site. Self-help request tools can assist with password resets by, for example, requiring the user to validate their identity by answering previously set questions before the reset takes place. Additionally, a self-help request tool could download approved versions of requested software.
The next generic requirement is for a workflow or a process engine that can automate the steps of the process (assigning, escalating, etc.). It can also release work orders when prerequisite steps have been completed.
The next generic requirement is for an integrated configuration management system (CMS).
The service management tool should be integrated with the CMS to allow the organization’s configuration item (CI) information to be interrogated and linked to incident, problem, known error, and change records as appropriate.
Another generic requirement is for discovery, deployment. and licensing technology tools; these are extremely helpful in verifying the accuracy of the CMS, especially with regard to license use. It is also very helpful if only changes since the last audit can be extracted and reported upon. The same technology can often be used to deploy new software to target locations. This is essential to enable patches, upgrades, and so on to be distributed to the correct users.
When implemented in conjunction with the self-help functionality previously mentioned, the service management tool facilitates the automation of the fulfillment of many service requests for software.
Another generic requirement is remote control. This allows the service desk analysts to take control of the user’s desktop (under properly controlled security conditions) to do things such as conduct investigations and correct settings.
Some tools will store diagnostic scripts and other diagnostic utilities to assist with earlier diagnosis of incidents.
Good reporting is a requirement of any ITSM toolset. The tools hold enormous amounts of information about what is happening day to day. This data is helpful in planning ahead and tracking trends, but such reporting has to be flexible if it is to be useful. Standard reports and ad hoc reports should both be easily available.
Another generic requirement to consider is a dashboard facility. Dashboards are useful, both for day-to-day operations and for IT and business management to get a clear idea of real-time performance.
To facilitate greater business alignment, business applications and tools need to be able to interface with ITSM support tools to give the required functionality. An example of integration includes event management tools spotting unusual spending patterns on credit cards.
Software as a Service (SaaS) technologies offer hosted service management capabilities over the Internet. The advantages this offers include lower capital and start-up costs, faster implementation, and built-in service continuity.
However, it also means limited customization and changes to functionality, access restricted to the vendor’s hours of service availability, and licensing schemes that may become restrictive or expensive. There may also be limits on data storage size and possible security and access management constraints or risks. Finally, integration with other service management tools may be difficult or even impossible.
Each organization should review its requirements carefully so that it acquires the most appropriate toolset for its needs.
Good Practices for Practice and Process Implementation
In the following sections, we’ll consider the basics of implementing good practices and processes. We need to take into account the requirements relating to the planning, protection, and optimization processes, and the approach to implementing service design. This should include
- Where do we start?
- How do we improve?
- How do we know we are making progress?
When looking at the implementation of any service management processes, including those of service design, the important factors to consider are the needs and desires of the customer and the business. The activities should be prioritized by
- Business needs and business impacts
- Risks to the services and processes
The activities will also be influenced by the service level requirements and agreements made in service level agreements.
Business Impact Analysis
One of the key inputs for understanding business needs, impacts, and risks is the output from a business impact analysis (BIA). BIA is used in a number of service design processes, particularly IT service continuity management (see Chapter 9, “IT Service Continuity Management and Demand Management”), where it is essential to help define the strategy for risk reduction and disaster recovery. BIA is normally used to identify the effect a disaster will have on the business, both on individual sections and on the business as a whole. It is used to identify the criticality of any particular business processes or activities, and also used to identify the times when this will be particularly affecting. BIA is also used for other processes—for example, availability management, capacity management, and information security management.
There are two areas for BIA. One is for business management, understanding the impact of loss on a business process or function. The second is to understand the BIA from the perspective of service loss. Both of these should be applied to identify the critical services and what constitutes a major incident on the services when a new service is being implemented. BIA will also assist in defining the acceptable level and duration of service outage, including the important periods to avoid. BIA can also assist with the understanding of financial loss and any security issues.
Service Level Requirements
As part of the service level management process (see Chapter 18, “Service Level Management and Supplier Management”), service level requirements for all services will be identified and the ability to deliver against the requirements will be assessed and agreed to in the service level agreements. This needs to be part of the approach to the design of services, and all processes in planning, protection, and optimization will have to be considered as part of the requirements capture.
Risks to the Services and Processes
It is important to ensure that business-as-usual processes are not adversely impacted by the implementation of the planning, protection, and optimization processes. This factor needs to be considered as part of the risk assessment during design, and it will be explored more fully during the transition lifecycle stage. Risk assessment and management form a key part of the planning, protection, and optimization processes—for example, availability management and IT service continuity management. Any solution created during service design must take risks into account.
Implementing Service Design
The process, policy, and architecture for the design of IT services will need to be documented and utilized to ensure that the appropriate services are provided to the business.
Best practice recommends that service design follow the continual service improvement approach and base the designs on the business requirements:
- Where do we start?
- How do we improve—the CSI approach:
- What is the vision?
- Where are we now?
- Where do we want to be?
- How do we get there?
- Did we get there?
- How do we keep the momentum going?
Challenges, Critical Success Factors, and Risks
When we consider the relationship between implementing good practices and planning, protection, and optimization processes, it is important to be aware of the challenges, critical success factors (CSFs), and risks associated with the implementation.
Challenges
Challenges will take many different forms, depending on the nature of the organization supported, but there are some common factors that will probably be applicable to all organizations in some aspect. These include
- Understanding business requirements and priorities
- Understanding organizational culture
- Effective communication to the business and service management staff
- Collaboration and engagement with all stakeholders
- Gaining commitment from management and staff
- Supplier management and contractual obligations
- Cost and budgetary constraints
These are common to most organizations, and the meeting of these challenges will be critical to the success of implementation of service management processes, including those for planning, protection, and optimization.
Critical Success Factors
As you are aware, critical success factor is a term used for an element that is necessary for an organization or project to achieve its mission. They can be used to identify the important elements of success. CSFs are measured by key performance indicators (KPIs) and should be set and measured as part of the service design lifecycle stage. The PPO processes will be critical in establishing the service requirements, and understanding the CSFs for each of the processes will provide a strong basis for the KPIs that will be used to demonstrate success in the service lifecycle stage.
Risks
As with challenges, some common risks are applicable to most organizations. They need to be appropriately identified and addressed to ensure successful service management implementation. Some examples include
- Meeting the identified CSFs
- Maturity of process
- Unclear business requirements
- Unrealistic business timeframes for service management design, transition, and operation
- Insufficient testing
- Lack of balance in focus on innovation or stability
- Lack of coordination among business, IT, and suppliers
- Insufficient resources, including cost and budget
- Lack of a holistic approach across the whole service management lifecycle
Service Management Tool Choice
Many service management tools are available, each with its own strengths and weaknesses, which makes choosing the right one difficult. To overcome this, you should define some objective selection criteria.
One simple method is MoSCoW analysis. This involves creating a detailed list of all your requirements and classifying each one as must have, should have, could have, or would like in the future.
- Must have requirements are mandatory. Any tool that does not satisfy all of those requirements is rejected.
- Should have requirements are those that we expect but are not essential.
- Could have requirements are useful but not hugely important.
- Would like in the future requirements are those that we don’t need right now but will need in the future. For example, we’re choosing a tool for incident management right now, but we’d like it to have problem management capability later.
You can then devise a scoring system based on this analysis, which would enable you to rank alternatives. It is possible to weight your decision, making a scoring system to ensure that you are getting the service management tool that delivers against your requirements.
Planning and Implementing Service Management Technologies
The final topic of this chapter is service management tools. A good service management tool can be very helpful for implementing processes based on the ITIL framework. Many organizations implement new tools to assist their implementation of new or improved processes. These organizations need to consider a number of factors if the new tool is to be helpful and appropriate.
Licenses
The first factor to be considered is the type of license. There are usually a number of options, at different costs. When tools are licensed on a modular basis, careful planning is required to ensure that the right access is obtained to enable people to carry out their work with no unnecessary modules being purchased. Here are some possible options:
Dedicated Licenses For this option, each named person has their own license. Dedicated licenses are suitable for staff that require frequent and prolonged use of a particular module. For example, service desk staff would need a dedicated license to use an incident management module.
Shared Licenses These licenses can be shared between individuals; there is, however, a possibility that a staff member may not be able to access the tool because the license is already in use. Shared licenses are suitable for regular users who do not require constant access, such as second-line support staff. Careful calculation is required to ascertain the correct ratio of users to licenses. These licenses are more expensive than dedicated licenses, but fewer are required.
Web Licenses These allow access via a web browser. Web licenses are usually suitable for staff requiring remote access or only occasional access. They usually cost a lot less than other licenses (they may even be free with other licenses). It is possible to provide sufficient access for a large number of occasional users by purchasing a small number of such licenses, since the number of concurrent users and therefore the number of licenses required will be low. In this way, overall costs can be reduced further.
On Demand Access to tools is provided when required (on demand), and the supplier charges for the access based on the time spent using the application. This can be attractive to smaller organizations or if the tools in question are very specialized and used relatively infrequently. A variation to this is the use of a specialist tool as part of a consultancy assignment (e.g., specialist capacity management tools); in such cases, the license fees are likely to be included in the consultancy fee.
Agent/Activity A further variation in license options is software that is licensed and charged on an agent/activity basis. An example of this is simulation software (e.g., agent software that can simulate customer paths through a website to assess and report on performance and availability).
In all cases, it is essential that sufficient investigation be done to ensure that the costs are understood and agreed to and that the organization remains legal in respect to having sufficient licenses.
Deployment
Many ITSM tools, particularly discovery and event monitoring tools, will require some client/agent software deploying to all target locations before they can be used. This will need careful planning and execution and should be handled through formal release and deployment management. Some deployment considerations are listed here:
- There should be careful scheduling and testing, and the deployment must be tracked so that it is clear which CIs have the software and which have yet to receive it.
- The CMS should be updated as the deployment progresses.
- It is often necessary to reboot devices for the client software to be recognized, and this needs to be arranged in advance to minimize service interruption.
- Special arrangements may be needed for portable equipment, which may not be present on site during deployment.
- The devices receiving the software must be checked in advance to ensure that they have sufficient storage and processing capacity to host and run the new software.
- The network capacity needs to be checked to ensure that it is capable of transmitting everything required.
- The best time to deploy a tool is dependent on the maturity level. A tool that is deployed too early shifts the focus of the improvement initiative away from the requirement to change processes and ways of working, and the whole improvement exercise then becomes merely a tool implementation.
- Training in the tool prior to deployment is necessary if benefits are to be realized.
Remember, a tool is usually not enough to make things work better. However, if it supports processes and the user has been trained to use it, a good tool can help staff carry out new processes.
Here are some further aspects of the deployment that must be considered:
The Type of Introduction to Be Used A decision must be made whether a “Big Bang” introduction or some sort of phased approach is to be adopted. Because most organizations will have live services to keep running during the introduction, a phased approach is more likely to be necessary.
Transition between Tools If an older tool is being replaced, consideration must be given to the best way to transition between the old tool and the new tool. For example, the service desk should not be assigning an incident on a new tool to a team that has yet to transition from the old tool.
Data Migration A decision needs to be made regarding what data needs to be migrated from the old tool to the new one. This may require reformatting, and so may need to be validated after migration, especially if the data is transferred electronically. A period of parallel running may be implemented instead, with the old tool being available in a read-only mode for an initial period alongside the new one so that historical data can be referenced if needed.
Complete details on the release and deployment management process can be found in the ITIL Service Transition publication.
Designing Technology Architectures
It is important for an IT organization to provide an infrastructure that will support the delivery of quality IT services, and this requires the correct approach to technology and technology architecture. Architecture is a term used in many different contexts. In this context it can be described as the fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. System is used in the most general, not necessarily IT, sense to mean a collection of components organized to accomplish a specific function or set of functions.
The work of architectural design must assess and reconcile many types of needs, some of which may be in conflict with one another. The work should ensure that
- IT infrastructures, environments, data, applications, and external services serve the needs of the business, not just in terms of technology but also management of the technology
- The correct balance of innovation, risk, and cost is reached
- Compliance with standards, strategies, policies, regulations, and frameworks is achieved
- There is coordination between IT planners and designers and business planners and designers
The designs, plans, architectures, and policies should cover all aspects of IT, including roles and responsibilities, services, technology, architecture and frameworks, processes and procedures, partners and suppliers, and management methods. The work of architectural design must also cover all areas of technology, including the infrastructure, environment, applications, and data, and it should be closely linked to the overall business planning and design processes.
The complete enterprise architecture can be large and complex. Enterprise architecture is defined by Gartner as
The process of translating the business’s vision and strategy into effective enterprise change by creating, communicating and improving key requirements, principles and models that describe the enterprise’s future state and enable its evolution toward it.
There are many proprietary and nonproprietary frameworks for the development of an enterprise architecture, as illustrated in Table 10.1.
TABLE 10.1 Enterprise architecture frameworks
| Full framework name | Framework abbreviation |
| Architecture of integrated information systems framework | ARIS |
| Bredemeyer framework | Bredemeyer |
| Business transformation enablement program transformation framework | BTEP |
| Department of Defense architecture framework | DODAF |
| CSC catalyst | Catalyst |
| Computer integrated manufacturing open systems architecture | CIMOSA |
| Enterprise architecture framework | Gartner |
| Enterprise architecture planning | EAP |
| Extended enterprise architecture framework | E2AF |
| Federal Enterprise Architecture (FEA) reference models | FEA |
| Generalized enterprise reference architecture and methodology | GERAM |
| Integrated architecture framework | IAF |
| Pillars of Enterprise Architecture (EA) | Forrester |
| Reference model for open distributed processing | RM-ODP |
| Technical architectural framework for information management | TAFIM |
| Treasury enterprise architecture framework | TEAF |
| The Open Group Architecture Framework (TOGAF®) technical reference model | TOGAF |
| Zachman framework | Zachman |
These frameworks include descriptions of all the relevant components and how they integrate. The enterprise architecture should be an integrated element of the business architecture and should include the following major areas:
- Service architecture
- Application architecture
- Data/information architecture
- IT infrastructure architecture
- Environmental architecture
The roles most likely to associated with the development of these architectures are often described as
- Business/organizational architect
- Service architect
- IT infrastructure architect
The real benefit and return on investment of the enterprise architecture comes not from the architecture itself, but from the ability of an organization to design and successfully implement projects and solutions in a rapid and consistent manner.
Technology Management
A strategic approach should be adopted with regard to the planning of an information technology and its management. Architectures need to be developed within the major areas of technology.
Technology Architectures
Architectures are needed in all areas of information technology. Where relevant, they need to be developed in the following areas:
- Applications and systems software
- Information, data, and database, including information security and confidentiality, data warehousing, and data mining
- Infrastructure design and architecture:
- Central server, mainframe architectures, distributed regional servers, including local file and print servers
- Data networks (LANs, MANs, WANs, VPNs, protocols etc.), Internet, intranet and extranet systems
- Converged network technologies, including voice networks (PABXs, Centrex, handsets, mobiles, faxes, etc.)
- Client systems (desktop PCs, laptop PCs, mobile access devices (handheld devices, mobile phones, palmtops, PDAs, scanners, etc.)
- Storage devices, storage area networks (SANs), network-attached storage (NAS), including backup and recovery systems and services (servers, robots, etc.)
- Document storage, handling, and management
- Specialist areas of technology such as EPOS, ATMs, scanning devices, GPS systems, etc.
- Environmental systems and equipment, including their monitoring and management
This will result in a hierarchy of architectures, which will need to be integrated to construct a set of technology architectures for the organization.
Summary
In this chapter we reviewed the generic requirements for technology required to support the PPO processes and service design lifecycle stage. We explored some of the challenges and risks associated with their implementation, and considered the importance of an enterprise infrastructure. We discussed the overall requirements of an integrated set of service management technology tools to support the processes in planning protection and optimization.
Exam Essentials
Understand the role of tools in supporting service design. This includes understanding how to select tools that are appropriate for organizational needs.
Explain the generic requirements that service design has for toolsets and why they are important. Understand the generic requirements that are applicable to PPO processes and how these tools will support the objectives of the lifecycle.
Understand the specific requirements for the individual PPO processes. Be able to identify the requirements for the individual processes from PPO to ensure maximum efficiency from the toolset.
Explain the selection technique known as MoSCoW. Know what the acronym stands for (Must/Should/Could/Would) and be able to explain the use of each concept in tool selection.
Understand the risks in implementing technology. Understand how these risks might be managed.
Understand the license options available when implementing a new service management tool. Be able to describe the different options and give examples of when each would be appropriate.
Understand the deployment options available when implementing a new service management tool. Be able to describe the different options and give examples of when each would be appropriate.
Review Questions
You can find the answers to the review questions in the appendix.
-
Which of these is most likely to be part of a self-service portal?
- The ability to reset passwords
- The ability to log requests
- The ability to authorize a change request
- The ability to download approved software
- 1, 2, and 3
- 2, 3, and 4
- 1, 3, and 4
- 1, 2, and 4
-
Management support is critical for successful service management. What benefits are expected from management’s commitment to technology and tools?
- Leadership, funding, and supporting commitment
- Higher first-time fix rate, reduced outages, and funding
- Improved customer satisfaction, reduced outages, and higher first-time fix rate
- Reduced outages, funding, and supporting commitment
-
Which of the following is not a license option for service management tools?
- Dedicated
- Time limited
- Shared
- Web based
-
Which of these considerations for reporting requirements for service management tools is important?
- Only industry-standard reports should be generated.
- No reporting capability should be integrated into the tool; it should be managed separately.
- There should be a good selection of generic reports.
- There should be a good selection of generic reports supported by easy generation of custom reports.
-
Which of the following is not a benefit of using project management for complex operational changes?
- It provides a clear, agreed statement of the benefits to be delivered by the project.
- Project management would be funded by service transition and the project office, thus providing cost savings to service operation.
- It gives greater visibility of tasks and their management, which enables other IT groups and the business to understand the contributions made by operational teams. This helps in obtaining funding for projects that have traditionally been difficult to cost justify.
- It provides greater consistency and improved quality of the deliverables.
-
Which of these statements is/are correct?
- A CMS should be an integrated part of the service management tool.
- A service management tool without an SKMS is not a true service management tool.
- Statement 1 only
- Statement 2 only
- Both statements
- Neither statement
-
Which of these would be included in the generic requirements for a service management tool?
- Remote access capability
- Capability for integration with business tools
- Capability to link records such as incident and problem records
- Web-based access
- 1, 2, and 3
- 2, 3, and 4
- 1, 2, 3, and 4
- 1, 3, and 4
-
Which of these statements about service management tools and technology is correct?
- Tools are useful but not essential.
- Tools assist good processes instead of replacing them.
- Tools can replace processes that do not function well.
- Tools define the processes we use by formalizing the steps in the design.
-
What is the MoSCoW technique used for?
- Categorization of requirements
- Categorizing incidents and problems
- Categorization of service desk components
- Design of the SKMS
-
What is the first step when choosing a service management tool?
- Define the interfaces the tool will need to integrate with business tools.
- Understand the requirements for the tool.
- Decide how staff will be trained to achieve most from the tool.
- Research the available tools.