9 ms·

DevOps uses a capability model, not a maturity model

164 points by kiyanwang 4y ago

dboreham 4y ago
This is the software industry equivalent of an article in "The Onion".
- crabbone 4y ago
  I thought that software industry equivalent to The Onion was LinkedIn blog posts, but yeah... this would fit there just fine.
mjfisher 4y ago
Useful take on a common problem. Another way of approaching the same concept would be through the Cynefin[0] framework; maturity models occupy the simple or complicated contexts, whereas capability models can be fulfilled via iterating in the complex domain. [0] https://en.m.wikipedia.org/wiki/Cynefin_framework https://en.m.wikipedia.org/wiki/Cynefin_framework
- stevefenton 4y ago
  Cynefin is a great model - I must admit I've been insterested in it for a long time (I think Liz Keogh brought it to my attention) - but I've not applied it practically. Anyone got ideas for using it IRL?
  - mjfisher 4y ago
    There are a couple of specific situations I tend to run into fairly frequently with my consultant hat on: 1. People or organisations wanting to implement process by well-defined stages and checklists. They'll see that works in certain situations elsewhere, but not realise that such processes will fall apart quickly in the complicated or complex regions they're trying to manage. Talking through where they sit on a Cynefin diagram can help them understand which action model is the most useful, whether it's really possible to define "best practice" for any given situation, etc. 2. Products being managed as though they were projects. Big organisations tend to run on a project model by default because it seems like a way for them to manage risk - a certain amount of budget signed off for a few months to a year that ensures X, Y, Z is delivered for a certain timeframe. The true risk is that absolutely kills innovation for an early stage product looking for PMF. You don't really know what the end result is supposed to look like, but you probably do know what the process for getting there should be. Being able to talk about complicated (often, projects) and complex (often, product development) regimes being distinct areas that require different handling is a good start.
netfortius 4y ago
I don't think this is an either/or problem. Very simply put, the maturity and capability form a two-dimensional "grid", within which each organization fits its levels - e.g. let's say "maturity levels" on the vertical axes, and "capability controls" on the horizontal one. Where the two meet on the grid, you get the two-dimensional org level. I recently had to conduct an org maturity analysis and identified a #1 (out of 5) existing level (i.e. very immature in some capabilities, functions and their associated specific processes), then define and implement a maturity model and path for them towards achieving such, whereas their "horizontal"/capability was in a "semi-automated and developing new" level (btw 3-4).
- phkahler 4y ago
  Can you clarify what each of your 2 axis are? This sounds interesting On a tangent, I once drew 2 dimensions and put all our political parties on them. It turned out the "left" and "right" were trending toward "up" and "right" not opposites. Upper right corner was totalitarian BTW.
  - sharemywin 4y ago
    I thought we were headed for neo-feudalism.
    - toyg 4y ago
      Totalitarianism is an implementation methodology. Actual underpinning values can vary by system.
- mattcwilson 4y ago
  Almost as though there should be a “Capability Maturity Model.” Man, I wish someone had come up with that 40 years ago.
  - quickthrower2 4y ago
    I looked up CMM bit it seems different to what is described in the article by Octopus and sounds more like just a maturity model.
robertlagrant 4y ago
This article is highlighting a problem with badly designed maturity models in general. If you have a good maturity model (e.g. for DevOps one based on DORA metrics) then the capabilities needed to arrive at a higher level can be determined per-org. That solves the real problem. I think the article has a fundamental "AB problem" issue.
- simplotek 4y ago
  > If you have a good maturity model (e.g. for DevOps one based on DORA metrics) then the capabilities needed to arrive at a higher level can be determined per-org. How do metrics like deployment frequency and lead time for changes can have an impact on "the capabilities needed" by an org? Honestly, your comment reads a bit like machine learning generated buzzword bingo.
  - robertlagrant 4y ago
    > How do metrics like deployment frequency and lead time for changes can have an impact on "the capabilities needed" by an org? Hitting tighter metrics is going to need more advanced capabilities.
- stevefenton 4y ago
  Rather than a maturity model, DORA use metrics and a capability model. The idea is you use the metrics to decide on which capabilities to focus on. This tailoring to your context is the great thing about it - it's what you mention when you talk about determining the capabilities per-org... that's why you'd choose a capability model, not a maturity model. Maturity models seek to standardize the practices globally, rather than leaving room for customization. I guess... we're pretty much in agreement - except perhaps over the definition of the two types of model :)
