Technology changes. Tools change. Acronyms change—sometimes daily. But the underlying problem doesn’t: go from idea to value efficiently, safely, and reliably.
DevOps gets described in a lot of different ways–a movement, a practice, a culture, a category, a tool, a job title. At its core, DevOps is about optimizing the speed of new features and the reliability of releases. Put more simply: it’s the optimization of work. To understand where we are going, you need to know how we got here, and what exactly we mean by work.
The Goal: A Process of On-going Improvement by Eliyahu M. Goldratt in 1984 is not only still relevant, but surprisingly entertaining. It revolves around a fictionalized Socratic dialog between Jonah, the professor, and Alex, the plant manager. Goldratt's story of Alex battling to save his plant that may be shut down, popularized Goldratt’s Theory of Constraints. The premise? Work flows (not workflows), constraints matter, and optimizing the system (not each individual component) is how you win. DevOps applies the same concepts developed in The Goal to software delivery.
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, published In 2013 by Gene Kim, George Spafford, and Kevin Behr updated The Goal for our current era of software development. A new story for a different time. Now the Socratic pair is Erik, the eccentric board member, and Bill, the newly promoted VP of IT Operations who must save the chronically failing Phoenix Project (and the company).
DevOps: The AHA! Moment
These books have been around for a while. When did I read them? Last summer 2025! Even without this historical context DevOps made a big impression on me. For many years into my career, development and operations lived in friction. Releases were infrequent and difficult. Things broke. Ops got blamed for dropping the ball in the endzone. Dev got blamed for handing off code that shouldn’t have been near production.
When I first heard the word DevOps–I’ll admit—it felt like a revelation. DevOps—literally mashing the words Development and Operations—showed that closer collaboration, better tools, and automation could speed feature delivery and increase operational stability. I wasn’t thinking about how work flows or system constraints, I was “automating everything,” but the side effects of these efforts? Handoffs, waiting, rework, and mistrust dropped. Flow improved. Releases became faster. Systems became more reliable. Work was optimized.
Security: Turns Out the Internet Can Be Dangerous
While the Internet made information systems accessible, vulnerabilities in the software running those systems made them exploitable. Often, security was ignored—or set up to fail—slapped on at the end, but still expected to prevent problems that had already been coded and deployed.
DevSecOps solved for this by pulling security into the system rather than treating it as a gate:
- Build securely from the start
- Automate controls
- Share responsibility
Security does not have to be a bottleneck. It can be part of the flow. Features can move fast—and safely.
Automation: Solving One Problem, Creating Another
DevOps leans heavily on automation:
“If you have to do it twice, automate it.”
This work has made a mountain of change to how software is released and operations are managed. Traditional automation is fast, but GenAI (including Machine Learning) is driving change, yet faster. With GenAI automation penetrates more of the stack:
- Policy generation
- Code development
- Infrastructure deployment
- Incident remediation
Breadth has increased dramatically—but control has fallen behind.
A Philosophical Detour (Because I Can’t Help Myself)
DevOps shortened the distance between thought and reality. A developer has an idea. They type code. That idea is suddenly running somewhere, affecting real people—sometimes in ways no one fully anticipated.
GenAI compresses that distance further. Ideas, implementations, and changes now propagate faster than Monday morning coffee disappears. At some point, you have to pause—preferably while sipping said coffee—and ask:
Who—or what—is actually in charge here?
Enter GovOps: Because Someone Has to Be in Charge
Governance has always existed, and yet, is generally unappreciated and typically done poorly or just well enough to meet regulatory requirements. Governance has not lived in the system. It’s been policies, audits, and slide decks no one reads. Continuous delivery and AI-generated everything break that model. We can no longer afford the risk of leaving Governance out of the loop. We need continuous Governance.
So we do what we did with DevOps and DevSecOps: pull governance into the flow. This is GovOps. Does that sound counterintuitive? Consider, AI is driving a rapid advancement in automation. These improvements will enable a change in how we think about Governance.
If:
- DevOps → Infrastructure as Code (continuous delivery)
- DevSecOps → Security Controls embedded into Code (continuous security)
Then:
- GovOps → Continuous (automated) compliance.
GovOps: Making Governance Relevant
GovOps isn’t about adding more controls—it’s about operationalizing Governance. It is settings standards, validating control implementation and providing observability with audit reports on request. Expectations are declarative:
- “We require encryption” → enforce it in code
- “Review access quarterly” → monitor it continuously
- “Produce audit evidence” → the system generates it automatically
What is now living in stale policy documents and inscrutable standards will be the AI prompts of our security and compliance agents. These prompts will define responsibilities, set limits, and enforce standards throughout the system with constant observability. Changes to standards (changes to the AI prompts governing agents) deployed to the system will have an immediate impact.
And here we go again.
The Pattern Should Look Familiar
We are repeating the same process:
- Identify the constraint
- Pull it into the system
- Automate
- Improve flow
DevOps did it for delivery. DevSecOps did it for security. GovOps does it for governance.
Reality Check
It may sound neat, but it’s going to be messy:
- People resist change
- Organizations protect silos
- Each new layer (DevOps, DevSecOps, GovOps) gets turned into a tool category before it’s understood as a way of working
Where This Lands
If The Goal taught us to optimize systems, and DevOps applied that to software delivery, what we’re doing now is extending that thinking across the lifecycle:
- Build it
- Secure it
- Prove it
Continuously.
We’re not just doing more work. We’re not just doing it faster. We’re understanding how work flows, where it breaks, and how to fix it—systematically. Everything else—tools, AI, acronyms—is just how we’re expressing that idea right now.
Give it a few years. We’ll rename it again.
No comments:
Post a Comment