Chapter 12

Going Back to the Drawing Board: Design Projects

In This Chapter

Understanding how the service design processes work in practice

Seeing how ITIL fits with service design projects

Seeing a service design project in action

Many organisations carry out a lot of the activities of the service design and service transition stages as projects. In this chapter I look at service design projects. (Chapter 13 covers service transition projects.) Here I use examples to show the relationship between the ITIL guidance, projects and the service operation functions.

In this chapter I bring together the concepts of the service design stage in the service lifecycle (which I cover in Chapters 5 and 6) with the ITIL processes that are most relevant at this stage. More often than not, the requirements and design activities of a service are performed as part of a project, or even as a project in its own right. (Chapter 10 gives you the low-down on projects and how you use them to implement the service lifecycle.) This chapter contains advice on how you use the service design processes in practice.

Seeing What Happens in a Service Design Project

As you can see in Chapters 5 and 6, the service design stage includes the activities associated with the requirements and design of the service. I now take a closer look at the core activities you carry out in a service design project. Chapter 3 describes the relationship between the service lifecycle and development projects (Figure 3-2 is particularly useful).

Gathering and analysing requirements

After a service has been chartered or a change requested, you need to get a clear understanding of the requirements. The business case, which I explain in Chapter 4, is a major input to this stage and includes the business requirements. These should be adequate enough to estimate the effort and resource required to develop the new or changed service. It is very unusual for detailed requirements to be established at the business case stage, because it’s a costly and time-consuming task to gather and analyse requirements. So now’s the time to put flesh on the bones.

The gathering and analysis of requirements is often done by business analysts or requirements engineers. They gather all the requirements of the IT service, including the functional and non-functional requirements. The result is usually a requirements specification which is signed off by the business as a true description of what is required.

Business analysis/requirements engineering

It is important to have a structured approach to identifying requirements. Requirements engineering is a discipline in itself, and many sources of guidance and qualifications are available in this area. The ITIL books briefly cover this area. Here are some important points:

Identifying stakeholders: A stakeholder is anyone who has an interest in, or is affected by, the thing that you are doing. So in terms of requirements engineering, you must identify anyone who is associated with the service you’re developing. After you identify and list all the stakeholders for the service, you develop a plan of attack for getting their requirements for the service. If you overlook a stakeholder or talk to the wrong stakeholder, you end up with an incorrect or incomplete set of requirements.

Gathering requirements: There are many ways of collecting requirements from stakeholders. Obviously you should go and talk to them; however, there are other ways that may be more appropriate in some situations. This is not the place to go into detail, but methods of gathering requirements include workshops, observation, questionnaires, document gathering and analysis, and prototyping.

Documenting requirements: As requirements are gathered, they must be documented. The most common term you hear is requirements catalogue: a catalogue of requirements that is a central repository for all the requirements for a given service or system and is version controlled.

In many cases a spreadsheet is a good way to record the requirements.

Types of requirements

There are many types of requirements, and at the point of gathering requirements all must be treated with equal importance. However, as you move on to the design of the service, it can be helpful to categorise the requirements into groups that are relevant to people who have to design and build the various parts of the service:

Functional requirements: These tell you what the service must do. For example, the basic functional requirement of an email service is to send and receive messages. Without this ability, it would be a fairly useless system. You go into much more detail than this, including a description of what each screen or part of a software application does. For example, the sales service will require a ‘customer input screen’. The functional requirements here include a description of the fields that appear on the screen, the calculations or manipulations the application must perform, and the output, in other words what appears on the screen when the user has finished. Roughly speaking, the utility of a service is related to its functionality. These types of requirements are usually of most use to the application developers who create the software application.

Management and operational requirements: Often known as the non-functional requirements of a service, these don’t describe what the service does, but they describe how well it will do it. These requirements often put constraints on the system: demands such as how fast the service must operate, who is allowed to use it, and so on. There are many types of management and operational requirements, but the ones that are most relevant to service management are those that equate to service levels: availability, capacity (including performance), continuity and security. These are often known as the warranty requirements. (Chapter 6 focuses on warranty.) Generally speaking, these requirements are needed by those that build the physical system hardware as well as the software application developers.

