Everything Looks Green From Where You Are Standing 

Digital service operations is the practice of running the IT and digital services a business depends on proactively, so that trouble is caught and dealt with before a customer ever feels it. AIOps is the intelligence that makes that possible at scale. This is the story of how that intelligence changes the two numbers every board cares about: how often services fail, and how quickly they recover.

Mak: This is somebody’s house?

He said it from just inside the door, his bag already gone. They take your bag here. There is nowhere to put it and nowhere to stand, and the woman at the desk had explained that you would put an elbow through something irreplaceable just turning around. Mak handed it over and walked in and stopped almost at once.

He had flown in from Indore that week. We were in London together to prepare for a meeting with a large insurer, and we had the day before it to ourselves. I had been telling him about this place for two years, and he had pictured something grander. Most people do.

Mak: Who lived here?

Keyvan: John Soane. An architect. He built half the things you would recognise in this city and almost nobody knows his name. He also could not stop collecting, and anything he liked he brought home. The house is what happened.

 

What Soane did to the house is the thing you cannot picture until you are standing in it. He cut away the floors through the middle of the building and left a shaft of open space running from the glass roof at the top all the way down to the basement. So you walk in on one level, and you find yourself on the edge of a kind of balcony, and when you look up there is light pouring down through three storeys, and when you look down there is the same drop falling away beneath you. Every surface around the void is crowded with marble. Cornices, fragments, the head of a statue jutting out into the air at the level above you, an arm reaching from the level below. Mak went to the rail and looked up, and then he looked down, and he stayed there for a while.

Mak: You can see the same things from every floor.

Keyvan: You can.

Mak: But each floor shows you a different part of them. That head up there. From here it is a face. From the floor above it would be the back of a skull. From below, the underside of a jaw. Same object. Three floors, three completely different things, and you would not know they were the same object unless you could stand in all three places at once.

Something in the way he said it stopped him, because he turned away from the rail and looked at me.

Mak: You have one problem in a live service. One. And it shows up in a dozen places looking like a dozen separate problems. The application team sees errors climbing. The platform team sees something straining. The people watching the network see a delay on one path. The service desk sees the calls starting to come in. Every one of them is looking at the same single failure from a different floor, and every one of them thinks they are looking at their own.

Keyvan: But that is nothing new, is it? The view has been split like that ever since client-server architectures became the norm. Different teams, different tools, different parts of the same elephant. Why is this any different now?

Mak: Because you no longer have to be the one who stands in all three places at once. That used to be the job, and it was impossible. A modern service is built from hundreds of moving parts that come and go by the minute, and no person and no wiring diagram could keep up with what depends on what. An AIOps platform now works that out for itself, by watching how the service actually behaves and what talks to what. So when the one real fault occurs, instead of a dozen teams opening a dozen bridges, it gives you the single thing that caused all of it, and it understands the rest as consequences of that one thing. The noise falls away and you are left looking at the cause.

Keyvan: And tomorrow’s meeting is a good example of why that matters. This is a personal and commercial lines insurer, and the thing they want to talk about is the claims journey. Think about what a claim actually is. Someone has had a fire, or a fleet of vans is off the road, and the moment they come to you is already the worst day they have had in a year. If the service that takes that claim is slow, or down, or loses them halfway through, you have a furious customer at the exact moment they are deciding whether to stay with you. That is churn, and it is cost to serve climbing at the same time. So keeping that journey healthy is not a technical nicety for them. It is the business.

Mak: And a claim is exactly the kind of service I mean. It is not one system. It is a long chain. The broker portal, the policy lookup, the fraud checks, the payment, the documents, a dozen handoffs, and a person waiting at the end of all of it. A failure can hide anywhere along that chain and present as something else entirely. Which is why the first thing you have to be able to do is see the whole journey as one thing, the way you can only see that statue head once you can stand on every floor at once.

Keyvan: So once you can see the whole journey, what is it you are actually watching for? You could watch ten thousand things and drown.

Mak: You come back to three questions, and only three. Is the service available? Is it performing? Is it doing the job it exists to do? Availability, performance, functionality. Can a broker reach the claims journey when they need it? That is availability. When a storm hits and a thousand claims arrive at once, does it stay quick or does everyone wait? That is performance. When a claim goes in, does it actually move through and settle? That is functionality. Answer those three honestly at any moment and you know the health of the service. Everything underneath only matters for what it does to one of the three.

This is the rare technical idea a board grasps without translation. A CEO has no wish to hear about thresholds and event streams. A CEO leans forward for the question: is the thing our customers depend on available, is it fast enough, does it do the job.

Keyvan: So you have the whole picture and you know the three questions to ask of it. That is a very good monitoring system, Mak. We have had monitoring systems for thirty years. People have been staring at red and green screens my entire career.

Mak: And that is exactly where most organisations stop, and it is the thing I most want to change. A screen like that tells you something has gone wrong. It tells you after. By the time it shows red, the broker is already on the phone and the customer has already had a bad morning. Watching for the moment something turns red is waiting to be told you have a problem.

Keyvan: You are going to tell me there is something better than knowing the moment it breaks.

