Штош, все сроки просраны (как в жизни), но под вечер воскресенья попробую отдать хоть часть долга.

Итак...

Рассказывая в рамках конференций, личных бесед или рабочих обсуждений об архитектурных решениях, я часто говорю, что мы не обязаны принимать некоторые решения прямо сейчас. И что вообще одна из функций современного архитектора — помогать откладывать принятие важных решений на попозже.

Эту фразу я впитал в голову несколько лет назад, даже не помню, где (нейросети подсказывают, что это было в книгах у Форда и Ричардса, а также в каких-то книгах по Agile Software Development, которые я если и читал, то по диагонали).

Для многих людей, для которых архитектура — это в первую очередь то, что дорого менять, поэтому надо это решить как можно раньше, это вызывает диссонанс. Более того, на одной из конференций меня даже как-то попросили «пояснить за базар» (цитата). И посмотрев топовую презентацию от Грегори Хоупа, автора книги про паттерны интеграции и автора знаменитой метафоры про «архитектурный лифт», я у себя в голове наконец-то вроде как смог сформировать такое пояснение. Попробую оформить.

Архитектурные решения действительно являются важными, потому что:
🔹 на них базируется множество других, более частных решений
🔹 они влияют на множество свойств и «разрезов» системы сразу
🔹 их принятие требует компромиссов (иначе говоря, «мы не сделаем всех счастливыми, поэтому сделаем всех одинаково несчастными»)

Примеры таких решений на моей практике: buy or build, выбор пути развития системы/подсистемы, выбор технологий (разной степени), выбор общих принципов и подходов («фреймворк»). Далее на каждом уровне абстракции таких решений наберётся ещё несколько десятков — от выбора подхода к версионированию сущностей до определения порядка сборки репозиториев для деплоя на стенд. Помните, что архитектура — это то, что важно именно для вас, поэтому это не всегда разговоры о стратегии и высоких материях.

И да, стоимость изменения таких решений в будущем действительно будет выше, чем для других. Именно поэтому во времена big design up-front существовала иллюзия, что такие решения надо принять как можно раньше, в момент старта проекта/создания продукта и как можно «правильнее». Уже тогда это было «сомнительно, но окэ».

Теперь же, в эпоху lean IT практик и agile трансформации SDLC (ключевое свойство которой — заказчик/потребитель больше не готов мириться с отлитыми в бронзе требованиями и решениями, которые меняются раз в цикл) это в принципе невозможно: на момент старта у нас недостаточно информации, мы не можем учесть все аспекты контекста, не можем заглянуть в будущее (привет, расчёты сайзинга — самая «полезная» и «эффективная» часть современного ИТ).

В итоге мы:
🔹 либо принимаем решение под давлением желания сделать хоть что-то и миримся с необходимостью всё переделать в будущем (возможно, далёком, но, скорее всего, ближайшем)
🔹 либо пытаемся отложить принятие решения до момента, когда это действительно необходимо (в англоязычных материалах это называется last responsible moment) и затем уже принимаем решение (хотелось бы верить, что «осознанно и рационально», но...)

Что с этим делать и при чем тут архитектор и архитектура - расскажу в следующем посте, а то и так много получилось, обещал больше одного-двух экранов не писать)