Architecture Decision Record

Active theme: Light

← Шаблони за записи на решения

Шаблон за запис на решение от Jeff Tyree и Art Akerman

Това е шаблонът за описание на архитектурно решение, публикуван в "Architecture Decisions: Demystifying Architecture" от Jeff Tyree и Art Akerman, Capital One Financial.

  • Проблем: Опишете архитектурния проблем при проектирането, който разглеждате, като не оставяте въпроси защо го разглеждате точно сега. Следвайки минималистичен подход, разглеждайте и документирайте само проблемите, които трябва да бъдат разгледани в различни моменти от жизления цикъл.

  • Решение: Заявете ясно посоката на архитектурата — тоест позицията, която сте избрали.

  • Състояние: Състоянието на решението, например в очакване, взето или одобрено.

  • Група: Можете да използвате просто групиране — например интеграция, презентация, данни и т.н. — за да организирате набора от решения. Можете да използвате и по-усъвършенствана архитектурна онтология, като тази на John Kyaruzi и Jan van Katwijk, която включва по-абстрактни категории като събитие, календар и местоположение. Например при тази онтология бихте групирали под събитие решенията, които се отнасят до случаи, в които системата изисква информация.

  • Допускания: Описвайте ясно основните допускания в средата, в която вземате решението — разходи, график, технология и т.н. Имайте предвид, че ограниченията на средата (като приети технологични стандарти, корпоративна архитектура, често използвани модели и т.н.) могат да ограничат алтернативите, които разглеждате.

  • Ограничения: Фиксирайте всички допълнителни ограничения за средата, които избраната алтернатива (решението) може да наложи.

  • Позиции: Изброете позициите (жизнеспособните варианти или алтернативи), които сте разгледали. Те често изискват дълги обяснения, понякога дори модели и диаграми. Това не е изчерпателен списък. Не бива обаче да чуете въпроса „Мислили ли сте за...?“ по време на финален преглед; това води до загуба на доверие и поставяне под въпрос на други архитектурни решения. Този раздел помага и да се гарантира, че сте чули мненията на другите; изричното посочване на други мнения помага да се привлекат техните защитници към вашето решение.

  • Аргумент: Очертайте защо сте избрали дадена позиция, включително неща като разходи за реализация, общи разходи за притежание, време за излизане на пазара и наличност на необходимите ресурси за разработка. Това вероятно е толкова важно, колкото и самото решение.

  • Последици: Решението има много последици, както отбелязва метамоделът REMAP. Например решението може да породи нужда от вземане на други решения, да създаде нови изисквания или да промени съществуващи; да наложи допълнителни ограничения върху средата; да изисква повторно договаряне на обхвата или графика с клиентите; или да изисква допълнително обучение на персонала. Ясното разбиране и изразяване на последиците от вашето решение може да бъде много ефективно за получаване на подкрепа и за създаване на пътна карта за изпълнение на архитектурата.

  • Свързани решения: Очевидно е, че много решения са свързани; можете да ги изброите тук. Установихме обаче, че на практика матрица на проследимост, дървета на решенията или метамодели са по-полезни. Метамоделите са полезни за диаграмно показване на сложни връзки (като моделите на Rose).

  • Свързани изисквания: Решенията трябва да се движат от бизнеса. За да покажете отчетност, изрично съпоставяйте решенията си с целите или изискванията. Можете да изброите тези свързани изисквания тук, но установихме, че е по-удобно да се прави препратка към матрица на проследимост. Можете да оцените приноса на всяко архитектурно решение за изпълнението на всяко изискване и след това да оцените доколко изискването е изпълнено във всички решения. Ако дадено решение не допринася за изпълнението на изискване, не вземайте това решение.

  • Свързани артефакти: Изброете свързаните архитектурни документи, документи за проектиране или за обхвата, които това решение засяга.

  • Свързани принципи: Ако предприятието има договорен набор от принципи, уверете се, че решението е съвместимо с един или повече от тях. Това помага да се гарантира съгласуваност между области или системи.

  • Бележки: Тъй като процесът на вземане на решения може да отнеме седмици, установихме, че е полезно да се фиксират бележките и проблемите, които екипът обсъжда по време на процеса на социализиране.