Service Design – Overview

The Service Development Lifecycle is a classic approach that's easy to latch onto. We use tangible models to map how we're going to introduce technology. We have reviews, models and gauges. We start with developing requirements, designs and then building the service. After, we begin testing, validating requirements and evaluating it for its operational use, users effectiveness and usability.

Then we move onto thinking about deploying it including operations and support. We really want to start changing the business and IT perspective of introducing technology and building services as a more continual approach too, so it's no longer liner.

The official definition for Service Design is:

"The design of appropriate and innovative IT services, including their architectures, processes, policies and documentation, to meet current and future agreed business requirements"

In Service Design, the process is only part of the overall picture. In truth we need to think about understanding the architecture and putting it together. How to deal with technology requirements and technology considerations. All of the phases including Service Catalogue Management, Service Level Management, Availability Management, Capacity Management, IT Service Continuity, Supplier Management and Information Security; need to be addressed to some relative degree in the design of a service. Even when you're continually addressing change it's important to do all the phases.

During Service Design we aim to design services to meet agreed business outcomes and processes, which support the service lifecycle. Risks are identified, documented and ultimately managed. We use metrics and measures to actually feedback the business value and calculate how we're doing as a business. Designs take many different forms and include plans, processes, policies, standards, architectures, frameworks and any documents that support the quality of the IT solutions.

We need to think about new services, services due to change and also maintaining services that are already in production. You may be designing a new service or you may be reshaping a new service. You might also be involved in a minor or major change to the infrastructure of IT.

These things really require you to go back to design pages and start thinking about high availability, capacity aspects or even security. We may have to adjust our architecture approach. Consider using Service Management technology and tools, as in most cases this is significantly underestimated. Management feels it takes too much time to address this. It's important to take time to build things such as a change management system or a ticketing system.

It's easy to fall into the trap of thinking that I want to create this one time and make it fit everything. We can't always make a square and make it fit into a triangle. But as we bring in new tools we sometimes miss out the design phase to alter these tools. What different alert streams you might need for monitoring for these new systems etc.

ITIL goes into great detail about how to build effective methods, metrics and measures. It's common practice to get hold of templates so you can rapidly get things going and included in the Service Design. During design we cover the idea of developing those as much as you can rather than waiting for the operations phase and worrying about them later

These things take time and there are a lot of pitfalls in getting there. It's not always a consistent process either; the business might be growing, merging etc. We need to take that into account. So we need to design the service so that it accounts for these business risks for an effective business strategy, requirements and needs. And transform this into effective processes and methods.

Fundamentals

Designs should not be done in isolation, we must consider the overall impact on the service, the architecture, systems and also the tools (e.g. Portfolio). ITIL recommends the holistic approach for all Service Design aspects and areas. This ensures regularity and incorporation.