THE FOLLOWING ITIL INTERMEDIATE EXAM OBJECTIVES ARE DISCUSSED IN THIS CHAPTER:
In this chapter, we’ll consider the core concepts of service design. We’ll start by looking at service design principles and then examine service design in more detail, looking at the principles that underpin good design and considering the various aspects that together make up the overall design. We’ll also consider the importance of creating a balanced design. This chapter covers the following topics.
The learning objective for this module of the exam syllabus is to gain sufficient knowledge to interpret and analyze service design principles, techniques, and relationships and their application to the design of effective service solutions. In particular, the student should understand the following:
When a design needs to be changed or any of the individual elements of the design need to be amended, consideration must be given to all aspects. This is called having a holistic service design. When a new application is being designed, its impact on the overall service, the management information systems and tools (e.g., service portfolio and service catalog), the architectures, the technology, the service management processes, and the necessary measurements and metrics all need to be considered. This will ensure not only that the design considers the functional elements, but also that all of the management and operational requirements are included. The requirements should be a fundamental part of the design and not added as an afterthought.
The holistic approach and the five aspects of design are important parts of the service provider’s overall service management system. Adopting a holistic approach when planning for changes to the service and for its retirement helps prevent unforeseen consequences. Unless carefully planned, the retirement of a service or any aspect of a service could cause avoidable negative effects on the customer or business. A holistic approach ensures integration of all activities and processes, providing the end-to-end functionality and quality that the business requires.
Not every change will require the same level of service design activity. Although every change needs to be designed, not every change requires a large design overhead. Often changes have been carried out many times before and have an accepted approach, so minimizing the design effort required. It is important to remember that a seemingly small change may have a large potential impact, so each organization needs to define what level of design activity is required for different categories of change. As with all guidelines, the message should be clear and unambiguous and communicated to all staff. An important part of the change management impact assessment is assessing the service design requirements of each change. More information about the change management process, including impact assessment, is described within the ITIL Service Transition publication and in Part 3 of this book.
For a service to deliver value, its design must deliver both utility and warranty (see Figure 11.1). Utility is the functionality offered by a product or a service to meet a specific customer need. Warranty provides the assurance that a product or service will meet the agreed requirements. It refers to the ability of the service to be available when needed, to have sufficient capacity to meet the requirements, and to be reliable in terms of both security and continuity.
We will look at the particular processes of availability, capacity, security, and service continuity in the next four chapters, which cover service design processes, but we’ll consider them briefly here because it is a basic principle of service design that all of these aspects must be considered and delivered in an integrated manner.
It is essential that IT systems and services are designed, planned, implemented, and managed to suit the business requirements.
IT services must be business and customer oriented. The focus must be on delivering the business requirement, and therefore achieving the business strategy, rather than on the technology used. A good service that is too expensive will fail to deliver the business benefit, so the design must also consider cost-effectiveness.
The warranty aspects of the service must be incorporated into the design. This means that the design must meet the customer’s security requirements and provide the appropriate availability and capacity for business needs, and it must also offer the required service continuity.
Service design must deliver services that can be managed and operated with an acceptable level of risk. They must perform well at the point of delivery while also offering flexibility and adaptability. They should be designed to be able to cope with increasing volume and speed of change as needs change. There is a temptation to minimize or ignore the design and planning processes. This is dangerous because the overall quality of the design depends upon the quality of the planning process. Although there may be pressure to deliver in a particular timeframe, the time spent on design should be protected because skimping on this area may cause delays and expense later. This is an important principle that needs to be understood by those carrying out the design and those exerting the pressure for delivery. There may be some circumstances in which meeting the delivery date is critical, even if it means a design that will need rework later, but these situations are rare. In most cases, in order for the service to deliver the required value to the business, the design stage must be given sufficient time and resources.
The service provider should be able to develop expertise in this area, producing a repeatable process that can be used for future services. Having a mature service design practice will also reduce risk in the transition and operational stages of service. Where resources are stretched, the projects and services that have the greatest impact or benefit to the business should be prioritized so that effort is targeted at the areas that will yield the greatest return.
An integral part of design is understanding and managing risk to ensure that the risks involved in the provision of services and the operation of processes, technology, and measurement methods are aligned with business risk and impact.
The implementation of IT service management as a practice is about preparing and planning the effective and efficient use of the four Ps of service design: the people, the processes, the products (the services, technology, and tools), and the partners (the suppliers, manufacturers, and vendors). Service design must consider each of the four Ps to ensure a robust design that meets the requirements, as shown in Figure 11.2.
Service design must consider all aspects of the design:
Listed here is a set of questions that need to be answered when undertaking a design for a new or changed service:
You need to understand the functional requirements and the business process being supported. You need to know how the service being offered supports these. And you need to be aware of any relevant policies or strategy and any governance or compliance requirements. The service requirements must be clear, and the necessary service level agreements (SLAs) need to be in place. The technical design must be understood, and the necessary components need to be available and ready to deliver the service, along with any environmental requirements such as power and air conditioning. You need to understand where the data is going to come from and have it verified for accuracy. The applications required to manipulate the data and provide the functional requirements of the business processes must be designed and validated. The requirements for any supporting services that are necessary to support the operation of the delivered service must be identified. The requirement for support from internal teams or suppliers must be agreed and documented in the OLAs and underpinning contracts. Finally, the service management processes needed to ensure the successful provision of the service must be considered.
Figure 11.3 shows the composition of a service. You can see how the business requirement and the governance and compliance requirement are the inputs into defining what the utility of the service needs to be. The SLAs take these SLRs and define the warranty requirements; each SLA is then underpinned with the appropriate OLAs and underpinning contracts, defining what the support teams and suppliers will deliver. This is the assets and capabilities layer. The service itself is designed in terms of the assets and resources it requires, such as infrastructure, environment, data, and applications. Finally, the service management processes support the management of the resources or products, the people, and the third-party partners.
All service design needs to balance the functional requirements and the performance targets (that is, the functionality of the service with how it will operate). In other words, it needs to ensure that all required utility and warranty can be delivered by the service being designed. This balance must be achieved within the time and cost restraints. Failure to meet the deadline, going over budget, delivering a service without the necessary functionality, or delivering one that fails to perform as required—any of these outcomes will prevent the value of the service from being realized. Design must therefore balance all of these requirements.
Jim McCarthy, author of Dynamics of Software Development (Microsoft Press, 2005), states that as a development manager, you are working with only three things:
Functionality The service or product and everything that is part of the service and its provision
Resources The people, technology, and money available for the effort
Schedule The timescales for completion
You should note that throughout service design, the word functionality typically refers primarily to the utility of a service—what it does for the customer. In this context, however, McCarthy was using the term to refer to both utility and warranty (what the service will do and how it will do it)—this is what is being designed.
Figure 11.4 shows the three aspects of resources, time (i.e., schedule), and functionality. Changing any one of the three elements will impact the other two; overemphasizing or ignoring one will unbalance the design. You use resources to deliver this functionality to the customer within the schedule required. The service provider must always remember that the customer’s business requirements include not only the details of the service itself but also the cost and the schedule.
It is likely that business drivers and needs will change during design and delivery. Services should be designed so that they continue to deliver value throughout the lifecycle—often designers fail to consider what happens after the implementation of the service into the live environment. A holistic approach should ensure that not only does the service deliver the agreed requirements of the business, it is designed so that it can be effectively managed and improved throughout its operational life to achieve all of its agreed service targets.
We discussed the need for a holistic approach to design earlier in this chapter. When you consider service requirements as part of this holistic approach, you need to understand not only the service, but also its constituent components and their interrelationships.
There are a number of things that we must ensure:
The relationships and dependencies between these elements are illustrated in Figure 11.5. Services are not designed in isolation. It is essential that the staff of the service provider organization understand the supporting components and supporting services of each service. The targets set within the OLAs and contracts must relate to and underpin those agreed between the service provider and its customers.
As you have seen, the elements of a service are interrelated. Should any element be changed, the impact of that change on all the other elements must be understood and catered to. So the design of a new or changed service may require numerous changes to the elements that contribute to the service. Because these various elements might be provided by a number of third-party suppliers, such changes need to be coordinated by a central service design authority to ensure that services and processes are fully integrated across all parties.
There are four separate technology domains that support components of every service, and design needs to address all four. The four domains are as follows:
Infrastructure The management and control of all of the infrastructure elements used by the service, including servers, network equipment, database systems, mass storage systems, systems software, utilities, backup systems, firewalls, development and test environments, management tools, and so on.
Environmental The management and control of all major equipment rooms. This includes planning the use of the physical space and layout as well as the power, air-conditioning, cabling, physical security, and other environmental requirements.
Data/Information The means of managing and controlling the data and information. This includes ensuring that access to the data is controlled as required. It may include the management of test data.
Applications The management of application software, including that which has been bought in and applications that have been developed in-house.
In order for IT to provide services that meet the business needs, it must have accurate information on business requirements and drivers. Business drivers are the people, information, and tasks that support the fulfilment of business objectives. Maintaining the accuracy and completeness of this information requires IT to have a close relationship with the business. IT needs to be aware of the operational, tactical, and strategic requirements of the business. The business relationship management process detailed in ITIL Service Strategy is vitally important to achieving this aim.
The business information needs to be obtained and agreed in three main areas:
Existing Services IT must understand how existing services are used and be aware of any changes that may be required with regard to increased utility requirements, changes in volumes of service transactions, service level targets, and so on. Changes in business processes may have an impact on the criticality and impact of the service, either increasing or decreasing its importance.
New Services Information on the requirements of new services is needed. This includes information about how they support the business, the utility, warranty, and management information. Seasonal fluctuations in demand, the likely future growth in demand for the service, and the type of changes that may be required in the future must all be considered.
Retiring Services IT needs information on which services or parts of services are to be retired, when and how this should happen, and what the replacement will be. The disposal and/or reuse requirements for the service assets and configuration items need to be agreed upon, as does the archiving strategy for any business data.
Collecting information on the business requirements is the first and most important stage for designing and delivering new services or major changes to existing services. Information must be accurate, and the business must appreciate how important it is to provide the information accurately. Senior business support for this is necessary because a design based on incomplete or inaccurate information will inevitably result in the design of services that do not match the needs of the business. Business requirements may change over time, so there needs to be a formal process for documenting and agreeing on these changes. Requirements should be documented in a clear, concise, and unambiguous manner.
As we said previously, spending time to capture the requirements accurately will prevent issues later and will minimize the likelihood of there being a gap between the business expectation for the service and what is delivered. As part of the gathering business requirements stage, a number of actions should take place:
All design activities are triggered by changes in business needs or service improvements. A structured and holistic approach to the design activities should be adopted to ensure that consistency and integration are achieved within all design activities throughout the IT service provider organization. Too often organizations focus on the functional requirements, almost to the exclusion of other important areas such as manageability and operational requirements. A design or architecture by definition needs to consider all design aspects. It is not a smaller organization that combines these aspects, it is a sensible one.
Once the desired service solution has been designed, service design must carry out three activities before the solution passes into the service transition stage:
If external supplier services and solutions are involved, choosing a supplier and solution will involve evaluating alternative solutions:
It is important to remember that costing should include both one-off costs and the ongoing costs of operation and ownership, including support and maintenance. More information about service economics and service costing is covered in Part 1 of this book, “Service Strategy.”
Most solutions require some involvement from external suppliers. The following activities are required to procure the solution:
The development phase consists of translating the service design into a plan for the development, reuse, or redevelopment of the components required to deliver the service and the subsequent implementation of the developed service.
Major service changes may need to be developed into a program of plans, each responsible for delivering one or more components. The plans should include the following:
Careful project management should avoid conflict and ensure compatibility of components sourced from different development activities.
All design activities operate within a number of constraints. These constraints come from the business and service strategy and cover many different areas, as illustrated in Figure 11.6. Designers are not always “free” to design the most desirable solution; they must always take these constraints into consideration.
The most important constraints are the utility and warranty requirements because any solution that does not satisfy these will not deliver the required business value. Cost is another obvious constraint; the budget may not stretch to the best technical solution. The designer must either work within the constraints or seek to have them changed, by negotiating a bigger budget, for example.
There may also be many external factors that can influence the design, as shown in Figure 11.7. Many arise from the need for good corporate and IT governance, and others are from the requirement for compliance with regulations, legislation, and international standards. Designers must recognize these constraints and ensure that their design includes all of the necessary controls and capability required by them.
We are now going to spend some time considering the five aspects of service design. We listed these in Chapter 10, “Introduction to the Service Design Lifecycle Stage.” As a reminder, the five aspects are as follows:
You should remember studying these five aspects before, as part of the Foundation course. Here you will look at them in more depth. You need to ensure that, for each of the five aspects, the desired business outcomes and planned results are clearly defined. This should help ensure that the final service delivered meets the expectations of the customers and users. Each of the five aspects must focus on this to facilitate quality, consistency, and continual improvement.
The key aspect is the design of new or changed service solutions to meet changing business needs. Every new solution must be checked to ensure that it conforms to the five aspects and will interface with other services successfully.
Service design is responsible for creating plans for the design, transition, and subsequent operation of these five different aspects. The plans should include the following items:
The plans should result in the production of a service design package containing everything necessary for the subsequent testing, introduction, and operation of the solution or service. This should include the production of a set of service acceptance criteria (SAC) that will be used to ensure that the service provider is ready to deliver and support the new or changed service in the live environment. We looked at the contents and use of service acceptance criteria in Chapter 10.
There are many activities to be completed within service design. Managing them all and meeting the time, budget, and quality criteria is challenging and requires a formal and structured approach. This will facilitate the delivery of the new service at the right cost, utility, and warranty and within the right time frame.
An example of such an approach and its constituent stages is shown in Figure 11.8, together with the other major areas that will need to be involved along the way. This is a complex diagram; take the time to fully understand it.
The diagram shows the lifecycle of a service from the initial or changed business requirement through the design, transition, and operation stages of the lifecycle.
First you see how the service moves through a design and development stage, into a pilot, and finally into the live operations stage. The project team is involved during the first two stages, but not in the live operations stage. You can see the involvement of the service level management and change management processes throughout and the release and deployment management processes of service transition.
You can see how the business requirements feed into the service acceptance criteria (SAC). Documented requirements and service level requirements are produced during the strategy and design lifecycle stages.
As the solution is designed, developed, and built, the business requirements continue to feed into the SAC, allowing for any changes to be incorporated (if this is agreed). The SLRs and SAC will be updated to fit the changed requirement. The service is then tested in transition against the criteria and deployed. It is important that knowledge transfer between the operational staff and the project staff takes place at all stages to ensure smooth progression through each of the stages illustrated.
The diagram also shows the role of the project team within this activity of delivering new and changing IT services to the business and its relationship to design activities. This approach must be iterative/incremental to ensure that the service meets the evolving needs of the business as these needs develop during the business process development and the IT service lifecycle. Additional project managers and project teams may need to be allocated to manage the stages within the lifecycle for the deployment of the new service.
Now we’ll begin to look at each of the five aspects of service design in detail. The first of these that we’ll examine is designing service solutions. The following areas need to be considered within the design of the service solution:
It is an essential responsibility of design to ensure that the service acceptance criteria are planned into the initial design. Alternative designs should be evaluated and costed to ensure that the final design is the optimum approach:
Before commencing on building the solution, a check should be made that it is in line with all corporate and IT strategies, policies, plans, governance and security controls, and architectural documents. If there is any aspect where the design is in conflict with any of these, either the solution will need to be revised or a change will need to be made to the strategic documentation. Any such change to strategy or policies may have repercussions that will need to be taken into account. The changing of strategy will involve a significant amount of work and will be done in conjunction with service strategy.
The best designed service solution will fail if the organization is not ready to use it. An organizational readiness assessment should be carried out to ensure that the organization has the appropriate capability to deliver to the agreed level. This will include the following:
Next we’ll consider the second aspect of service design, the design of the management information systems and tools. These systems and tools will be essential to the management of the service throughout its lifecycle. Management information systems are usually part of a larger framework of policies, processes, functions, standards, guidelines, and tools that are planned and managed together and used to ensure that the desired objectives are achieved. This larger system, or framework, is known as a management system, and examples include a quality management system, an information security management system, or even the overall service management system.
The service management system may include the service portfolio, CMS, capacity management information system (CMIS), availability management information system (AMIS), security management information system (SMIS), and supplier and contract management information system (SCMIS).
The service portfolio (Figure 11.9) is the most critical management information system. It supports all processes and describes a provider’s services in terms of business value. It articulates business needs and the provider’s response to those needs.
The service portfolio either clarifies or helps to clarify the following strategic questions:
Ideally the service portfolio should form part of a comprehensive service knowledge management system (SKMS) and be registered as a document in the configuration management system (CMS). Further information on both the CMS and the SKMS is provided within ITIL Service Transition. Once a strategic decision to charter a service is made, this is the stage in the service lifecycle when service design begins architecting the service, which will eventually become part of the service catalog.
Each organization should choose the content and access allowed to its own service portfolio. The following content is required for each service included in the portfolio:
The service portfolio is the main source of information on the requirements and services and needs to be very carefully designed to meet all the needs of all its users. The design of the service portfolio needs to be considered in the same way as the design of the IT service itself to ensure that it meets all of these needs.
You should remember from your Foundation level study that the portfolio is made up of the pipeline, the catalog, and retired services.
The service pipeline is a database or structured document listing all services that are under consideration or development but are not yet available to customers. It provides a business view of possible future services and is not normally published to customers. The pipeline contains details of all of the business requirements that have not yet been addressed via existing services. It is used to define, analyze, prioritize, and approve all requests for new or changed services to ensure that new and changed services are aligned to business requirements. It is an input to the activities of the service strategy and service design stages of the service lifecycle, but it also provides valuable input to service transition.
The service catalog is another database or structured document. It contains information about all live IT services, including those available for deployment. The service catalog is the only part of the service portfolio published to customers, and it’s used to support the sale and delivery of IT services. It includes information about deliverables, prices, contact points, ordering, and request processes. It is essential that all of the details within the overall service portfolio are accurate and updated as a service moves from the pipeline into the catalog. We’ll look in more detail at the service catalog and its management in Chapter 12, “Service Design Processes: Design Coordination and Service Catalog Management.” The retired services area of the service portfolio represents services that are phased out or retired. The retirement of a service must be carefully planned during service design and is managed through service transition. When services are retired, the related knowledge and information is stored in a knowledge base for future use.
The service portfolio should contain information relating to every service and its current status within the organization. It is recommended that the service portfolio include the following status options:
Requirements A set of outline requirements have been received from the business or IT for a new or changed service.
Definition The requirements for the new service are being assessed, defined, and documented, and the SLR is being produced.
Analysis The requirements for the new service are being analyzed and prioritized.
Approved The requirements for the new service have been finalized and authorized.
Chartered The new service requirements are being communicated and resources and budgets allocated.
Design The new service and its constituent components are being designed and procured, if required.
Development The service and its constituent components are being developed or harvested, if applicable.
Build The service and its constituent components are being built.
Test The service and its constituent components are being tested.
Release The service and its constituent components are being released.
Operational/Live The service and its constituent components are operational within the live environment.
Retiring The service is still being delivered in the live environment to legacy customers but will not be sold to or activated for new customers.
Retired The service and its constituent components have been retired.
The service portfolio would therefore contain details of all services and their status with respect to the current stage within the service lifecycle, as shown in Figure 11.10.
A service should appear in the service pipeline from the “requirements” status to the “chartered” status. Once a service achieves the “operational” status in the live environment, it should appear in the service catalog. Between “chartered” and “operational,” each organization should decide on a clear policy regarding when a service will move from pipeline to catalog. Between “operational” and “retired,” each organization should decide upon a clear policy regarding when a service will move from catalog to retired services. The responsibility and accountability for a service at different stages should be clearly defined.
As part of the design of its service portfolio, each organization should define clear policies regarding the service lifecycle and the relationship between each service status and the service’s progression through the sections of the service portfolio. The relationship between service status and portfolio shown in Figure 11.10 is one possible approach. In this example, services within the service portfolio between “chartered” and “retiring” appear in the service catalog and are therefore accessible to customers and users.
Each version of a service should be assigned a number or other unique identifier to assist in clearly monitoring the progress of that version of the service throughout its lifecycle. Ideally, each particular version of a service should exist in only one section of the portfolio at a time. Newer versions of a service may be in the pipeline while the current version is in the catalog or in the catalog while an older version is in the retired services.
Clear rules are needed where multiple versions exist in the same portfolio section. There may be two or more versions in the catalog due to a phased rollout. Service strategy and design staff need access to the whole portfolio; other staff need only a subset. It should be noted that the portfolio is designed during service design but managed through strategy.
Architectural design can be thought of as the blueprint of the development and deployment of an IT infrastructure to satisfy the current and future needs of the business. In this context, architecture is defined as the fundamental organization of a system—that is, how its components relate to each other and to the environment and the principles guiding its design and evolution.
The system could be, for example, a whole organization, a business function, a product line, or an information system. Each of these systems will have an “architecture” made up of its components; the relationships between the components; the relationships between the system and its environment; and the design principles that inform, guide, and constrain its structure and operation as well as its future development.
Enterprises are complex and usually include the following components:
We are concerned with the architectures of the business of the organization and the information systems that support it. Each of these architectures calls on distinct architectural disciplines and areas of expertise, as seen in Figure 11.11.
In this diagram you can see enterprise architecture, service architecture, application architecture, and data architecture. The IT infrastructure and environmental architectures are also shown.
Gartner defines enterprise architecture 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” (Basualdo, Militza. “Business Value through Enterprise Architecture.” Gartner, 2010. Executive Programs Road Notes). This should be an integrated element of the business architecture and should include the major architectures: service, application, data/information, infrastructure, technology, and environmental architectures. Let’s consider these different architectures in turn:
Management architectures need to be business aligned, not technology driven. There are two separate approaches to developing a management architecture: either use a proprietary integrated management architecture across the whole infrastructure or adopt a “best of breed” architecture for each requirement.
In Figure 11.12, you can see how these different architectures relate to each other. Take a moment to study it.
Enterprise architecture frameworks include the following items:
They show how these components interoperate and contribute to the achievement of business goals and objectives and provide the basis for identifying the requirements for information systems that support these business processes. The real benefit and return on investment of the enterprise architecture comes from the ability of an organization to design and successfully implement projects and solutions in a rapid and consistent manner.
There are a number of enterprise architecture frameworks that have been widely adopted, including these two:
The Open Group Architecture Framework (TOGAF) This is a high-level and holistic approach to design. It relies heavily on modularization and standardization and already existing, proven technologies and products.
Architecture of Integrated Information Systems (ARIS) This is an approach to enterprise modeling; it offers methods for analyzing processes and taking a holistic view of process design, management, work flow, and application processing.
It is possible to identify (at least) three architectural roles. They could all report to a senior “enterprise architect” in the organization. They are the business/organizational architect, the service architect (which may be split into applications and information/data architect), and the IT infrastructure architect.
Let’s now move on to the next aspect of service design, process design. But first, here’s a reminder of the definition of a process. A process is a structured set of activities designed to accomplish a specific objective. It takes one or more inputs and turns them into defined outputs. Process definitions should include the roles, responsibilities, tools, and management controls required to reliably deliver the outputs. The definition may also define or revise policies, standards, guidelines, activities, processes, procedures, and work instructions if they are needed.
Figure 11.13 shows the generic process model, which you should recognize from your Foundation studies. It shows how data enters the process, is processed, and is output and how the outcome is measured and reviewed. A process is always organized around a set of objectives, which define what the main outputs should be. Importantly, a process should always include process measurements (metrics), reports, and process improvement.
Each process should be owned by a process owner, who should be accountable for the process and its improvement and for ensuring that a process meets its objectives. Service design should assist in the design of processes to ensure consistency and enable integration between processes.
The output of an effective process conforms to the business objectives. If the activities are carried out with a minimum use of resources, the process can also be considered efficient. Process analysis, results, and metrics should be incorporated in regular management reports and process improvements. Even before starting, it is important to think about what the process outcomes should look like. Outputs from processes should be compared to what is expected (“norms”) to assess the quality. Measuring allows comparison of what has actually been done with what the organization set out to do and helps to identify and implement improvements within the process. This integrates with the Plan-Do-Check-Act cycle of continual improvement.
Not all process activities take place within the same organizational unit. The individual activities should therefore be clearly mapped to well-defined roles. The roles and activities are coordinated by process managers. Once detailed procedures and work instructions have been developed, an organization must map the defined roles and the activities of the process to its existing staff. Clear definitions of accountability and responsibility are critical success factors (CSFs) for any improvement activity. Without this, roles and responsibilities within the new process can be confusing, and individuals will revert to “the way we’ve always done it” before the new procedures were put in place.
The RACI model should be familiar; you studied it as part of your Foundation course. As a reminder, this is a method of defining who is responsible, accountable, consulted, or informed for each task. The responsible person is the person who actually does the job, whereas the accountable person has ownership of the quality and the end result. Some people may be consulted and input knowledge and information into the process, while others are kept informed on progress.
When the RACI model is applied to a process, only one person should hold end-to-end accountability for the process, typically the process owner. Similarly, there is only one person accountable for any individual activity, although several people may be responsible for executing parts of the activity.
In Figure 11.14, you can see an example of a simple RACI matrix. Remember, there has to be one, and only one, person accountable, and one or more people have to be responsible. Not every task includes people who are consulted or informed.
Now we move on to the last of the five aspects of service design, designing measurement systems and metrics. You might be familiar with the Peter Drucker’s saying, “If you can’t measure it, then you can’t manage it.” This is very true, and so in order to manage and control processes and services, they have to be monitored and measured.
Care should be exercised when selecting measurements and metrics and the methods used to produce them. This is because the metrics and measurements chosen will actually affect and change the behavior of people being measured, particularly where this relates to objectives, personal and team performance, and performance-related pay schemes. Therefore you should include only measurements that encourage progression toward meeting business objectives or desired behavioral change. For example, measuring first-contact fix rates at the service desk may encourage staff to spend too long on an incident, trying to resolve it rather than passing it on to second line. This may actually impact customer satisfaction because users might wait longer for their call to be answered.
Measurements should have the following characteristics:
There are four types of metrics that can be used to measure the capability and performance of processes:
Measurements and metrics should develop and change as the maturity and capability of a process develops. Initially, the progress and compliance of the process need to be the main focus. As the process maturity develops, effectiveness and efficiency metrics can also be used.
What to measure and how to measure and report it requires careful design and planning. The primary metrics should always focus on determining the effectiveness and the quality of the solutions provided. Secondary metrics can then measure the efficiency of the processes used to produce and manage the solution. The priority should always be to ensure that the processes provide the correct results for the business. Measurements in individual areas should be aggregated together to give the full picture, but this means that there cannot be gaps in what is being measured or inconsistencies in how it is being measured.
The metrics tree shown in Figure 11.15 is based on a typical balanced scorecard and uses dials to represent metrics results for each level shown. It is important to note the linkage from the lowest level of the tree of individual component metrics all the way up to objectives and metrics of the business itself. Each lower step should be feeding into the step above. For example, individual customer satisfaction scores for particular services feed into overall customer satisfaction measurements.
Measurement systems should ensure that each role is provided with appropriate information so that business managers and customers get a top-level business dashboard, aligned with business needs and processes, while senior IT managers focus on the top-level IT management dashboard.
Service owners will focus on the performance of particular services, and process owners and managers will want to view the performance of their processes. Finally, technical specialists can look at the performance of individual components.
The best-practice approach of a service-oriented architecture (SOA) should be used in the design of business processes and solutions. This SOA approach is used by many organizations to improve their effectiveness and efficiency in the provision of IT services. SOA is defined by OASIS (Organization for the Advancement of Structured Information Standards, www.oasis-open.org) as follows:
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
OASIS is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards.
SOA encourages reuse of modular self-contained services. This modular approach encourages shared services that can be used in many different areas of the business. It increases flexibility and reduces development time. Most important, it encourages a focus on business outcomes rather than technology. More and more organizations are converting business processes to common packaged services that can be used and shared by many areas of the business.
When SOA principles are used by the IT service provider organization, it is critical that an accurate service catalog is maintained as part of an overall service portfolio and CMS. This will illustrate and document how a single application may form part of more than one service and how a single service may utilize more than one application. Adopting this approach can significantly reduce the time it takes to deliver new solutions to the business and to move toward a focus on business outcomes instead of technology.
Service-oriented architecture can bring many advantages to an organization in terms of flexibility and reuse of self-contained services. However, to benefit from this approach, IT must have first defined what a service is. ITIL defines a service as “a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.”
The important aspect of this definition is the focus of customer outcomes. SOA also requires that IT understands and clearly identifies interfaces and dependencies between services. ITIL and SOA work well together because many of the prerequisites for benefiting from this approach are outputs of ITIL processes. For example, the service catalog and the CMS show the composition of and interfaces and dependencies between services. ITIL also provides a standardized approach for the development and definition of services and encourages the use of common technology and toolsets. ITIL’s change management process ensures that the impact of changes to shared services is determined in advance of the change. If the SOA approach is to be adopted, IT must ensure that staff receive training in SOA to enable a common language to be used and to improve the implementation and support of the new or changed services.
The model selected for the design of IT services will depend mainly on the model selected for the delivery of IT services. Before adopting a design model for a major new service, conduct a review of the current capability and provisions with respect to all aspects of the delivery of IT services. The review should consider all aspects, including the business drivers and requirements and the demands, targets, and requirements of the new service. The scope and capabilities of the existing service provider and the external suppliers should be considered together with the maturity of the processes and the culture of the various organizations currently involved.
The IT infrastructure and all components involved in the service should be reviewed, as should the degree of corporate and IT governance, ownership, and control required. Finally, the financial and staff resources should be assessed. The main sourcing structures are as follows:
For all sourcing solutions requiring external providers, the need for a clear agreement of what is to be provided is essential. The supplier management process should also be used to ensure that the suppliers deliver the agreed service. These delivery strategies are relevant to the design, transition, and operational stages of the service lifecycle. The suppliers themselves may operate offshore, adding to the challenge of maintaining good communications with them.
Another challenge is to ensure that all organizations involved clearly understand their own roles and responsibilities and those of the other organizations involved, especially when different strategies have been adopted for different stages of the lifecycle. Without this understanding, there is a risk to effective acceptance and the handover processes.
There are a number of different approaches to design and development:
Structured System Development This is the traditional “waterfall” approach. It involves defining a complete set of requirements early in the lifecycle and then managing changes to them, if necessary.
Rapid Applications Development Approach This is becoming increasingly popular. There are a number of variants of RAD, of which the most popular is the Agile methodology. The rapid approach involves the introduction of increments and iterations in the development process so that risks associated with uncertainty and changing requirements can be managed.
Commercial Off-the-Shelf (COTS) Solutions This involves purchasing, implementing, and possibly customizing commercial packaged solutions.
In this chapter, you studied service design principles. We looked at holistic service design, service composition and the four Ps of service design, and the importance of and approach to balanced design. We also discussed service requirements, business requirements, and drivers. We examined design activities, constraints, and models, including the five aspects of service design and the management of service design processes. Finally, we considered service-oriented architecture principles and service design models.
Understand what is meant by the term holistic service design. Give examples of aspects to be considered using this approach.
Be able to explain the four separate technology domains that support components of every service and that design needs to address. Be able to give examples.
Understand the five aspects of service design. Be able to list and explain them.
Understand and expand on the concepts of service-oriented architecture. List the benefits it can deliver and how it relates to ITIL best practice.
Be able to list the typical contents of a service design plan. You should be able to specify what is in a service design plan.
You can find the answers to the review questions in the appendix. Which of the following statements is correct? Which of the following are aspects of warranty? What are the four Ps of service design? Which three aspects must be balanced in a balanced design? Which of the following are domains that need to be addressed by the service design? The Service Portfolio is made up of which three parts? What is meant by holistic service design? Which of the following is NOT a possible risk when designing a service? The design for a service must include which of the following? Once the desired service solution has been designed, service design must carry out three activities before the solution passes into the service transition stage. Which of the following is NOT one of these activities?Review Questions