Architecture Decision Record
← dockiments

Hoo tae stairt uisin ADRs

Tae stairt uisin ADRs, hae a blether wi yer teammates aboot thir areas.

Decisioun identification:

  • Hoo urgent an hoo important is the AD?

  • Haes it tae be made noo, or can it wait til mair is kent?

  • Baith personal an collective experience, as weel as recognised design methods an practices, can help wi decisioun identification.

  • Ideally keep a decisioun todo list that gaes alangside the product todo list.

Decisioun makin:

  • A wheen o decisioun makin techniques exist, baith general anes an saftware architectur specific anes, for instance, dialogue mappin.

  • Group decisioun makin is an active research topic.

Decisioun enactment an enforcement:

  • ADs are uised in saftware design; sae they hae tae be communicatit tae, an accepted bi, the stakeholders o the system that fund, develop, an rin it.

  • Architecturally evident codin styles an code reviews that focus on architectural concerns an decisiouns are twa relatit practices.

  • ADs an aw hae tae be (re-)considered whan modernisin a saftware system in saftware evolution.

Decisioun sharin (optional):

  • Mony ADs recur athort projects.

  • Sae, experiences wi past decisiouns, baith guid an bad, can be valuable reusable assets whan employin an explicit knowledge management strategy.

Decisioun documentation:

  • Mony templates an tuils for decisioun capturin exist.

  • See agile communities, e.g. M. Nygard's ADRs.

  • See traditional saftware engineerin an architectur design processes, e.g. table layouts suggestit bi IBM UMF an bi Tyree an Akerman frae CapitalOne.

For mair: