A recent column in the Wall Street Journal’s CIO Journal argued that while DevOps is gaining inroads in small and mid-sized businesses, it’s facing a much less rosy future in large enterprises. The story cited organizational challenges, many of which we covered, such as large siloes, regulatory compliance, and resistance to change as great impediments enterprises embracing DevOps.
The column also spoke of the buzzword “DevOps,” how it’s a software development methodology, and spoke about “holistic” DevOps tools. Interestingly, that’s not how we view DevOps. Not at all. DevOps is more a movement about organizational collaboration and driving improvement.
Still, the author wasn’t completely wrong. There are significant hurdles to overcome when moving to a DevOps culture, and those that the author cited are the primary obstacles for both enterprise and SMBs – mainly cultural changes the processes to support it – and they are being overcome. Just, typically, at a slower pace among larger organizations.
“I think the SMB vs. enterprise is the wrong axis to use,” says Donnie Berkholz, an analyst at Redmonk. “Like any change, it’s going to be a lot easier for greenfield teams and projects, so new startups will have an easier time starting from scratch with a DevOps mindset. And there’s also no guarantee that SMBs are new — in fact many of them have been around for a long time and have similar inertia, relative to their sizes, as large enterprises do,” says Berkholz.
And, as Berkholz explains, one of the big challenges for companies considering DevOps is whether the benefits of the move exceed the switching costs. “Fortunately we’ve got growing data, such as the Puppet Labs survey, showing that DevOps greatly accelerates time to delivery, although quantifying “first to market” in terms of dollars can be challenging,” he says.
Bigger ships turn more slowly, but they still turn
Jeff Sussna, founder of the IT service innovation consultancy Ingineering.IT, concurs and says change always happens more slowly in enterprises than SMB’s, simply because they’re larger and more complex. And just because enterprises are bigger ships that turn more slowly, they’re still turning, though it may be more difficult to perceive immediately. “I think people are confused and [they] think DevOps requires either smashing org charts and mushing everyone into shared teams, or else rolling out some big expensive overarching tool across the entire organization,” he says.
The reality is DevOps is manifesting when teams collaborate and partner much more closely – no matter their size within the enterprise or if such change is occurring at a sweeping pace, at first. It’s when operations teams seek developers’ input, and when developers reach out proactively to operations. When teams are working to improve continuous QA, they are performing DevOps. “I think the fundamental problem with DevOps at the moment is we think it’s a destination, when really it’s a path,” says Sussna.
And Berkholz adds that just because it’s a slower and more cautious in the enterprise doesn’t mean it’s not transformational. “Like any other organizational transformation, the path of least resistance tends to be one of incremental change rather than a wholesale shift. Switching one tool at a time to a tool chain that encourages DevOps-style behavior and discourages silos can help catalyze that transformation. Continuous integration and continuous delivery/deployment pipelines are great examples of this,” he says.
And those are exactly the kinds of transformations underway at the enterprises we speak with every day.
Big rivers often begin as small streams
As for the business benefits, many organizations view it as a matter of survival. “I think over the years folks have been amazed how long (not to mention how expensive) it has taken just to bring basic levels of good, let alone best practice in to IT. There have been more than enough failed Bataan Death March style best “implementations” to make any executive wary of the next new thing. In my opinion this is the real opportunity cost of old scientifically disproven mechanical metaphors for human organizations,” says Kevin Behr, chief science officer, at enterprise opsflow consultancy Praxis Flow, and co-author of The Phoenix Project and Visable Ops.
“I believe if your org can not improve at the individual level it is incapable of getting much from DevOps, or anything else for that matter,” Behr says. That is why I have focused on first evolving some sort of continuous improvement form or kata using the scientific method as its base. This capability starts day one helping to create resilience, which is the ability to handle change. With that you can “improve into DevOps” iteratively and within the guardrails of your organizations overall direction and strategy. We call this approach Opsflow, as you’re flowing Ops in to Dev, then to test, then to infosec, and then on to the rest of the business,” says Behr.
And the data increasingly show that the move to DevOps is in fact well underway. And happening it already is, at least according to numerous and recent studies. One is the Vanson Bourne study (funded by CA Technologies) of 1,300 senior IT decision-makers, at enterprises with $100 million in revenue, and within financial services, healthcare, manufacturing, public sector and telecommunications industries from 21 countries around the world. In that study, a decisive 99% see a greater need to move foreword with DevOps.
Additionally, the 2013 State of DevOps Report by Puppet Labs found that the majority of those that have implemented DevOps have found significant benefits including improved quality of software deployments, more frequent software releases, improved visibility into IT processes, cultural change, and IT being more responsive to business needs.
