UpGuard Blog

Enterprise DevOps & the Cloud

Written by UpGuard | Mar 7, 2014 8:29:00 AM

There has been plenty of discussion as of late regarding whether the DevOps movement has left the “enterprise” behind, plus where automation and the cloud fits in DevOps. There is more and more evidence that automation creates less collaboration and shows signs of a turf war between the chasm of tools that are needed to ‘do DevOps’. In the spirit of trying to address and debunk some of these myths, we asked Kevin Behr, the co-author of The Phoenix Project: A Novel and the VisibleOps Handbook to join us in a discussion about some of the trends plaguing enterprise IT as they struggling to align legacy IT infrastructure to business goals while becoming more agile.

At what level is your DevOps initiative being driven?

We asked attendees to help us understand where in the organization is the DevOps initiative being instigated from. What we found was that 36% of all attendees stated that it was a ‘grass roots’ movement which makes sense considering DevOps is still very much in the early adopter phase. Most surprising, however, was that nearly 20% (18% to be precise) said that DevOps was being driven from the executive level. This is a very encouraging trend because tone at the top can drive specific behaviors and the transformational possibilities of ‘doing DevOps’ across an organization is exciting.

Kevin Behr (@kevinbehr) had this to say:

I like to see this collaboration starting at the grass roots level but often it becomes important to garner early executive support. Since DevOps staff often report to different organizations, it is important to coordinate between their often competing priorities. Otherwise folks can often get frustrated by the fits and starts this can create.

Kevin also noted that he is seeing significant executive interest around DevOps. His current work at Praxis Flow has him talking with many CIOs, CTOs and yes even CEOs about building and cultivating new DevOps strategies for their organizations. A very positive sign indeed.

How important are cultural considerations for your DevOps initiative?

What we’ve seen in enterprises who attempt to make DevOps work for them is they frequently run into cultural and incentive structures that may slow things down. It is no surprise, that 88% of all attendees stated cultural considerations as important to their DevOps initiative. What is curious, however, is the 12% who said it wasn’t important. One of the attendees made the comment that “It seems many leaders look to lead a very objective change rather than a collaborative change.” I suppose that if DevOps is being driven by executive leadership, they can insist on certain goals and bypass cultural considerations. But this is a short term fix that I suspect will exasperate that lack of collaboration and communication if buy-in isn’t achieved at every level of the business.

Kevin Behr’s reaction was:

Collaboration outside of problem solving may be a new universe for many enterprise IT organizations. As a result, IT leaders lack effective approaches to fostering company-wide mission, operational and tactical intents. The direct result of this is a lack of clarity among people in the organization when it comes to understanding how the work they are doing is moving the company forward. When an enterprise is not practicing continuous improvement there is often a sort of cultural malaise or learned helplessness in play. This comes from the long planning and project cycles that sometime span years. This makes it hard to connect immediate actions with outcomes and often causes us to feel like we can’t make a difference in our environment. Continuous improvement focuses on experiments against obstacles that have short J-curves (In other words the short duration experiments with near immediate results). Daily practice not only improves operational reliability and agility but also overcomes learned helplessness.

What is the failure rate of automation projects in your business?

We asked webcast attendees to estimate what percentage of their automation projects fail. Nearly half of these projects fail, which is not surprising and creates tremendous churn in the already maxed out IT function. The more important question is not whether they fail or not, but why they fail. I believe it is because organizations are too quick to jump onto the automation bandwagon and don’t take the critical steps to get the visibility and accountability into their business. A few great soundbites were discussed during this discussion that I wanted to share:

"People often believe automation solves the drift problem. It doesn’t because automations have to be explicit about what should and shouldn't be configured."

"Our projects don't fail. We often don't have a clear goal we can use to define success. Instead we define success on the fly."

Kevin Behr added:

I can’t overemphasize the need to better understand the lessons painfully learned by the software engineering community over the last many years. Specifically I am referring to the need to bring sound clean coding principles (shout out to uncle Bob), Test Driven Development, pairing and source control to our automation efforts. I often suggest to enterprise IT shops that this is one way to benefit from DevOps even if you don’t have a dev team - “Up your ops” so to speak.

You can follow Kevin Behr’s insightful and often irreverent tweet stream on twitter by following @kevinbehr.

Additional Resources