By Alastair McAulay, PA IT and cloud strategy expert and Fred Johnsen, PA AI and automation expert
The cliché of the butler who’s shrewder and wiser than his master is well known throughout the world. P.G. Wodehouse must be credited for creating Jeeves, the most memorable fictional (and very English) example of the indispensable servant who quickly learns how to resolve awkward problems and make things happen. Without him, Bertie Wooster would get in a terrible mess.
And you could get in a terrible mess if you don’t plan ahead when you introduce AI and automated systems. You could become reliant on tools that continually learn more about how the business and the IT operations work. Like Bertie, your organisation might become utterly dependent on those systems and tools and the knowledge accumulated within them. What would happen if you wanted to switch supplier? To replace the irreplaceable Jeeves?
In one sense it’s not a new problem for IT. There used to be far higher levels of undocumented operations in the IT team – legacy systems created with specialist technology and arcane programming languages known only by the few. The ‘Y2K bug’ code conversion extravaganza of the late 90s helped get a lot of these systems under control. Since then there’s been a greater awareness of the need to share knowledge and not let it reside in human brains. And organisations have almost universally adopted documented best practice (like ITIL®) to provide a framework for describing how systems operate.
But it becomes challenging with autonomic systems because they learn and adapt through experience and reinforcement. Should your organisation decide to switch to a different supplier, it’s likely that the years of contextual knowledge built up within the autonomic system will be lost. Any new system will have to start from scratch. So it will take a while to see any benefit and, worse still, something could go badly wrong in the meantime.
Forewarned is forearmed
So, right at the start, you need a plan for how you’ll migrate between autonomous toolsets in future. It’s new ground for many suppliers and their customers. We think there are three main things to put in place:
- Make sure your exit requirements include provisions for transferring knowledge from the outgoing suppliers. Traditionally, knowledge of how to run a customer’s IT systems is captured in runbooks that by their nature are intended for human technicians to share. In an autonomous system these won’t exist, so we recommend identifying an alternative way of knowledge sharing from the outset.
- Make sure it’s clear who owns what in terms of the learning inside an autonomic toolset and what happens if suppliers have evolved or enhanced their core tools based on what they’ve learned from the way you work. You might not be happy to share your recipes for performance tuning a system with a rival business.
- Get bidders to clearly demonstrate how they’ll meet the service levels you’re used to getting, while their toolset learns your environment, and ask them how they intend to acquire the knowledge.
There’s no doubt there’s an excellent business case for adopting more and more autonomic systems operations –- for taking away the low-level drudgery in people’s jobs. But it’s essential to manage the way you introduce the technology and monitor it as it learns. Your negotiations with suppliers must include how the autonomic system’s learning is monitored, recorded and ultimately transferred.
Every CIO needs to ward against the Jeeves syndrome.
Artificial intelligence (AI) and automation: is your IT department getting left behind?
“I’m sorry Dave…I can’t do that” – making sure chatbots and AI don’t ‘go rogue’