Многие думают, что ADR — Architecture Decision Records — это про фиксацию решений. Вообще нет, это, в первую очередь, мощный инструмент для принятия решений.

Если думать про это, только как про фиксацию, то вроде и пользы не так много — ну да, мы можем отследить, когда и какое решение было принято, бла-бла… Скучно. Это из области управления знаниями, которое очень трудно продается и про которое начинают думать, когда все остальные проблемы уже решены. А проблема — это как раз принятие решений, вот что у всех постоянно западает.

И в ADR есть отличные механики для этого.

Про них почему-то не всегда даже пишут, а это-то самое важное, что там есть. Вот смотрите:

1) Срок действия решения. Это то, что убивает все обсуждения и заставляет их длиться бесконечно. Люди бьются, как будто каждое решение принимается навсегда! Стоит только вбросить волшебную фразу “это только на следующие полгода” — как все затыки и противоречия чудесным образом снимаются. Ну, полгода уж мы как-нибудь потерпим!

Конечно, тут крайне важно, чтобы это действительно были полгода, и чтобы у вас в принципе был процесс пересмотра решений. То есть, вот прямо в план вставлены регулярные встречи для анализа и пересмотра всех действующих ADR! Хотя бы раз в квартал, ну или с какой скоростью вы двигаетесь.

Ну и гибкость архитектуры важна, чтобы мы действительно могли что-то через полгода малыми усилиями поменять, а не заливать всё бетоном навечно. Если этого нет, то и ADR-ы не нужны, действительно, зачем?..

2) Триггеры для пересмотра. Решение может изменяться не по времени, а по значению какой-то метрики. “Это решение действует, пока объем передаваемых данных / частота обращения к API / время обработки сообщения / … не превысит значение X”.

Разумеется, тут нужен механизм, автоматически отслеживающий этот показатель и напоминающий, что нужно бы ADR-то  пересмотреть.

3) Обратимость решения. Если решение обратимо без последствий и разумными усилиями — его вообще обсуждать долго не нужно, нужно выбрать какой-то вариант, определить метрики и критерии успеха, и посмотреть, что будет. Если не получилось — вернуться назад. В культуре Amazon (“Day 1”) это называется “two-way door”: дверь, в которую можно и войти, и выйти. Если пристально посмотреть и создать правильную инфраструктуру, таких решений может быть гораздо больше, чем кажется!

4) Уровень уверенности. Если вы не уверены в решении, это НЕ означает, что его не нужно принимать. Это означает, что оно должно быть обратимым и измеримым. А ещё — записать в явном виде, какой информации нам не хватает для принятия решения, и какие риски мы рассматриваем.

Ещё интересно, когда стоит вообще принимать решение. В последний момент, но не позже! (Last Responsible Moment). Решение, принятое слишком рано, может быть не самым оптимальным, потому что мы ещё многого не знаем. Это как раз связано с информацией из п.4. Ключевые вопросы: нам обязательно принимать это решение сейчас? Что нас заставляет это сделать? Можем ли мы что-то делать уже сейчас, не принимая пока это решение? Что позволит нам принять более взвешенное решение (если мы будем знать что?).

В общем, ADR задает хорошую структуру для обсуждения и принятия решения. Если у вас к совещанию будут подготовлены варианты с описанием почему нам нужно принять это решение (драйвер), почему именно сейчас, что мы не можем сделать без этого решения, какие альтернативы мы рассмотрели, какие у них есть преимущества и недостатки, на какой срок / до каких условий мы принимаем это решение, обратимое ли оно (и какие усилия нужно будет предпринять для отката) — ваше обсуждение пройдет гораздо более эффективно.