- Chico75 4y ago
  I would encourage you to read the book "Accelerate" which was at the source of the DORA metrics, as it clearly advocate for a capability model, not a maturity one.
vrglvrglvrgl 4y ago
[dead]
samsquire 4y ago
What upsets me about devops work is that everything I do at a client is a lineage of architecture and design that needs to be maintained going forward and it only exists at that client. The lineage of interesting or useful things I do are tied to the client and dies with that client or when I leave. I just think of the thousands of CI/CD systems, build systems, attempts at parallelising builds, impressive optimisations, tooling, automation that have been written for each company over-and-over-again, and there's no cross polenation except when they are open sourced. I suppose Kubernetes is part of the answer here, a distribution of practices that survives organisations and spreads between organisations and client-specific lineages of software evolution. I want to work on interesting capabilities such as diagrammatic observability and live visualizations of systems. I really need to make a idle cloud environment simulation game where you invest time in servers, capabilities to handle load and problems that occur randomly or on a schedule.
- hendry 4y ago
  Surely Github workflows https://github.com/actions/starter-workflows https://github.com/actions/starter-workflows or Gitlab templates is the culmination of your devops work? Not Kubernetes (?) unless I missed something. The rewarding thing for me is applying this and other sensible defaults like observing iteration speed and driving delivery..
  - samsquire 4y ago
    I'm imagining something similar to a 3D wireframe model of networks and systems, with particles that move around between nodes that represent requests or IOPS. Circuit breakers, bottlenecks, IOPs, load shedding, traffic behaviours can all be visualised. I'm not sure how you would represent latency with this visualization but that's also important. It more represents throughput. Can also be used to represent human work/tasks itself.
    - hendry 4y ago
      Sounds a bit complex, I usually stick to the R.E.D. method for services and from the devops perspective largely iteration speed.
a_c 4y ago
What is devops here again? Is it the The Phoenix Project one on one extreme or system admin for the cloud on the other extreme?
- pjmlp 4y ago
  For many organizations, a rebranding of systems engineer.
  - a_c 4y ago
    Hence the call out. There is a "Dev" in DevOps which was meant to cross the organisation silo of developers and system admins, to "shift left", to understand the value chain and do whatever to deliver value. Which meant different things to different people, and it ended up meaning different things to different people.
    - ilyt 4y ago
      "Dev" in our Devops (we call it sysops usuall tho) is "we make the tools to glue stuff together instead of relying on dev teams for anything that's longer than few hundred lines of code long.
- stevefenton 4y ago
  DevOps part one was just "developers and operations working more closely together". It only really required the managers to update the goals of the two specilizations to remove the conflict (developers are rewarded for delivering more, operations are rewarded for stability). Once the research picked up, they started building out a broader picture of what a DevOps organization did and whether those things made them more successful (better at delivering software, more reliable, more profitable, etc). The Phoenix Project / The Unicorn Project explain the concept by telling a story - they kind of tell the same story, but from different perspectives. There's also Investments Unlimited which takes an even broader view by adding governance, risk, and compliance (but in a way that aligns to DevOps). In 2023, DevOps is best described by the DORA research (The State of DevOps Report) as it covers technical, cultural, and product concerns that all amplify each other.
zug_zug 4y ago
Not really sure we need another "model" of devops. All of these "philosophy of devops" discussions I've ever seen really boil down to "I am annoyed my coworkers aren't owning X, and here's a big fancy post explaining why it's their fault in smart words." In my experience, a big fancy post in smart words is never actually a practical implement to change the current practices of a company.
opentokix 4y ago
DORA Metrics is not a good place to start. This blog post is sales pitchf or whatever they are selling.
- tra3 4y ago
  Curious to hear your thoughts. What's a good place? I'd argue that if your releases take forever, or lead times are huge they are worth improving first. What would you look at first?
  - stevefenton 4y ago
    I'd start with small batches. Quite a lot of the benefits come out of just doing fewer things between each release.
