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

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

• Проблема (Issue): опишите проблему архитектурного проектирования, которую вы решаете, не оставляя вопросов о том, почему вы решаете её именно сейчас. Следуя минималистичному подходу, рассматривайте и документируйте только те проблемы, которые требуют решения на разных этапах жизненного цикла.

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

• Состояние (Status): состояние решения, например pending, decided или approved.

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

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

• Ограничения (Constraints): зафиксируйте любые дополнительные ограничения среды, которые выбранная альтернатива (решение) может накладывать.

• Позиции (Positions): перечислите позиции (жизнеспособные варианты или альтернативы), которые вы рассматривали. Часто для них требуются длинные пояснения, иногда даже модели и диаграммы. Это не исчерпывающий список. Однако вы не хотите услышать вопрос «А вы думали о...?» на итоговом рассмотрении; это ведёт к потере доверия и сомнениям в других архитектурных решениях. Этот раздел также помогает убедиться, что вы выслушали мнения других; явное изложение других мнений помогает привлечь их сторонников к вашему решению.

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

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

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

• Связанные требования (Related requirements): решения должны определяться бизнесом. Чтобы показать подотчётность, явно сопоставляйте решения с целями или требованиями. Вы можете перечислить эти связанные требования здесь, но нам удобнее ссылаться на матрицу прослеживаемости. Вы можете оценить вклад каждого архитектурного решения в выполнение каждого требования, а затем оценить, насколько хорошо требование выполняется всеми решениями вместе. Если решение не способствует выполнению какого-либо требования, не принимайте это решение.

• Связанные артефакты (Related artifacts): перечислите связанные архитектурные, проектные документы или документы об объёме, на которые влияет это решение.

• Связанные принципы (Related principles): если в предприятии есть согласованный набор принципов, убедитесь, что решение соответствует одному или нескольким из них. Это помогает обеспечить согласованность между областями или системами.

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