Should deployer tree replace Utility with Automatable?

[j---]

Should the suggested deployer tree only care about Automatable? Rather that Utility, which includes automatable but also Value Density. My thinking is that Mission Impact stands in for the distribution of vulnerable components in the deployer's purview.

[j---]

This has a dependency on #180 in the sense that we need to be able to express versioning before we do this. This change would represent a new recommended deployer tree, which should bump the minor version number.

Will create a project identifying what open issues can be bundled together for version 2.1

[ahouseholder]

Converted to a discussion so we can have the conversation and decide what (if anything) is to be done. We can spawn new issues once this discussion resolves.

[j---]

I think the deployer tree is too complex / too many items for getting down to 4 outcomes. Unless there is someone with a strong argument to keep value density in the deployer tree, I think it should be removed. A strong argument could include removing something else instead.

[ahouseholder]

While I have no strong opinion on "too complex/too many items" in this case, I do agree that Value Density as part of Utility is better suited to or assumes a higher abstraction decision-maker (e.g., a supplier or coordinator) who has fuzzy or incomplete knowledge of deployment contexts and therefore needs to make a proxy judgement on potential impact. Such a stakeholder likely has a meaningful value gradient between diffuse (more likely to be noisy, slower, or otherwise more opportunity to detect) and concentrated (more likely to be quick, thorough, and difficult to observe).

In situations (like the deployer stakeholder) where we expect Mission Impact to be discernible, then it pairs more orthogonally with Automatable. In that context, the information added by Value Density is mainly about the effort required to deploy mitigations or fixes, but there's not even necessarily a strong ordering to diffuse vs concentrated from the deployer's perspective. Because assuming the literal patch installation is mostly automated/low transaction cost, most of the effort is going into testing the patch before deployment. And you aren't likely going to want to touch either of (a) all the machines, i.e., diffuse, or (b) your crown jewel ERP database (concentrated) without doing some work to make sure you're not breaking the organization by doing so.

So unless there's another perspective we haven't hit on yet in favor of keeping Value Density in the Deployer tree, I'm in favor of removing it and replacing it with Automatable, and adjusting the tree as needed.

[ahouseholder]

Closing discussion as resolved. See #238 for follow-on task.