How Good Is Your Service Definition, Design and Transition?

To make matters worse, customers construct their own services using evermore complex supply chains which involve not only the traditional IT department, but also cloud provisioning (e.g. Azure, AWS) and direct partnerships with middleware and software-as-a-service providers, who provide platforms where business process is automation, and digital transformation become a reality that had previously been out of reach to many.

And still we hear the constant challenge of the need for a service design, the “service wrapper”, and service performance monitoring targets and reports.

So, against this backdrop it’s probably time for us to get a clear definition in our minds about what actually constitutes a service, so that we can do the service design, service transition and all the other development disciplines correctly first time.

Today’s project managers, technology managers and business change agents are being faced with the challenge of effective service definition as their services are often constituted with a mixture of commodity services such as cloud(E.G. AWS), as well as homegrown applications Systems and infrastructure components.

I’ve always defined the service as something which supports a business process, something with an outcome and something which is tangible by the business.  Of course, in a complex supply chain there will be many different perspectives on the service being provided, as the service providers themselves will perceive their element of the service as a service in its own right but it is in fact amalgamated with a number of other services to form a business outcome.

So how do you do ineffective service design and how do you ensure that services transitioning from the project development world to the production environment to be supported in BAU are adequately documented and defined?

In my opinion, it all starts with an effective set of service design criteria. These would be constituted of the building blocks of a service as defined in best practice standards such as ITIL, and include things such as service requirements and outcomes relating to performance, availability, reliability, availability. As well as, other elements of a good service design such as disaster recovery/Continuity arrangements, capacity requirements and operability requirements.  Critically, these are not written by technology architects.  They are designed collaboratively with users, business sponsors, business process owners and technical support teams.

Most critically of all however is the desire to ensure that all services meet the required business outcomes, and this therefore requires outcomes to be documented in the first place and the outcomes to be measurable in order that they can be proved.

Hand-in-hand with the requirement for effective service design, comes the requirement for effective service transition.

In other words, ensuring that services not only operable supportable maintainable available etc, but the quality of these service elements can be assured by the life-support operation prior to the service transitioning from the development of our environment into BAU (business as usual).

A highly effective service design process will only be as effective as the service transition process which insures its quality.  The inverse is also true.

Defining what constitutes a service isn’t easy.  However, it should not be bypassed, nor should it be viewed as a “necessary evil” to appease a governance forum.  A set of service design principles should be seen as the touchstone of any service, in that it is constantly referred to, throughout the project lifecycle, especially at the point of transition.

How good are your service design and transition practices?  By far, this is the area where we are being asked to offer assistance to our customers, as the importance of service definition in today’s complex world becomes more evident.

To find out how we help organisations like yours design and build highly effective operating models, read our ultimate guide to ITSM.