How to measure your architecture
summary
Claim: most architectures aren’t measured so defects and costly redesigns hide until users leave; one out of ten architectures is verified. Practical tools and tests used: run architectural kata to produce three–four candidate designs in a two‑hour session, apply scenario methods (ATAM/SA), measure with F‑quadrant plotting cyclomatic complexity versus change frequency, and track with SonarQube, JavaMelody, NewRelic, AppDynamics, JMeter. Concrete wins: a Hibernate bug with IN lists >1000 fixed by chunking IDs, ignored tests eliminated by a build‑failing ignore check. cyclomatic complexity ~10 safe, ~70 risky
AI-written summary · about
chapters (18)
- 0:00Introduction and speaker intro
- 2:25Why measure architecture
- 6:26Costs and casino analogy
- 10:02People and knowledge effects
- 13:18What is architecture
- 18:25Discovery review process
- 21:13Architectural Kata explained
- 25:51Scenario-based methods
- 30:32FS quadrant for measuring
- 35:40Visualization tools
- 37:30Data versus information
- 39:37Summary and benefits
- 43:58User engagement importance
- 46:05Domain-driven design basics
- 48:55Tools for measurement
- 51:06Simplicity in metrics
- 53:20Comparing designs
- 57:25Q&A session starts
related talks
44mTesting Software Architecture
49mMetrics for Architects
51mTesting Software Architecture
58mTesting Software Architecture
01h 34mThe Intersection of Architecture and Implementation
46mManaging architectural debt in a hypergrowth context
48mDown the Ivory Tower towards Agile Architecture
35mQuantitative measures for software Architecture quality evaluation