Royal Army College

Lesson Overview

A small force that runs its own digital estate faces a quiet, chronic danger that has nothing to do with attackers: that its systems exist only in the heads and habits of one or two people, set up by hand, undocumented, and impossible for anyone else to understand, reproduce, or recover. When those few people are tired, busy, away, or gone, the estate becomes a mystery no one can safely touch, and a single failure or departure can cripple it. This lesson is about the disciplines that defeat that danger: documentation, writing down how the systems are built and run so the knowledge does not live only in someone's head; automation, having machines perform setup and tasks consistently rather than by error-prone hand; and reproducibility, building systems so they can be re-created reliably from their definitions rather than nursed as irreplaceable hand-made things. Together these turn an estate from a fragile, personal, hand-built mystery into a documented, automated, reproducible system that a small team can sustain, hand over, and recover. For a small force especially, they are not sophistication but survival.

The governing idea is that a small force cannot afford systems that only one person understands, so it writes them down, automates them, and makes them reproducible. A large organisation can absorb the loss of an administrator or the mystery of a hand-built server, having others who know and spare capacity to relearn; a small force, with one or two people holding the whole estate, cannot, and an undocumented, hand-built, irreproducible estate is for it a standing crisis waiting to happen, where one person's absence or one host's failure brings down what no one else can rebuild. The disciplines of this lesson are the answer: documented, so the knowledge survives the person; automated, so setup is consistent and not dependent on a person's careful hands each time; reproducible, so a system can be rebuilt exactly from its definition rather than reconstructed from memory. These are what make a small force's estate robust against the loss of people and the failure of machines, which is much of what robustness means for a small force. The member who builds and runs systems by these disciplines makes the estate sustainable; one who hand-builds undocumented mysteries makes it fragile.

This is the knowledge layer; the practice is done under those who administer the estate, with elevated access following appointment (Lesson 10). It reflects the reality of running a small, self-hosted estate sustainably, and is wholly defensive. Read this to understand the disciplines; the practice comes under guidance.

By the end you will be able to explain why undocumented, hand-built systems are a chronic danger to a small force, document systems so the knowledge survives the person, use automation to make setup consistent and repeatable, build reproducible systems that can be re-created from their definitions, and explain how these disciplines make an estate sustainable, handable-over, and recoverable.

Key Terms

Documentation: the written record of how systems are built, configured, and run, so the knowledge does not live only in people's heads.
Automation: having machines perform setup and repetitive tasks consistently and repeatably, rather than relying on error-prone manual work each time.
Reproducibility: the property that a system can be re-created reliably from its definition, rather than existing only as an irreplaceable hand-made thing.
Bus factor: the number of people whose loss would cripple an estate; a bus factor of one, where only one person understands the systems, is a standing crisis.
Tribal knowledge: undocumented knowledge that lives only in people's heads and habits, lost when they are unavailable or leave.
Runbook: documented, step-by-step instructions for a routine or emergency task, so it can be done correctly by someone other than its author.
Infrastructure as code: defining systems and their configuration in written, version-controlled files, so the estate is built from definitions rather than by hand.
Version control: the disciplined tracking of changes to definitions and documentation over time, so history is kept and changes are reviewable and reversible.
Manual error: a mistake made in hand-performed work, which automation reduces by performing tasks the same way every time.
Handover: the passing of an estate or system to others, made possible by documentation and reproducibility, fragile or impossible without them.

The danger of systems only one person understands

The chronic danger this lesson defeats is not an attacker but a structural fragility peculiar to small teams: that the estate exists only as tribal knowledge, undocumented, hand-built, living only in the heads and habits of the one or two people who made it. Such an estate works, often well, as long as those people are present, healthy, and remembering, but it has a hidden, standing weakness: it cannot survive their loss. If the person who built the systems is tired and makes a mistake, busy and unavailable when something breaks, away when a problem strikes, or simply gone, the estate becomes a mystery that no one else can safely understand, change, reproduce, or recover, and a single absence or departure can leave a small force unable to run or fix its own statehood. This is the danger of the bus factor of one: when the loss of a single person would cripple the estate, the estate is in a standing crisis that nothing but luck is holding off.

