Architecture: The Stuff That's Hard to Change
summary
Argues that architecture is the stuff that's hard to change and that the architect’s real users are developers (including future hires and maintainers), so decisions must serve their needs within business and technical constraints. Recommends concrete tools: network traces to inspect real traffic, API contracts and tests, monitoring dashboards on the wall, and Conway’s Law to shape team boundaries. Describes practical wins: consolidating 15 separate email senders into a relay service, pairing on observability dashboards, and migrating to off‑the‑shelf systems like Dynamics when it reduces cost. make a decision communicate it reinforce it
AI-written summary · about
chapters (16)
- 0:00Introduction to architecture
- 1:07Defining software architecture
- 3:28The evolution of the field
- 6:56Core principles of architecture
- 9:12Planning and self-organization
- 12:58Constraints and decision making
- 15:15Understanding current systems
- 18:04Requirements and business value
- 21:11The four Ps of delivery
- 23:32Buy, build, and consolidate
- 25:53Communication through diagrams
- 28:13Reality-based documentation
- 33:10Architecture terminology
- 34:38Verification and collaboration
- 38:23The architect's role in coding
- 42:06Empowering teams and conclusion
related talks
48mArchitecture: The Stuff That's Hard to Change
01h 01mArchitecture: The Stuff That's Hard to Change
01h 02mThinking Like an Architect
40mThe (too) many faces of architecture
45mTeam and Software: Making an Impact as an Architect
49mCultivating Architecture
37mSoftware Architecture for Humans!
24mThe too many faces of Architecture