Hey there, aren't you the one who keeps telling everybody that the IT operations team is a service provider to the business? That you're customer-centric? That you deliver high-quality technological capabilities for a fair price? Aren't you the one who said that you know what it takes to satisfy the needs of developers and application owners and your IT operational plan is foolproof?
If that's the case, then why are your "clients" taking as much business as they can to public clouds and other service providers? If your service is so awesome, why do the budget owners keep telling you you're too slow, expensive and are lacking capabilities they can get elsewhere?
If you really want to be a service provider, you need to think like a service provider.
In the past, the job of a data center owner and IT operations team was to provide safe, reliable and efficient facilities, storage, networking and servers to operate applications. Provisioning these, as well as operations and monitoring tools, is what typically comes to mind for a service provider.
One of the challenges in an internal IT operations team getting credit as an IT service provider is that most of what you do every day is invisible to your customers. If you didn't run the generators, check the power distribution units, monitor the ambient temperature on the data center floor, perform change control, replace or rack and stack new equipment, put out fires, upgrade the storage frame, open the ports, plug the holes, and stop the distributed denial-of-service attacks, at some point nothing will work. The problem is that nobody cares that you do any of these things until one thing breaks.
Balancing reliability and innovation for strategic IT planning
There's a reason data center leaders are the last to try something new: career safety. Take a data center and IT ops leader, Bob, vice president at a fictional company, Corporation 1. As a data center veteran of 20 years, Bob has seen it all. He works 70 hours per week to keep IT running, and relies on big vendors to cover him, never taking the newer and sometimes better tool sets from innovators.
Because he uses time-tested products with time-tested processes, Bob's IT strategy and performance is totally drama-free. Bob doesn't listen to others (including his customers) about what's going in the market and has no interest in "competing" for business with Amazon. "I know what my company needs" is a common refrain.
But end users complain that Bob's processes are killing them.
A virtual machine (VM) provisioning request is six pages long and takes 10 approvals to get into the task queue, typically over three to four weeks. The build and delivery of the VM might take another week or longer. Pre-delivery testing often finds issues that need to be addressed, because Bob's manual processes are error-prone. However, once the VM is up and running, reliability is never an issue.
At another fictional company, Corporation 2, Pete is an experienced data center and IT ops leader who is comfortable taking risks. He attends conferences and sends team members to see the new technologies and processes. Pete has a vision of a lights-out, hands-off data center using end-to-end automation and a lot of never-tried-before processes and steps. Pete built a private cloud at the company that includes an integrated service catalog and far lower-cost models than traditional IT provisioning.
The end users love Pete's cloud and the fact that the VM request-to-delivery cycle often takes less than 30 minutes. But reliability has been an issue due to pressure to get the new cloud operational, with a few high-profile outages that affected the business. Pete knows that this is a small price to pay for being a true service provider.
In most IT organizations, Pete is more likely to get fired, while Bob is more likely to be promoted. Being innovative at the expense of service interruptions and downtime is not a good tradeoff in most IT shops. Poor service-level agreement performance is why risk taking is something you do not want in your IT operations team.
What if you want the stability of Bob with the innovation of Pete? What do you do? Start selling management on the concept that your IT team already delivers services. Then, develop a larger plan about how to accomplish that end-user satisfaction, but with higher reliability and resiliency.
How to overhaul your IT operational plan
There are certain steps IT operations folks can follow to become true service providers to their companies and end users. Here are five main steps to take.
Step 1: Listen to end users. Go talk to them and hear what they need. Often, that means hiring one or more product managers to create product requirements and balance competing priorities.
Step 2: Set your benchmarks against the right alternatives. Amazon may not be the right benchmark for a cloud, though for many it will be. You may not be building a cloud, necessarily, so pick your benchmarks correctly.
Step 3: Create your "minimum viable product" concept. Use the insights you get from end users and product managers to develop a concept, then go back and validate it with end users. And for your sake and your users' sake, keep it simple!
Step 4: Focus on early wins. Start with small capabilities for one or two simple use cases that can be fully automated and reliable. The worst thing you can do right now is try to deliver too much in your first release. Build your architecture like application software and ensure 100% "cloud coverage" in your QA and automated-testing regimes. Be safe by keeping it small and testing it like your job depends on it. (Guess what? It does!)
Step 5: Take stock. Measure user satisfaction with you as a service provider and make the measurement a regular and automated process. Use metrics such as Net Promoter Score to see if your end users will recommend your new service to their peers in the organization.
If this sounds like being a vendor, you're right. If you don't think you're competing for business within your company, you're not getting the point. If you really want to be a service provider, you need to think like a service provider.
This was first published in August 2013