Mak: Knowing before it breaks. Almost nothing in a real service fails in an instant. It drifts there. A journey gets a little slower by the day as volume grows. A change goes in on Tuesday and something starts behaving differently by Thursday. The signs are there long before the failure, and they are too small and too spread out for a person to catch. So instead of waiting for something to go wrong, you learn what healthy looks like for that service, and you watch for the shape of it starting to bend. The claims journey is answering a little slower each hour this morning. At this rate it gives out by lunchtime. There is your quiet hour, and your chance to act, taken before a single broker has noticed anything.

Keyvan: But how on earth does anyone watch closely enough to catch that, across a service that size, every hour of every day? No operations team I have ever seen could do that.

Mak: No team could, and that is the whole reason the intelligence is there. That is the part the letters AI are doing in AIOps, and it is the only thing they are doing. It is what makes this possible at the scale and the speed and the constancy a real estate needs. It holds the whole picture at once, it knows what healthy looks like better than any individual could, and it sees the shape starting to bend across thousands of signals while everyone is asleep. And where the right response is already understood, it takes it. It moves work away from the part that is starting to strain. It puts capacity in front of the demand instead of behind it. It reverses a change that has started to misbehave before most people are touched by it. The customer at the end of the claim feels nothing, because the thing that would have become an incident was dealt with while it was still a trend.

 

 

We had come down by now to the floor of the house, where the open shaft bottoms out and an enormous Egyptian sarcophagus sits in pale alabaster, lit from above through the glass. It is the size of a small boat. Mak put his hand near the stone without touching it, and I asked him the question I had actually brought him here to think through.

Keyvan: Put it in the language my board uses. If I spend money on this, what moves?

Mak: Two numbers, and they are the two that matter. The first is how often a service-affecting failure happens at all. Stretch the time between those failures and you have a business that simply stops falling over so much. The second is how long you are down when something does get through, because nothing catches everything. Shorten that, because the intelligence has already found the cause and done the first hour of the work before a person even arrives, and the day a failure does land, it costs you a fraction of what it used to. Fewer failures, and shorter ones. Those two numbers are the whole business case, and a board understands both without you explaining either.

Keyvan: And the first of those, the failures happening less often. Where do most of them actually come from? Because you make it sound as though the system just prevents them out of the air.

Mak: It does not, and this is the part people miss. Most service-affecting failures are not bad luck. They are caused by us. Something we changed. A release, an update, a fix that was meant to help. So the single biggest lever on how often things break is the quality of the change going in. This is where it stops being an operations story and becomes a service-management story, because the operation has to be wired into how change is governed. When you can see the true health of a service, you can see what a change did to it within hours, and you feed that straight back into the change process. The changes that cause trouble get caught and stopped earlier. The ones that keep causing the same trouble get fixed at the root. Good change management is what makes failures rarer in the first place, and a proper operation is what keeps your change management honest. The two of them work the same two numbers from opposite ends.

Keyvan: So it loops.

Mak: It loops. You run the service, you see the truth of how it behaves, and you carry that truth back into how you decide and govern the next change. Failures grow rarer because the change going in is better, and the failures that still slip through are shorter because the operation is already on them. That loop is the thing worth building. The screen on the wall was only ever the very first inch of it.

 

 

We came to the small room at the back. I had been saving it. It is just over thirteen feet by twelve, and nineteen feet high, and every wall is covered in wooden panels. It looks, when you walk in, like a modest panelled room with a handful of pictures on it. The guide asked whether we would like to see, and she took hold of the first panel and swung it open.

Behind it, paintings, a whole wall of them where a moment before there had been a flat panel. Mak made a sound. Then she took hold of those paintings, because they are themselves hung on hinged planes, and swung them open too, and behind them were more paintings still. He stepped back. Soane built this room so that a hundred and eighteen works hang in a space that looks as though it could hold a dozen, by folding wall behind wall behind wall. A visitor who is never shown the planes walks in, looks at the calm surface of the room, and leaves believing they have seen it.

Mak stood in the middle of it and said nothing for a while.

Mak: How many were there?

Keyvan: A hundred and eighteen. In a room this size. You would never know it from the wall you walk in to.

Mak: And most people only ever see that wall.

Keyvan: They see a finished room. It looks calm and complete. Why would you knock on it?

He nodded, and I knew he had arrived where I had arrived a moment before him. This is the room every organisation thinks it is running. The service looks calm from the level you are standing on. The wall in front of you looks finished. And folded behind it, out of sight, is everything actually happening to that service, all the parts of the claims journey moving and straining and drifting while the surface stays still. The mature operator is the one who knows the room is far deeper than it looks and keeps opening the planes, while it still looks calm, until the thing forming in the back of it is found long before it ever reaches the wall you can see. Almost everyone else stands at the calm surface and calls it the room.

We collected Mak’s bag and stepped out onto Lincoln’s Inn Fields, into the grey and the wet, the great square spread in front of us with its bare plane trees and a single barrister cutting across with a folder held over their head.

There is a café in the middle of the square, and we had the afternoon. And there was a wall I wanted to get behind, the one Mak is best on. If a thing this useful makes failures rarer and shorter, and a board understands the case in a sentence, why is almost nobody truly doing it? What keeps an organisation standing at the calm surface and calling it the room?

In Part 2, Mak and I get into exactly that, over a pot of tea, with Ray joining us for the part about data. The things that keep organisations standing at the surface. Almost none of them are about the technology.