Abstract: Documenting architecture design decisions is commonly considered a good practice but few teams take the time to write down the decisions they make. In our experience this happens for a few reasons: architecture documentation is rejected as being too heavyweight, documentation is typically out of sight and out of mind, and many developers don’t know what to document. Architecture Decision Records (ADRs), a lightweight documentation approach
proposed by Michael Nygard, solves these problems by recording design decisions in a simple markdown template in the same repository as the code affected by the decision. We've found that this technique has many advantages. Documenting ADRs creates opportunities to involve more teammates in the design process. Up and coming architects can safely practice design under the guidance and review of experienced teammates. Over time ADRs form a catalog of proto-patterns that can be bootstrap future architectures.
In this talk we will share our experiences and lessons using ADRs over the past two years while working on the IBM Watson Discovery Service. By the end of this talk you will know how to create effective ADRs, introduce the technique to your team, and avoid common pitfalls with the method.
View the Experience Report Lessons Learned from Your Experience: - How to phrase a decision as a lightweight decision record and share it with others
- How to think through decisions and how to guide others in doing so
- ADRs help us write better code
- ADRs help us understand what risks we are accepting and we are able to think more strategically about risk
- Other documentation is still required and ADRs are a good way to figure out what else needs to be documented. ADRs are a part of a minimalist set of design documentation
- We can learn from past decisions in other parts of the system and extract team and institutional patterns
Attachments:
