DevOps Explained Graphically
Stack layered responsibilities across a life cycle gives all sorts of weird combinations

Vertical integration across the life cycle

DevOps Explained Graphically

First post - I’ll get better, I promise!

I started out writing about DevSecOps, and came up with a tldr; diagrammatic description of what DevOps is. So, here it is on it’s own:

Devop isn’t about technology,it’s about ownership and responsibility. While DevOps is usually enabled and implemented via good technology, if you think it’s about technology you’re missing the point!

Devops is culture/management, not technology.

  • DevOps is Vertical Integration of Technology Systems.
    • We don’t go we don’t separate responsibilities across time
    • We do not separate responsibilities by tech stack layer

In Pictures: DevOps, The Union of Development and Operations.

First, there was a stack

Most technologies are built or running on other technologies, themselves built or running on other technologies.

Simplified Software Stack - Infrastructure + OS + Virtual hardware + App Platform + Application

Next, specialization divides up the pie

Most companies like to split out the responsibilities for these layers to different specialized people or parts of the company.

For instance,

  • Information technology (IT) runs the Hardware and Supplies the Operating Systems (OS),
  • database administrators (DBAs) run the databases
  • systems administrators (sysadmins) configure and run the OS Infrastructure.

Finally, developers do their thing with the application.

Simplified Stack With Responsibilities split between IT, Sysadmins, DBAs, and Developers

Life cycle Maturity Phases

Life cycles and Pipelines Gonna Flow

So, put the stack aside for now because we have another dimension to think about: Time.

Many systems are developed and operated in a linear pipeline or development process. First they are in a “development” state, then they move to a “test/QA state”, and finally to a “production state”.

A component can be in each of these states, and often owned by different people and operated in separate environments depending on the state it is in.

Simplified Stack

Note the colors indicating the life cycle state, they’ll be important in a moment.

There be dragons - But they’re not my responsibility!

Specialization/Separation up and down the stack, combined with Specialization/Separation across the deployment/operations states gives you this:

Stack layers across a life cycle gives all sorts of weird combinations

Who owns and is responsible for each thing at each time? Good luck figuring that out without a RACI.

Devops to the rescue?

Devops simply gives the whole thing to the same team, in both dimensions.

Devops gives responsibilities over time and over stack layers to the same team

  • Who is responsible for X? - Developers
  • Who is blocking it because of Y - Developers
  • Who decides to take risks around Z? - Developers

Developers, Developers, Developers. Steve Ballmer would be proud!

A Couple of Devops Readings:

Prologue musings: Is specialization an antipattern?

No specific claims here, just leaving some thoughts. - feel free to

While writing this, thinking of DevSecOps, and discussing with a friend, it occurred to me that specialization might itself be an antipattern in many situations…. After all,

  • It’s not common to have dedicated experts in UX, performance, or accessibility, so why is it so common to have a security person?
  • The aim is to manage the emergent property, you don’t care how it gets there

Specialization has positives and negatives:

  • Pluses: specialists tend to be better at the specific thing, and have a more specific responsibility that is theoretically less open to conflict of interest.
  • Specialists may not be useful to the team outside of their specific expertise, and can be somewhat unconcerned with the holistic interest of the whole system over the whole life cycle.

Kate P

Devops, pictures, lifecycle, sdlc