KrugerDunnings 4y ago
Lately I've been made to understand that DevOps or Software Engineering is not for me, capability/maturity models, processes written in anything other then code, or metrics this and that just ism't me. We can argue about the meaning of words all day long but like I said this just isn't me. Some of us just prefer to say close to the metal (as in reality with all its complexity that escapes the precision of words and that is totally ok) and are deeply suspicious of any excessive abstractions. There must be others like me, so I am in search for my tribe, and I want to know what do we call ourself, maybe we don't want to call ourself anything, but where can we meet, who want to hire us, please tell me if you know, Thanks!
- marcosdumay 4y ago
  I don't think any place actively looks for grey-beards in particular. But well, they do have an easy time posing as seniors. The only question is whether pushing for working things instead of nice talk will get enthusiastic support or opposition from the management.
- stevefenton 4y ago
  Companies who need every engineer to "Do Everything™" are doing it wrong. A team may need to cover a lot of ground, but by putting together folks who have different skills. It's a management skill to assemble a team with diverse experience, rather than only hiring individuals who are "a team on their own". I don't think you should feel excluded from "Software Engineering" just because you don't have a passion for managing containers. We need people who can write great code in the world, too!
- b4ke 4y ago
  SOURCErer
- jedberg 4y ago
  I don't want to disappoint you, but what you want to do is not really supported by many companies anymore. Maybe the cloud providers would be interested in someone close to the metal. A few companies still run their own data centers, but even for them, hardware is so cheap it's usually easier to just throw more hardware at the problem than optimizing what you've got. The one area where you might want to focus is HPC. All the companies building huge GPT models need highly optimized hardware.
