Lessons Learned: arc42 in a DevOps Team
summary
Reports experience using the arc42 architecture template in a corporate DevOps product team: unstructured docs were migrated into arc42 in a wiki, then tooling was changed to a Docs-as-Code workflow (AsciiDoc microsite) to improve documentation quality. Covers decision points for the software architecture iteration—handling developer prose, outdated docs, and key architecture decisions for DevOps—and describes integration with Kanban plus mistakes such as missing QA on docs and mixing domain and technical topics.
AI-written summary · about
chapters (19)
- 0:00Welcome
- 1:48What is the DB Content Hub?
- 3:38What is Product Development?
- 8:12Argumentation
- 15:59Why arc42?
- 18:54Bullet points of arc42
- 20:37arc42 in the Architecture Guild
- 22:32Chapter 11: No longer documenting
- 23:21Chapter 12: Technical Documentation
- 24:03Chapter 13: Wiki
- 26:18Chapter 14: Documentation
- 28:18Chapter 15: Infrastructure
- 28:52Chapter 16: Documentation
- 31:06Chapter 17: Documentation
- 32:55Chapter 18: arcDoc
- 34:28Chapter 19: arcDoc in Practice
- 36:26Chapter 20: arcDoc in Practice
- 38:53Chapter 21: arcDoc in Practice
- 41:08Chapter 22: arcDoc in Practice
related talks
40mLessons Learned: arc42 in a Real Devops Team
42mLessons Learned Using arc42 in a Real DevOps Team
46mArchitecture & DevOps
41mSoftware Architecture in a DevOps World
44mPushing documentation (so it doesn't hurt anymore)
20mJourney Of Devops Teams in a Corporate Environment
47mDocumentation Is Fine, Don't Worry
46mBest Practices for Keeping Architecture Documentation Up to Date