Your Diagram Is the Architecture: Documentation as a First-Class Deliverable
Every reference I have ever received mentions documentation and diagramming. I take that as a professional compliment, because I hold an unfashionable view: the documentation is not a record of the architecture - in an enterprise, it functionally is the architecture. Decisions that exist only in heads and chat threads are opinions with good marketing.
The stack I produce on every engagement
- Motivation and strategy models - ArchiMate views tracing business drivers and regulatory obligations to architectural goals. These are what make the roadmap defensible when priorities are challenged.
- Conceptual architecture - technology-agnostic patterns: what capabilities exist and how they relate. This layer is where vendor-agnostic thinking lives, and it is the layer that survives platform swaps.
- Logical architecture - identity domains, trust relationships, federation topology, data flows. The layer where most design errors are caught, because drawing a trust relationship forces you to justify it.
- Physical and solution design - HLDs and LLDs specific enough that an engineer who has never met you can build from them, with configuration decisions recorded alongside their rationale.
- Decision records - short, dated, immutable records of what was decided, the options rejected, and why. The cheapest artefact in the stack and the one future-you thanks you for most often.
Diagrams are reasoning tools, not illustrations
A diagram drawn after the design is decoration. A diagram drawn during design is an instrument: it exposes the trust relationship nobody can justify, the single point of failure hiding inside a resilient-sounding sentence, the data flow that crosses a boundary it should not. My rule: if I cannot draw it precisely, I do not understand it yet - and neither does anyone approving it.
Write for the reader you will never meet
The audience for an HLD is not the current project; it is the engineer at 2am three years from now, the auditor with a control matrix, and the architect who inherits the estate. That reader needs stated assumptions, explicit non-goals, and honesty about compromises - the paragraph that says “this deviates from best practice because of constraint X, revisit when Y” is worth more than ten pages of polish.
None of this slows delivery. It is the difference between an architecture function that compounds knowledge and one that re-litigates every decision annually. Draw first, decide on the drawing, and version everything.
Have an identity challenge worth solving?
I take a small number of freelance and contract engagements each year.