From 9c7c4029bec0666de1b8ee9092d9fb9913cd1661 Mon Sep 17 00:00:00 2001 From: "Roland Edwards, AOE GmbH" <39269273+raedwards@users.noreply.github.com> Date: Wed, 16 May 2018 15:31:59 +0200 Subject: [PATCH] Update adr.md --- radar/2017-10-01/adr.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/radar/2017-10-01/adr.md b/radar/2017-10-01/adr.md index d8387ca..ba6ad59 100644 --- a/radar/2017-10-01/adr.md +++ b/radar/2017-10-01/adr.md @@ -6,21 +6,21 @@ quadrant: methods-and-patterns --- Architecture Decision Records -Is a lightweight documentation of important architecture decisions taken by the team. +ADR is a lightweight documentation of important architecture decisions taken by the team. Without documentation of the architecture and the architecture decisions, new team members can only do two things: -* either (blindy) accept what they find and see or +* either (blindy) accept what they find and see or * (blindy) change things -Both is of course not right. +It goes without saying that both options aren't right. -Therefore we suggest to document the important architecture decisions. We are using a simple tool like https://github.com/npryce/adr-tools and store them in version control. -In bigger projects with many teams we also establish a regular "architecture board / coi" with regular meetings. -Often the architecture decision are taken in such meetings. +Therefore, we suggest documenting the important architecture decisions. We use a simple tool such as https://github.com/npryce/adr-tools and store them in version control. +In larger projects with many teams we also establish a regular "architecture board / COI" with regular meetings. +Often, the architecture decisions are taken in such meetings. -The main purpose of this documentation is: -* inform new team members about the previous architecture decisions and its purpose and backgrounds -* inform the whole team (also all the people who where absent) -* documentation that can be used to remeber things (e.g. conventions, patterns, etc) +The main purpose of this documentation is to: +* inform new team members about the previous architecture decisions and their purpose and backgrounds +* inform the whole team (including all people who were absent) +* create documentation that can be used to remember things (e.g. conventions, patterns, etc.)