This fragility is far more dangerous to a small force than to a large one, which is why the disciplines matter so much here. A large organisation has many administrators, overlapping knowledge, written procedures, and spare capacity to relearn a mystery; the loss of one person is absorbed. A small force, with the whole estate in one or two heads, has none of that cushion, so the undocumented hand-built estate that a large organisation would merely frown on is, for a small force, a genuine and standing threat to its ability to function. The very thinness that makes a small force efficient, a few people running everything, is what makes the loss of any of them, or the mystery of what they built, so dangerous, and it is precisely why a small force must work hardest at the disciplines that defeat the fragility.

The disciplines that defeat it are the three this lesson teaches, each attacking the fragility from a different angle. Documentation ensures the knowledge survives the person, so the estate is not a mystery when its builder is gone. Automation ensures setup is consistent and not dependent on a person's careful hands each time, reducing both error and the reliance on tribal skill. Reproducibility ensures systems can be rebuilt from their definitions, so a failure is recoverable by anyone, not only by the one who hand-made the original. Together they convert a fragile, personal estate into a robust, shared, reproducible one, which is what a small force needs to survive the loss of people and machines alike.

Documentation: the knowledge that survives the person

Documentation, writing down how the systems are built, configured, and run, is the most basic of the three disciplines and the one most often neglected, because it feels like overhead to people who already know how everything works. But that very feeling is the trap: the knowledge that is obvious to its holder is exactly what is lost when the holder is unavailable, so documentation's whole value is to make the estate understandable by someone other than the person who built it, including the builder's own future self, who will have forgotten. Good documentation turns tribal knowledge into shared knowledge that survives the person, which is the first defence against the bus-factor fragility.

Useful documentation has a few forms and qualities. It records how the systems are built and configured, so another person can understand the estate, what runs where, how it is set up, why it is as it is. It includes runbooks, step-by-step instructions for routine and emergency tasks, so that a task, restarting a service, restoring a backup, responding to a failure, can be done correctly by someone other than its author, which is critical for the emergencies that strike when the expert is unavailable. And it is kept current, because documentation that has drifted out of date is worse than none, misleading the reader into acting on a system that no longer matches the description; so documentation is updated as the systems change, ideally as part of making the change. The discipline is to document as you build and change, not "later" (which never comes), so the written record stays a true map of the estate.

For a small force, even modest documentation transforms the estate's robustness. A written record of how the systems are built, a set of runbooks for the routine and emergency tasks, kept reasonably current, means that when the one expert is away or gone, the estate is not a mystery: another member can understand it, run it, and recover it from the documentation. This is not bureaucracy but survival, the difference between an estate that depends on one person's continuous presence and one that can be sustained and handed over. The member who documents as they go gives the small force an estate that survives its people; the one who keeps it all in their head leaves a mystery that dies with their availability.

Automation and reproducibility: building from definitions

The second and third disciplines, automation and reproducibility, go together and attack the fragility more deeply, by changing how systems are built and run. Automation means having machines perform setup and repetitive tasks consistently, rather than relying on a person to do them correctly by hand each time. Hand-performed setup is slow, inconsistent, and prone to manual error, the missed step, the typo, the thing done differently this time, and it ties the estate to the person who knows how to do it; automation performs the task the same way every time, faster, without the manual errors, and without depending on a particular person's careful hands. Automating the setup and the routine tasks of the estate thus both reduces error and breaks the dependence on tribal skill, because the automation, not a person's memory, holds the knowledge of how the task is done.

Reproducibility is the deeper property automation enables: building systems so they can be re-created reliably from their definitions, rather than existing as irreplaceable hand-made things. The key practice is infrastructure as code: defining systems and their configuration in written, version-controlled files, so that the estate is built from these definitions, automatically, rather than hand-assembled. When a system is defined as code, it can be rebuilt exactly from that definition by anyone, the definition is the system's recipe, so the system is no longer a unique hand-made artifact that only its maker understands but a reproducible thing anyone can re-create from its written definition. This is the same repeatability that containers gave (Lesson 07), extended to the whole estate: systems defined, not hand-built, and therefore reproducible.

