Sometimes the useful thing I make first is not the final product at all.
It is a representation: a timeline, a schema, a project map, a content model, a source register, a prototype, a set of states or a diagram that makes two previously separate processes visible in the same place.
That representation matters because complicated work is often difficult long before it is technically difficult. People are acting on different versions of the same situation. Important relationships exist, but only implicitly. Decisions are being made against structures nobody can quite see.
A hotel is not a collection of screens
In Trigger SMARTS, the visible product is digital signage for hotels and conference venues.
If you start from the screen, the problem seems to be displaying some text attractively. But a screen is only the end of the chain.
The useful structure is the relationship between hotels, rooms, clients, bookings or events, display types and directions through a physical venue. A single booking can use several rooms. A lobby display needs different information from a room sign. Staff need to update operational information without becoming system administrators. A room name is not merely a string if it is tied to how people navigate a building.
Once those relationships are explicit, the interface becomes easier to reason about because it is representing a domain rather than decorating a screen.
A book catalogue is not a list of books
The Richard Craven publishing work began with recognisable publishing activity: manuscripts, editing, proofing, production, covers, metadata and publication.
As the catalogue expanded, however, the unit of work stopped being only the book.
Characters recur. Places connect works. Terms accumulate meanings. Events have chronology. Later books can alter how earlier material is understood. Editorial notes and source passages matter because a summary on its own is not enough to establish what the text actually says.
That creates a different kind of structure: works, editions, characters, places, glossary terms, events, evidence, candidate interpretations and accepted editorial state.
The technical model is useful only if it respects those editorial distinctions.
An organisation is also a system
At IMLPO, there was no single software product to model.
The structure was organisational: members, subscriptions, payments, communications, events, suppliers, website systems, account ownership and responsibility.
Much of that structure was partly formal and partly tacit. The handover I produced at the end of the role mattered because it made enough of those dependencies visible for somebody else to continue operating the organisation.
That is systems work even when the primary artefact is documentation rather than software.
Structure is not the same thing as complexity
There is a temptation in systems work to make a model elaborate because the original environment is complicated.
That is not the objective.
A good model should expose the distinctions that matter and ignore the ones that do not. The purpose is not to reproduce every detail of reality. It is to create a representation useful enough for a particular decision or workflow.
A hotel administrator does not need the same view of Trigger SMARTS as the developer. A reader does not need the same view of a literary corpus as an editor. A landlord using a compliance checker does not need to see its entire internal requirements architecture.
The structure can be deep without every user being forced to encounter all of it.
This is one reason I like the phrase structured, not sterile. A good system can be precise without pretending the messiness of human work has disappeared.
The source-of-truth question
Making structure visible often reveals another question: which representation is authoritative?
If the same event exists in WordPress, Eventbrite, Zoom and Vimeo, which one defines the title, date or publication state?
If an AI extracts a relationship from a novel, is that relationship now part of the accepted corpus, or is it a candidate that still needs editorial review?
If a compliance wizard contains an uncertain answer, should the system quietly resolve it into a confident result?
Those are not implementation details. They are part of the domain model.
The structure has to carry not only what the information is, but sometimes what kind of information it is: source, user input, inference, proposal, reviewed state or canonical record.
Structure as a way of thinking
Increasingly, I use software to test whether I have understood the structure properly.
The sequence is often: concept → model → build → observe → revise.
A prototype forces questions that a diagram can leave unanswered. What happens when this record changes? Who approves it? Is this actually one entity or two? What state is visible after a failed operation? Which piece of data should survive a migration?
A build that exposes a bad model is useful. It gives you something concrete to revise.
Coding agents have made this cycle much faster for me, but they have not made the modelling problem disappear. If anything, faster implementation makes it easier to build the wrong model convincingly.
The practical outcome
“Making structure visible” does not imply that every engagement ends with a grand architecture.
Sometimes the useful outcome is a content model. Sometimes it is a handover, a workflow diagram, a migration inventory, a small prototype or a decision about which system should be authoritative.
The common feature is that the environment becomes more intelligible to somebody other than the person who already knew how it worked.
Visibility is valuable when it changes what somebody can inspect, decide, maintain or hand over. That is the kind of structure I am interested in.
Related
Trigger SMARTS, Richard Craven / Cravenverse and IMLPO each needed a different kind of representation before anything else could be built. Method sets out where that work fits in the wider sequence.