IT Service Management Strategy
It’s true. The full potential of automation cannot be fully realized until it is informed and supported by an effective IT service management strategy (ITSM) that encompasses your entire IT environment, as well as business objectives, and corporate policy. Technology and business really can function as one. That’s when the magic starts.
Realizing that potential is not easy to accomplish, however. And I’m saying that with some hard knocks behind it. You need to have a clear vision of the transformation that leveraging cloud computing through automation and orchestration can accomplish for your organization, but you also have to know that the journey from here to there is apt to have some challenging, if not harrowing moments.
That’s because much of the journey involves rooting around in your own stuff: the IT environment that has been cobbled together over the years, much of it by technicians who have added several lines to their resume since leaving your company; the culture of aggressively protected fiefdoms between your server, storage and network teams that has them jousting against each other in recurring budget fights; the conflicting expectations of C-level executives who want you to do more of everything and spend less doing it; and the tendency on the part of virtually everyone in your organization to want to do things tomorrow just the way they did them yesterday.
The Rabbit-Hole of Self Discovery
Be careful what you wish for. The pursuit of the benefits of automation leads you inevitably down the rabbit hole of self discovery. You need to know why things work the way they do in your organization—not just the technology but the people and processes as well. You need to examine all the assumptions you’ve made about the interdependencies across your infrastructure. You need to stand eyeball to eyeball with everything about your IT environment that keeps you up at night trying not to think about.
And, when you have become intimately familiar with every detail of the way things are, then you have to define—in exact detail—everything you want to accomplish in the future. Want to reduce time to market for new services? What does that mean, exactly? Want to leverage the technical, financial and operational efficiencies of cloud computing? How do you plan to do that…exactly.
The good news is: If you can define it in enough detail, you can have it.
Automation accomplished through a tight integration with ITSM forces you to work at the right level of detail to define what you want to accomplish. Some of the details you have to work with, however, are highly nuanced.
A Matter of Pride
Some are people. It’s easy enough to complete automation scripts that will do some task and update your ITSM system. The issue is: what if someone accesses your infrastructure and does something manually, i.e., doesn’t use the automation. How do you know that? Most service management techs take it as a matter of pride to be able to go in on the command line and solve problems. They may not like being told: “Hey. You are not allowed to go in on the command line anymore. Now there are two buttons you can push: Reset or Restart.”
Your technicians need to have confidence that the tools and procedures they are given can actually solve the problems they are charged with fixing. The only way they are going to have that confidence is if they understand how automation works at its most basic level. Automation tied into ITSM has the potential to free your technicians from repetitive tasks of routine maintenance, but switching their allegiance over to some automated process isn’t any easier for them then it was when IT teams came streaming into virtually every other department in the organization and automated what they did for a living.
Ironically, the IT department has been a hold out on the automation that their technology has set loose on everyone else. Now it’s their turn. And, for the same reasons. Just like everyone else in the corporate world, things are happening way too fast for the most agile technician to keep up using manual tools and seat-of-the pants methods—no matter how willing he or she is to work all-nighters on the weekend. As the IT environment expands to private, public and hybrid cloud environments systems need to be able respond dynamically to each other in accordance with pre-approved policies and procedures. Automation is the only way they can do that at the speeds required.
It’s a good rule of thumb to try out automation with your technicians first and then gradually make it available to a wider community of users. Before you make anything available at a self-service portal, you need to be very sure it can’t inadvertently be used against you. We generally let our monitoring team try out an automation script first and make sure they have no problems with it. Then we’ll let the network technicians use it and work any kinks out before turning it on within service management so customers/end users can do it for themselves.
An Expanding Wave of Data
Plan on changing…all the time. The inescapable truth about automation is that as you extend its reach you need to be aware in real-time of an expanding wave of data about essentially everything that’s going on in your IT environment. The inter-dependencies of systems within your environment grow exponentially as you integrate more functions into automation. Basically, anything has the potential to change everything else. Ideally, you would have an enterprise service bus combined with messaging that is able to see the entire process flow between all your systems. Your hypervisor needs to be able to report on itself to a central queue, for example. It might say, “I just deployed a virtual machine,” and your other systems then will be able to respond accordingly. Service management, in this incident, will see the message from your hypervisor and know to create a configuration item (CI).
Just the thought of all the uncertainties you can expect to encounter on the automation journey toward cloud computing is enough to cause the hardiest IT pros to pause and start to think that maybe standing still isn’t such a bad strategy. It’s worked until now, they might say.
Standing still is not a strategy, especially in this day and age.
A Great Adventure
Automation and the journey toward cloud computing in general have all the components of a great adventure. Exciting technology, leaps ahead in capabilities, performance, and efficiency. Technicians could see it as an opportunity to get free of mundane, repetitive tasks and unleash their talent to tackle creative projects that support the business. Technology leaders could see it as an opportunity to actually be able to do more with less and become a true service provider instead of just a cost center. Business leaders could see it as an opportunity to surge ahead of the competition and finance IT out of the operational expense budget (OpEx) instead of capital expense budget (Capex).
But if the prospect of all the things – real and imagined – that could go wrong still discourages you from getting started with your automation adventure, consider this for motivation: There is always more to be afraid of in standing still than there is in moving forward.
“Don’t look back. Something might be gaining on you.” Satchel Paige
By Brian Day