18 июня 2026 года InfoQ пересказал доклад Эндрю Хармила-Ло на GOTO Copenhagen о том, как принимать архитектурные решения без привычного театра одного архитектора. Рецепт на удивление не про новый фреймворк, а про дисциплину: короткие Architecture Decision Records, асинхронные советы коллег и открытый еженедельный архитектурный форум. Для русскоязычных команд это звучит особенно прикладно: чем сложнее стек и чем больше людей трогают систему, тем дороже становятся решения, принятые в личке или «на опыте».
Как пишет InfoQ, Хармил-Ло предлагает смотреть на архитектуру не как на набор больших схем в Confluence, а как на процесс принятия решений. В его модели человек или команда, которая реально меняет систему, не просит разрешения, а запрашивает совет и при этом сохраняет ответственность за итог. Поддержкой для этого служат легкие ADR: короткие записи, в которых фиксируются контекст, выбранный вариант и причины выбора. Смысл не в бюрократии, а в том, чтобы заставить мысль пройти через текст. Если перевести на язык ежедневной разработки, это способ не спорить бесконечно в созвоне о Kafka, REST, очередях, границах сервисов и правах доступа, а быстро зафиксировать, что именно решили и почему.
Ключевой тезис здесь неприятен для любителей архитектурной вертикали: хорошие архитектурные решения не обязаны рождаться только у людей с титулом architect в подписи. По версии Хармила-Ло, ADR помогают принимать маленькие, обоснованные решения быстрее и вовлекают ровно тех людей, которых нужно вовлечь в конкретный момент. Асинхронный формат еще и полезен чисто технически: не все думают одинаково быстро в митинге, а письменный совет дает время сформулировать аргументы без давления комнаты. В результате ADR превращаются не только в журнал изменений архитектуры, но и в карту того, как команда вообще рассуждала. Для онбординга это почти золото: новый инженер видит не только текущее состояние системы, но и весь неловкий путь, который к нему привел.
Отдельная деталь, которая делает подход рабочим, а не декоративным, это еженедельный архитектурный форум. Хармил-Ло описывает его как открытую для всех регулярную встречу, где можно вынести ADR, получить синхронную обратную связь и просто посмотреть, как в компании принимаются решения. Это важно не из соображений корпоративной теплоты, а потому что архитектура в классическом исполнении слишком часто уезжает за закрытые двери. Там, где решения обсуждаются только между «старыми» людьми, остальные либо молча исполняют, либо тихо обходят процесс. Форум снижает порог входа: кто-то приходит просто послушать, кто-то впервые показывает свой ADR, кто-то видит, что спорить о системных компромиссах можно без политического триллера.
В этой истории есть и неприятная часть. Самая частая причина провала, по словам Хармила-Ло, не в плохом шаблоне документа и не в неудачном расписании встреч, а в дефиците доверия. Люди, которым формально дали право решать, иногда боятся им пользоваться. Более опытные коллеги, наоборот, нередко занимают все доступное пространство и возвращают систему к старой модели: «давайте я быстро скажу, как правильно». Еще один типичный сбой — решения, которые проходят ниже радара. Команда либо не распознает их как архитектурные, либо опасается лишний раз поднимать тему, ожидая запрета сверху. И здесь звучит важное уточнение: в advice process никто не обязан идти за разрешением. Нужно запросить совет, а не индульгенцию.
Контекст у этой дискуссии понятный. За последние годы отрасль уже насмотрелась на последствия решений, которые принимались либо слишком централизованно, либо слишком хаотично. Хармил-Ло прямо напоминает про микросервисы: обещанная автономия команд во многих случаях закончилась распределенным монолитом, где формально сервисов много, а независимо двигаться не может никто. С появлением все более сложных цепочек поставки ПО, внешних API, внутренних платформ и инструментов на базе LLM проблема только обостряется. Архитектура никуда не исчезла, просто теперь она сильнее завязана не только на код и инфраструктуру, но и на социотехническую организацию: кто что меняет, кто с кем согласуется и где вообще проходит граница ответственности.
Для разработчиков и тимлидов практический вывод довольно приземленный. Если в компании архитектурные решения до сих пор живут в головах нескольких людей или растворяются в тикетах, ADR в облегченном формате могут дать очень быстрый эффект. Не за счет красоты процесса, а за счет снижения стоимости возврата к прошлому решению. Для продактов и IT-директоров в этом тоже есть выгода: меньше архитектурных бутылочных горлышек, меньше зависимость от одного «гуру», проще объяснять, почему команда выбрала именно такой путь. Для HR и руководителей инженерных функций польза еще прозаичнее: рынок давно дорогой, а знания, которые нельзя передать и проверить, превращаются в риск для найма, онбординга и удержания людей.
Главный вопрос теперь не в том, нужны ли компаниям архитекторы, а в том, готовы ли они делиться архитектурной властью без имитации демократии. Если отрасль действительно хочет больше скорости и меньше случайных распределенных монолитов, то архитектурные решения придется делать не сакральным актом, а повторяемой командной практикой, где текст, обратная связь и ответственность важнее должности на визитке.