DevOps has unquestionably turned a corner. While confusion remains, there is now broad consensus that DevOps is more of a cultural and organizational shift than a technology-centric one.
Central to this cultural change is the breaking down of organizational silos, starting with development and operations, but adding quality assurance, security, and governance to the list as well over time, as DevOps becomes SecDevOps.
The natural progression of this trend is clear, and Intellyx is among a chorus of voices calling for what people are increasingly labeling BizOps – extending the cultural shift that DevOps represents across the entire enterprise.
As a buzzword, BizOps rolls off the tongue – but as with many such terms, the devil is in the details. How would we go about extending DevOps principles outside of the IT organization in practice? Do we really want BizOps to infect every corner of our organization, or will a partial roll-out suffice?
And perhaps the most perplexing question of all: what is the role of technology in all this? While the focus of DevOps is more on organizational change than on the technology itself, there’s no question that this trend is technology-enabled.
Take DevOps and subtract the technology, and all you have left is some kind of cross-silo Kumbaya moment. Is BizOps doomed to the same fate?
The Problem with Kumbaya
Kumbaya moments – work events that are intended to break down conflict and bring people together – are so common in the world of management fads and motivational speaking that they have become clichéd fodder for any sitcom with a business setting.
Imagine any “trust-building” exercise at your last employee retreat, from that dreadful three-legged race to falling backward into the hands of colleagues. The stuff nightmares are made of, am I right?
Today, newly christened BizOps gurus are telling management to flatten their organizations, break down their silos by putting people into cross-functional, self-organizing teams without managers. Then watch the Kumbaya begin.
Only it never seems to work out that way. Gather a group of people and give them the expectation that they should self-organize, and more likely than not, one or two loudmouths will dominate the conversation. Soon no one else wants to chime in because they are trying to avoid conflict – and avoiding conflict is what Kumbaya is all about anyway, isn’t it?
If the group of people are from different departments, the situation is often worse. No one knows the role they are supposed to play, the language they should use to communicate with one another, or how to connect the dots between the problem they have been assigned to address and whatever solution might be the best one.
Clearly, something important is missing from this picture. The bottom line: self-organization is hard. It requires its own specialized knowledge, often through training and experience. And getting self-organizational principles to work across organizational silos requires the right tools and the proper know-how regarding their use.
The DevOps Virus Virtuous Cycle
In an earlier Cortex newsletter, I wrote about the DevOps Virus – how companies that figure out DevOps should encourage its principles to expand to other parts of the organization as needed to support agility requirements in the face of disruptive change.
It would be a mistake, however, to limit DevOps principles solely to cultural or organizational change, as that particular flavor of tunnel vision leads to Kumbaya moment problems.
Instead, we must also consider the technological component of DevOps, and how we must extend it – if not the technology itself, then the architectural principles that uniquely differentiate DevOps from the various organizational trends to hit software development in the past.
In fact, the interplay between DevOps’ organizational and technology change creates a virtuous cycle – one building upon the other as the overall practice matures. Once we understand the subtleties of this cycle, we can finally break out of Kumbaya-centric thinking and flesh out the specifics of the DevOps Virus.
The starting point for this cycle is the environment that gave rise to DevOps in the first place: software development organizations achieving a good measure of success with Agile approaches.
Such techniques encourage iterative development, customer-centricity, and shifting quality “to the left” – in other words, hammering out test plans and other quality-centric activities within each iteration before development commences.
Add to this Agile DevOps precursor the DevOps toolchain – improved tooling that drives automation of the software lifecycle, from quality assurance to release management to integration to ops management and beyond.
By leveraging modern integration approaches like REST as well as other best practices from the open source movement, the tools that make up such toolchains work well together, and furthermore, support broad-based automated orchestration and workflows.
This combination of Agile organizational principles and improved automation tools, in turn, shift the responsibility of the ops team. Instead of manually monitoring and fixing issues in the operational environment, ops personnel can use many of the same tools as the app dev team to automate previously manual tasks.
At that point, the level of technology expertise among the DevOps team facilitates the cross-silo self-organization that characterizes DevOps – but not because dev and ops folks pile into a conference room and decided to self-organize.
Rather, the shifting capabilities of their shared set of technology tools, combined with hard-won expertise with those tools, facilitates and empowers new ways for them to organize themselves.
Distilling the Essence of DevOps
The DevOps toolchain itself, however, isn’t the key to this virtuous cycle. Instead, the essence of DevOps is how the “shift left” mentality combined with declarative automation approaches lead to immutable infrastructure on the one hand and Software-Defined Everything on the other.
Remember that “shift left” arose as an Agile approach to quality, where instead of handling quality assurance after development was complete (as is the case in waterfall projects), the team writes the tests ahead of time, and only considers an iteration complete when all the tests corresponding to that iteration pass.
The test plan itself therefore becomes an abstracted representation of the working software – a declarative approach to automation that itself defines the desired functionality. In other words, this Agile approach to quality is “Software-Defined” – a phrase that is now gaining currency across all levels of technology infrastructure.
DevOps takes this notion of shift left/Software-Defined and extends it to the entire software build. All aspects of software deployment – from packaging to environment configuration to integration to problem resolution – now appear in the scripts or recipes that define the entire software infrastructure, from the network all the way to the user interface.
As a result, cross-team collaboration centers on those recipes. In a world of immutable infrastructure where no one manually provisions infrastructure, deploys software, or fixes issues, people no longer deal with each of those activities in isolation.
Instead, everyone works together on the recipes – and if there’s a problem in production, fix the recipe and redeploy as often as necessary.
The Intellyx Take: Extending Shift Left/Software-Defined to the Enterprise
Software-Defined Everything is yet another catchy buzzword, and to be sure we can easily coin the term Software-Defined Enterprise if we like – but does it even make sense to extend the notion of shift left/Software-Defined practices to an organization as a whole?
Perhaps not. After all, when you look at a typical large organization, there are many activities that involve human actions and interactions with little or no involvement of technology.
For digital organizations, however, the story is different. As digital transformation progresses and a company becomes increasingly digital, a greater portion of their activities overall – even the human-centric ones – become technology-enabled, if not entirely software-driven.
This fact brings us to what we might perhaps call a grand unified theory of Digital, DevOps, and Software-Defined Everything: to achieve the levels of agility necessary to deal with and capitalize on increasingly prevalent disruption, organizations must leverage shift left/Software-Defined principles to facilitate cross-organizational self-organization – and furthermore, this technology-enabled organizational change is at the core of every successful digital transformation.
There’s far more to say on this subject, of course, but in the meantime, now you know why DevOps, Software-Defined Everything, and the Agile Architecture that glues them together all intertwine on our Agile Digital Transformation Roadmap poster.
Furthermore, if your Digital, DevOps, and Software-Defined efforts aren’t all different facets of the same transformation, then rest assured you’re doing it wrong.
Copyright © Intellyx LLC. Intellyx publishes the Agile Digital Transformation Roadmap poster, advises companies on their digital transformation initiatives, and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers.
Comments