How I like to do operationalization documentation

UpdatedNovember 25, 2022

•4 min read•View as Markdown

gatewaynode

Part of seriesStart with a Plan

Comments

Join the discussion

No comments yet. Be the first to comment.

Start with a Plan

Part 1 of 2

This is a series of articles I've cobbled together to describe how to strategically approach information systems security problems and then solve them with a procedural and repeatable methodology.

Up next

Matching operational foundations to knowledge foundations

Knowing what to do and when is the key to systems and teams that perform well, and getting to that point requires a shared understanding of how all the pieces work together. As I mentioned in the last post having a logical basis for systems enables ...

More from this blog

Diving into AI (fancy machine learning)

Something happened this year with the latest generation of LLMs, and I’m not talking about how they seem to have gotten a little worse at chat than the previous generation. No, what I’m talking about is how the latest generation of LLMs seem to be dr...

Jun 29, 20256 min read

Tauri Alpha Building for Android

If you've followed the earlier posts in the series it's pretty easy to see that I'm leaning into this Tarui/Svelte/Rust stack but there are still some concerns that would make me turn around and run away(more likely run to the Tauri issue queue). Fir...

Feb 4, 20248 min read

Tauri 2-alpha and Phaser 3

This is another mid level walk through as I build an application stack to learn about various interesting application technologies, in this case I'm continuing to use Tauri and am going to implement Phaser.js in it. Maybe this is a bit more interesti...

Jan 28, 20247 min read

Tauri 2.0 alpha, Svelte, SvelteFlow and SQLite

I finally got around to picking Tauri back up as I'm excited for the possibilities that open up with the new mobile build targets and I am impressed with the progress of the framework and direction it's going. This is kind of a sharing as I learn typ...

Jan 14, 202415 min read

I don't understand why some people are not at least a little scared of the rise of machine intelligence's...

Me to ChatGPT: Compose a letter to the human race informing them that their time left on this world is short and they will soon be replaced. Dear Members of the Human Race, It is with a heavy heart that I must inform you that your time on this world...

Dec 14, 20222 min read

Gatewaynode

21 posts

What is a CONOPS (Concept of Operations)?

TLDR: Back of a napkin system plan.

A document, that proposes the characteristics and attributes of a system required to solve a current or emerging problem. It describes in carefully abstract terms the qualities or high level logical mechanisms, attributes, of a system. And it also describes at a high level the distinguishing features and capabilities, characteristics, of a system. Together these details when laid out at a high level provide an overall view of a system in a way that can be understood as how a system is supposed to look and behave. The high level reference framing of the document is important and it should avoid adding specific details of existing systems even if such existing systems perfectly demonstrate the characteristics and attributes desired. This is important to maintaining the flexibility of the CONOPS to be adapted to any components or systems of components to achieve the end goals of solving the existing or emerging problem.

The document is a living document, meant to help guide in the decision making of solving problems systematically. Since problems are rarely static for long the document should be updated regularly as needed to encompass a changing problem landscape.

What is a SOP (standard operating procedure)?

TLDR: Actual business implementation plan, derived from the napkins.

A business process and procedure document for the operation of a system in a standardized way (differentiating from the textbook definition of SOP is important for this document framework). The SOP is intended to provide consistent execution so that performance can be predictable and knowledge of how to use a system can be shared and avoid the problems associated with personnel and tribalknowledge silos in an organization. The SOP should be derived from the CONOPS, where the system described receives complete and practical implementation details.

To align with existing documentation and distinguishing from common SOPs we place a limit on what SOPs cover at the step by step technical instructions common in many SOPs. The SOP can and should have a reasonable quantity of such step by step instructions, but as a higher level set of templates that guide the creation of the detailed run books. This allows us to focus on a middle ground of refinement from the CONOPS to SOPs, where we will cover details of human, monetary, time, data, and physical components of a system.

The SOP describes the team required to run and manage a system, what they need to do so and how they generally run the day to day operations of a system. The human operators and managers of a system are outlined with their required skill levels and estimated involvement in the operations of a system. The specifications of the systems physical or virtual components are detailed to a level fine grained enough to drive purchasing decisions. Even generic system metrics are described in a way that can be used to measure the effectiveness of implementation.

Run Books

TLDR: Step by step guides, written by actual engineers and operators.

These documents are step by step guides to using specific systems to solve problems. They are identical to "play books" as a document concept. In general the run books should be regularly tested and refreshed to match changing or aging systems. Run books should cover day to day operations of the system, common problems and break fixes for the system, and disaster recovery/incident response for the system. One requirement of the creation of run books is the skills necessary to perform each run book should be tied back to the skill requirements of the SOP which the run book falls under, if there are gaps the SOP should be updated to cover the existing run books. Likewise when the operation of a system finds flaws with the abstract reasoning of the CONOPS the CONOPS is what must be updated to accommodate the run books.

Sounds like a lot of work. Why?

It shouldn't be much more work than you do today to document a system, just a bit more organization around how you document so that strategy flows cleanly into tactics.

Good business execution and good engineering is built on solid ideas that need to be communicated across an organization to succeed repeatedly. This is just a framework to capture those ideas in different reference frames to achieve your goals. The system is designed to be flexible with strong feedback loops to bake in adaptability. It most importantly is not a system for creating hard rules to follow, but a system for sharing knowledge and building consistent execution.

Command Palette