getoffmyyawn 4y ago
DevOps as a movement died when it started being used as a job title. In my experience, it quickly stopped being a philosophy for Dev and Ops teams to work on working better together and just because a new name for System Administrator. Before the popularity of the term "DevOps" it was always true that any System Administrator worth hiring knew how to script for automation (the job title for people who didn't was System Operator). Unfortunately the market was flooded with a lot of people in that role who barely knew what they were doing and so resisted every change anyone else in their company wanted. From my perspective, the greatest achievement of the DevOps movement was to push the bar higher for the expected skill level of the average SysAdmin. I see that as a good thing.
- mjr00 4y ago
  > DevOps as a movement died when it started being used as a job title. In my experience, it quickly stopped being a philosophy for Dev and Ops teams to work on working better together and just because a new name for System Administrator. The "DevOps" job title can arguably just be a sysadmin, but I do think the main ideals of the movement are just so tightly ingrained in software now that we don't even notice. It's easy to forget that 10-15 years ago, the most common dev/ops model was "toss it over the fence"--developers write code, do a ton of QA work on the test system, and then toss it to ops, who had no idea what metrics to look for beyond standard cpu/mem/etc. Your dev team would write up a "runbook" for operators to follow if anything broke, which was usually just restarting things until they got into a good state again. The big tech players of the 00s like AWS and Google were probably more advanced of this, but the rest of the world largely wasn't. Now, the most common model for companies of all sizes is "if you build it, you operate it". Devs are expected to know what metrics to expose, have oncall rotations, and have direct access to their production systems. Cloud, CI/CD and git helped quite a lot in this regard, reducing time between deployments from months to weeks to days to hours and minutes. This continues to be the lasting legacy of "DevOps" IMO, it shouldn't be understated how much of an impact it had on our industry.
  - marcosdumay 4y ago
    > It's easy to forget that 10-15 years ago, the most common dev/ops model was "toss it over the fence" Hum... My first guess is that what really changed was the ratio of developers working on places that do this to the ones working on places that integrate the jobs. The wall was never the only model around. It still isn't. The same kind of company that practiced it still largely have walls. The IT industry just hired a lot of people.
jayd16 4y ago
Is the tl;dr just to do your devops in an agile way? I can't seem to pull anything else out of this.
- dijit 4y ago
  DevOps as she is written originally was “Agile Systems Administration”. So, yes. Any other variation is not what Patrick Debois was talking about when he created DevOps days, from which the job title takes its name.
pictur 4y ago
Working with the logic that the author talks about can cause terrible situations for large companies. If you create a culture based on trying new things in companies that are in constant business development, you must create a culture that will take responsibility for it. otherwise, you'll have environments where answers to "hey why isn't this working" questions can't be found.
- stevefenton 4y ago
  It's fair to say that culture eats everything else alive. It's also the hardest thing to change. I've worked in a few places where we felt helpless to impact the culture and creating a culture-bubble (i.e. to the extent of the technical teams, but no further) didn't help impact business outcomes, even where it made our lives a better. Maybe that was enough to make the culture-bubble worthwhile.
durpleDrank 4y ago
Has DevOps, the approach to software development that accentuates the amalgamation and communication between software developers and IT experts, undergone a rebranding effort in recent years, replacing its nomenclature with Site Reliability Engineering (SRE)? Was this transformation brought about due to a growing demand for individuals who possessed a modicum of familiarity with cloud technologies, and sought to transition into teams responsible for software reliability engineering? Moreover, did this shift also encompass DevOps practitioners with rudimentary coding proficiencies?
_8j50 4y ago
My challenge to the author is why can't maturity models be dynamic and continually improved. What is being suggested here is too complex and involves a lot of busy work. Why can't you, as part of the process implement a capabilty driven dynamic (as in you review and change it) maturity model? I mean, capability driven sounds great to talk about but how do you go about implementing it? A maturity model is simple to define and measure. I worry about endless meetings with what is proposed here but maybe I misunderstood a few things.
- crabbone 4y ago
  This reminds me how once my then girlfrend's friend brought a textbook from some course she took for MBA degree. We had to wait hours for a train, or our other friend was late... and so having nothing better to do, I tried reading that coursebook. At first, it was hard to work through the terminology, but once you get the hang of it, you realize that if only they used planer language, the whole book could've been refined int a few trite statements. Like... "reward diligent employees and avoid the neglectful ones" and so on. This post reads about just like that. I wish we had better insight into how to manage processes in programming businesses... but so far I haven't seen anything that truly goes beyond the obvious stuff. The only difference is how much the author is willing to elaborate on that obvious stuff.
dukodk 4y ago
I’ve seen “DevOps handover” on a whiteboard. I still don’t know how that makes sense.
- Godel_unicode 4y ago
  Yeah, there are a lot of people confused about the difference between devops and sre.
TeeMassive 4y ago
One of the very first point the book Accelerate (which I really recommend reading since it gives you the ammunition to sell DevOps culture to your coworkers and leaders) hammers this point early on. Maturity models quickly devolves into cargo cults and of course making metrics a goal makes these metrics useless. What really matter are meaningful capabilities, which when read aloud it just feels so obvious.

164 points by kiyanwang 4y ago

dboreham 4y ago

This is the software industry equivalent of an article in "The Onion".

crabbone 4y ago
I thought that software industry equivalent to The Onion was LinkedIn blog posts, but yeah... this would fit there just fine.

mjfisher 4y ago

Useful take on a common problem. Another way of approaching the same concept would be through the Cynefin[0] framework; maturity models occupy the simple or complicated contexts, whereas capability models can be fulfilled via iterating in the complex domain. [0] https://en.m.wikipedia.org/wiki/Cynefin_framework https://en.m.wikipedia.org/wiki/Cynefin_framework

stevefenton 4y ago
Cynefin is a great model - I must admit I've been insterested in it for a long time (I think Liz Keogh brought it to my attention) - but I've not applied it practically. Anyone got ideas for using it IRL?
- mjfisher 4y ago
  There are a couple of specific situations I tend to run into fairly frequently with my consultant hat on: 1. People or organisations wanting to implement process by well-defined stages and checklists. They'll see that works in certain situations elsewhere, but not realise that such processes will fall apart quickly in the complicated or complex regions they're trying to manage. Talking through where they sit on a Cynefin diagram can help them understand which action model is the most useful, whether it's really possible to define "best practice" for any given situation, etc. 2. Products being managed as though they were projects. Big organisations tend to run on a project model by default because it seems like a way for them to manage risk - a certain amount of budget signed off for a few months to a year that ensures X, Y, Z is delivered for a certain timeframe. The true risk is that absolutely kills innovation for an early stage product looking for PMF. You don't really know what the end result is supposed to look like, but you probably do know what the process for getting there should be. Being able to talk about complicated (often, projects) and complex (often, product development) regimes being distinct areas that require different handling is a good start.

netfortius 4y ago

I don't think this is an either/or problem. Very simply put, the maturity and capability form a two-dimensional "grid", within which each organization fits its levels - e.g. let's say "maturity levels" on the vertical axes, and "capability controls" on the horizontal one. Where the two meet on the grid, you get the two-dimensional org level. I recently had to conduct an org maturity analysis and identified a #1 (out of 5) existing level (i.e. very immature in some capabilities, functions and their associated specific processes), then define and implement a maturity model and path for them towards achieving such, whereas their "horizontal"/capability was in a "semi-automated and developing new" level (btw 3-4).

phkahler 4y ago
Can you clarify what each of your 2 axis are? This sounds interesting On a tangent, I once drew 2 dimensions and put all our political parties on them. It turned out the "left" and "right" were trending toward "up" and "right" not opposites. Upper right corner was totalitarian BTW.
- sharemywin 4y ago
  I thought we were headed for neo-feudalism.
  - toyg 4y ago
    Totalitarianism is an implementation methodology. Actual underpinning values can vary by system.
mattcwilson 4y ago
Almost as though there should be a “Capability Maturity Model.” Man, I wish someone had come up with that 40 years ago.
- quickthrower2 4y ago
  I looked up CMM bit it seems different to what is described in the article by Octopus and sounds more like just a maturity model.

robertlagrant 4y ago

This article is highlighting a problem with badly designed maturity models in general. If you have a good maturity model (e.g. for DevOps one based on DORA metrics) then the capabilities needed to arrive at a higher level can be determined per-org. That solves the real problem. I think the article has a fundamental "AB problem" issue.

simplotek 4y ago
> If you have a good maturity model (e.g. for DevOps one based on DORA metrics) then the capabilities needed to arrive at a higher level can be determined per-org. How do metrics like deployment frequency and lead time for changes can have an impact on "the capabilities needed" by an org? Honestly, your comment reads a bit like machine learning generated buzzword bingo.
- robertlagrant 4y ago
  > How do metrics like deployment frequency and lead time for changes can have an impact on "the capabilities needed" by an org? Hitting tighter metrics is going to need more advanced capabilities.
stevefenton 4y ago
Rather than a maturity model, DORA use metrics and a capability model. The idea is you use the metrics to decide on which capabilities to focus on. This tailoring to your context is the great thing about it - it's what you mention when you talk about determining the capabilities per-org... that's why you'd choose a capability model, not a maturity model. Maturity models seek to standardize the practices globally, rather than leaving room for customization. I guess... we're pretty much in agreement - except perhaps over the definition of the two types of model :)
Chico75 4y ago
I would encourage you to read the book "Accelerate" which was at the source of the DORA metrics, as it clearly advocate for a capability model, not a maturity one.

