Pragmatic Approach to Architecture Metrics
summary
Argues that architecture success maps to business outcomes via two vectors: ability to change (frequency) and ability to evolve (effectiveness). Recommends four measurable signals — change lead time, deployment frequency, change failure rate, mean time to recovery — collected from ticketing systems and CI/CD pipelines, and warns of Goodhart/Cobra effects. Presents a pragmatic complexity model: four coupling types (implementation, functional, model, contract coupling) plus physical distance; cost of change scales with complexity and coordination (CRM→OMS→portal example).
AI-written summary · about
chapters (10)
- 0:00Introduction to metrics skepticism
- 2:29Why software metrics are flawed
- 8:06Business ability to change
- 11:21Pragmatic measurement guidelines
- 15:37Goodhart’s law and unintended effects
- 18:27Change cost and trade-offs
- 22:42Defining software complexity
- 26:59Problems with design metrics
- 31:34Measuring coupling and knowledge
- 47:20Summary and key takeaways
related talks
37mArchitecting for Tomorrow: A Pragmatic Perspective
58mThe past, present and future of Architecture
01h 00mAgile Architecture
01h 13mPragmatic Architecture
01h 15mHow to measure your architecture
49mCultivating Architecture
46mPractical (a.k.a. Actually Useful) Architecture
39mPrinciples of Evolutionary Architecture