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](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions), 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.
