Aligning Architecture with Responsibility Indices
summary
A concrete process for creating Responsibility Indices maps each primary responsibility to the exact code locations, records quality measures, planned refactorings and rules of engagement, and surfaces where responsibilities duplicate. Practice uses spreadsheets and colored quality views today, applied to two large systems, and recommends about 7±2 primary responsibilities per scope. The claim is that treating responsibilities as primary lets teams tailor testing and change rules and schedule incremental refactorings to increase cohesion; caveats: no tooling yet and indices can go stale.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 0:42Legacy systems and renewal
- 2:49System modeling and coat hangers
- 5:37Bias toward visible elements
- 8:47Telling the system story
- 9:29Responsibility driven design
- 12:58Mapping responsibilities
- 14:28Workflow system analysis
- 17:35Primary responsibilities count
- 19:40Architecture and system value
- 22:27Process rules by responsibility
- 24:11Responsibility index for refactoring
- 26:36Long-term planning rules
- 27:39Core idea and coherence
- 28:41Practical considerations
- 29:22Q&A
related talks
29mTools of Intentional Architectures
20mSupporting your architecture with code coverage and static analysis rules
49mArchitecture assessments
48mDown the Ivory Tower towards Agile Architecture
42marchitect's Guide to Managing a Code Base
33mRefactoring with Observability
41mInside Software Architecture - Where the Bodies are Buried
28mGet a grip on your quality by using Quality Views