vrglvrglvrgl 4y ago

[dead]

samsquire 4y ago

What upsets me about devops work is that everything I do at a client is a lineage of architecture and design that needs to be maintained going forward and it only exists at that client. The lineage of interesting or useful things I do are tied to the client and dies with that client or when I leave. I just think of the thousands of CI/CD systems, build systems, attempts at parallelising builds, impressive optimisations, tooling, automation that have been written for each company over-and-over-again, and there's no cross polenation except when they are open sourced. I suppose Kubernetes is part of the answer here, a distribution of practices that survives organisations and spreads between organisations and client-specific lineages of software evolution. I want to work on interesting capabilities such as diagrammatic observability and live visualizations of systems. I really need to make a idle cloud environment simulation game where you invest time in servers, capabilities to handle load and problems that occur randomly or on a schedule.

hendry 4y ago
Surely Github workflows https://github.com/actions/starter-workflows https://github.com/actions/starter-workflows or Gitlab templates is the culmination of your devops work? Not Kubernetes (?) unless I missed something. The rewarding thing for me is applying this and other sensible defaults like observing iteration speed and driving delivery..
- samsquire 4y ago
  I'm imagining something similar to a 3D wireframe model of networks and systems, with particles that move around between nodes that represent requests or IOPS. Circuit breakers, bottlenecks, IOPs, load shedding, traffic behaviours can all be visualised. I'm not sure how you would represent latency with this visualization but that's also important. It more represents throughput. Can also be used to represent human work/tasks itself.
  - hendry 4y ago
    Sounds a bit complex, I usually stick to the R.E.D. method for services and from the devops perspective largely iteration speed.

a_c 4y ago

What is devops here again? Is it the The Phoenix Project one on one extreme or system admin for the cloud on the other extreme?

