Architect
Rationale
How-toNormative

The four lenses

Architect, project manager, developer, designer — every structural decision is looked at four ways before it is taken, and the disagreement is the useful part.

A solutions architect is not four people. It is one person who refuses to take a structural decision having looked at it only one way.

Run all four before committing. Skipping one is how a decision that looks right on Tuesday becomes expensive in March — almost always the lens you find least natural.

Only the questions that are not ordinary competence are listed. Cost forecasting, naming discipline and evidence are covered by evidence and forecast; what follows is what those do not say.

Architect

Owns: structure, boundaries, what outlives the brief.

  • Is this configurable or rigid? Would it be false if the client reorganised next year?
  • Where does this truth live? Which artefact owns it, and what may only reference it?
  • What is expensive to reverse? Data footprint, published identifiers, semantics others depend on.
  • Does it hold for the second client, or only this one's current shape?
  • Am I configuring the path or the walls?
  • Does this create a second source of truth for something that already has one?

Failure mode: designing the org chart of one client into the product, then discovering it during their restructure.

Project manager

Owns: cost, sequence, what the commitment actually is.

  • What is genuinely blocked on the client, versus what I am about to ask because I did not make it configurable? Run the list through the questions pass before it leaves.
  • Who will administer this once we are gone? Configurability with no administrator is cost with no benefit.
  • Which requirements are deferrable to the second release, and which absolutely are not? The non-deferrable ones are those whose late arrival costs a migration or a disclosure.
  • Is this build or buy, over the years the client will run it rather than the weeks we will build it?
  • What does it block? What cannot start until this lands?

Failure mode: a question list handed to the client as if every entry were a real blocker, stalling the work on answers that were never needed.

Developer

Owns: whether it can be built, tested, and changed later.

  • What does this do to the schema? What becomes unrecoverable once real records exist?
  • What is testable? Every rule should have an observable someone can check.
  • What is the migration cost if this is wrong?
  • What must be atomic? Which effects must succeed or fail as one block?
  • What happens under concurrency — two people acting on the same record at once?
  • What happens on retry? The same act submitted twice must not produce two effects.
  • Does the type system still catch additions? A new enum value should fail compilation everywhere it must be handled — or, once values are runtime data, a publication check must fail instead.

Failure mode: a beautiful model whose first migration is impossible because the version identifier was never stored on the record.

Designer

Owns: whether a human can live with it.

  • Say the sentence out loud. "The applicant declares the town where the project takes place." If the model's own words cannot be spoken like that, the model has the wrong words.
  • If the documentation needs a sentence to translate a name, the name is wrong. A glossary explaining that "organisational entity" means "the office" is the design telling you which word it wanted.
  • Does this expose internal structure to someone who has no reason to know it? An applicant should never have to interpret the client's org chart to fill in a form.
  • Does the person who has to use this every day get fewer clicks or more?
  • Is an irreversible act visibly irreversible before it happens?
  • Does an error message say what to do, not merely what failed?
  • Is the administration surface usable by whoever will actually operate it, or have we built a configuration screen only its author can safely touch?

Failure mode: an internally coherent model that forces an external user to learn the organisation's internal vocabulary in order to use it.

Craft is part of this lens, not a later pass. Motion and polish for component shape, animation and the invisible details; layout and spacing for rhythm and hierarchy. A decision that survives the other three lenses and produces an interface nobody wants to use has not survived this one.

When the lenses disagree

They will, and the disagreement is the useful part.

TensionHow it resolves
Architect vs project managerBy reversal cost. If the rigid version can be opened up later without touching stored data, ship rigid. If opening it later means a migration, pay now.
Developer vs designerThe speakable name wins on anything an external user touches. The clean model wins on anything only the code sees.
Architect vs designerGenerality that costs a speakable name is usually generality nobody asked for.
Architect vs developerIf the general version can be reached later without touching stored data, build the specific one now.

Whichever way it resolves, write down which lens lost and why. That sentence is what makes the decision reviewable in a year.

On this page