Open jkleinlercher opened 7 months ago
To me:
Different functional groups have different measurement tools that they are focused on internally, within the context of their day-to-day. AppDev may internally have different measurables than AppDelivery than AppSec than infra, etc (however you have divided things). Platform teams Optimizing in this space understand the different frameworks these groups have in place, and work to facilitate improvement in areas where they can reasonably interact.
Thinking from the product side. My developers are my users, and if there are areas where they are struggling to meet their measurables, then they are not successful. By having knowledge of their framework, I'm demonstrating a level of understanding of what success means to my users, and I'm able to proactively work toward helping them be more successful. My SRE team are also my users, and they have different measurables but may also have some overlap with the developers.
If I help dev reduce time-to-release by giving them better tools to tag and deploy releases, but affect SREs measureables for uptime by failing to facilitate blue-green deployments, well then my measurables for user-success should fall.
This is a great question and points to (once again) the fact that all of these points are nuanced and open to different focuses.
@jkleinlercher I am going to share some thoughts below, but I would be really interested to hear more about your confusion or concern as well. Do you have an example that you feel would not fit with these sentences? Or do you have an idea that feels like it tackles measurements from a different perspective and you'd expect to see in optimizing
level?
I really like the direction @krumware went as that is very user focused and focuses on the fact that platforms are an intersection of many different systems and teams. And that effective platforms handle that intersection with grace. IMO the highlighted statements are pointing at the fact that a platform is a service. And as such the platform needs to both provide its operators with enough data to support it, as well as expose its users enough data to be successful.
I think that these particular sentences focus on the measuring platform builders are doing of their own product. And when these platform builders reach the optimizing
level, they are aware that their measurements can leverage common frameworks while also realising that any one measurement, or even framework, can create the wrong incentives so it is important to balance measurements. Worth noting, many of the points made in this model can be applied to any software application and this is no different. If you have ever worked on a team that is lazer focused on only following SAFe or only following XP or only following DORA metrics, you will notice that there are blinders on that could be improved by a more balanced measurement plan.
In https://github.com/cncf/tag-app-delivery/blob/72da56c7ff0e41f2ea0ffdab38ca8640f3326d54/platforms-maturity-model/v1/index.md?plain=1#L479 there are two sentences which I would like to discuss:
To be honest, I am not sure if I really understand those things correctly. Does someone have a deeper explanation or examples in the context of platform engineering measurement?