Invisible Service Management

Artificial intelligence (AI)-enabled automation is increasingly seen by organisations as a critical driver of efficiency and enhanced user experience within their service management domain.

The evolution of IT Service Management continues at a rapid pace – in recent years we’ve seen the shift from pro-active to predictive to cognitive – and most major ITSM vendors lay claim to that these days – but there is another evolutionary cycle under way; that of Invisible Service Management (ISM).

Before we delve too deeply into ISM let’s consider the payments industry and what has happened in that space; during that same period the payments industry has undergone seismic changes in their use of AI and ML; how many people now pay with cash? Wallets which would have bulged with notes now bulge with cards, and for the savvy those cards have been consolidated into digital wallets; we wave our smartphones and watches at a reader and our transaction is done.

Companies like AirBnB and Uber have taken this further, moving us into the age of invisible payments; taking the example of the latter, we request a service and wait for the driver, and at the end of it, once we have the confirmatory email, we have the option of rating the driver and adding a tip if we want to show our appreciation for the scintillating conversation we’ve enjoyed; this is as close to zero touch and as invisible as they can make it. Do we worry about the payment? No, we know that it’s all been dealt with in the background. We have an established trust relationship with Uber that is underpinned by the transparent and sophisticated use of AI.

Switching back to ISM,  this is exactly what is coming down the line, an absolute trust relationship between myself, my  user entity and all that is related to it, and the ISM system. If there is an issue, or the potential of one, with an item in my IT universe, one I don’t even need to be aware of it, the service will deal with it in a manner invisible to me, but which ensures that at all times I am able to use the business applications I need in my role.

Let’s deconstruct this:

• I, as a business or customer user, am a consuming data entity

• My entity is related to other data entities

• I exist within an data entity universe unique to me, but related to other data entities and universes, which are part of a business wide data mesh

• My entity universe has a configuration unique to me

• My data entity is constantly monitored and key data collected

• The data is analysed to identify potential issues and the impact to my data entity and to others sharing the same configuration patterns

• A Healing Pattern is established and validated

• Healing packages are collated and applied

• Once applied and validated I am informed that an action was taken, and that is the extent of my interaction with the ISM.

What makes this possible is firstly the use of lightweight collectors, kernel level micro services gathering data on:

• Devices

• Application packages

• Executables

• Binaries

• Application availability

• Network paths

• Ports

• Destinations

• Connections

• Network bandwidth, 

• Memory and CPU consumption

• Signature changes

• Activities

  • Installations

  • Executions

  • Web requests

  • Print jobs

Secondly it’s the increasingly sophisticated and trusted use of AI and ML – thoroughly trained –  to analyse and identify possible issues, the extent of the impact of those issues, the priority and urgency and to trigger the appropriate automated corrective actions. All of this logged and with a clear audit trail and the “experience” used to train and refine the AI for future use. All of this invisible to the affected user(s). And no human touch so far.

NO HUMAN TOUCH!

Of course there will be human touches. The support analysts who used to man the telephone lines, wait for the chat bots to transfer conversations into their queues, are now busy creating and updating knowledge – data that drives the ISM engine -, training the AI, building the automated workflows and remediation paths, and monitoring the effectiveness of service delivery, and acting on the user sentiment feedback.

But where does an organisation begin on the journey to ISM? The first step is not to look for an ITSM tool as the magic bullet, but to have a comprehensive Service Catalogue, to know which services need to be fulfilled and who/what will be consuming them. Map each service end to end, identifying hand-offs and dependencies between groups and systems, and then optimise and automate the top 10. Identify a pilot group and test and refine the fulfilment flows using feedback from both the support teams and the users. This requires close management and collaboration between the teams but this will identify any changes to the organisational structure to accommodate new roles and responsibilities. Also, equally importantly, the results will inform the pace at which you then move towards a state of complete Invisible Service Management.

In my next article, I will go into the key considerations your organisation will need to address before initiating your journey to ISM. These will help you assess the requirements for a successful outcome.

If your organisation is struggling to start the journey or is ready to develop a plan for a future-ready ITSM then contact Sentinel Software Systems Ltd for an informal chat.