Skip to content
Go to file

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

Documenting Architectural Decisions

Presented by: David Ayers
Innovative Technology Professional | Passionate Lifelong Learner | Giant Nerd
Full Bio

Talk Abstract

As technologists, we make architectural decisions all of the time; what we're not good at is recording the context surrounding the decision and properly communicating that decision to the rest of the team (or teams). Enter ADRs (Architecural Decision Records) -- a lightweight was to record and communicate these decisions.

Talk Description

"Why did we decide this?" – every developer in history, 12 months after making a decision.

As technologists, we make architectural decisions all of the time. What we're not good at doing is:

  • Socializing these decisions though the team/department (whoever participated in the discussion has the context, everyone else is out of luck!)
  • Recording the decisions, and more importantly, the context behind the decisions, in a way that our future selves (or anyone – someone just joining the team, for example) can look back and understand why the decision was made and what the factors that went into the decision were.

Enter ADRs. First proposed by Michael Nygard, Architectural Decision Records provide a way to capture these decisions as part of the codebase that you're working on; where the rubber meets the road.

In this short lightning talk, we’ll go through the case for ADRs and a simple primer and how to get started using this technique in your projects.

Links included:

The following links are referenced in the presentation:


No releases published


No packages published
You can’t perform that action at this time.