// Tools of a Software Architecture for Everyone!

Software architecture is not just the domain of dedicated architects — the tools, practices, and communication patterns it relies on apply to every engineer on every team. In this episode, Chris is joined by John Kilminster, a software architect and Azure MVP with a background in e-commerce and high-traffic systems, who walks through the practical toolbox he has assembled over years in the role.

John begins by clarifying what a software architect actually does — it is less a progression from senior developer and more a shift to a different type of work: setting guard rails across teams, evaluating third-party options, providing cross-team context, and taking a longer-term, more holistic view of technical direction.

The tools and practices covered in this episode include:

• C4 Diagrams (Simon Brown’s model): A four-level hierarchy for visualising software architecture — from system context down to code — designed to communicate clearly to different audiences without requiring specialist tooling.
• Architecture Decision Records (ADRs): Lightweight documents that capture not just what architectural decision was made, but why — preserving the context and rationale that is otherwise lost as teams change over time.
• Tech Radars: Popularised by ThoughtWorks, a tech radar categorises technologies across adopt, trial, assess, and hold — helping organisations share a consistent view on emerging and established tools.
• Docs as Code: Treating documentation as first-class artefacts stored alongside code, versioned in Git, and built through pipelines — eliminating the gap between code and its documentation.
• Backstage: Spotify’s open-source developer portal, now a CNCF project, which brings together service catalogues, TechDocs, tech radars, and more into a single internal developer portal. John covers both self-hosted and SaaS options.

A recurring theme throughout is communication: even without a dedicated architect, small teams benefit from shared context, and these tools are accessible to any organisation willing to invest the time. As John puts it: “whatever decisions you make architecturally, they’re the best decisions you can make at that time.”