Operational Assurance

Software systems are designed around capabilities that are the focus of the system.

Human factors, automation factors, usability, these are all controllers of systems that focus on sets of capabilities. Starting with that focus and decomposing into components, gives rise to the OA Circuit.

How many times have you been in a meeting and someone said "I didn't know my change would affect that capability?"

Change one component and that change ripples up to the focus

Quantifying isn't enough for metrics, they need to be proven. OA defines proofs for metrics to verify the provenance of reported quality metrics.

Cross discipline experience creates the languae of cooperation.

Systems are not just software, they are hardware, cryptographic elements, humans, and AI. The numbers are the key to measuring software and systems quality and raising visibility. Being able to monitor the metrics and prove their provenance is the cornerstone of success in [OA].

Would you hike without a map?

No plan can survive contact with a contested arena, but without a plan, no system can survive the rigors of user interactions. The OA Plan is the collection of the OA artifacts, the Focus, Metrics, Circuits, and the Arena. Documentation is helpful, but a living document that responds to operator interaction, now that's a plan that can survive.

always contested and dynamic

The arena is where the system meets the operator. Whether automated or human, the operator will put the system through a rigor that typically defies prediction. Having a complete decomposition of focus capabilities, the system can adequately quantify operator interactions and convey defects to software.