Service Design and Change Management

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.

Utility and Warranty

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.

Business Focus

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.

Risk

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:

• Products: The new service should be added to the portfolio, and the entry should be updated as it moves through design and transition and into operation.
• Processes: The processes of service level, financial, and capacity management will each play a part in the design.
• People: The technical, application, operations, and service desk staff will need to be aware of what will be required of them as far as operations and support is concerned.
• Partners: Supplier management will need to identify suitable partners/suppliers.

Listed here is a set of questions that need to be answered when undertaking a design for a new or changed service:

• Do you understand the functional requirements? What constraints are you working within (governance, compliance, etc.)?
• Do you understand the service level requirements (SLRs) for the service? Are the operational level agreements (OLAs) and underpinning contracts (UCs) in place?
• Do you understand all the technical components that will be needed?
• Do you know the applications required, and have you verified the data sources?
• Have you considered the environmental requirements and supporting services?

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.

Balanced Design

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.

Service Requirements

There are a number of things that we must ensure:

• The services delivered meet the requirements of the business in all areas, including the scalability of the service to meet future requirements in support of the long-term business objectives.
• The services also deliver the requirements of the business processes and business units it supports:
  • The agreed business requirements for functionality, that is, the utility requirements
  • The service level requirements and service level agreement covering the warranty requirements
• The design also specifies what technology will be used to deploy and deliver the service.
• Other requirements that design must consider include the internally delivered supporting services and components and their associated OLAs, and the externally supplied supporting services and components and their associated underpinning contracts. Design must specify the performance measurements and metrics that will be required and the required security levels.
• There may also be other aspects that the customer requires, such as the service having to meet sustainability requirements.

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.

Business Requirements and Drivers

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.

Evaluate Alternative Solutions

If external supplier services and solutions are involved, choosing a supplier and solution will involve evaluating alternative solutions:

• Compiling a statement of requirements for the suppliers
• Tendering the work
• Compiling a short list from the proposed solutions put forward by the suppliers, excluding any proposed solution that did not fulfil any of the mandatory requirements in the statement of requirements
• Evaluating the proposed solutions against a set of agreed criteria, using an agreed scoring mechanism
• Costing the solutions
• Choosing the winning supplier solution based on the scoring and costings

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

Procure the Preferred Solution

Most solutions require some involvement from external suppliers. The following activities are required to procure the solution:

• Completing all necessary due diligence checks on the preferred supplier
• Finalizing the terms and conditions of any new contracts
• Ensuring that all corporate policies are enforced
• Signing the contracts
• Completing the procurement of the selected solution

Develop 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:

• The needs of the business
• The timescales involved
• The strategy for developing and/or purchasing the solution
• Ensuring that sufficient resources are available in terms of facilities, IT infrastructure, and skills
• Developing the service, including the management, monitoring, and measurement mechanisms
• Service and component test plans

Careful project management should avoid conflict and ensure compatibility of components sourced from different development activities.

Designing Service Solutions

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:

• Analyze the agreed business requirements.
• Review the existing IT services and infrastructure; this may identify alternative solutions, which can reuse or exploit existing components.
• Design solutions to the new requirements, including their constituent components. The design should include the facilities or features and functionality required (i.e., the utility) and any information required that will enable the performance of the service or process to be monitored.
• The design must address the requirements of the business processes it will support, and so it needs to take into account dependencies, priorities, criticality, and the impact of the service together with the business benefits that will be delivered by the service.
• The design will also need to cater to the business cycles and seasonal variations and the related business transaction levels, service transaction levels, the number and types of users, anticipated future growth, and any business continuity requirements.
• The design of the service has to be in line with the service level requirements and service level targets (i.e., the warranty requirements).
• It also needs to be aware of the service measuring, reporting, and reviewing activities.
• The timescales, planned outcome from the new service, and its impact on existing services must be understood.
• The design must also take into consideration any required testing, including any user acceptance testing (UAT) and how the test results will be managed.
• The new service will need to integrate into the overall service management system.

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:

• The design stage has to have an agreed budget and timeline to design, develop, build, test, and deploy the service.
• The business benefits, especially the required return on investment, should be confirmed.
• All costs and benefits and any increased revenues need to be identified and quantified. The costs should cover the total cost of ownership of the service and include startup costs and all ongoing operational costs, including management, support, and maintenance.
• Finally, all parties can agree on the preferred solution and its planned outcomes and targets (both utility and warranty).

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:

