7 takeaways from DevOps Enterprise Summit 2016
More than 1,300 technology leaders, industry pundits, and IT practitioners came together in the San Francisco last week for the third annual DevOps Enterprise Summit. The three-day event, which kicked off on November 7th, illustrated the increased enterprise interest in DevOps, as the conference has doubled in size from its first engagement just two short years ago.
This year's attendees, representing some of the nation's largest companies, brought a can-DOES attitude as they discussed the technology, organizational changes, leadership patterns, and culture needed to move everyone's DevOps journey forward.
The keynotes were live-streamed, some of the presentation videos are now available online, and all of them will be live within a few weeks. In the meantime, here are the biggest takeaways from the conference presentations, the buzz on the exhibitor arena, and the all-important "hallway track," including what you should be on the lookout for in 2017.
1. DevOps gets the lead role
At previous events, presenters and attendees would mention DevOps at the beginning of the conversation, but then quickly move the conversation to concrete practices, such as continuous delivery.
This initial focus on implementation, centered around a tooling and technology perspective, shouldn't be surprising. In fact, I observed it at previous DevOps Days conferences too. And since many of the values, both cultural and technical, aren't entirely intuitive, it makes sense that enterprise leaders at earlier events would focus on concrete practices and tools, not only to get a sense of this weird, new DevOps concept, but to use that to reason about how it would fit, at least from a technology standpoint, into their existing organizations.
But this year, the conversations were more balanced. Presenters covered the technology with an ever-growing excitement about continuous delivery, but attendees also acknowledged that technology alone is not enough. They wanted to know how a DevOps culture fits into their organizations, and what that looks like from a leadership perspective.
2. DevOps practices no longer up for debate
Accepted practices now include continuous integration of code, continuous delivery pipelines, including tests and deployments, source control for all production artifacts, and configuration management for infrastructure as code. Presenters also discussed generally accepted practices around monitoring, incident response and management, and communications platforms that foster transparency and collaboration.
What's different this year: These practices aren't seen as new and innovative anymore—they're now DevOps table-stakes.
3. All avenues of experimentation are on the table
CSG International's Scott Prugh recounted a story that Pivotal's Elizabeth Hendrickson told: When she realized that her quality assurance team was creating a bottleneck, she dissolved the team and reimagined it. Prugh realized that he had to do he same with his dedicated operations team.
These stories of fearlessly running experiments, not only with new technology and development practices, but with the structure of the organization (and, fundamentally, the stream of delivering customer value) formed the backbone of many presentations and hallway discussions this year.
Many of the now generally accepted DevOps practices have unleashed tremendous productivity and value gains, but the real innovation on the enterprise front lies in porting the principles that make software development faster and infrastructure operations more sustainable to other parts of the business.
These potentially require a hard reexamination of practices that have been considered to be just the way companies have done business for decades. But many organizations are now saying "We see the benefits to our software and IT organizations by making these difficult, and sometimes counterintuitive, changes. So what happens if we apply them elsewhere in the value stream too?"
4. Rediscover failure, and leverage it to improve
Presenters at company after company talked about how embracing failure, learning to dampen it, and learning to recover from it quickly, allowed them to run more experiments.
Failure is inevitable, but the tendency in the enterprise is to be averse to risk and to try to build barriers and buffers into the system to contain failure. This is not just a waste of time and energy, but in a complex system it doesn't work.
Conference presenters offered case studies of organizations that focused on failure detection, incident response, and engineering ways to dampen failures, including using smaller batch sizes. Removing failure or protecting against it isn't the goal: Building a team that can detect it sooner and react to it faster is.
Cultivating those skills allowed these organizations to run experiments to explore emergent spaces within their systems, which could (and often did) pay huge dividends. It took re-framing risk from something the organization should avoid, to something it can deal with. And since it will happen whether you embrace it or not, you might as well exploit it for business benefit.
5. DevOps Dojo-mania is on the rise
Target was one of the first large enterprises to build, experiment, and openly share its experiences with a "DevOps dojo," a place to create what it called "immersive experiences" for its teams. Heather Mickman, Senior Director, Platform Engineering, kicked off this year's summit with an in-depth update of Target's five-year DevOps journey, including the important role the dojo played in carving out a learning space. It brought home many new principles and gave teams a way adapt the ideas to their local context and work.
Since its unveiling at the first DOES, the dojo idea has been popular one with technology leaders. This year, there were open conversations about organizations such as Capital One and Verizon, that are working to build their own DevOps dojos. For those who haven't caught dojo mania yet, there was also much discussion about running DevOps Days-like events internally, as a way to cultivate new team skills and culture.
The last two takeaways may sound at odds with each other, but they're not.
6. Technological hygiene matters
Whether it was a conscious effort to pay down years of technical or architectural debt or investment in areas previously thought of as cost centers that dragged down the business, the presentations demonstrated that many organizations are starting to realize benefits. They have done so because they reframed how they think of operations, quality assurance, and release engineering, and focused on leveraging those areas to create competitive advantages.
Some organizations continue to think they can just stuff those disciplines in different corners of the building, isolating them from the value stream, and dump inhumane levels of work on the teams in the hope that a 30-year-old IT strategy will somehow turn out differently this time around.
Speakers who described their wins at DOES realized that these are the areas where investment can deliver huge returns. Draining those swamps not only looks and smells better, but it makes for better products, happier customers and employees, and higher revenues.
7. Successful organizations are pushing DevOps at the edges
We're starting to see more work from QA, release engineering, security, product management, and marketing teams to bring transparency and speed to their contributions. As early innovators finally finish getting their QA processes fully into the pipeline, look for security and compliance efforts to be the next customer to be "shifted left," and added to continuous delivery pipelines.
As DevOps teams integrate more inputs into continuous delivery pipelines, and produce more types of outputs, release engineering will continue to be an important discipline. It can help steer development and operations away from rebuilding software delivery practices from first principles—and doing it badly.
Seven years ago, after Patrick Debois coined the word "DevOps," and held the first DevOps Days in Ghent, Belgium, the IT industry looked at its principles and practices and said, "Yeah, but will it work in the enterprise?"
The presenters at this year's DevOps Enterprise Summit answered with a resounding "yes," and they are succeeding in pretty much every market. The question you should be asking at this point isn't "Will it work?" Someone has already made it work in an industry similar to yours. Rather, you should be asking how you make DevOps work for your company.