How to introduce DevOps into a moribund corporate culture

How to introduce DevOps into a moribund corporate culture

Summary: 'DevOps is an invisible thread that runs through the entire process of IT, from the design of the software right out to the software running in production.'


"We need to do DevOps."

Data Center at CERN 2 -photo courtesy of CERN Press Office
Photo: CERN Press Office

And there you have it — the scariest words that could ever come out of the mouth of an executive.

There is a lot of interest these days in DevOps, especially as organizations of all types and sizes evolve into software producers themselves. The problem is DevOps — like its siblings, agile lean and quality — is not something that can be pushed onto the workforce from way on high.  DevOps is not a "program," an "initiative," or even a "best practice." DevOps is a way of doing business, a way of thinking, that stretches from the moment an application is conceived in someone's mind to its release into production, and way beyond.

DevOps is the melding of developers' tasks with those of operations people. This is important in today's go-to-market-fast economy, because software releases need to be fast and furious. Release 3 needs to be ready to spring just as Release 2 is sent out to customers. The goal of DevOps is to align the creative and innovative spirit of developers with the constraints and requirements of ongoing operations.

Many organizations simply do not have the corporate cultures to support such an approach. They may be siloed, they may have fiefdoms, they may have uninspired, hidebound managers who prefer to throw products over the wall with a minimum of testing, and only go back to fix problems when enough customers are screaming loud enough.

That's the wall that IT leaders seeking DevOps run up against. In a recent post, ActiveState's Phil Whelan puts it this way:

From enterprise IT customers and conversations I have had, it seems that DevOps may be a little intimidating. Nobody wants to be accused of not doing DevOps right, especially if it has been mandated from high up the chain that 'we need to do DevOps.'

Companies that are successful with DevOps do more than just push tools and continuously deliver pipelines, Whelan says. "They have the right culture. The culture for learning, for adapting and for seeing the bigger picture. They see how the drawing board relates to final product."

That's because, as Whelan eloquently explains: "DevOps is an invisible thread that runs through the entire process of IT, from the design of the software right out to the software running in production." Accordingly, it needs to be baked in right from the beginning.

So, there's the challenge, what's the solution? It's a long-term process to embed DevOps, quality and agile into an organization. Let's face it, IT leaders are not in a position to overturn a calcified, counter-productive corporate culture overnight. Here are some ways to start the process:

Engage the business. You may hear this a lot, but this is especially important when moving to DevOps. Business leaders need to be made aware of the potential of DevOps to streamline and improve the business. Also, business executives are increasingly turning to their IT leaders for guidance as we lurch into an increasingly digitized economy. They want IT to take a proactive stance on laying out a compelling business technology vision for their organizations. IT executives are in a position to promote DevOps as part of this new, digital direction.

Study and learn from organizations that have successful DevOps underway. This doesn't have to include IT DevOps, either. There are organizations that have successfully aligned their design, engineering and production operations in a DevOps way.

Join professional organizations that provide education and knowledge sharing in DevOps.  While there aren't professional organizations or certifications specifically for DevOps, many existing bodies may hold sessions or provide instructions in the DevOps way. User groups may also be a resource as well. The values found in lean, continuous improvement and agile also have DevOps components. There is also an ongoing series of "DevOps Days" conferences held throughout the world.

Failure is an option. The most successful organizations are constantly innovating and improving, and that comes from allowing people to fail, and learning from those failures. Whelan notes that successful DevOps companies "often have new hires push to production on their first day. The testing hurdles in place almost always ensure that no real damage could be done by any naive new hire. Failure here is placed on the infrastructure and not on the new hire."

Topics: IT Priorities, Software Development, Social Enterprise, Innovation

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Failure is an option....

    I don't look at it strictly from the perspective of failure being an option, the fact is that it matters not whether failure is an option or not. Failure may or may not come, and sometimes failure does came when its considered to be not an option of any kind. One thing is for sure a fact, if failure comes simply because you were sloppy or didn't try hard enough, its more than an option, its a distinct possibility.

    The fact is that failure exists, and it exists even in places where we want it the least. You don't have to make it an option, just accept the reality that it can happen and be prepared to deal with it correctly. I tend to think that while most people think that saying failure is an option is just asking for trouble, Ive actually seen more cases go the other way, where it was said over and over that failure wasn't an option.

    Making failure an unspeakable taboo that isn't even properly considered is the true recipe for disaster. Avoid failure as best you reasonably can, but have plans in place to deal with it astutely as you can when it inevitably happens sooner or later.
  • Also Continuous Delivery

    An article about DevOps should also mention Continuous Delivery. Folks should read cover-to-cover the excellent definitive book "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation" by Jez Humble & David Farley.

    Regarding selling failure as an option to biz folks, consider the J-curve: As with most change initiatives, things typically get worse before they get better.