Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Current »

Use the ?? (MADR) technique to capture decisions


status: {proposed | rejected | accepted | deprecated | … | superseded by ADR-0005}

date: {YYYY-MM-DD when the decision was last updated}

deciders: {list everyone involved in the decision}

consulted: {list everyone whose opinions are sought (typically subject-matter experts); and with whom there is a two-way communication}

informed: {list everyone who is kept up-to-date on progress; and with whom there is a one-way communication}

Use the GitHub ADR and MADR for architecture decisions

Context and Problem Statement

The Architecture Working Group must capture decisions.

We need a simple and agreeable way to capture and track these decisions.

Don't want too many decisions, just the consequential ones.

Decision to make:

  • what template
  • where to keep them - github or wiki
    • maybe in the future we'll have a documentation repo to keep them in
  • governance
    • status checking
    • approvals

Decision Drivers

  • simple
  • mature
  • agreed upon
  • works for opensource

Considered Options

  • github adr / madr
  • ad hoc
  • {title of option 3}
  • …

Decision Outcome

Chosen option: "{title of option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}.

Consequences

  • Good, because {positive consequence, e.g., improvement of one or more desired qualities, …}
  • Bad, because {negative consequence, e.g., compromising one or more desired qualities, …}
  • …

Validation

{describe how the implementation of/compliance with the ADR is validated. E.g., by a review or an ArchUnit test}

Pros and Cons of the Options

GitHub ADR / MADR

simple and mature way to capture architecture decisions

  • Good, because it is widely used
  • Good, because works in code and in confluence
  • Bad, because {argument d}
  • …

Technology Selection Template

  • High Level Summary
  • Principles
  • Options 1/ Option 2
  • Option 1 Info
  • Option 2 Info
  • Cost Factors Option 1
  • Cost Factors Option 2
  • Recommendation

useful for Technology/Platform selection

Ad-Hoc

We come up with our own way to capture

  • Bad, because only used for openIDL


  • No labels