Usability requirements: These refer to ease of use, or what is often called user friendliness. In other words, how easy it is for the user to use the service, whether the software application is intuitive to use, whether lots of training is required, and so on. In general, these requirements, along with the functional requirements, are of most use to the application developers who create the software application.

Designing solutions

Having collected the requirements (see the previous section ‘Gathering and analysing requirements’), you need to design a solution to meet these requirements. Designing IT services is a complex task taking many requirements into account. Specialist staff are required, depending on the technical needs of the solutions.

In Chapter 5, I describe the many aspects that you consider during the design phase, including:

Designing the overall service solution including the hardware, software and support

Determining the need for, and acquiring or developing, service management systems and tools

Ensuring the technology architecture and management systems are in place to support the design of the infrastructure, data and environments

Designing the service management processes

Designing a structure to collate the right measurements and metrics to provide the necessary visibility and ability to control the service and the service management processes

The following sections focus on designing the service solution, considering service and system architecture, and developing applications.

Designing the service solution

The service solution refers to the new or changed service. Designing the solution can include designing some or all of the following:

Software applications: The software application that provides the basic functionality of the service and presents the front end of the service to the user. Software developers will be involved in creating the detailed design of the application based on the requirements gathered by business analysts.

Infrastructure: For example, the IT hardware and networks, and any system software such as operating systems. This may include servers, networks, storage, databases, operating systems, messaging protocols and software agents.

Data: The data and database structure for storing and handling the data that is collected, manipulated and output by the service. The requirements of data are usually inextricably linked with the functional requirements of the service or software application.

Support: The operational requirements such as how the service will be delivered and supported on a day-to-day basis. Support includes the skills, processes and resources required to ensure that the service is operating correctly and can be recovered in the event of a failure.

Physical environment: The data centres, computer rooms and so on, including the air-conditioning systems and the power supplies.

Considering system architecture

There is a growing need for flexible and adaptable solutions, and to provide new systems and services as quickly as possible to customers. One way of achieving this is to adopt a modular approach to the design of your services. This often means that your IT service consists of sub-services that in turn consist of sub-sub-services (if there are such things), and so on.

A service may consist of a network service, a processing service, a storage service and a database service. Each is designed as a service in its own right then, when a new service is required, these building blocks can be joined together to form a service.

An ever-increasing number of technical advancements support this concept and make it easier to be more flexible. However, they come with a greater need for forward planning and good design. Much of this concept has been around for a while and is encapsulated in something known as service oriented architecture.

You may be familiar with server or data centre virtualisation. This allows multiple software environments to be created on a single physical hardware server, thus making better use of resources. Computer servers themselves are often built in clusters or using blade servers (servers that are stripped down to their essential components so that many can be fitted into a smaller space, thus using less power and being easier to add and remove), which contributes to more resilient server design and makes more efficient use of resources. In terms of data storage, storage area networks enable storage solutions to be designed independently and are able to be expanded or contracted as necessary to meet changing needs.

All of this contributes to the ever-more-popular concept of cloud computing. A cloud is the name given to an invisible IT network and infrastructure, a bit like the Internet. Suppose you store your photographs on an Internet site or back up your data to a virtual file store; you don’t know where the physical computer equipment is, you just trust the provider to look after it for you. These are examples of putting things into a cloud. The cloud provider needs to ensure that it has an extremely robust set of systems, and the concepts I describe here are essential to providing such a service.

The point is that you must have a set of architectures that tell you how all these technical bits and bobs join together. In this way, an architecture can act as a long-term plan.

Building an architecture is similar to building a new bookshelf. Perhaps you’ve taken up a new hobby or interest and you know that over the next few years you’ll build up quite a collection of books. You may deliberately build the bookshelf too big with lots of spare space in it. Not only that, but you leave one section the right size for big books and another for small books. Then as you obtain more books you pop them in place. Planning your technical architecture is the same in that you plan the blank spaces for more processor capability or more storage capacity and then fill it up when you need it.

Developing applications

