Make it a thing! - The practice of software architecture
summary
Argues for a hard rule: Make it a thing! — convert vague principles into concrete artifacts such as architecture decision records kept next to code (they speed onboarding and preserve why decisions happened), C4 context diagram at system scale (stable and useful), measurable cross‑functional requirements (confidentiality integrity availability, throughput targets) driven by performance tests and observability, API guidelines enforced by automated checks, and an organizational pattern of “one team per thing” (inverse Conway) to align teams, code, and governance. Advocates coding or pairing to stay grounded.
AI-written summary · about
chapters (5)
- 0:00Start
- 1:52An object that one need not, cannot, or does not wish to give a specific name to An inanimate material object as distinct from a living sentient being An example or type of something
- 3:54Make it a Thing! Do not accept the vague or the abstract. Seek the explicit, concrete and tangible. This will lead to value generating action.
- 10:42Many decisions we make are about navigating a course for our software delivery or organisation, maps help us to make navigational decisions
- 32:18Do architects need to code? - Well, they at least need to understand how software is created go pair with some devs/bas/qas/pms!
related talks
49mCultivating Architecture
07msoftware architecture vs code
37mSoftware Architecture for Humans!
29mCultivating architecture
48mArchitecture: The Stuff That's Hard to Change
25mThinking Architecturally
25mBuilding Castles, Not Sandcastles: Strategies for Software Architecture Success
38mPractices for Effective Continuous Software Architecture