Editor's note: Arik Hessendahl is a guest blogger covering PuppetConf.
If you know anything about the ways that IT operations have evolved over the last decade or so, then you intuitively understand how automation can be beneficial. I’m no technical expert, but I’ve spent a fair amount of time over the last 20 years talking to them, so I get it, at least in broad brushstrokes.
But there’s broad brushstrokes, and then there’s details. During my two days at PuppetConf 2017, I learned a lot about how companies as varied as Nike and Porsche have embraced automation as a critical step as they’ve wrestled with the digitally-driven changes to their overall business. I was surprised to learn how much of a difference automation can make in allowing IT teams to be more efficient and thus play a bigger part in those bigger changes.
I got the chance to talk about it with Puppet CEO Sanjay Mirchandani. We met a few hours after he had delivered his PuppetConf keynote, and I decided to drill down a bit on a key point he made on stage. An edited portion of our conversation is below:
You said today that many organizations who are going on this journey have success in just one part of the organization and that it’s siloed off and that it’s difficult to scale it up. Why do you think that is?
The way it tends to go, is you take some transformation project or a mobile app, you do agile and you do DevOps, and you go deep with that project and you automate the infrastructure around it. The success tends to be isolated to that project. Everyone who has been in on the project — business, security, development, ops and engineering — everyone wants to take it more widely into the company.
It’s like they’re suddenly the cool kids in the company.
Exactly. But what happens is that once you leave that project you’re back to your old ways. Or sometimes they go back and apply something horizontally across the company, like say, config management. So the thrust of my conversation this morning was for automation to become really pervasive in a company you have to go both broad and deep.
You either go deep on a project and everyone’s eyes are on it. You build it and you automate the entire capability, and implement DevOps. And it works beautifully. But the moment they leave the project it’s back to the old way. CIOs see this because all eyes are on those successful projects and they wonder why they can’t take the techniques they used on it everywhere in the company.
Or there are cases where IT takes a particular domain, for example config management, and go super-wide with it, so it goes broad but with a sliver of functions. The magic dust of automation only works when you go both broad and deep.
This is a variation of a conversation I’ve had a lot of times, where older, established companies envy and try to replicate what these younger and more agile competitors can do. What do you think is stopping them? What are they bumping up against?
We could talk for hours about this. I had a ringside seat at a well-run IT organization while I was CIO at EMC. There’s incredible envy of the born-in-the-cloud companies. They’re newer, so everything they’ve got is fresher. And at a high level they have only one of everything: technology, process, standards. And they go at whatever they’re doing maniacally. They simplify, they standardize and they automate. Established companies tend to have at least one of everything. It’s just where life has taken them. And so you end up being a systems integrator for everyone else’s technology and you spend hours trying to make things work as they should. It’s too hard and it’s been too hard for a long time. At Puppet we believe that’s changing.
When Puppet goes into these engagements with these companies, is there a playbook you follow? Or is it tailored and specific to the customer?
The conversation with the CIO starts with the question “Do you have an automation roadmap?” And you’d be surprised how few actually do. Some say they’ve had some success with it and they see how they can stand to benefit from it. But the essence of what these conversations leave me with is that it’s not widespread. And everyone wants to take that initial success they’ve experienced and want to make it pervasive. … They want to know how they can get more productivity from people by automating things. How do you eliminate errors by automating more things? The number one reason for outages in IT in my experience is human error.
That makes sense. Someone can mistype an IP address somewhere and bring something down.
These things really do happen. And there’s no reason for them to happen.
When companies go through this sort of change, it usually happens in phases. What do you think the phases are?
I would say there are three or four phases depending on where you are in the lifecycle. But the simplest way to think about it is with product heros. They get started on a project and they do this right from the beginning. And others see that success and start asking how the hero did it. The content and the approaches and the tools get shared and it starts to spread. And our estimate is that this can get you to — pick a number — 15 percent or 18 percent of your core infrastructure. And the infrastructure is the stuff that runs the applications and some of the network and some of the storage, and maybe some of the cloud workloads. And that exposes you to some of the process changes. And that gets you to a tipping point where you go from 15 percent to maybe 50 percent or 60 percent and you’re cracking some really big rocks. Then the biggest rock that most people realize they have to crack is simply asking “What do I have?”
That’s a big a complicated question in some IT shops.
Right? And it sounds silly almost, but what if you’ve bought 10 companies over the last 10 years. Or you’ve opened data centers overseas. Or you’ve spun something out. Everything is moving so fast that it’s hard to keep up. So we believe that not knowing what you have when you start this process is a big inhibitor. And so I think that’s an opportunity for technology so you can can figure out what you have so you can manage it, and then do things to it.
The next phase is when you ask “Okay, what’s left?” And that is the hardest piece because it’s about changing processes, you’re changing the way that people have always done things. As a CIO, the toughest job is to change how things are done when they’ve been done a certain way and to say they’re going to be done in a new way.
Is resistance then more about culture than technology?
Technology is the easy part. You’ve always had religious wars about technology, but once you’re able to prove that the stuff you’re doing actually works, it becomes less about the technology but about how you get there, and the destination. That’s where leadership has to step in help people see what the endpoint looks like and get them there.
So you talk to a lot of CIOs about this. Broadly speaking, where are they in those three or four phases?
My estimate is that as much as 40 percent of companies are in phases one or two.
If you’re at or approaching phase one, really just starting the process, how do you begin?
You start by looking inside your organization. You’ve got pockets of this already happening. You’ve got heroes who have made their own lives easier by automating. They’re already using Puppet or something similar. Go find them. Make them the heroes. Make them the champions and help them share what they’re doing. Just cast the net. You’ll find them.
Arik Hesseldahl is veteran technology journalist and independent analyst. He was a founding editor at Recode, has written for The Wall Street Journal, Bloomberg BusinessWeek and Forbes, and has contributed to CNBC and NPR.