“There are only two hard things in Computer Science: cache invalidation and naming things.” (Phil Karlton)
Let’s face it, devops is an incredibly bad name for what we are talking about. The origin and the development of devops has been mostly organic, which can cause problems when one tries to specify what something is and isn’t, especially when it comes to ways of thinking and how to approach problems. So, it is natural that something already hazy gives birth to even more haziness, in this case to DevXOps.
What the DevXOps assume, is that the devops is limited to the developers and ops personnel, and if we were to stay in the original idea to get the two, and ONLY the two, talking to each other, it would be absolutely right. For every additional field, there would then be yet another part added to the term and to include everything, the resulting term would be “DevQAUXSec… … Ops”. Whenever there would be only specific set in the team, there would be a different variation of it. Not only would this be impractical, it would also be highly confusing (which the current DevXOps terminology already can be).
Another interpretation is that the X represents what feature is emphasized in the overall process. This just raises more questions than it truly answers:
- why something needs to be emphasized over the others?
- does DevSecOps then mean that security goes above everything else, and quality assurance and user experience do not matter that much?
- is it necessary to use a different term rather than simply (and explicitly) state “devops with emphasis on security”?
- should the approach be changed from one to another, when the emphasis or the theme changes (e.g., from DevSecOps to DevQAOps or DevUXOps)?
The organic evolution of the devops also makes it much more difficult to understand, and it seems people are divided on what it contains and what it doesn’t. The thing is, devops does not really contain anything, but rather guides us to do things better. We need to remember that most of all, it is a way of thinking, a philosophy, and there can never be a product that could be counted, but it is possible to say that we follow the devops principles. But then, how to determine if something is or is not following the devops way of thinking?
The How
Let’s take a look at my definition of devops from https://gofore.com/en/devops-101-pt-1-journey-to-enlightenment/:
“DevOps is an anthropocentric organizational and cultural movement, and a philosophy with a goal of improving organizational and SDO (software delivery and operations) performance, productivity and the quality of the service.”
I have defined devops by what it aims to achieve with two main constraints:
- People are at the center of it
- It is limited to software development
The first constraint aims towards sustainability. The intent is not to gain more by squeezing every possible ounce of will and energy out of employees, just to discard them afterwards. The second constraint limits the methods to the context of software development.
Now, to guide our thinking process, let’s ask some question:
- How can we improve the performance and the productivity…
-
- …of the organization?
- …of the teams and the individuals?
- How can we ensure the quality of the service or the product as it is perceived…
-
- …by the end users?
- …by the developers?
From these questions, we can design the following core mind map:
The next step would be to take some higher level aspects (culture, psychological safety, processes, security etc.) that we know to have an effect on the four objectives. By adding those to their right places (at least mostly), we get:
The goal matters
While the mind map is not all-encompassing, it should point out the key points, from which we can move towards the finer details and ask even more questions. In many cases on the performance and productivity side of things, the things to consider are applicable to other industries as well. However, as long as we keep in our minds on the why, we can say that they are part of devops philosophy as well.
A good example of when something belongs or doesn’t to the thought model is the automation. We can teach that it is a good practice to automate everything and that it reduces the amount of repetitive manual work, but alone, creating pipelines or tools is just plain old software automation. When we add the why to it so that we do it in order to leave more time for the developers to be productive, to make it repeatable, to reduce memory load and so on, then we can say it is practicing the devops way of thinking.
As an example, let’s add a few things to the mind map:
- Processes
- Agile
- Lean
- Measurements (not strictly a process though)
- Culture
- Culture of experimentation
- Culture of trust
- Well-being (see: https://gofore.com/en/devops-101-part-3-psychological-safety-and-recovery/)
- Recovery
- Stress and frustration (negative relation to well-being)
- Burnout
- Automation
- Continuous Integration and Deployment
Yet again, not an all-encompassing view, but does give the idea how things are related and where everything could belong (notice that there are some shared aspects as well).
So… what now?
So now we can say that devops is everything and nothing. It is a software development-related phenomenon and a way of thinking aimed at being more productive through removal of silos, amongst many other things, while keeping the quality and the humans involved in a key role. The “need” for DevXOps might rise from the organic evolution of devops, the birth of folk models of the devops (more on this in https://gofore.com/en/devops-101-pt-1-journey-to-enlightenment/) and the bad name of it, but in the end, if we keep in mind what kind of problems the devops philosophy tries to solve and in what context, there is little that falls outside of it. This is the source of its inclusiveness. To understand the relations between all the different things, keep in mind the two constraints (anthropocentric phenomenon, software development) and the core questions:
How can we improve the performance and the productivity…
- …of the organization?
- …of the teams and the individuals?
How can we ensure the quality of the service or the product as it is perceived…
- …by the end users?
- …by the developers?
