<![CDATA[Reliability Enablers: Reliability Blueprint]]>https://read.srepath.com/s/software-reliability-frameworkhttps://substackcdn.com/image/fetch/$s_!hjhf!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F99ee1dc2-77bf-4ffa-b056-f66dac8ad0d0_128x128.pngReliability Enablers: Reliability Blueprinthttps://read.srepath.com/s/software-reliability-frameworkSubstackSun, 05 Apr 2026 00:27:52 GMT<![CDATA[Major changes to the "map"]]>https://read.srepath.com/p/major-changes-to-the-maphttps://read.srepath.com/p/major-changes-to-the-mapWed, 05 Jun 2024 08:29:35 GMTI am not one to write changelogs for daily work because, for 10+ years, my accountability was for work done over weeks to months to sometimes years.

But I have been chipping away at what I originally called the “reliability capability map”.

Level 1 of the blueprint, now working on the “Observability” workstream

Right now, it’s a static database, but the goal is to enable interactivity.

That probably will require a customer/sponsor to financially support a bespoke build-out if they are desperate enough to get reliability off the ground the right way.

The idea is to get your people-process-technology in sync so that magic reliability can happen. Maybe a little magic too.

The reliability capability map blueprint now has an updated link to: https://www.srepath.com/reliability-blueprint/

]]><![CDATA[I've worked out Level 1 of the Reliability Map ]]>https://read.srepath.com/p/ive-worked-out-level-1-of-the-reliabilityhttps://read.srepath.com/p/ive-worked-out-level-1-of-the-reliabilityTue, 28 May 2024 13:58:07 GMTHere’s a sneak peek of the first part of the updated framework I alluded to in my last post:

Above is level 1 of the capability map.

I will work on populating level 2 items next, probably starting with a Capability Area that’s not too controversial. Perhaps Observability fits the bill.

What’s all this level 1, level 2 business?

I could make a very funky-looking map like the original I made in 2021 and showed in the last post.

But I think it’s worthwhile complying with TOGAF standards that enterprise architects have been using for years.

]]><![CDATA[Restarting my reliability capability project]]>https://read.srepath.com/p/restarting-my-reliability-capabilityhttps://read.srepath.com/p/restarting-my-reliability-capabilityFri, 24 May 2024 05:10:01 GMTAbout 3 years ago, I started working on a visual framework for breaking down the what of reliability work in software.

My goal was to give a comprehensive view to all concerned, whether they are SREs, consultants, DevOps people, or anyone else.

It would enable you to analyze what you are doing right now, what you could be doing, and what you need to get there.

Here’s a screenshot of part of that first version:

It’s not bad at all. A lot of people messaged me and told me it was very useful.

But then someone put this fear in my mind that I am just enabling certain groups to get richer from my insights by offering this as part of their consulting…

… and I would make myself just poorer in terms of time.

I took the map down promising to bring it up when I had a more protected position to benefit in some way from it myself.

I then distracted myself with more subtle ways of getting this framework out there. But I’ve learned that subtlety doesn’t get you anywhere.

I’ve also learned one more thing: through my podcasting efforts, I have learned a lot more about the reliability space from other people.

It’s time I overcame that strange concern that I’m enriching others without enriching myself and moving forward with this.

Because sometimes you just gotta do what you gotta do. And for me, building a capability framework for reliability of one of those things.

]]>