When it comes to designing the software application, there are lots of concepts and methodologies out there. A couple of approaches you may have heard mentioned are rapid application development (RAD) and agile methods – these are development methodologies that share the ability to deliver software applications in short timescales. Traditional application development methodologies suggest that you gather all the requirements for an application, then design all the functionality of the application and then build and deploy all the modules of the application. This can take a long time. And in the past, when IT organisations had eventually implemented a new service, the business no longer needed or wanted it because the business had changed!

RAD and agile methods break the development down into bite-size chunks. A certain amount of work is required up front to get the overall business requirements of the application, but then the detailed requirements, design and development are broken down into smaller parts, each of which delivers an amount of functionality to the business. This leads to several releases of the application, deployed at shorter intervals, and each delivering more functionality. This results in the business getting the service more quickly.

Bringing Together ITIL and Service Design Projects

The previous section gave an overview of a service design project and some of the activities involved. You may have noticed that there was very little mention of the ITIL service management processes. Now is the time to explain where these fit in. In this section I show how the ITIL service design processes are coordinated and work together. The processes are not just a disparate bunch of activities; they must work together and complement each other.

Following the design process

Figure 12-1 shows some of the requirements and design activities I describe in the previous section, to which I have added some activities that are performed as part of the service management processes. Please note that this is simply an example, is not prescriptive, and may be different in your organisation.

Here’s the process broken into steps:

1. The business relationship manager liaises with the customer and identifies that the customer has a new requirement. A business case is created (see Chapter 4), service portfolio management (see Chapter 4) facilitates the approval of the business case, and then the service is chartered. This is when the project is initiated and the design coordination process gets involved to plan the work and coordinate the design activities.

2. The detailed functional requirements are gathered. The team or individual that does business analysis or requirements engineering in your organisation performs this step. These analysts often gather the non-functional requirements at the same time as all other requirements.

It is important that there is a trigger to involve the service level management process. The service level manager documents and analyses the service level requirements (SLRs: see Chapter 5) and triggers other service management processes to establish whether the service level requirements are achievable or not. It is often the case that some design work is needed in order to understand what is involved in achieving the SLRs. The technical teams will identify what is required and liaise with the financial management for IT services process to calculate the costs of the new service.

3. The requirements are agreed and the design work starts. The software application will be designed by a combination of application management and application development. The infrastructure parts of the service (hardware, networks, system software, databases) will be designed by technical management teams.

4. The design coordination process produces a service design package (SDP). The package contains all the design documents along with the requirements and the estimates of cost, and is the main output of the service design stage. (See Chapter 5 for more about SDPs.)

Each ITIL process that is involved in these activities has its own flow of activities, as the following sections illustrate.

Coordinating the design processes

There’s quite a lot of activity described in the list in the last section, and more detail to come in the next sections. How can you be sure that everything will be done in the way it is intended and nothing will be overlooked or forgotten? Answer: the design coordination process, which I describe in Chapter 5. This process covers all the activities required to ensure that all activities are performed correctly. This will include:

Maintaining policies, standards and guidelines and ensuring they are used

Planning the resources needed for service design activities

Ensuring the production of the SDP from documents and inputs provided by the application and technical teams involved in the design activities

ITIL and requirements

Two processes are especially relevant to the requirements phase of a design project: service level management and supplier management.

Service level management

Service level management, which I explain in Chapter 5, is a key process in the requirements stage of design projects. Figure 12-2 shows an example of a process flow for service level management. Service level management performs many activities and is likely to have several different process flows. This example flow is triggered by the need to gather new requirements.

Service level management gathers and negotiates the service levels with the customer. The critical part of this process is to establish whether the service levels are achievable, by liaising with the staff who know.

Once the IT teams have agreed that the service levels are feasible, it’s a good idea to get their agreement and create an operational level agreement (OLA). Similarly, establish whether your supplier can supply its services to meet the proposed service levels. This involves supplier management (see the next section).

Supplier management

It is often the case that your organisation doesn’t provide all of the service itself. Part of the new service may come from a third-party supplier. If you decide to get some or all of the service from a supplier, the supplier management process, which Chapter 5 explains, must be involved. In the example in Figure 12-2, the service level manager has recognised that one part of the service will be provided by a supplier, so has asked the supplier management process to negotiate an underpinning contract (UC) with the supplier.