pjmlp 4y ago
For many organizations, a rebranding of systems engineer.
- a_c 4y ago
  Hence the call out. There is a "Dev" in DevOps which was meant to cross the organisation silo of developers and system admins, to "shift left", to understand the value chain and do whatever to deliver value. Which meant different things to different people, and it ended up meaning different things to different people.
  - ilyt 4y ago
    "Dev" in our Devops (we call it sysops usuall tho) is "we make the tools to glue stuff together instead of relying on dev teams for anything that's longer than few hundred lines of code long.
stevefenton 4y ago
DevOps part one was just "developers and operations working more closely together". It only really required the managers to update the goals of the two specilizations to remove the conflict (developers are rewarded for delivering more, operations are rewarded for stability). Once the research picked up, they started building out a broader picture of what a DevOps organization did and whether those things made them more successful (better at delivering software, more reliable, more profitable, etc). The Phoenix Project / The Unicorn Project explain the concept by telling a story - they kind of tell the same story, but from different perspectives. There's also Investments Unlimited which takes an even broader view by adding governance, risk, and compliance (but in a way that aligns to DevOps). In 2023, DevOps is best described by the DORA research (The State of DevOps Report) as it covers technical, cultural, and product concerns that all amplify each other.

zug_zug 4y ago

Not really sure we need another "model" of devops. All of these "philosophy of devops" discussions I've ever seen really boil down to "I am annoyed my coworkers aren't owning X, and here's a big fancy post explaining why it's their fault in smart words." In my experience, a big fancy post in smart words is never actually a practical implement to change the current practices of a company.

opentokix 4y ago

DORA Metrics is not a good place to start. This blog post is sales pitchf or whatever they are selling.

tra3 4y ago
Curious to hear your thoughts. What's a good place? I'd argue that if your releases take forever, or lead times are huge they are worth improving first. What would you look at first?
- stevefenton 4y ago
  I'd start with small batches. Quite a lot of the benefits come out of just doing fewer things between each release.

KrugerDunnings 4y ago

Lately I've been made to understand that DevOps or Software Engineering is not for me, capability/maturity models, processes written in anything other then code, or metrics this and that just ism't me. We can argue about the meaning of words all day long but like I said this just isn't me. Some of us just prefer to say close to the metal (as in reality with all its complexity that escapes the precision of words and that is totally ok) and are deeply suspicious of any excessive abstractions. There must be others like me, so I am in search for my tribe, and I want to know what do we call ourself, maybe we don't want to call ourself anything, but where can we meet, who want to hire us, please tell me if you know, Thanks!

marcosdumay 4y ago
I don't think any place actively looks for grey-beards in particular. But well, they do have an easy time posing as seniors. The only question is whether pushing for working things instead of nice talk will get enthusiastic support or opposition from the management.
stevefenton 4y ago
Companies who need every engineer to "Do Everything™" are doing it wrong. A team may need to cover a lot of ground, but by putting together folks who have different skills. It's a management skill to assemble a team with diverse experience, rather than only hiring individuals who are "a team on their own". I don't think you should feel excluded from "Software Engineering" just because you don't have a passion for managing containers. We need people who can write great code in the world, too!
b4ke 4y ago
SOURCErer
jedberg 4y ago
I don't want to disappoint you, but what you want to do is not really supported by many companies anymore. Maybe the cloud providers would be interested in someone close to the metal. A few companies still run their own data centers, but even for them, hardware is so cheap it's usually easier to just throw more hardware at the problem than optimizing what you've got. The one area where you might want to focus is HPC. All the companies building huge GPT models need highly optimized hardware.

getoffmyyawn 4y ago