The benefits for a small force are exactly what it needs. Reproducible, code-defined systems are recoverable: a failed system can be rebuilt from its definition rather than reconstructed from memory, which, with the backups of Lesson 05, is much of what makes recovery on a bad day feasible. They are consistent: every system built from the same definition is the same, ending the drift and divergence of hand-built systems. They are handable-over and shareable: the definition is the knowledge, written and transferable, so the estate does not live only in one person's head. And version control, tracking changes to the definitions and documentation over time, keeps a reviewable, reversible history, so changes are deliberate and recoverable rather than untracked and mysterious. Together, automation and reproducibility turn the estate from a collection of hand-made mysteries into a set of definitions from which the systems are reliably built, which is robust against the loss of both people and machines.

   DEFEATING THE FRAGILITY OF A SMALL ESTATE  (loss of people OR machines)

   THE DANGER     estate exists only in 1-2 people's heads, hand-built,
                  undocumented -> a BUS FACTOR OF ONE: one absence/departure
                  or one host failure cripples it. Far worse for a SMALL force.

   DOCUMENTATION  write down how systems are built/run + RUNBOOKS for tasks;
                  keep current -> knowledge SURVIVES THE PERSON
   AUTOMATION     machines do setup/tasks the SAME way every time -> less
                  manual error, no dependence on one person's careful hands
   REPRODUCIBILITY systems built from DEFINITIONS (infrastructure as code,
                  version-controlled) -> rebuilt exactly from the definition
                  by ANYONE; recoverable, consistent, handable-over

   For a small force these aren't sophistication, they're SURVIVAL.

Why this is survival, not sophistication, for a small force

It is worth stating plainly why these disciplines, which can seem like the over-engineering of a large IT department, are for a small force the opposite: not luxury but necessity. The reasoning is the bus-factor one, taken seriously. A small force's estate is held by very few people, so the loss of any of them, to fatigue, absence, departure, or worse, is a real and ever-present risk, and an estate that cannot survive that loss is a crisis waiting for the loss to happen. The disciplines of this lesson are exactly what let the estate survive it: documented, so the knowledge does not leave with the person; automated and reproducible, so the systems can be rebuilt and run by others from their definitions. They are, precisely, what make a thin-staffed estate robust rather than fragile, which is why a small force needs them more than a large one, not less, despite the temptation to think it cannot afford the effort.

The same disciplines also serve the recovery and continuity the course has stressed throughout. An estate that is documented, automated, and reproducible is one that can be recovered on a bad day, the systems rebuilt from their definitions and the procedures followed from the runbooks, which is the practical content of the continuity that Lesson 05 and the incident-response course care about. Fragile, hand-built, undocumented estates are exactly the ones that cannot be recovered when their maker is unavailable; robust, reproducible ones can be. So the documentation, automation, and reproducibility that defeat the bus-factor fragility are the same disciplines that make recovery feasible, which is why they sit at the heart of running a small force's systems sustainably.

The member's part is to build and run systems by these disciplines as a matter of course: documenting as they build, automating the setup and routine tasks, defining systems as reproducible code under version control, and keeping it all current, so that the systems they touch are not added to the pile of hand-made mysteries but become part of a documented, reproducible estate that survives them. This is, in the end, what professionalism looks like for those who run a small force's systems: not heroic hand-built cleverness that only they understand, which is fragility dressed as skill, but the disciplined creation of systems that others can understand, reproduce, and recover, which is what actually keeps a small, self-hosted Principality's estate alive over time. Documentation, automation, and reproducibility are how a few capable members run an estate robustly, which is the whole aim of this course.

In Practice: The Estate That Survived Its Builder

A member of the Royal Kaharagian Army studies two ways the Principality's systems might be run, and sees why one is fragile and one robust, the difference being entirely the disciplines of this lesson. In both, a few capable people run the estate; the difference is whether the estate exists only in their heads or in documentation and definitions that survive them.

