Breadcrumb

IT leaders from Intuit, MetLife and Red Hat outline key points CIOs can follow as they look to support their digital transformations with DevOps.

Clint Boulton Dec 04th 2017

Successful digital transformation requires internal disruption, and CIOs intent on embracing a digital future must often alter their IT operating models to get there. Nowhere is this more evident than when it comes to developing software and services.

To build software faster, CIOs are kicking old waterfall habits in favor of agile methodologies in which they partner with business stakeholders to build applications rapidly in iterative sprints. And some believe they can accelerate software development even further by implementing an emerging philosophy known as DevOps.

And it is catching on. Fifty percent of 237 organizations surveyed said they are implementing DevOps, according to Forrester Research. "The DevOps momentum is occurring within all industry sectors," analyst Robert Stroud wrote in the research report. "As we are near the end of 2017, the number of inquiries are increasingly focused on how organizations will be successful given the pressure of accelerated delivery of applications and services — without additional headcount."

The DevOps shift

Blending cybersecurity and DevOps for a software maker whose 4,500 developers have built applications using waterfall for years is no easy task but it's the No. 1 priority for Shannon Lietz, director of DevSecOps for Intuit. The shift has required getting developers to be accountable for the value they create for customers. "It’s such a cultural shift," Lietz says. "The closer you can get to the customer, the more enriching the experience becomes for developers, the other people within the company and for your customers."

"There’s a scientific dedication that makes DevOps practical and successful and I've found that trying to introduce science into a company is very hard," Lietz says. "It’s a different way of operating."

For MetLife, introducing DevOps has gone hand in hand with innovation. In the past few years, MetLife has embarked on DevOps in parallel with its adoption of cloud services from Microsoft and IBM and container technology from Docker, according to Alex Seidita, chief technology architect for the 150-year-old insurance company.

MetLife's ModSquad, an innovation team comprised of engineers, cyber professionals and developers, has embraced cloud, agile and DevOps to "learn fast, fail fast and deliver fast," Seidita says. The ModSquad operates under the mantra, “You don’t wait until you know everything before you start anything."

Religious zeal around containers, microservices and other tools that enable DevOps lured CIO Mike Kelly to Red Hat in August 2016. Kelly, who joined open source software developer after a CIO stint at McKesson, was fed up with how the CIO role had evolved into that of a software buyer.

Enterprise CIOs bought packaged software to ensure process efficiency and managed the changes associated with those applications, Kelly says. But CIOs’ hands were tied in terms of customizing software for things that were too unique or hard to change.

“I always felt like I’d get through with these big projects and find someone that wasn’t happy,” says Kelly, who introduced DevOps at McKesson. “With [DevOps, agile and culture change] we now have tools in the proverbial toolbox to help address these longstanding issues.”

12 best practices for implementing DevOps

Based on their hands-on experience transitioning to DevOps, Lietz, Seidita, and Kelly offer the following recommendations for ensuring DevOps success.

Align DevOps strategy with the business. IT and business strategy alignment is a common refrain among CIOs but it's just as important for DevOps, which will fall down if IT and the business aren't on the same page. "If you don’t, you’re just off creating surprises" — potentially unwelcome ones, Lietz says.

Bolt into existing programs. Don't approach DevOps as a science project; rather, bolt it into existing programs so that it is beholden to the typical delivery deadlines. "Pick one, two or three projects that you can take a little risk on but that don’t have unlimited time," Seidita says. "You want people to get into sprints and get something into production ultimately."

Go broad. For DevOps to work, culture is essential. Be as inclusive as possible so you can "change hearts and minds," Seidita says, adding that it's important not to exclude people because it could create problems. "You have to be broad and inclusive so people feel like they’re participating and contributing to the journey."

Focus on what makes you unique. When choosing were to implement devops, choose projects that add value that will differentiate the business. “Don’t try to do DevOps for your core ERP system,” Kelly says.

Choose proven platforms. Tools are another essential component of DevOps. From configuration management to continuous delivery platforms, pick tools that have known networks. Betting on an unknown courts risk, Kelly says.

Look for homegrown skillsets. There isn't enough DevOps talent on the market so you should appeal to experienced talent across the organization. Loop them in to contribute to projects. "They can give you the right bar to look at something," Lietz says. She says Intuit observes "boundaryless leadership," in which managers can pull willing team members from across the company. More often than not, they agree to help because they know they are working on something that is part of the business strategy.

Avoid “classes of citizenship” problem. Many organizations feature risk-taking engineers working on emerging technologies and engineers maintaining legacy technologies, such as ERP systems. This cool-kid factor can cultivate resentment. “You have to be incredibly hands on and authentic about having the conversation with your associates and explain that this is not a binary thing,” Kelly says. The people working on legacy environments are just as important as those doing DevOps, he says.

Time is always a factor. Don't underestimate the importance of time, especially for public companies that report quarterly financials. Lietz says companies must commit to value creation for a specific quarter and have every stakeholder focused on learning part of the development pipeline. The learning should occur for both IT and business stakeholders to ensure alignment between the mission and outcome.

Don't look too far ahead. Given the high velocity of DevOps, some organizations may be tempted to solve problems that are far out in the future. That can lead them to miss the opportunity to create value iteratively, or even a product recall, wasting everyone's time.

Embrace storywriting. Think of this as a blueprint for creating value for customers. It starts with a verb, such as "enabling" a specific feature of a product to make it more safe. If you don't create a story arc that plots how you plan to meet your customers’ needs, you likely won't build the best products, Lietz says.

Avoid bureaucracy. Bureaucracy can be a DevOps killer, especially in IT organizations that are ripe with rules centered around taking orders. "Don’t believe there is one way to make a decision," Lietz says. "Experimentation is key and the minute you add bureaucracy to DevOps you will lose."

Iterative learning. Make sure that folks are ready to embark on this journey and make some mistakes. "Don’t tie them to a rigorous financial model where you need to tell me today how much you’re going to spend in the next year," Seidita says. "Go in small chunks.