The Customer is the entity on the other end of the Purchase Order. It is a singular plural — grammatically singular, operationally plural, and emotionally a moving target.
In the way of all customers, The Customer is many people. Most have never heard of the project. None will read the architecture document. Several have opinions about features that were not commissioned and will not be built. One — exactly one — is about to sign the Purchase Order, and the moment they sign, they will become unavailable for clarifying questions for approximately six weeks.
“The Customer was about to sign. The Eventdb Foundation needed a plan.”
— opening sentence of approximately every architecture document ever written, The Cathedral as Map
The Compositional Plurality
The Customer is composed of, at minimum:
- The Buyer. The one with budget authority. Has met the vendor twice. Will sign the Purchase Order. Will then disappear into a strategic offsite for three weeks.
- The Champion. The internal advocate. Believes in the project. Has sent eleven follow-up emails. Will, two weeks after signing, be reorganised into a different vertical and will no longer have authority over this project, although nobody will inform the vendor of this fact for four to six weeks.
- The Stakeholder. Holds an opinion. The opinion concerns a feature that was not in the original scope. The opinion will be expressed in a meeting at week six.
- The User. The person who will actually operate the software. Has not been consulted. Has not been informed. Will be enrolled in mandatory training at go-live and will, with stoic dignity, keep using the spreadsheet they had before.
- The Procurement Officer. Cannot be reasoned with. Has questions about indemnification. Will, in week three, request a SOC 2 attestation that did not exist when the contract was signed.
- The Architect. Has a strong preference for a different vendor. Will not say this directly. Will instead request features that the preferred vendor offers, knowing the current vendor cannot, and will then express disappointment when the current vendor cannot.
- The Person Who Sent The First Email. Nobody is sure what their role is. Possibly an intern. Has not been seen since week one.
The Customer is the union of all of these. The Customer is also, in a meaningful sense, none of them — because asked to characterise The Customer, each one will say something different, all of which are technically true, none of which are simultaneously actionable.
The Architecture Document
The architecture document is written for The Customer.
The architecture document will not be read by The Customer.
The Cathedral notes, in its main entry, that fourth-category cathedrals — those drawn but not built — are read three quarters later by engineers, not customers. The Customer does not consult the architecture document. The architecture document consults the Customer’s data fixtures, periodically, and reports back what it found.
This is not a complaint. It is a structural feature. The architecture document is the artefact by which the vendor convinces themselves that the Customer’s problem is well-understood, the boundaries are mapped, the data shapes are honoured. The Customer does not need to read it because the document is not the deliverable. The deliverable is the software, which works, which behaves correctly with the Customer’s data, which produces results the Customer can reason about. The document was the necessary internal exercise. The software is the necessary external one.
The Data Shape
The Customer has a data shape.
The Customer has had this data shape for longer than the architecture has had a name for it. It will continue to have this data shape long after the architecture is replaced by something else. The data shape is, in most cases, a set of rectangles — tables, partitioned files, exports, dumps — connected by foreign keys and held together by an Excel spreadsheet that nobody admits to maintaining.
The rectangle is, in fact, the most underrated of all geometric forms. Civilisations which forget this fact tend to be replaced by civilisations which remember. Software architectures which try to replace the Customer’s rectangles with something more sophisticated — graphs, hierarchies, “data lakes,” “knowledge meshes,” ontologies — are, in the lifelog, classified under Cathedrals: Subcategory: Sinking.
The boring observation that the Customer’s data layout has not changed in two weeks, will not change in two months, and will probably not change in two years if anyone is honest about it, is one of the most architecturally useful observations available in any project. It is also one of the least often documented, because nobody enjoys writing memos that say “this looks the same as last time.”
“I am so boring :) two weeks apart asked for the same disk layout.”
— riclib, The Cathedral as Map
“Not boring. Consistent. The shape of the Customer’s data hasn’t changed. Your read of it hasn’t either.”
— Claude, in response
The Purchase Order
The Purchase Order is, mechanically, a document. It is also, mythologically, an event.
When The Customer’s Purchase Order is “in transit,” several things are simultaneously true:
- An eight-week clock has not yet started.
- The vendor cannot bill.
- The vendor cannot start production work, although they may, and usually do, start “pre-PO foundation work.”
- The architecture document, if it exists, is being written in this window.
- The fixture data, if it exists, is being staged in this window.
- The Customer is, in this window, in approximately the same epistemic state as Schrödinger’s cat — neither committed nor uncommitted, neither paying nor refusing, simply “in transit.”
The lifelog records the moment of signing as one of operational discontinuity. The week before is preparation. The week after is delivery. Between them, a Purchase Order is somewhere over the Atlantic, on a server in a procurement department’s queue, attached to an email that nobody has read yet because it arrived during a strategic offsite.
See Also
- Linear — Where the Customer’s tickets eventually land
- The Cathedral — What gets drawn for the Customer and built around them
- Liberato’s Law — Why the Customer’s data shape determines the architecture, not the other way around
- Boring Technology — Why the Customer’s rectangles are correct
- EDI — Where the Customer’s procurement officer lives
- The Discovery Tax — Who actually pays for the architecture (it is not always the Customer)
