Reading the whiteboard

Saturday afternoon, the office quiet, the freeze holding. Finn stands at the wall diagram with a fresh coffee and reads the whole thing, top to bottom, the way you walk a course the day before you race it.

What the wall shows is Traversal’s system architectureConcept · lights on your mapsystem architectureA system’s high-level structure: its major parts, the responsibilities assigned to each, and how they interact. The organisation above the source code, not the code itself.: the major parts, what each is responsible for, and how they talk. Not the code. The shape above the code, the thing this story has been assembling in your head since a chip crossed a mat. The wall is its formal portrait: an architecture diagramConcept · lights on your maparchitecture diagramA visual representation of an architecture: boxes, arrows, labels, and boundaries at a chosen level of detail. A simplified view made for a purpose, so the first question is always what it is trying to explain., boxes and arrows at a chosen level of squint. The first question to ask of any such diagram is the one Finn taught Dana years ago: what is this drawing trying to explain? This one explains race day, and it leaves out everything that does not fail on a Sunday.

Reading the boxes

Most boxes on the wall are a serviceConcept · lights on your mapserviceA component that provides a capability to the rest of the system through a defined interface, often running as its own deployed application. Every service is a component; not every component rises to being a service.: a component grown up, deployed on its own, offering its capability through a defined interface. Registration is one. Results is one. The projection service that met the crowd dial on Wednesday night is one, with fresh headroom pencilled beside it. Component was Act 0’s word — service is the same idea wearing its own pager.

And the arrows are the part amateurs skip. Following one piece of information through the boxes, where it enters, what transforms it, where it rests, what returns, is tracing the data flowConcept · lights on your mapdata flowThe path information takes as it moves through a system. To trace it is to follow one piece of data from entry, through the components that receive, transform and store it, to whatever returns., and it is the single most useful thing a non-engineer can do with a whiteboard. Finn does it now, with a finger, for one split: mat, ingest, queue, workers, results, notification, Molly’s phone. The mat’s half-second, drawn as furniture. You have been scrubbing this diagram since Act 0 without being told it was one.

One box on the wall is older than the others and drawn with a thicker marker, as if the wall itself were being careful around it. Its story is next.