Architecture Before Technology Selection: A Repeatable Decision Sequence

I’ve written about why regulation, and the data model, both have to precede the tool. This is the practical version of that argument — not the philosophy, the actual repeatable sequence, usable on any technology decision regardless of size, that keeps the reasoning from collapsing into “let’s just look at some vendors” by the second meeting.

Most technology decisions drift toward a vendor comparison faster than the underlying thinking is actually ready for, because comparing vendors feels like progress and architectural reasoning feels like delay. The sequence below exists specifically to resist that drift, in a form concrete enough to actually follow rather than just agree with in principle.

The five steps, in order, each one gating the next

1. Name the obligation. What does this decision actually have to make possible — a regulatory requirement, a specific business capability, a defined operational need? Stated precisely enough that it could be wrong, not so vaguely that anything satisfies it. “Improve customer service” is not an obligation. “Resolve a support ticket within four hours for 90% of enquiries, with a complete audit trail” is.

2. Define what has to be provable. Once the obligation is named, what would count as evidence that it’s being met? This step is frequently skipped, and skipping it is why so many systems get built that satisfy the spirit of a requirement without being able to demonstrate it on demand — the gap between doing the thing and proving the thing, covered at length elsewhere on this site, starts exactly here, at the point the requirement was first defined.

3. Model the data before touching a platform. What entities does this decision need to reason about, and what does each one need to carry to satisfy step two? This is the step that most reliably gets skipped in favour of jumping straight to a vendor shortlist — and skipping it is what produces the “buy first, discover the data model was wrong later” failure pattern I’ve written about separately.

4. Identify the two or three architectural properties the solution must have. Not features — properties. Does it need to be replaceable within a defined timeframe? Does it need to operate across multiple jurisdictions with data residency guarantees? Does it need to integrate with a specific existing system of record without becoming the new one? These properties, named explicitly, become the filter the vendor conversation runs through — rather than the vendor conversation defining, retroactively, which properties turned out to matter.

5. Only now, select the tool. With the obligation, the evidence requirement, the data model, and the architectural properties all named, the vendor conversation becomes a narrow, well-defined search rather than an open-ended exploration — because most of the actual decision has already been made, and what remains is finding the specific implementation that serves it.

Why the order is the entire point

Reverse this sequence — start from a platform and work backward — and each step still nominally happens, but in a compromised form: the data model gets bent to fit whatever the chosen platform’s schema assumes, the architectural properties get discovered only when the platform turns out not to have one of them, and the evidence requirement gets satisfied partially, in whatever form the platform happens to produce, rather than in the form the obligation actually needed. The steps aren’t a checklist to complete in any order. They’re a dependency chain, and skipping the order defeats the purpose of having named them at all — a sequence followed out of order isn’t really a sequence, just a list of good intentions.

Running it on a real decision

A maritime operator evaluating a crew-management platform ran the sequence explicitly rather than starting from a shortlist. The obligation: track crew certifications and rest hours in a way that satisfies both flag-state requirements and internal safety policy. What had to be provable: a complete, dated record of every certification check and rest-hour calculation, producible on demand during a port state control inspection. The data model: “crew member,” “certification,” and “vessel assignment” needed to be genuinely unified across what had previously been three disconnected spreadsheets per vessel. The architectural properties: the system needed to work with intermittent satellite connectivity and sync reliably once reconnected. Only at that point did the vendor conversation start — and it eliminated two of the four platforms the operator had originally been leaning toward, because neither handled offline operation credibly, a property nobody had thought to check before the sequence forced the question.

Running a specific technology decision through this sequence, before any vendor conversation starts, is core to how every engagement here begins — see the fuller argument on how I work, or get direct support applying it to an active decision through a technology control assessment.

Five steps, followed in order, on a decision that would otherwise have started with a vendor shortlist — that is the whole method, and its value is almost entirely in the discipline of not skipping ahead.