Факторы принятия и пересмотра решений

Как вы принимаете архитектурные решения? Согласитесь, что вопрос непростой даже для человека с опытом. Давайте подумаем и попробуем ответить на этот вопрос структурно.

В общем случае я придерживаюсь примерно такой последовательности:

• Погружаюсь в контекст проблемы.
• Выясняю функциональные требования.
• Выясняю нефункциональные требования.
• Определяю важные архитектурные свойства.
• Выясняю ограничения и сроки реализации.
• Выясняю, какие решения уже приняты или реализованы.
• Выясняю, что не устраивает в существующем варианте.
• Определяю положение элемента в системе и его связи.
• Рассматриваю несколько возможных вариантов.
• При необходимости провожу R&D для их сравнения.
• По совокупности факторов выбираю наиболее оптимальный.
• Описываю принятое решение и как оно решает проблему.
• Описываю плюсы и минусы.
• Описываю риски, их важность и вероятность.
• Описываю способы снятия или смягчения рисков.
• Перечисляю рассмотренные решения и причины их отклонения.
• Указываю этапы реализации и их оценку.
• Описываю возможные дальнейшие шаги развития.
• Описываю способ осуществления архитектурного контроля.
• Презентую идею команде/комитету/руководителю/заказчику.
• Отрабатываю замечания и предложения.

В зависимости от сложности задачи, некоторые пункты могу пропускать или добавлять на очередной итерации доработки и согласования.

Пройдя этот путь мы, наконец, приняли решение. Но принятое решение – это статика, точка в прошлом. Что насчет динамики, развития и пересмотра?

Как мне кажется, этот вопрос до сих пор остаётся открытым. Было бы здорово, если бы кто-то тебе напоминал: “Слушай, помнишь, ты принимал решение X? Сейчас пришло время его пересмотреть!”

Полагаю, мы к этому скоро придём, а сейчас я бы предложил в ADR опционально добавлять пункт Критерии пересмотра решения.

Как минимум, можно обозначить следующие мотивы пересмотра принятых решений:

• Появление новых архитектурных стилей. Например, повторное использование кода в монолитах часто начинает работать как антипаттерн, т.к. увеличивает связность. MSA позволила решить эту проблему.
• Изменения в экосистеме. В мире всё меняется очень быстро. Отвергнутые или недопустимые решения могли стать лучше; возможно, появилось что-то более эффективное. Многие алгоритмы долгие годы пылились на полках в ожидании своего звёздного часа.
• Изменения внешних условий. Условия лицензирования, стоимость подписки или аренды, доступность зарубежных ресурсов, необходимость импортозамещения, политические решения. Своевременная реакция может существенно повлиять на результат.
• Изменение предметной области. Изменение законодательной базы, новый способ налогообложения, пересмотр бизнес-процессов в связи с появлением пресловутой ИИ и т.п. Если подобные вещи могут влиять на архитектурные свойства, решение требует пересмотра.
• Новые возможности хранения. Например, поддержка JSON в ClickHouse эволюционировала постепенно, и долгое время JSON обрабатывали как строку, а не колоночный тип. Это создавало проблемы для тех, кто хотел OLAP для документов с вариативным набором атрибутов.
• Изменение характера нагрузки. Даже если две системы делают одно и тоже, но одна рассчитана на 5k DAU, а другая – на 100k DAU, они будут иметь принципиально разную архитектуру. Например, система прохождения курсов по программированию и система проведения онлайн-олимпиад. В обеих случаях нужно проверять решения, но характер нагрузки совершенно разный.
• Рост объема функций. Здравый смысл подсказывает: начинайте с модульного монолита. Когда разные модули имеют разные архитектурные свойства, нужно серьезно задуматься! Например, что-то нуждается в масштабировании, а что-то нет. Так появляются инсталляции с огромным Heap-ом, а сеньоры с умным видом начинают перебирать различные версии GC.
• Рост количества связей. Когда хореография превращает проект в “клубок”, не ждите, идите в оркестрацию.
• Деградация связей. Начали с синхронного взаимодействия, уперлись в пропускную способность вызываемого сервиса, решили перейти на асинхронное.

---

А что дальше?

Дальше было бы неплохо попробовать автоматизировать процесс “напоминаний”. Добавить в CI автотест, который будет проверять условия пересмотра решений и оповещать об этом ответственных лиц.