When you approach a supplier, be very clear about what you want it to do or provide. A common document used here is a statement of requirements (SOR). The SOR should be derived from the SLRs obtained from the customer, but includes a specification of just the bit that you want the supplier to do for you.

Typically, supplier management performs the following activities in new design projects:

Establish whether a suitable supplier exists

Get quotations

Negotiate the contract

ITIL and design

The service will be designed to meet the service level requirements, which relate to warranty. The four aspects of warranty are availability, capacity, continuity and security, and I cover each of the warranty processes in Chapter 6.

The design work is usually done by your technical management teams. Many organisations employ technical architects and designers to do this work. The importance of the processes is to ensure that when the designers and architects work on a new service or infrastructure design, they take into account the service level requirements.

Figure 12-3 shows an example process flow for the warranty processes responding to a request to review new requirements. You will see that there is much similarity between the processes. This is of course only one example; you must create something to suit your organisation.

Availability management

In availability management, there are two aspects you take into account when designing the service or infrastructure:

Design for availability: Design the service to be available, that is design the service to not fail. Well, perhaps a single component can fail, but you don’t want the user to be aware of this. So, designing for availability includes building in resilience such that if one component fails, the service does not fail, and the user is blissfully unaware of any IT problems.

Design for recovery: Design the service and your organisation to be able to restore the service as quickly as agreed in the service level agreement (SLA). This includes having the processes, spare parts and appropriate people in the right place at the right time so that you can get the service going again.

Capacity management

The role of capacity management in design is to ensure that there are enough IT resources for the number of users intended to use the service, and that the service runs fast enough when those users are using it. Two techniques of capacity management are particularly relevant here:

Application sizing: Identify the size of the computer that runs the application. In the same way that you need to know the size of the present you have bought for your partner before you buy the box to put it in. So, when your application developers design the software application, they pass information to capacity management, who calculate how much processor power, network bandwidth and storage space are required to run it. This information is used to ensure that these resources exist before the service goes live.

Modelling: Application sizing can sometimes be inaccurate, and to improve the resource estimates you can do some modelling. Nothing to do with fashion catwalks, modelling is testing under various scenarios, like saying ‘what if . . .?’. What if I double the number of users: will the system cope? This gives you a better idea of how the application and service will run when it goes live, and therefore improves your application sizing estimates.

IT service continuity management

The role of IT service continuity management in design is to ensure that the business requirements for restoration of service in the event of a disaster are built into the design. This may involve checking that existing recovery arrangements are adequate and the new service can be added to existing recovery plans. On the other hand, a new recovery plan and mechanism may be required. You carry out:

Business impact analysis (BIA): The analysis of the impact on the business of a disaster or event that prevents the business from operating normally. The IT department will work with the business to identify the business impact and hence the importance of the IT services that the business relies on. For new services, if the business impact is unknown, a BIA must be carried out.

Risk analysis: The analysis of any risks to the IT service that may cause it to fail in a big way and lead to a major outage or disaster. For new serv- ices, if the risks are not known, an assessment must be carried out.

Information security management

Information security management (ISM) must ensure that the requirements of security are built into the design. ISM protects the interests of those relying on the information and data held in the IT services. So the information must not be corrupt, must only be shown to the people that need it, and must be available as and when required. ISM is responsible for assessing any risks to information security and building any new recommendations into the design.

Looking at an Example of a Service Design Project

Dummy Co. is a commercial IT service provider. Dummy Co. has implemented ITIL and allocated many of the service management roles to members of the technical teams, as Figure 12-4 illustrates.

An account manager has found a new customer. The account manager is Henry, and one of his roles is to act as the business relationship manager. The customer requires an invoicing service and doesn’t want to acquire and run the system itself. It wants to utilise it as part of a cloud (see the earlier section ‘Considering system architecture’ for an explanation of a cloud) from a software as a service (SaaS) provider. This means that the users will access the invoicing service from their Internet browsers over a private Internet connection, and use Dummy Co’s software application and hardware.

