# How I like to do operationalization documentation

# 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.