Service Design

This is an excerpt, you will find more detailed descriptions in the book.

Producing a new IT service in order to generate a specific value in the business can be very complex. There are often several different organizations involved in the work, with each one having its own perspective on what is important.

One example is whether a new application should be developed, and the project concentrating all its energies on the functionality in the application. On completion of the application the realization dawns that it does not fit with the rest of the IT infrastructure, the tools we use for all other applications don’t work, and the Operation department’s staff do not have the expertise required to manage it.

In this example, a major cost is created which was not included in the calculation from the outset and in the worst case, the total cost becomes so great that the project should not have been implemented at all if all costs had been known.

Creating a process which regulates the activities facilitates the challenge of including all aspects of a new IT service throughout its life cycle. Furthermore, it establishes a prerequisite of continually improving the quality of new services and streamlining the work of producing them.


The purpose of Service Design is to ensure that all different aspects of the design work are taken into account so that objectives and purpose are achieved for the new IT service.

The purpose is achieved through:

  • Providing uniform activities when designing new and changed services
  • Producing complete design packages
  • Ensuring that sufficient design work is undertaken before handover to the Change Management process
  • Ensuring that all new IT services are in line with policy documents and strategies
  • Measuring and improving the quality and efficiency of the design activities


In a small IT organization that does not perform its own development, can the process in its simplest form consist of a checklist describing which different areas must be taken into account in production of a new IT service.

For larger organizations with their own development and frequent introduction of new IT services, Service Design needs to be an explicit process which is clearly linked with the processes used to manage requirements in the development model.

The scope of Service Design consequently differs greatly between different IT organizations depending on the size and number of internally developed applications. Each IT organization must therefore decide which level of ambition and scope the process should have.

As a starting point, Service Design comprises the activities required to ensure the quality and functionality in new or changed IT services.

Managing all changes through Service Design is not efficient. A trigger must therefore be inserted in the Change Management process to indicate when a change should be managed by Service Design. The level at which this trigger is set is naturally different for each organization. However, new services, high risk changes or those which affect several different services can be a good starting point. To facilitate this, it is beneficial if the trigger for Service Design is the same as the trigger for which changes should be managed by CAB in the Change Management process.

Regardless of the size of the organization, Service Design includes:

  • Developing and administering policy and method for design work
  • Streamlining Service Design
  • Producing complete design packages for CCB

Design aspects

It is important to try to have an overall view in relation to design of services. Regardless of their role, people with different backgrounds have different views on what needs to be done and what is important. It is easy to get stuck in one’s own specialist area, one’s own aspect, and in the worst case, design solutions that do not function together with the rest of the IT environment. To facilitate the overall perspective, five different aspects are used for design work:

Design of the service– This aspect comprises in part the requirements for which value the service should fulfil and in part how the service’s architecture is constructed. This includes links and dependencies on existing services, parameters to be found in policies and controlling documents. In addition to this, all requirements for functional capacity and value must be obtained and documented.

Information and tools– Existing information systems and tools should be analyzed in order to ascertain whether they can manage the requirements from the new service. What should be analyzed is the service portfolio’s structure, including the method for cost calculation and service structure and the tools used for knowledge management and to measure the service.

Architecture– Both the technical and the organizational architecture must be analyzed to ascertain whether they meet the requirements from the new service. The technical architecture includes the infrastructure platform, but also the tools used for tasks such as monitoring and deployment. The organizational architecture comprises functions and roles, as well as the methods used.

Processes and functions– A new service entails new information and new procedures for existing processes. Functions need to be analyzed in order to identify any new skills required to manage the new service.

Measurement and reports– Existing tools and report structures need to be analyzed to ascertain whether the new service can be measured and followed up or whether new tools are needed.

Design package

A design package should be created under Service Design for each new or changed service. The design package contains all information needed to build, test and establish the service in the IT environment. A design package usually consists solely of documents, but in certain issues can also contain simple forms of applications and systems in order to display concepts and functionality prior to a decision to develop a full-scale service.

As a minimum, a design package should contain:

  • Contact details
  • Business requirements
  • The service’s prospective value in the business
  • Service Design
    • Functional requirements
    • Non-functional requirements
    • Service levels
    • Operational requirements in the IT operation
    • Design and architecture for the service
  • Organizational analysis
  • The service
    • Plan for transition
    • Plan for IT operation
  • Acceptance criteria

©2020 OpenTRIM® a model to ease the adoption of ITIL®, OpenTRIM® is a registered trademark of OpenTRIM AB. All rights reserved. ITIL® is a registered trademark of AXELOS AB. All rights reserved.


We´re not around right now. But you can send us an email and we'll get back to you, asap.


Log in with your credentials

Forgot your details?