There are many things that enterprises can and should outsource. IT, however, isn’t one of them.
In fact, as the Puppet Labs 2015 State of DevOps Report reveals, treating IT like a core competency is one of the best ways to ensure better software, both in terms of deployment velocity and reduction in failure. Interestingly, taking a DevOps approach, wherein organizations center on continuous deployment, may well be one of the absolute best ways to reflect how seriously an enterprise takes its job.
In other words, the less it makes a big deal of any particular release, the better its overall quality of releases becomes. DevOps, then, may primarily be associated with development velocity, but where it really shines is in the quality of code it delivers.
More and faster
Among the key findings of the annual survey, now in its fourth year, a few stand out:
- High-performing IT organizations experience 60X fewer failures and recover from failure 168X faster than their lower-performing peers
- Such organizations deploy 30X more frequently with 200X shorter lead times
- More than just new-school apps: Continuous delivery can be applied to any system, provided it is architected correctly. That said, high performers are more likely to use a microservices architecture and less likely to outsource software development or run their software on mainframes
- The more painful code deployments are, the lower the IT performance, organizational performance, and organizational culture
Even among these high-level findings, one stands out: DevOps practices keep delivering better software.
In fact, speed of deployment didn’t pick up its already torrid pace between 2014 and 2015, according to the report, but software quality did–and by a lot.
In 2015, the survey uncovered a 60X decrease in software failures with a 168X faster recovery time (the time required to restore service when a service incident occurs, like an unplanned outage). In 2014, those numbers were 3X (decrease in software failures) and 48X (improved recovery time), respectively.
As one IT executive at a large financial services company told me, “Product stability comes from releasing code more frequently, not less. You want each release to be a non-event, not a major launch.”
Here’s how those numbers look in the context of IT performance clusters, representing the continuum of super-high performance teams down to low-performance teams. (Each bar represents 100% of the cluster members–the segment at the 50% mark represents the median of each group.)
This suggests that DevOps is driving better initial code quality but also improved testing, not to mention a mindset shift toward continuous improvement. It also indicates that DevOps is very, very real–at least where performance and code stability matter.
Related to this, the report also finds that those enterprises that take development seriously, and hence take it in-house, perform much better. For those that believe that “IT doesn’t matter,” it shows in the quality of software they produce. The more an enterprise outsources to third-parties, the more its software suffers.
This is true no matter the kind of software, whether it be packaged software acquired from a company like SAP or if it’s custom-developed in-house. What matters is the architecture of the software–high-performing teams focus on microservices-oriented architectures–and not how it’s sold.
Such agile architectures lead to improved developer productivity as teams scale:
We’ve been hearing this for years, and it’s now showing up clearly in IT performance. Indeed, as Forrester analyst Diego Lo Giudice has written, “Within the modern applications era, regardless of whether new software applications are being developed and delivered for mobile, tablets, or the web, the truly successful app-dev leaders will be those who focus on delivering constant value and incremental improvement to their business.”
Call it Agile, call it DevOps, call it whatever you want… but it’s increasingly an imperative way to run a development team.
Yes, you can
This leads us to the final conclusion of the report: a lot of this success depends on the IT manager and not on some magical assembly of “DevOps developers.”
IT leaders, in other words, can shape teams to embrace DevOps practices. Here are some ways that can prove to be effective, according to the report:
- Establish a dedicated training budget and make sure people know about it
- Give staff the latitude to choose training that interests them
- Encourage staff to attend technical conferences at least once a year and summarize what they learned for the entire team
- Set up internal hack days, where cross-functional teams can get together to work on a project
- Give staff dedicated time, such as Google’s 20% time or several days after a release, to experiment with new tools and technologies
These are simple things and not particularly expensive. However, each augments the feeling among a development team that they have the autonomy to succeed. Ultimately, that’s what DevOps is really about: trusting developers to move fast, break a few things, and (in the process) create exceptional software.