DevOps uses a capability model, not a maturity model
1–10 of 115 posts
Re: DevOps uses a capability model, not a maturity model
#2Useful 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.
Re: DevOps uses a capability model, not a maturity model
#3I 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).
Re: DevOps uses a capability model, not a maturity model
#4This 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.
Re: DevOps uses a capability model, not a maturity model
#5I 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.
Re: DevOps uses a capability model, not a maturity model
#6[dead]
Re: DevOps uses a capability model, not a maturity model
#7I 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…
Almost as though there should be a “Capability Maturity Model.” Man, I wish someone had come up with that 40 years ago.
Re: DevOps uses a capability model, not a maturity model
#8What 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.
Re: DevOps uses a capability model, not a maturity model
#9What 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..
Re: DevOps uses a capability model, not a maturity model
#10I 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…
Almost as though there should be a “Capability Maturity Model.” Man, I wish someone had come up with that 40 years 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.