Henry has established the customer’s business requirements. These have been reviewed using the service portfolio management process (see Chapter 4). Dummy Co. has an existing application that can be used to deliver the service, and this will fulfil most of the utility requirements. However, the warranty requirements are quite demanding and exceed any service levels offered to existing customers. A business case has been established and approved via service portfolio management with a little help from the financial management and demand management processes (see Chapter 4). There is a considerable return on investment (ROI) to be gained from the venture. The design project is initiated. Charlie is the service delivery manager, and she has been allocated the role of design coordination manager, so she takes charge of the project.

Henry has invited Charlie, who also acts as the service level manager, to a meeting with the customer to identify the service level requirements. The service level requirements are as follows:

The service will be used at several locations worldwide, so it must be available 24/7, five days a week. Any single failure leading to loss of service at a site must be fixed within 30 minutes, and it will not break more than twice in any one week.

The maximum number of people using the service at any one time is likely to be around 3,000. Because the users are spread across various sites, demand will not fluctuate much throughout the day. The response time of the system must be less than two seconds.

As the service provider, you need to have appropriate disaster recovery facilities in place in the event that you have a disaster. As the customer, in the event that we have a disaster and want to relocate our staff, we require the ability for the service to be accessible at alternative locations in less than one hour.

The data protection act requires us to protect our client’s information. All invoice data must be protected and must be restorable in the event of a cyber-attack. Our data must be backed up and recoverable in the event that you suffer a security breach.

Charlie takes these requirements and documents them as the SLRs. She follows a process flow like the one in Figure 12-2. Charlie reviews the new requirements and compares them with the targets in the existing OLA and UC to see whether there are other services that are delivered to these service levels. If it turns out that these service levels have not been offered before, or there is doubt as to whether they can be achieved, then the technical designers must be consulted.

Well, Dummy Co.’s IT department has just one technical architect, and he is called Fred. Fred does what he always does when he has a new design project to get to grips with: he looks at the architecture of the infrastructure. He looks to see whether there is enough network equipment to cope with the additional load that the new service will need. He looks at the servers in the data centre to see whether there are enough of the right type. He looks at the data storage to see how much is in use. Pretty much what any technical architect would do.

However, Fred has many roles. For the projects that he undertakes, he performs the roles of availability manager, capacity manager, security manager and IT service continuity manager. So when he is reviewing the infrastructure, he takes the SLRs and looks at the requirements from the four warranty points of view. In fact, Fred takes the SLRs and converts them into detailed requirements for availability, capacity, continuity and security, and then considers the requirements in his musings. The work that Fred is doing is sometimes called a capability review. The results of this are that Fred produces an outline design and proposal of how the new requirements will be met. This of course comes at a cost, so Fred will obtain costs and quotes for any additional resources that are needed.

The main content of Fred’s proposal is as follows:

To fulfil the 24/7 availability requirement, additional server equipment will be required to provide the necessary resilience. The network currently operates at this level, and no additional resilience is required.

To meet the capacity and performance requirement, additional data storage will be added to the existing storage area network. This will also contribute towards the security requirement.

In addition, to meet the security requirement, additional data backups are required, and an additional off-site storage facility is needed.

The continuity requirement can be met with the existing recovery facility, but the recovery plans must be updated to ensure that the new serv- ice is recovered within the target time.

Fred sends the proposal back to Charlie. The next step is for Dummy Co. to decide whether it wants to spend the money required by Fred’s proposal in order to upgrade the infrastructure, agree to the customer’s requirements and win the business. This involves Charlie, Henry and Dummy Co. senior management. The decision is made to go ahead. Hurrah!

Henry and Charlie arrange to see the customer, and get into negotiation about the finer points of the SLA and, of course, the commercial stuff. Once the SLA is agreed, the detailed design work is started and Charlie liaises with Fred and others in the technical management team to help with any issues as they arise. When the design work is complete, Fred creates an SDP. This marks the end of the design project. Of course the next step is to build, test and implement the solution – but that’s another story that comes under service transition, which I cover in Chapters 7 and 13.

Figure 12-5 provides an overview of the example in this section. It is not complete as I need a much bigger piece of paper than a page of this book to show it all, but hopefully it gives you an idea.

A swimlane flow diagram like the one in Figure 12-5 is a really good way to visualise how the processes will work in your organisation.