This chapter serves one activity: describing an architecture so that it can be versioned, reviewed and tested, and recording why it looks the way it does. It treats all four kinds of tool. The artefacts are the workspaces, reference models, overlays, templates and decision records that the series defines. The own tools are the small scripts that validate and render them. The third-party tools and standards are the modelling notations and documentation toolchains that the volumes name, and the methods are the named practices that tie the rest together. Most of the material comes from Architecture as Code (Chapters 4, 6 and 22) (1, Nordqvist, 2025), which defines the architecture-as-code discipline; the AI volumes extend it with the AI Decision Record, the reference architecture and security properties on model elements: AI Governance (2, Nordqvist, 2026), AI Platform and Security (3, Nordqvist, 2026), AI Red Team (4, Nordqvist, 2026), The Transformed Security Architect (6, Nordqvist, 2026), AI Boss (7, Nordqvist, 2026), AI Purple (9, Nordqvist, 2026) and AI Operations (10, Nordqvist, 2026).
The inventory assigns 70 entries to this chapter. The chapter treats the principal ones in full entries, names the rest in family tables, and leaves minor variants to Appendix A. Policy engines and the pipelines that run these checks are in Chapter 5, and the AI Decision Record itself, which extends the architecture decision record treated here, is in Chapter 7. Inclusion of a tool is a statement about what the series says of it and nothing more: for third-party software the facts come from its own documentation, and an earlier volume is cited only to show where the series uses the tool.
Architecture drawn in a graphical tool decays: the diagram and the system drift apart because updating the diagram is a separate, manual act. Architecture as Code (Chapter 6) calls this diagram decay and answers it by keeping one text model under version control from which the diagrams are generated (1, Nordqvist, 2025). The tools in this family are a notation (the C4 model), two languages that make the notation or an alternative to it machine-readable (the Structurizr DSL and CALM), and the workspaces, templates and scripts built on them. All three languages appear in the series in the same role, and the later volumes use the first two without changing them.
Primary topics explored
- Architecture modelling
- Architecture and decision records
- Documentation, requirements and knowledge as code
- Summary
- Sources
About Tools
Tools is a companion to The Transformed Architecture. It collects the tools that Books 1 to 10 describe in one reference, organised by what the practitioner is doing: artefacts (templates, manifests, records), own tools, third-party tools and standards, and methods. Each entry says what a tool is for, when to use it, what it needs and produces, and where the book that defines it explains the reasoning. The book covers choosing, adopting and retiring tools, architecture and delivery, governing AI, securing and testing, operating, agents and autonomy, and people, organisation and society, for European enterprises and public authorities. It comes with a template library, an inventory, three web tools and the Toolbox Maturity Method.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple and AI Operations.
Architects and security architects, CIOs and CISOs, platform and operations leads, heads of governance, risk, compliance and third-party risk, AI governance and AI platform teams, red, blue and purple team leads, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 4: Architecture and Decision Tools in Tools gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Architecture and Delivery” and is one of 29 drawn from the manuscript.