I Asked More Than 50 DevOpsDays Attendees One Question
By Marc Hornbeek, DevOps_the_Gray | Senior Advisor for DEVOPS INSTITUTE®
At DevOpsDays Denver on September 22 and 23, I spoke with more than 50 attendees and vendors. I began each conversation in much the same way: “You are here at DevOpsDays, so I think it is fair to assume you know something about DevOps.” Everyone agreed.
Then I asked a serious question: “What is DevOps?”
The answers varied widely. Some people described a culture. Others named automation, collaboration, CI/CD, or a set of tools. Several paused before answering. These were engaged people at a DevOps community event, yet the question still produced uncertainty.
Those conversations were informal, not a survey of the community. They did, however, reinforce something I have seen over many years: we have developed valuable DevOps practices without always developing a shared explanation of the system those practices are meant to create.
I followed with one more question: “Would you like a solid answer?” Every person I asked said yes.
A shared answer matters
During the event, I presented a 30-minute talk, “From Practice to Profession: DevOps in the AI-Native Era.” My argument was that DevOps began as practitioners working together to repair a broken system of software delivery. Development and operations had different incentives. Security and feedback often arrived late. The community found better ways to collaborate, automate, deliver, operate, and learn.
That practical origin remains a strength. As DevOps has spread, though, organizations have assembled its practices in different ways. A team may have excellent pipelines while its release decisions, production feedback, security controls, and accountabilities remain disconnected. People can use the same word, DevOps, while describing quite different capabilities.
A shared definition gives us a starting point. DEVOPS INSTITUTE defines DevOps as “a socio-technical system that integrates people, processes, and technology practices to support the efficient, safe, and reliable delivery of software-enabled products and services.”
That definition makes room for the human and technical work. It also gives leaders and practitioners a more useful question to ask: how well does our complete system deliver value, manage risk, and learn from outcomes?
What The DevOps Standard brings together
I introduced attendees to the new DEVOPS INSTITUTE book - The DevOps Standard, for which I am the lead contributor. The book has been reviewed by hundreds of people from the DevOps and ITIL communities. It sets out a vendor-neutral DEVOPS INSTITUTE Operating Model drawn from practices used in organizational transformations.
The model connects the Nine Pillars of DevOps practices with a four-layer DevOps architecture Blueprint. Continuous governance, feedback, and improvement operate across the model. This gives teams a way to relate leadership and culture to design, integration, testing, infrastructure, monitoring, security, and delivery. It also connects those practices to the environments, pipelines, release orchestration, and value stream decisions where work actually happens.
The model is intended to provide common language and expectations while leaving organizations room to adapt their implementation. A useful standard should help people understand the capabilities they need, the evidence those capabilities produce, and where improvement is most valuable.
Why the AI-native era raises the stakes
AI increases the amount and speed of change that teams can create. It does not automatically increase their ability to validate that change, deploy it safely, or understand its effects in production.
For that reason, the book incorporates AI practices throughout the Nine Pillars, the four Blueprint layers, and the governance and feedback loops. An AI-assisted change still needs provenance, behavioral and security validation, an appropriate release decision, observability, recovery, and a person accountable for consequential decisions. AI can also help teams analyze evidence and improve the delivery system itself.
In my talk, I put the challenge this way: AI increases our capacity to create change. DevOps must increase our capacity to trust change. That requires connected practices across the entire value stream, rather than greater speed at one step alone.
The reaction in Denver
The response in my conversations was consistently favorable. People were grateful to receive a signed printed overview of The DevOps Standard book and an opportunity to register for notification when the complete digital book becomes available to download. Several conversations continued beyond the opening question into what a common definition and operating model could mean for their teams.
I came away encouraged by their curiosity. The uncertainty around “What is DevOps?” did not signal a lack of commitment. It showed that experienced people still want language that connects their work to a coherent whole.
DevOpsDays has always been a place where practitioners share what they are learning. The DevOps Standard can give that conversation a stronger common foundation. It offers a clear answer to the question I asked in Denver, and a practical way to keep improving the system behind that answer.