In the fragile way, the estate is hand-built and undocumented: the one or two people who made it know how everything works, but nothing is written down, the setup was done by hand and differently each time, and the systems are irreplaceable hand-made things only their maker understands. It works, until the maker is tired, busy, away, or gone, and then the estate becomes a mystery no one else can safely run, change, or recover, a bus factor of one that puts the Principality's digital substance one absence away from crisis. A single host failure, with no reproducible definition to rebuild from, or a single departure, with no documentation to learn from, could cripple what no one else can reconstruct.

In the robust way, the same few people run the estate by the disciplines of this lesson. They document as they build, recording how the systems are configured and writing runbooks for the routine and emergency tasks, kept current, so the knowledge survives the person. They automate the setup and routine tasks, so they are done the same way every time without manual error and without depending on one person's hands. And they build the systems as reproducible definitions, infrastructure as code under version control, so each system can be rebuilt exactly from its definition by anyone, not nursed as a hand-made original. So when the builder is away, or a host fails, the estate is not a mystery and not lost: another member understands it from the documentation, the systems are rebuilt from their definitions, and the force runs and recovers its own statehood without depending on one person's continuous presence. The robust estate survives the loss of people and machines because it was built to; the fragile one does not. For a small force, that difference is not sophistication but survival, which is the whole point of this lesson.

Check Your Understanding

Explain the chronic danger of an estate that exists only as tribal knowledge in one or two people's heads (the bus factor of one), and why this fragility is far more dangerous to a small force than to a large one. What three disciplines defeat it?
Explain why documentation is so often neglected yet so valuable, its forms (how systems are built and configured, runbooks) and the need to keep it current, and how it makes the estate understandable by someone other than its builder.
Explain automation (machines doing tasks consistently, reducing manual error and dependence on tribal skill) and reproducibility (systems built from version-controlled definitions, infrastructure as code, so they can be rebuilt exactly by anyone), and why together they make a small force's estate recoverable, consistent, and handable-over, "survival, not sophistication."

Reflection (write a short paragraph): This lesson argues that for a small force, heroic hand-built cleverness that only its maker understands is "fragility dressed as skill," while the disciplined creation of systems others can understand, reproduce, and recover is what actually keeps the estate alive. Why might it be tempting, even satisfying, to be the one person who understands the systems, and why is that exactly the wrong thing for a small force? Think about a piece of knowledge or a system that, in some group you have been part of, lived in only one person's head: what happened, or could have happened, when they were unavailable, and how would documentation, automation, and reproducibility have changed it?

Summary

A small force faces a chronic, structural danger: that its estate exists only as tribal knowledge in one or two people's heads, hand-built and undocumented, so the bus factor of one means a single absence, departure, or host failure can cripple what no one else can run or rebuild. This fragility is far worse for a small force, which lacks the cushion of many administrators and spare capacity.
Documentation records how systems are built, configured, and run, including runbooks for routine and emergency tasks, kept current, so the knowledge survives the person and the estate is understandable by someone other than its builder. It is neglected because it feels like overhead to those who already know, which is exactly the trap.
Automation has machines perform setup and tasks consistently, reducing manual error and the dependence on one person's careful hands. Reproducibility builds systems from version-controlled definitions (infrastructure as code), so they can be rebuilt exactly by anyone rather than nursed as hand-made originals, with version control keeping a reviewable, reversible history.
Together these make a small force's estate recoverable (rebuilt from definitions and runbooks on a bad day), consistent, and handable-over, robust against the loss of both people and machines. For a small force they are survival, not sophistication, needed more than by a large one, and they are the same disciplines that make recovery and continuity feasible.
The member's professionalism is to build and run systems by these disciplines as a matter of course, documenting, automating, and defining as reproducible code, rather than adding hand-made mysteries, so the estate survives them.
This is the knowledge layer; the practice is done under those who administer the estate, with elevated access following appointment (Lesson 10). The lesson extends the repeatability of Lesson 07 to the whole estate, sustains the configuration of Lesson 08 against drift, underpins the recovery of Lesson 05 and CIS 310, and is what lets the few capable members this course builds run a small force's systems robustly. Everything here is defensive.

Documentation, Automation, and Reproducible Systems