Appendices¶
Status: 🟢 Active | Owner: Architecture Team | Last Reviewed: 2025-Q4
Introduction¶
The appendices provide supporting reference material that complements the main sections of the portal. While the primary sections contain the standards themselves — the what and the why — the appendices contain the reference material that makes those standards practical to apply: glossaries that define shared language, templates that remove the friction of starting from scratch, a technology radar that communicates the organisation's view on the broader tooling landscape, and the administrative processes that govern exceptions and onboarding.
Intent¶
A Shared Vocabulary¶
Engineering organisations accumulate acronyms and jargon at pace. The glossary exists to create a shared vocabulary — a canonical definition of terms that may mean different things to different people. When a standard references an "error budget" or a "bounded context" or a "golden path", the glossary is where engineers can go to confirm they are using the term the same way the standard intends.
The Technology Radar¶
The organisation's Technology Radar is the mechanism by which the Architecture Team communicates its view on the broader landscape of technologies, frameworks, tools, and techniques — beyond the specific approved choices documented in individual sections. The radar uses four quadrants (Techniques, Tools, Platforms, Languages & Frameworks) and four rings (Adopt, Trial, Assess, Hold) to communicate signals to engineering teams about where to invest learning and where to exercise caution.
The radar is not a mandate. An item in "Hold" is not necessarily prohibited — it means the Architecture Team does not recommend new adoption. An item in "Assess" means the organisation is watching it with interest but has not yet committed. The radar supplements the specific standards in this portal rather than replacing them.
Templates as Accelerators¶
Every standard that requires an engineer to create an artefact — an ADR, a runbook, a pull request description, an RFC — is accompanied by an approved template. Templates remove the friction of starting from a blank page, ensure that required sections are not forgotten, and produce output that is consistent enough to be quickly scanned by reviewers who have read many similar documents before.
The New Joiner Checklist¶
The new joiner setup checklist is a practical, step-by-step guide for getting a development environment fully configured from scratch. It is designed to be followed on day one and to leave a new engineer with a working local environment, access to required systems, and familiarity with the key standards that apply immediately. It is kept up to date by Engineering Enablement and represents the current, validated path to a working developer setup.
What You Will Find Here¶
| Page | Intent |
|---|---|
| Glossary of Terms | Definitions of key terms, acronyms, and concepts used across the portal |
| Approved Technology Radar | Adopt / Trial / Assess / Hold signals across the technology landscape |
| Standard Templates | ADR, Runbook, PR Description, RFC, and Post-Mortem templates |
| Tools & Toolchain Reference | Master reference table of all approved tools, versions, and config links |
| Standards Exemption Process | How to request, approve, and track exceptions to standards |
| Language Decision Framework | Flowchart-based guide for selecting the right language for a new service |
| New Joiner Setup Checklist | Step-by-step environment setup for engineers joining the organisation |
| Tool Evaluation Scorecard | Template for assessing new developer tooling across standard dimensions |
Last reviewed: 2025-Q4 | Owner: Architecture Team