Live data from Hacker News

DevOps uses a capability model, not a maturity model

octopus.com

11–20 of 115 posts

Re: DevOps uses a capability model, not a maturity model

#11

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.

> 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.

Re: DevOps uses a capability model, not a maturity model

#12
post #9

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 optimisatio…

Surely Github 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..

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.

Re: DevOps uses a capability model, not a maturity model

#13
post #2

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

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?

Re: DevOps uses a capability model, not a maturity model

#15

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 optimisatio…

"diagrammatic observability and live visualizations of systems"

I hear you. IMHO there's massive opportunity / unmet need here. And working on the things that interest and excite you is the surest path to (or maybe even the definition of) success. I hope you can find a way to start pursuing your ideas! Good luck!

Re: DevOps uses a capability model, not a maturity model

#16

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 optimisatio…

This isn't unique to devops, this is a general software thing. But there is an answer, which is the standard technology stack:

- AWS - Postgres - Linux - Docker - Jenkins or similar - Slack - Pagerduty - Jira - Packer - Terraform - etc

If you stay on the path there will be dozens of tools, plugins, and paths to do outstanding things with minimal work. Parallelising builds for example is built in to jenkins (if you define the workflow), which will autoscale workers in a setup that takes If you're writing code to solve a problem that a standard tool exists for, you're the problem.

Re: DevOps uses a capability model, not a maturity model

#17

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 optimisatio…

For me what upsets me about devops work, is that for many organizations it is a synonym for systems engineer, lots of Ops and very little Dev.

Re: DevOps uses a capability model, not a maturity model

#18
post #5

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…

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.

I thought we were headed for neo-feudalism.

Re: DevOps uses a capability model, not a maturity model

#20

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.

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 :)

Post reply on HN