Шаблон запису рішення Джеффа Тайрі та Арта Акермана

Це шаблон опису архітектурного рішення, опублікований у статті "Architecture Decisions: Demystifying Architecture" by Jeff Tyree and Art Akerman, Capital One Financial.

• Проблема (Issue): опишіть проблему архітектурного проєктування, яку ви розв’язуєте, не залишаючи жодних запитань про те, чому ви беретеся за неї саме зараз. Дотримуючись мінімалістичного підходу, розглядайте й документуйте лише ті проблеми, що потребують розв’язання на різних етапах життєвого циклу.

• Рішення (Decision): чітко сформулюйте напрям архітектури — тобто позицію, яку ви обрали.

• Статус (Status): стан рішення, наприклад, очікує, ухвалено або затверджено.

• Група (Group): можна скористатися простим групуванням — наприклад, інтеграція, представлення, дані тощо — щоб упорядкувати набір рішень. Можна також використати складнішу онтологію архітектури, як-от онтологію Джона Кьярузі та Яна ван Катвейка, що містить абстрактніші категорії, такі як подія, календар і місце. Наприклад, за цією онтологією рішення, що стосуються випадків, коли системі потрібна інформація, групують під «подією».

• Припущення (Assumptions): чітко опишіть базові припущення щодо середовища, у якому ви ухвалюєте рішення, — вартість, графік, технології тощо. Зауважте, що обмеження середовища (як-от прийняті технологічні стандарти, архітектура підприємства, поширені патерни тощо) можуть обмежувати альтернативи, які ви розглядаєте.

• Обмеження (Constraints): зафіксуйте будь-які додаткові обмеження для середовища, які може накласти обрана альтернатива (рішення).

• Позиції (Positions): перелічіть позиції (життєздатні варіанти чи альтернативи), які ви розглядали. Вони часто потребують довгих пояснень, а іноді навіть моделей і діаграм. Це не вичерпний перелік. Однак ви не хочете почути запитання «А ви думали про...?» під час фінального рев’ю; це призводить до втрати довіри й сумнівів щодо інших архітектурних рішень. Цей розділ також допомагає переконатися, що ви вислухали чужі думки; явне зазначення інших думок допомагає залучити їхніх прихильників на бік вашого рішення.

• Аргумент (Argument): викладіть, чому ви обрали позицію, зокрема з огляду на вартість впровадження, сукупну вартість володіння, час виходу на ринок і доступність потрібних ресурсів розробки. Це, ймовірно, так само важливо, як і саме рішення.

• Наслідки (Implications): рішення має багато наслідків, як зазначає метамодель REMAP. Наприклад, рішення може створити потребу в ухваленні інших рішень, породити нові вимоги чи змінити наявні; накласти додаткові обмеження на середовище; вимагати повторних переговорів із замовниками щодо обсягу чи графіка; або вимагати додаткового навчання персоналу. Чітке розуміння й формулювання наслідків вашого рішення може бути дуже ефективним для здобуття підтримки та створення дорожньої карти виконання архітектури.

• Пов’язані рішення (Related decisions): очевидно, що багато рішень пов’язані між собою; ви можете перелічити їх тут. Проте на практиці ми з’ясували, що кориснішими є матриця відстежуваності, дерева рішень чи метамоделі. Метамоделі корисні для діаграмного відображення складних взаємозв’язків (як-от моделі Rose).

• Пов’язані вимоги (Related requirements): рішення мають бути зумовлені бізнесом. Щоб показати підзвітність, явно пов’язуйте свої рішення з цілями чи вимогами. Ви можете перелічити ці пов’язані вимоги тут, але ми з’ясували, що зручніше посилатися на матрицю відстежуваності. Можна оцінити внесок кожного архітектурного рішення у виконання кожної вимоги, а потім оцінити, наскільки добре вимогу виконано в усіх рішеннях разом. Якщо рішення не сприяє виконанню жодної вимоги, не ухвалюйте такого рішення.

• Пов’язані артефакти (Related artifacts): перелічіть пов’язані документи з архітектури, проєктування чи обсягу, на які впливає це рішення.

• Пов’язані принципи (Related principles): якщо в підприємстві є узгоджений набір принципів, переконайтеся, що рішення узгоджується з одним чи кількома з них. Це допомагає забезпечити узгодженість у різних предметних галузях чи системах.

• Примітки (Notes): оскільки процес ухвалення рішень може тривати тижнями, ми з’ясували, що корисно фіксувати нотатки та проблеми, які команда обговорює під час процесу узгодження.