• The commercial impact on the business and IT should be assessed, including all of the business benefits and all of the costs involved in the design, development, and ongoing operation and support of the service.
• Risks associated with the new or changed service, particularly to the operation, security, availability, and continuity of the service, need to be assessed and mitigated.
• The business needs to assess its own capability and maturity, ensuring that the right processes, structure, people, roles, responsibilities, and facilities are in place to operate the new service.
• IT must also assess its own capability and maturity and readiness to deliver the service. This should include assessing the impact on the environment, technology, and existing services.
• The IT department itself should be assessed to ensure that the required roles and responsibilities can be delivered, that the IT processes are effective, and that documentation is up-to-date.
• Any gaps in the skills, knowledge, and competence of the staff or in the capabilities of the processes and tools should be addressed.
• Changes to agreements with suppliers to ensure support of the service should be carried out.
• Finally, the service design package should be assembled for the transition, operation, and improvement stages.

The Design of the Management Information Systems and Tools

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

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:

• Why should a customer buy these services?
• Why should they buy these services from us?
• What are the pricing or charge-back models?
• What are our strengths and weaknesses, priorities, and risks?
• How should our resources and capabilities be allocated?

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:

• Service name
• Version
• Description
• Status
• Classification
• Criticality
• The applications and data used
• Which business processes the service supports and the business and IT owners for these business services
• The warranty and SLA and SLR levels
• The services and resources that support the service
• Which resources are dependent upon it
• How the service is supported, including the relevant OLAs, contracts, and agreements
• The financial aspects of the service—costs, charges, and revenue (if applicable)
• How the service is measured

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.

Management and Technology Architectures

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:

• Staff
• Business functions and processes
• Organizational structure and physical distribution
• Information resources and systems
• Financial and other resources, including technology
• Strategies, plans, management, policies, and governance structures

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:

• Service architecture translates applications and infrastructure, organization, and support activities into a set of services. This means that there may be changes in these architectures without changing the services themselves. It includes the services themselves, their overall integration, and the management of those services.
• Application architecture maps business and functional requirements onto applications and shows the interrelationships between applications.
• Data/information architecture describes the logical and physical data assets of the enterprise and the data management resources. It shows how the information resources are managed and shared for the benefit of the enterprise.
• IT infrastructure architecture describes the structure, functionality, and geographical distribution of the components that underpin the overall architecture and the technical standards applying to them. It includes product and management architecture:
  • A product architecture describes the particular proprietary products and industry standards that the enterprise uses to implement the infrastructure.
  • A management architecture consists of the management tools used to manage the products, processes, and environments.
• Environmental architecture describes all aspects, types, and levels of environmental controls and their management.
• Technology architectures include the following:
  • Applications and systems software
  • Information, data, and databases
  • Infrastructure design, including the design of the following items:
    • Servers
    • LANs
    • WANs
    • Voice networks
    • Internet/intranet/extranet
    • Client systems
    • PDAs
    • Storage area networks (SANs)
    • Network-attached storage (NAS)
    • Environmental systems

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:

• Descriptions of organizational structure
• Business processes
• Planning and control systems
• Management and governance mechanisms
• Enterprise policies and procedures

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.

Processes

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.

Measurement Systems and Metrics

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:

• Measurements should be fit for purpose, providing the information required.
• They should be fit for use, not overengineered or underengineered.
• Measurement systems should be right the first time, with minimal rework required. If the basis of measurement is being continually tweaked, it will raise questions about the validity of the results and make it impossible to establish any trends.
• Measurements should reflect the perspective of the business and the customers.
• They need to reflect the ability of the delivered solutions to meet the identified and agreed requirements of the business.

There are four types of metrics that can be used to measure the capability and performance of processes:

• Progress, that is, the milestones and deliverables in the capability of the process
• Compliance of the process to governance requirements and compliance of people to the use of the process
• Effectiveness of the process and its ability to deliver the right result
• Efficiency, which means the productivity of the process and its speed, throughput, and resource utilization

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.

SOA Principles

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.

Design and Development Approaches

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.

Summary

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.

Exam Essentials

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.