Architecture review
A design is cheapest to change while it is still a document, so the review happens before the commitment, not after it.
A design is cheapest to change while it is still a document. Once it exists as running code with real data inside it, most of what would have been a twenty-minute disagreement in a meeting has become a migration instead, and the cost of being wrong has moved by an order of magnitude.
A proposed design is tested against the things that actually break systems instead of against style: what happens under load, what happens when a dependency is unavailable, what happens when two operations run at the same moment, and what happens when the data turns out not to be shaped the way the design assumed.
Coupling is the property examined most closely, because it determines the cost of every future change. The questions are which parts must change together, and whether the seams in the design fall where the business actually expects change to happen. A system separated along the wrong lines is more expensive to modify than one with no separation at all.
Failure modes are enumerated per component, with the question asked in both directions: what does this break when it fails, and what breaks it. The second direction is the one usually skipped, and it is where the surprising dependencies live.
One-way decisions are separated from reversible ones and given proportionally more scrutiny. A choice that can be undone in an afternoon does not deserve a week of deliberation; a data model, a vendor commitment, or a public interface deserves considerably more than it usually gets.
The review names what the design is optimizing for and asks whether that matches the situation the business is actually in. A design built for a scale the business does not have, and has no concrete path to reaching, is paying complexity today for a benefit that may never arrive — and complexity is charged monthly.
Existing systems are reviewed the same way, with one addition: history counts as evidence. A decision that looks strange usually had a reason, the reason is often still valid, and the fastest way to introduce a defect is to remove something whose purpose was not understood.
The output is a written set of observations carrying severity and reasoning, not a redesign. Where a redesign is genuinely warranted that is said plainly and scoped as separate work, because a review that quietly becomes a proposal has changed what it was.
A review that finds nothing serious is a legitimate result and gets reported as one. The pressure to justify the engagement by producing findings is precisely how a review starts manufacturing them, and a list of stylistic preferences presented as risk does more damage than silence.
What this does not cover.
- Redesigning the system under review. That is separate work with its own scope.
- Style and convention preferences presented as findings.
- Reviews of a design nobody has written down. The document is the prerequisite.
Advisory
The systems audit
A read-only account of what an organization actually has, ordered by consequence and written to be checked by someone who disagrees with it.
Build versus buy
The quoted price is the reliable number and rarely the deciding one; the analysis is costed over a stated horizon with the commercial conflict disclosed in the document.
Findings and evidence
What separates a report that changes something from one that gets filed is whether each claim arrived checkable.
The case for doing nothing
Urgency is a property of risk, not of annoyance, and the recommendation to leave a system alone is the one most often left unmade.
Vendor and platform selection
Feature lists converge between finalists; what separates them is renewal terms, data portability, and what happens after the invoice is paid.
Independence
Arrangements that make the firm's interest visible and checkable, since no advisor can credibly claim to have none.