DevOps as a movement died when it started being used as a job title. In my experience, it quickly stopped being a philosophy for Dev and Ops teams to work on working better together and just because a new name for System Administrator. Before the popularity of the term "DevOps" it was always true that any System Administrator worth hiring knew how to script for automation (the job title for people who didn't was System Operator). Unfortunately the market was flooded with a lot of people in that role who barely knew what they were doing and so resisted every change anyone else in their company wanted. From my perspective, the greatest achievement of the DevOps movement was to push the bar higher for the expected skill level of the average SysAdmin. I see that as a good thing.

mjr00 4y ago
> DevOps as a movement died when it started being used as a job title. In my experience, it quickly stopped being a philosophy for Dev and Ops teams to work on working better together and just because a new name for System Administrator. The "DevOps" job title can arguably just be a sysadmin, but I do think the main ideals of the movement are just so tightly ingrained in software now that we don't even notice. It's easy to forget that 10-15 years ago, the most common dev/ops model was "toss it over the fence"--developers write code, do a ton of QA work on the test system, and then toss it to ops, who had no idea what metrics to look for beyond standard cpu/mem/etc. Your dev team would write up a "runbook" for operators to follow if anything broke, which was usually just restarting things until they got into a good state again. The big tech players of the 00s like AWS and Google were probably more advanced of this, but the rest of the world largely wasn't. Now, the most common model for companies of all sizes is "if you build it, you operate it". Devs are expected to know what metrics to expose, have oncall rotations, and have direct access to their production systems. Cloud, CI/CD and git helped quite a lot in this regard, reducing time between deployments from months to weeks to days to hours and minutes. This continues to be the lasting legacy of "DevOps" IMO, it shouldn't be understated how much of an impact it had on our industry.
- marcosdumay 4y ago
  > It's easy to forget that 10-15 years ago, the most common dev/ops model was "toss it over the fence" Hum... My first guess is that what really changed was the ratio of developers working on places that do this to the ones working on places that integrate the jobs. The wall was never the only model around. It still isn't. The same kind of company that practiced it still largely have walls. The IT industry just hired a lot of people.

jayd16 4y ago

Is the tl;dr just to do your devops in an agile way? I can't seem to pull anything else out of this.

dijit 4y ago
DevOps as she is written originally was “Agile Systems Administration”. So, yes. Any other variation is not what Patrick Debois was talking about when he created DevOps days, from which the job title takes its name.

pictur 4y ago

Working with the logic that the author talks about can cause terrible situations for large companies. If you create a culture based on trying new things in companies that are in constant business development, you must create a culture that will take responsibility for it. otherwise, you'll have environments where answers to "hey why isn't this working" questions can't be found.

stevefenton 4y ago
It's fair to say that culture eats everything else alive. It's also the hardest thing to change. I've worked in a few places where we felt helpless to impact the culture and creating a culture-bubble (i.e. to the extent of the technical teams, but no further) didn't help impact business outcomes, even where it made our lives a better. Maybe that was enough to make the culture-bubble worthwhile.

durpleDrank 4y ago

Has DevOps, the approach to software development that accentuates the amalgamation and communication between software developers and IT experts, undergone a rebranding effort in recent years, replacing its nomenclature with Site Reliability Engineering (SRE)? Was this transformation brought about due to a growing demand for individuals who possessed a modicum of familiarity with cloud technologies, and sought to transition into teams responsible for software reliability engineering? Moreover, did this shift also encompass DevOps practitioners with rudimentary coding proficiencies?

_8j50 4y ago

My challenge to the author is why can't maturity models be dynamic and continually improved. What is being suggested here is too complex and involves a lot of busy work. Why can't you, as part of the process implement a capabilty driven dynamic (as in you review and change it) maturity model? I mean, capability driven sounds great to talk about but how do you go about implementing it? A maturity model is simple to define and measure. I worry about endless meetings with what is proposed here but maybe I misunderstood a few things.

crabbone 4y ago
This reminds me how once my then girlfrend's friend brought a textbook from some course she took for MBA degree. We had to wait hours for a train, or our other friend was late... and so having nothing better to do, I tried reading that coursebook. At first, it was hard to work through the terminology, but once you get the hang of it, you realize that if only they used planer language, the whole book could've been refined int a few trite statements. Like... "reward diligent employees and avoid the neglectful ones" and so on. This post reads about just like that. I wish we had better insight into how to manage processes in programming businesses... but so far I haven't seen anything that truly goes beyond the obvious stuff. The only difference is how much the author is willing to elaborate on that obvious stuff.

dukodk 4y ago

I’ve seen “DevOps handover” on a whiteboard. I still don’t know how that makes sense.

Godel_unicode 4y ago
Yeah, there are a lot of people confused about the difference between devops and sre.

TeeMassive 4y ago

One of the very first point the book Accelerate (which I really recommend reading since it gives you the ammunition to sell DevOps culture to your coworkers and leaders) hammers this point early on. Maturity models quickly devolves into cargo cults and of course making metrics a goal makes these metrics useless. What really matter are meaningful capabilities, which when read aloud it just feels so obvious.