The six habits of the drafting desk

Hartvigsen Roberts Technologies LLC works from 1222 E 2850 N, North Ogden - 84414-3409, United States (US), and drafts computer integrated systems for organisations that need a system explained before it is installed. The desk does not sell hardware and does not run nightly operations. It draws a structure, reviews the loads on that structure and hands over a sheet that a build team can follow with confidence.

The six services below are the habits that produce that sheet. Each one can be booked on its own or combined into a full drafting program. Read the description for each habit, then choose the combination that fits your project.

Spec Sheet Bays

Most systems arrive at the desk in a state of friendly chaos. There is a network diagram from a contractor who has since retired, a software licence that nobody can locate, and a switch that is documented in three different places under two different model numbers. The spec sheet bay collects all of that into one controlled folder, and each line in the folder names the fact, the source, the date and the owner. When two sources disagree, the bay records the disagreement rather than hiding it.

A bay is organised in sections: hardware, network, software, dependencies and ownership. Hardware lines record models, serial ranges and support status. Network lines record addressing, paths and failover behaviour. Software lines record versions, licence tiers and renewal dates. Dependency lines record which other systems would feel a change. Ownership lines name the person who can approve a change to each of the above.

Over an engagement the bay becomes the first place a build team looks. When a vendor proposes a substitution, the bay shows whether the substitution matches the required baseline. When a project manager asks who owns a component, the bay gives a name. A well built bay removes hours of meetings, because the facts sit in one place and carry their own provenance.

Truss Drawing Runs

A truss drawing run turns the facts from the bay into a structure. The drawing uses the language of a physical truss: members are the components that carry load, joints are the contracts between them, and gussets are the agreements that keep a joint from buckling. The result is a diagram in which a weak point is visible at a glance rather than discovered under production traffic.

Each run begins with a load schedule. A user facing portal might rest on an identity service, a database cluster and a message queue, and each of those rests on further supports. The desk draws the whole path and marks the members that carry more than one dependent system. A member carrying several dependents is a candidate for redundancy, and the drawing shows the cost of leaving it unsupported.

The run is issued as a numbered sheet with a revision mark. A late change in vendor terms triggers a revised sheet rather than a scribble in the margin. By the end of the run the client holds a drawing that explains the system to an engineer, to a procurement officer and to a board member in the same document, because each of them can read the structure without needing the jargon.

Integration Letter Desks

Integration letters carry the agreements that sit between organisations. A vendor confirms that an interface will accept a specific format. A contractor confirms a delivery window. An internal team confirms that it will staff a cutover. In almost every project these confirmations live in email threads, and almost every project loses track of who agreed to what.

The integration letter desk drafts each letter in plain sentences. The letter names the interface, the parties at each end, the condition that makes the agreement valid and the consequence if a condition slips. A reference number ties the letter to the drawing so the two documents cannot drift apart. The desk writes every letter twice over a project: once when the agreement is proposed and again when the agreement is confirmed.

The desk also keeps a register of open letters. A build team can see which vendor confirmations are outstanding before it commits resources, which removes the surprise that arrives late in a project when a critical interface was never actually agreed. Every letter is signed off by the named owner at each end, and the register is issued alongside the final drawing.

Design Windows

A design window is a booked block of drafting time reserved for one system. The client brings the rough shape of the problem, the desk brings the drafting board, and the window ends with a marked drawing, a cost frame and a list of open questions. Most windows run two to four hours, and most clients find that a single well run window removes a fortnight of scattered decisions.

A window starts with a short framing conversation. What is the system for, who depends on it and what would make the project a success? The desk then drafts the truss live, with the client watching, so the client can correct a fact while the pencil is still moving. Questions that cannot be answered in the room are written as marks on the sheet rather than left as vague worries.

The deliverable from a window is a one page drawing, a one page cost frame and a marked question list. A client can take those three pages to a builder and receive a defensible quotation for the first time. If the project continues, the window output becomes the first revision of the fuller drafting program, so nothing drafted in the window is wasted.

Load Review Rounds

A load review round tests the drawing against the pressure the system will actually meet. Volume, latency, staffing and budget all act as loads on the truss, and a design that ignores any of them will bend in a way that the drawing did not predict. The review round brings each load onto the sheet and asks whether the member that carries it can bear the weight.

Volume load looks at the peak events that the system must survive, not the average day. Latency load looks at the paths where a delay compounds across several members. Staffing load asks whether the team that will operate the system has the skill to maintain each joint. Budget load asks whether the supports proposed are affordable across the life of the asset rather than only at build time.

Findings are written as short numbered notes. Each note states the member, the load, the observed risk and the recommended support. The notes are issued in priority order so the client can act on the most serious ones first. A review round does not rebuild the system; it marks the drawing and tells the client where the strongest action is needed.

Draft Sittings

A draft sitting puts the client at the drawing board. For a couple of hours the client and the desk edit the drawing together, updating facts, moving members and clearing marks. The sitting is the point at which the client stops being a reviewer of someone else work and becomes the owner of the sheet.

A sitting usually closes a phase. The open questions from earlier windows are answered, the outstanding integration letters are confirmed, and the load review findings are either accepted or explained. The desk records the changes live so the client leaves with a revised drawing and a change log. Every member on the final sheet has a named owner and a date.

A draft sitting is also the most efficient way to brief a build team. When the build lead sits in the room, the questions that would otherwise appear a month into the build are answered before the first ticket is opened. The signed sheet at the end of the sitting is the authority the build team needs to proceed.