Sorry, you need to enable JavaScript to visit this website.

Redefining the Service Catalog and Self-Service for the XaaS Era

Redefining the Service Catalog and Self-Service for the XaaS Era
February 17, 2017

With the proliferation of ITIL-based IT service management tools, many enterprises have availed these services – often becoming complacent and believing they have intrinsically embraced the service catalog and self-service offerings. This complacency is actually driven by the tool vendors’ definition of service catalog and self-service. While it had earlier served the purpose for legacy IT, a serious re-evaluation is required to determine its viability for the Anything-as-a-Services (XaaS) era.

Classic IT service catalogs are actually ‘Request Item’ catalogs (or Service Request catalogs). They are primarily designed for initiating a transaction-based service and the fulfilment of a specific item for the requestor. A typical Service Request Management System (SRMS) will generate a task or work order, automate the workflow to deal with that order, and the finally fulfilment happens manually. The same SRMS is also positioned as a self-service implementation tool, both by the vendors and the IT organization. The ability of the user to go to the portal, submit and track the request as it progresses is deemed as the self-service element. This is a long way from achieving real self-service – in classic SRMS implementation models, a true service catalog element and a true self-service element are typically missing.

What is a true self-service element? True self-service allows you to obtain the outcome without any intervention from service providers. If you have to await the execution of the fulfilment task by the provider, after having submitted a request for a service, then it is not known as true self-service.

Of course, you are able to track the task’s progress – but the outcome is not obtained, therefore the ability to track progress is also not a true self-service element. True self-service can be realized by appropriate service design, automation and empowering the service consumer with the ability to run the automated fulfilment method.

The most common example of self-service is service support in password reset automation. In the case of service delivery scenarios, a cloud service provisioning process is another common example. Service delivery systems may also allow you to provision, start, stop and reboot your service. We find frequent examples in the business world – for example, personal banking services allow you to pay bills and transfer money, or with automated airline services, we can book a new flight or change the seat without the provider’s intervention.

The XaaS world will usher in a new avatar of self-service. We envision a dedicated database to maintain the self-service component for each service and IT service management tool. A service may have multiple self-service components – each self-service component designed for a specific task. These tasks are either automated through API, or they invoke an orchestration model (execution method). Information about all of the above elements together forms a self-service delivery database.

Is an ‘item’ in the request catalog a service? Classical SRMS systems publish a catalog of ‘item’ to be delivered. SRMS generates a task (work order) and relies on the execution of the task to deliver the service. In fact, an item published in the request catalog may or may not be a service. A physical item or product, though not a service, can be deemed as one – because the execution of the task delivers the physical item (say a laptop) while it is actually the performance of ‘fulfilment service’. It fits very well into the fundamental definition of a service — benefits produced by execution of activities.

What about non-tangible items that really are services? Tasks are generated for fulfilment, but does the execution of the task actually produce the desired service? A classic request catalog may not have the mechanism necessary to guarantee that in the fulfilment process and may even require external systems processes. This is very likely to happen if the fulfilment tasks are manually performed.

In other words, the item in the catalog may fail the criteria of being a service. A service in the service catalog may be composed of multiple services – requiring orchestration across multiple service providers for delivery fulfilment. Such examples are common in business – travel services, for instance, offers airline, hotel, and car-rental bookings.

In IT operations, especially in XaaS models such as PaaS and SaaS, provisioning processes require orchestration across multiple elements.

The XaaS era will herald a new avatar of the service catalog that will incorporate orchestration as an integral element of the service catalog. A XaaS system would publish the consumption component, and the integrated orchestration model would be used for seamless outcome fulfilment and delivery – the entire process visible in the catalog.