CIOs need to avoid a mistaken path to DevOps

DevOps is the completion of the Agile methodology and creates an engineering environment in which developers can achieve speed. How fast is the difference? Agile is like a person running fast – about 20 miles per hour tops. DevOps is like a person driving a Ferrari who can exceed 200 miles per hour. Often as I talk with CIOs, I learn they focus on automated provisioning as an important aspect of DevOps. And it is. But it’s only a small component. Achieving the engineering environment similar to the acceleration of a Ferrari requires fundamental operating changes. 

For a decade or more, the IT community has been experimenting with and adopting Agile principles. It had origins in Silicon Valley where the need for speed in development caused them to develop this methodology, which was later widely adopted by large commercial enterprises.   

Once again, it was the tech startup community that determined that just using the Agile methodology is incomplete for achieving the desired development speed. So they started surrounding Agile with automation and also a different operating environment. That environment is software defined and is most easily visible in cloud offerings. It’s known as DevOps, which is a combination of a software-defined operating environment and automated tools for provisioning, testing and the ability to manage that operating environment. DevOps is the completion of Agile. 

A mistaken path to DevOps 

DevOps is not just a set of tools or a methodology. It’s a fundamental rethinking of what IT does. DevOps takes IT departments to a completely different construct. The key is that there is a different strategic intent – that IT’s purpose is to align with the business users’ needs to create value that is deeply satisfying to the business. That’s the new promise.

Inconveniently, the path to get there is the same general path you have to go from thinking about running very fast to driving a fast car. The strategic intent and organizational change issues are far more challenging that the investment in new technologies. It’s very unclear whether an IT organization can get to an effective DevOps environment that really delivers the promised benefits without investing in the organizational changes. 

So, as CIO, don’t fall into the trap of buying another set of provisioning tools or automated testing tools and believing that you’re going to get to a Ferrari. If you do that, you’re just training IT to run faster instead of driving a fast car, and you’re unlikely to get to an environment engineered for speed. 

The nuts and bolts of DevOps 

So what are the fundamental operational changes that DevOps requires? 

1. Integrated service model. At the heart of an effective DevOps environment is an integrated model. Historically we have managed IT through a shared-service model and a series of functional disciplines such as the data center, security, application development, application maintenance and procurement. But managing IT by these functional layers creates a gauntlet business users must navigate. DevOps requires switching from the functional orientation of IT services and organizing and managing IT by service lines instead. The service lines are based on IT-enabled services required by the business, such as onboarding new customers, sales, accounting, etc.

2. Cross-functional teams. To make an DevOps environments work, you need to organize the IT group into end-to-end, cross-functional teams based on the business service IT delivers to the business. This is very different from IT teams in the traditional shared-service, functional-oriented structure where a team has responsibility for servers, network, application development, etc. for each business service line. The cross-functional teams in a DevOps environment are responsible for development, maintenance and operating the environment for that service line. These teams are accountable for achieving the end users’ objectives and business value. 

Remember, in this environment, speed is the new currency, and alignment with business value is the objective. To better align IT with the business users, the cross-functional teams take on the overall responsibility for driving the particular business service line they support. 

Today’s IT provides standard components (whether they be cloud, outsourcing, Platform as a Service, etc.). The teams can assemble the optimal components, align them with the users’ business needs and make them as responsive as possible. There is more value in assembling the components against the business value and responsiveness than there is in managing the traditional functional disciplines of managing the individual components. 

3. Management framework. You’ll also need to create a highly integrated, elastic framework for managing the DevOps environment. Built on automation, software-defined processes and a consumption-based model, this framework enables engineers, for instance to deliver on business users’ need for continuous releases. It can reduce the time from concept to implementation and production fully tested drops from 18 months to four to six weeks. And I’ve seen it reduce an insurance company’s member-enrollment process from two months to 30 minutes. 

Finally, managing a DevOps environment includes establishing metrics that align with the business users’ needs instead of managing for functional excellence and cost efficiencies. Your IT group will be able to deliver deeply satisfying services and have performance dashboards showing IT is like a honeydew melon instead of a watermelon.