A tool enters an organisation by a decision, works there by being used, and leaves, if it is managed well, by another decision. The ten earlier volumes describe many tools for the first two decisions and fewer for the third, and none of them gives one procedure that runs from the first to the last. This chapter assembles the pieces in the order in which a practitioner meets them: selecting, adopting, keeping a tool under review and retiring it, with the anti-patterns that mark each stage as a failure. The order is this book's. The tools in it are the series'.
The chapter treats all four kinds of tool that Chapter 1 defines. The artefacts include the readiness scorecard of Architecture as Code (Chapter 26A), the adoption dashboard definition and the anti-pattern fitness functions of AI Governance, the production readiness checklist of AI Platform and Security, and the anti-pattern records that four of the later volumes keep in a common shape. The methods include the diffusion of innovation, Kotter's eight steps applied to AI, the production readiness review and the review procedures of The Transformed Security Architect, AI Boss, AI Blue, AI Purple and AI Operations. The third-party entries are the frameworks, protocols, voluntary codes and products that the volumes name as things an organisation may choose to follow (1, Nordqvist, 2025) (2, Nordqvist, 2026).
Two questions run through the chapter. The first is how an organisation chooses between a template, a product and a method. The second is what proves that a tool is adopted and still works. The answer to the second question is the thread of the whole chapter and follows a rule that AI Operations states for claims about resilience: a claim about a tool needs a statement of what was tested, when and with what result, and it expires (10, Nordqvist, 2026). A tool is adopted when the records show that people use it, and it still works when a test with a date says so. Both statements go stale, and the records in this chapter are built so that staleness is visible.
Primary topics explored
- Selecting
- Adoption and the diffusion of tools
- Maintenance and review
- Retirement and exit
- Anti-patterns
- Worked example: adopting a policy engine at Nordvik Region
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 3: Choosing, Adopting and Retiring Tools in Tools gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Toolbox” and is one of 29 drawn from the manuscript.