Old words, when fused together, have an uncanny way of defining new phenomena.
That’s what happened when Belgian consultant, project manager and agile practitioner Patrick Debois coined the term ‘DevOps’ back in 2009. A decade later, with the proliferation of enterprise cloud computing, DevOps has become a critical tool as companies work their way through digital transformation, digitizing business processes and accelerating product lifecycles.
But broadening the meaning of the term DevOps can lead to even greater gains, according to Mark Lavi, Principal DevOps Advocate for Nutanix.
DevOps typically refers to removing friction between developers (‘Dev’) who build software and operations people (‘Ops’) who have to run it.
Lavi’s definition goes much further.
"It’s about removing the friction between developers and the customer," he said.
Historically operating in silos, developers and IT operations professionals were often in discord, suffering from communication challenges, misaligned metrics and more. Lavi explained that software development was often many steps removed from direct customer interaction, with other departments like sales and marketing or business operations forming a many-layered buffer.
“Successful software development needs to understand how each of those layers interacts with each other — it's all part of the sequence of delivering customer value,” said Lavi.]
[Related article: DevOps is Reshaping IT and Fueling Dynamic Learning Organizations]
From this point of view, bringing software and operations teams together introduces agility, shared ownership and automation into the process of building and running software, but that’s just the beginning. Applied more broadly, Lavi said DevOps can speed a company’s ability to create essential new features of the business itself.
How can today’s business get there? Lavi offered some suggestions.
Don't be Just a Tool
Many of the pioneers in DevOps have been web-scale, software-based companies, Amazon and Netflix being a couple of notable examples. As these teams constructed vast distributed systems, they found many functions that old-school enterprise development tools simply weren't built to provide.
As a result, the story of DevOps has been partly a story of new tools: automation, orchestration, containers, packaging, monitoring and more.
[Related post: Why is DevOps So Hard?]
Web-scale development has a bit of Wild West flavor as those pioneers created (and often open-sourced) their own toolsets to operate at this new scale. But in DevOps, Lavi stresses that the real value isn't in the pipeline of tools, or in the conjoining of development and operations, but in the business functions those technologies and processes ultimately enable.
Documenting all the tools and technologies allows for simplification, integration and the creation of automated workflows in the future.
"We work with really advanced practitioners of DevOps — they have had to string together a whole bunch of wonderful different tools that were never designed to inter-operate together," Lavi said.
Map Two-Way Value Chains
Going beyond tools toward a more advanced DevOps mindset also means mapping the company's value chain.
"If you don't know the process of how you produce your goods — all the way back from the original creators and authors [forward] — then you can't actually understand whether or not you're doing it in an efficient manner, or if there are any process improvements that can be done," he said.
[Related post: Ten Steps to DevOps at Scale]
Good mapping, on the other hand, enables good measurement.
“That which is measured can be improved,” Lavi said.
True DevOps is a two-way street. Organizations sometimes focus their efforts on the speed and frequency of deployment. That's valuable, but it's equally important to improve the speed of information coming back from the customer. The better this feedback loop, the more software will deliver what customers really want, which unlocks revenue and profit.
"If we don't have that feedback, then how do we know the developers or engineers, or product management, or business development folks, or any of our leadership is actually encompassing the consumer experience and their feedback and their needs?"
Mark works with an agile engineering team that thrives on customer feedback. He said they re-prioritize work in order to help customers automate more of their business practices. One large customer required Nutanix Calm, software that orchestrates how IT teams manage business applications, to do something more. They wanted to orchestrate workloads on many remote branch offices for centralized management, but the existing deployment model of Calm required it to be installed in each remote site.
“Because the Calm engineering team had a DevOps value philosophy, it could prototype, test, and release the centralized Calm control plane for the customer in a calendar quarter,” Lavi said. “By centralizing the automation operations with Calm’s new model, it saved the customer installation time and streamlined operations through centralization and automation.”
He said those DevOps efforts helped the customer keep all governance under a single interface, allowing them to more easily manage all of their remote site applications and operations.
Beyond tools and feedback loops, Lavi said that the DevOps mindset is really about continual improvement.
"DevOps isn't a state; it's a constantly evolving process," Lavi said. "Removing friction means finding all of those barriers [and] understanding how to deliver your business efficiently."
Derek Slater is a contributing writer. His work has appeared in CIO, CSO, and other technology and business publications. Find him on Twitter @derekcslater.
Editor’s note: For a refresher on DevOps and how to become more agile, see this technical session by Mark Lavi and Jared Rypkahauer.
© 2020 Nutanix, Inc. All rights reserved. For additional legal information, please go here.