THE FOLLOWING ITIL INTERMEDIATE EXAM OBJECTIVES ARE DISCUSSED IN THIS CHAPTER:
This part of the book covers how service design takes the outputs from service strategy, the preceding stage of the service lifecycle, and uses them to ensure that the solution designs that are produced are consistent with the overall IT service provider strategy. We have seen, in the earlier chapters of this book, how service strategy sets the objectives; service design is about providing the services that are required to deliver those objectives. Service design is also concerned with redesigning existing services and retiring services that are no longer needed. This first chapter provides an introduction to this lifecycle stage; we consider the core concepts of service design in terms of its purpose, objectives, and scope and its relationship to the other ITIL lifecycle stages.
The learning objective for this chapter is to achieve a full understanding of service design terms and core concepts. We start by looking at the purpose of service design, its objectives and scope, and how it delivers value to the business.
Service design is a critically important stage of the service lifecycle. It is in design that the intentions behind the service strategy start to be made reality. A poor service design will fail to deliver the strategy, could prevent a worthwhile return on investment, and could potentially damage the performance and reputation of the business. This stage is often rushed, however, in an attempt to meet project deadlines; such a course of action is foolish because it remains true that time spent in design saves time spent in rework later.
The purpose of the service design stage of the lifecycle is to design IT services, with the necessary supporting IT practices, processes, and policies, to realize the service provider’s strategy. It is important to understand this point—design is not just about the technical design; it also considers the way it will be used and the processes required. Design should also include thinking about how the service will be transitioned; it should facilitate the introduction of the service into the supported environment in such a way as to ensure quality service delivery, customer satisfaction, and cost-effective service provision. So it is the job of design to make the strategy a practical reality. Importantly, design must consider how the service will work.
Let’s start by considering the goals and objectives of service design. Service design has to design services to satisfy business objectives and align with business needs. This includes consideration of quality, compliance, risk, and security requirements, ensuring the delivery of more effective and efficient IT and business solutions by coordinating all design activities for IT services. Ensuring consistency of service and business focus in the design is a key goal.
Service design activities can be periodic, or they can be triggered by a specific business need or event. (We call these exception-based activities.) In an ideal world, service design would design IT services so effectively that little or no improvement during their lifecycle would be required. However, it is only when services are actually being used in the live environment that we can really understand what is required of them. The use of the services will also change over time. It is essential, therefore, for service design to embed continual improvement in all its activities. This ensures that the solutions and designs become even more effective over time. This will enable changing trends in the business that could provide improvement opportunities to be identified and acted upon.
Additional goals and objectives of service design are as follows:
The final set of goals and objectives of service design are as follows:
The scope of ITIL service design includes providing guidance for the design of appropriate and innovative IT services to meet current and future agreed business requirements. The core guidance for this lifecycle stage describes the principles of service design and looks at identifying, defining, and aligning the IT solution with the business requirement. It also introduces the concept of the service design package and looks at selecting the appropriate service design model. We shall look at the contents and use of the service design package later in this chapter, and consider service design models in more depth in Chapter 11, “Service Design Principles.”
It is a key principle of ITIL service design that the initial service design should always be driven by factors such as functional requirements, the requirements within service level agreements (SLAs), the business benefits, and the overall design constraints. The service design Intermediate course syllabus covers the methods, practices, and tools to achieve excellence in service design. It discusses the fundamentals of the design processes and attends to what are called the “five aspects of service design.”
These are the five aspects of service design:
These shall be examined later in Chapter 11, “Service Design Principles.”
Also included within the scope of service design are the service design processes:
These processes are described in detail later in the book. It should be noted that all of these processes, other than design coordination, are also active throughout the other stages of the service lifecycle and processes in other stages of the service lifecycle will impact service design. All the lifecycle processes should be linked closely together to ensure the successful management, design, support, and maintenance of the services, the IT infrastructure, the environment, the applications, and the data. The interfaces between processes need to be clearly defined when designing a service or improving or implementing a process.
In Figure 10.1, you can see the complete service design stage. It starts with a set of new or changed business requirements and ends with the development of a service solution designed to meet the documented needs of the business. This service solution, together with its service design package, is then passed to service transition to evaluate, build, test, and deploy the new or changed service or to retire the service if this is the change required. On completion of these transition activities, control is transferred to the service operation stage of the service lifecycle.
The overall scope of service design and the five aspects of design are illustrated in Figure 10.2, within the context of the IT service provider’s relationship to the business. The diagram shows how IT and the business interact through the provision of service and how the work of service design is part of the complete service lifecycle.
Adopting the best practice recommended by ITIL delivers significant business benefits. Good service design ensures both the quality and the cost-effectiveness of the service. Both aspects need to be delivered if the service is to be useful to the business. Good service design using a standard, consistent approach delivers a number of benefits, which we will consider in turn:
Service design ensures that IT services focus on supporting business processes and goals. This includes the following:
Service design needs to be considered within the context of the whole service lifecycle. Each area of the lifecycle addresses a particular set of challenges that need to be addressed for successful service management, and each stage has an impact on all of the others.
Service Strategy Service strategy is at the core of the service lifecycle. It is the role of strategy to understand the organizational objectives and customer needs. People, processes, and products should support the strategy. ITIL service strategy asks why something is to be done before thinking of how. It helps service providers to set objectives; to set expectations of performance serving customers and markets; and to identify, select, and prioritize opportunities. Service strategy ensures that providers understand and can handle the costs and risks associated with their service portfolios.
The complete list of service strategy processes is as follows: strategy management for IT services, service portfolio management, financial management for IT services, demand management, and business relationship management.
Service Design Service design, the subject of Part 2 of this book, turns strategic ideas into deliverables. The design must always consider the strategy to ensure that services are designed with the business objectives in mind. Design considers the whole IT organization and how it will deliver and support the services, turning the service strategy into a plan for delivering the business objectives. Remember, design includes changes to existing services and retiring those services no longer required.
The complete list of service design processes is as follows: design coordination, service catalog management, service level management, availability management, capacity management, IT service continuity management, information security management, and supplier management. These processes ensure that both the utility and the warranty of the new or changed service is considered in design, covering the continuity of the service, its achievement of service levels, and conformance to security standards and regulations.
Service Transition Service transition provides guidance for developing and improving capabilities for introducing new and changed services into supported environments. The value of a service is identified in strategy, and the service is designed to deliver that value. Service transition ensures that the value is realized by enabling the necessary changes to take place without unacceptable risks to existing services. Service transition enables the implementation of new services, and the modification of existing services, to ensure that the services provided deliver the service strategy of achieving the business objectives and that the benefits of the service design are fully realized. Service transition also introduces the service knowledge management system, which ensures that knowledge is stored and made available to all stages of the service lifecycle, making sure lessons are learned and decisions are backed with factual data, leading to improved efficiency and effectiveness over time.
The complete list of service transition processes is as follows: transition planning and support, change management, service asset and configuration management, release and deployment management, service validation and testing, change evaluation, and knowledge management. Each process has a role to play to ensure that beneficial changes can take place and, as a consequence, the service can be introduced and will work as transitioned.
Service Operation Service operation describes best practice for managing services in supported environments. It includes guidance on achieving effectiveness, efficiency, stability, and security in the delivery and support of services to ensure value for the customer, the users, and the service provider. Without this, the services would not deliver the value required and the achievement of business objectives would become difficult or impossible.
The service operation stage is therefore critical to delivering the design and, in doing so, achieving the service strategy. Service operation provides detailed guidance for delivering the service within the agreed service levels by tackling issues both proactively, through problem management, and reactively, through incident management. It provides those delivering the service with guidance for managing the availability of services, controlling demand, optimizing capacity utilization, scheduling of operations, and avoiding or resolving service incidents and managing problems. It includes advice on shared services, utility computing, web services, and mobile commerce. By delivering the services to the agreed levels, service operation enables the business to use the services to achieve its business objectives.
The complete list of service operation processes is as follows: event management, incident management, request fulfilment, problem management, and access management. We shall be considering each of these in the service operation section of this book, in the chapters covering service operation processes. Each process has a role to play to ensure the delivery of services within the agreed service levels. Service operation also describes the four service operation functions: the service desk, technical management, IT operations management, and application management. Each function is responsible for managing its own area of delivery across all stages of the lifecycle.
Continual Service Improvement The final stage of the lifecycle is continual service improvement. CSI ensures that the service provider continues to provide value to customers by making sure the strategy, transition, and operation of the services is under constant review. Feedback from any stage of the service lifecycle can be used to identify improvement opportunities for any other stage of the lifecycle. It ensures that opportunities for improvement are recognized, evaluated, and implemented when justified. These may include improvements in the quality of the service or the capabilities of the service provider. It may be developing ways of doing things better or doing them to the same level but more efficiently. Improvements may be major or small and incremental. It enables every new operation to incorporate lessons from previous operations.
CSI ensures that feedback from every lifecycle stage is captured, analyzed, and acted upon. The CSI approach to improvement is based on establishing a baseline and checking to see whether the improvement actions have been effective. It uses the Plan-Do-Check-Act (PDCA) cycle, together with service measurement, demonstrating value with metrics and conducting maturity assessments. The seven-step improvement process provides a framework for these approaches.
In addition to these long-term improvement initiatives, there are the short-term ongoing improvements; these are the improvements made to working practices within the processes, functions, and technologies that underpin service design. They are generally smaller improvements that are implemented without any change to the fundamental nature of a process or technology. Examples include tuning, workload balancing, personnel redeployment, and training.
The main inputs to service design are requirements for new or changed services. The main output of service design is the service design package, which includes all of the information needed to manage the entire lifecycle of a new or changed service. We shall look at the service design package later in this chapter, but first we examine the particular inputs to service design and outputs from design for each lifecycle stage.
The inputs from strategy into service design are as follows:
Strategy provides the vision and mission about what is to be done. The decision regarding what services should form the portfolio is made in the strategy stage of the lifecycle, along with other strategies and plans.
Strategy provides the utility and warranty requirements to design for the new service. It formulates the service packages and service charters (these are covered in detail in the service strategy course). Strategy documents the patterns of business activity and the different user profiles and decides upon the service models. Finally, strategy is in control of the money—design can start its work only when strategy has decided to fund it.
Let’s now consider the reverse flow, the outputs from design into strategy:
Design provides important information that strategy uses in the service portfolio and to draw up business cases. The major output from design is the service design package, and this is an input to the strategy phase as well as to other lifecycle stages. Other outputs to strategy from design include updates to the service models, service catalog, and portfolio. Design will produce new process designs for strategy processes, will update the service knowledge management system, and produce financial reports and estimates to feed back into financial management.
Following the activities of service design, a number of outputs are passed to the next stage, that of transition:
The major output is the service design package (SDP), which includes the details of the new or changed service and plans for its transition and operation. We will look at the SDP in more detail shortly. Design will also raise the requests for change to kick off the transition and deployment. In addition, design will provide input to the evaluation process so that it is clear how the service is expected to behave and what benefits it is expected to deliver. Design may also provide information to the change advisory board to help in their deliberations. Finally, the SLAs, OLAs, and underpinning contracts that were drawn up as part of the design process of service level management are passed to transition. It will be the job of transition to ensure that the new or changed service meets the agreed service levels by the time it is accepted into operation.
Service design takes a number of outputs from transition. These are mostly in the form of feedback and potential improvements for the next service design:
Transition will provide feedback on every aspect of service design and on the adequacy of the service design package. Transition will also respond to the proposed transition plan it received from design, with any suggested amendments. Reports from the evaluation stage will be fed back to design, along with details of any design errors that came to light during transition and require redesign.
In addition, transition will respond to the requests for change raised by service design and will update the service knowledge management system and configuration management system as the service is deployed.
Service design provides the following outputs to the operation stage:
As you may notice, some of these were also outputs to other stages, particularly the service design package. Here, though, the SDP content that is passed to operations is particularly concerned with the operation of the new or changed service, containing details of utility and warranty that should be delivered in operations along with plans, procedures, processes, and security policies for operations to carry out. Again, we can see that the SKMS is updated. The utility and warranty requirements are backed up with the hardware and software maintenance requirements and details of the SLA to be delivered together with the underpinning OLAs and contracts that will be needed to meet the SLA successfully. Finally, details of vital business functions are passed to operations to assist in the assessment of the impact of incidents and their prioritization.
The service operation stage of the lifecycle provides the following inputs into service design:
The operational requirements to be incorporated into the design and the actual performance information ensure that design understands how the service is performing. Any operational issues that arise could result in an RFC to have a design change, and the provision of historical incident and problem records will show design the issues to be avoided in the new design.
Design provides the following outputs to the continual service improvement lifecycle stage:
CSI will need the service catalog, the SKMS, and the service design packages with the details of the utility and warranty requirements to identify which services are failing to meet their requirements and need to be improved. The achievements of the different service design processes against key performance indicators will identify which processes need improvement. CSI will also need to understand the design of the services, processes, and so on to identify where improvements can be made. Service design is responsible for the design of the seven-step improvement process and procedures.
Service design will also suggest improvements, which will be logged in the CSI register.
The outputs from continual service improvement to design are as follows:
The results of customer and user satisfaction surveys, indicating how well the design meets their requirements, will show where it should be improved. Feedback on the service design packages will be used by design to improve future SDPs. CSI will raise the RFCs required to implement design improvements. Finally, service reports and other data required for metrics, KPIs, and CSFs are provided by CSI to service design.
Table 10.1 summarizes service design inputs and outputs by lifecycle stage.
Table 10.1 Summary of service design inputs and outputs by lifecycle stage
Lifecycle stage | Service design inputs (from the lifecycle stage in the first column) | Service design outputs (to the lifecycle stage in the first column) |
Service strategy | Vision and mission
Service portfolio Policies Strategies and strategic plans Priorities Service charters, including service packages and details of utility and warranty Financial information and budgets Documented patterns of business activity and user profiles Service models |
Input to business cases and the service portfolio
Service design packages Updated service models Service portfolio updates, including updates to the service catalog Financial estimates and reports Design-related knowledge and information in the SKMS Designs for service strategy processes and procedures |
Service transition | Service catalog updates
Feedback on all aspects of service design and service design packages Input and feedback on transition plans Response to requests for change (RFCs) Knowledge and information in the SKMS (including the CMS) Design errors identified in transition for redesign Evaluation reports |
Service catalog Service design packages, including:
|
Service operation | Operational requirements
Actual performance information RFCs to resolve operational issues Historical incident and problem records |
Service catalog Service design package, including:
|
Continual service improvement | Results of customer and user satisfaction surveys
Input to design requirements Data required for metrics, KPIs, and CSFs Service reports Feedback on service design packages RFCs for implementing improvements |
Service catalog
Service design packages, including details of utility and warranty Knowledge and information in the SKMS Achievements against metrics, KPIs, and CSFs Design of services, measurements, processes, infrastructure, and systems Design for the seven-step improvement process and procedures Improvement opportunities logged in the CSI register |
Copyright © AXELOS Limited 2010. All rights reserved. Material is reproduced under license from AXELOS.
The service design package is the major output of service design. This is a collection of documents defining all aspects of the service. It could include technical design documents, service level agreements, acceptance criteria, business requirements, testing plans, and so on. Without the service design package pulling all these documents together into one place, there would be no single source of accurate information regarding the service.
The service design package should be produced during the design stage, for each new service, each major change to a service, the removal of a service, or even for changes to the service design package itself. It is passed from service design to service transition and from transition to operations. It details all aspects of the service and its requirements through all of the subsequent stages of its lifecycle.
The service acceptance criteria is a set of criteria used to ensure that the service meets its expected functionality and quality and that the service provider is ready to deliver the new service once it has been deployed. It can be used as a checklist to ensure that nothing has been forgotten. Table 10.2 shows typical service acceptance criteria.
Table 10.2 Typical service acceptance criteria
Criteria | Responsibility |
Have the “go-live” date and the guarantee period been agreed with all concerned parties, together with final acceptance criteria? | Change, service level |
Have the deployment project and schedule been documented, agreed, and made public to all affected personnel? | Change, incident |
Have the service level agreement (SLA) and service level requirements (SLRs) been reviewed, revised, and agreed with all concerned parties? | Service level |
Has the service been entered/updated in the service catalog/service portfolio within the configuration management system (CMS) and appropriate relationships established for all supporting components? | Service level, configuration |
Have all customers and other stakeholders been identified and recorded in the CMS? | Service level, business relationship |
Have all operational risks associated with running the new service been assessed and mitigation actions completed where appropriate? | Business continuity, availability |
Have contingency and fail-over measures been successfully tested and added to the overall resilience test schedule? | Business continuity, availability |
Can all SLA/SLR targets be monitored, measured, reported, and reviewed, including availability and performance? | Service level, availability |
Have all users been identified/approved and the appropriate accounts created for them? | Account management |
Can all workload characteristics, performance, and capacity targets be measured and incorporated into capacity plans? | Capacity |
Have all operational processes, schedules, and procedures been agreed, tested, documented, and accepted (e.g., site documentation, backups, housekeeping, archiving, retention)? | Operations, business continuity |
Have all batch jobs and printing requirements been agreed, tested, documented, and accepted? | Operations |
Have all test plans been completed successfully? | Test manager |
Have all security checks and tests been completed successfully? | Security compliance |
Are appropriate monitoring and measurement tools and procedures in place to monitor the new service, together with an out-of-hours support rota? | Systems management |
Have all ongoing operational workloads and costs been identified and approved? | Operations, IT finance |
Are all service and component operational costs understood and incorporated into financial processes and the cost model? | IT finance |
Have incident and problem categories and processes been reviewed and revised for the new service, together with any known errors and deficiencies? | Incident, problem reporting |
Have all new suppliers been identified and their associated contracts drawn up accordingly? | Contract and supplier management |
Have all support arrangements been reviewed and revised—SLAs, SLRs, operational level agreements (OLAs)—and contracts agreed, with documentation accepted by all teams (including suppliers, support teams, supplier management, development teams, and application support)? | Project manager |
Has appropriate technical support documentation been provided and accepted by incident, problem, and all IT support teams? | Incident, problem |
Have all requests for change and release records been authorized and updated? | Change |
Have all service, SLA, SLR, OLA, and contract details, together with all applications and infrastructure component details, been entered on the CMS? | Project management, support teams configuration |
Have appropriate software licenses been purchased or reallocated licenses used? | Configuration |
Have any new hardware components been recorded in the CMS? | Configuration |
Have all new software components been lodged in the definitive media library (DML) with details recorded in the CMS? | Configuration |
Have all maintenance and upgrade plans been agreed, together with release policies, frequencies, and mechanisms? | Release and deployment |
Have all users been trained, and has user documentation been accepted and supplied to all users? | Project manager |
Are all relationships, interfaces, and dependencies with all other internal and external systems and services documented, agreed, and supported? | Project manager |
Have appropriate business managers signed off on acceptance of new service? | Project manager |
Copyright © AXELOS Limited 2010. All rights reserved. Material is reproduced under license from AXELOS.
Understand the purpose of service design The purpose of service design is to design IT services with the necessary supporting IT practices, processes, and policies to realize the service provider’s strategy. Design is not just about the technical design; it also considers the way it will be used and the processes required.
Understand that services must be designed to be adaptable to future requirements. Services should be designed so that they are able to be easily expanded or developed to meet changing requirements.
Be able to list and explain the five aspects of service design. The five aspects of service design are the design of service solutions, management information systems and tools, architectures, processes, and measurements.
Understand how good design delivers financial and other benefits to the business. When the design fits the business requirement and is adaptable to changing requirements, the need to completely redesign the service is avoided, thus minimizing the total cost of ownership.
This chapter covered the purpose, goals, objectives, and scope of service design and how this lifecycle stage delivers value to the organization. We looked at service design within the context of the service lifecycle. We also discussed service design inputs and outputs and the contents and use of the service design package and the service acceptance criteria.
You can find the answers to the review questions in the appendix. Which of the following is NOT a purpose of service design? Which of the following are goals of service design? Which of the following is NOT one of the five aspects of service design? What is being defined here? “Document(s) defining all aspects of an IT service and its requirements through each stage of its lifecycle. A _______________ is produced for each new IT service, major change, or IT service retirement.” Which of the following is NOT a possible service acceptance criteria? Which of the following is NOT a service design process? Which of the following is NOT a benefit of effective service design? Which of the following are inputs into service design from service strategy? Which stage of the lifecycle provides the following outputs, and to which stage are they an input? Which of the following are valid inclusions in a service design package?Review Questions