Архитектурный комитет. В чём подвох? Иногда в проектах сильные инженеры объединяются в надстройку над разработкой - архитектурный комитет. Замысел понятный: экстраполировать договорённости между зонами ответственности на систему целиком, зафиксировать принятые решения и задать общие рамки для команд разработки. Комитет проводит встречи, обсуждает контуры ответственности, согласует взаимодействие компонентов и, в идеале, формирует архитектурные принципы, которым следуют команды. На практике архитектурный комитет перестаёт выполнять эту функцию, если: - архитектурные решения формируются как рекомендации и не закрепляются в виде ADR, обязательных к исполнению самими участниками комитета и зонами их ответственности; - принятые решения остаются обратимыми без формальной процедуры пересмотра и не влекут изменения в подходах, стандартах или ответственности. Если решение комитета можно обойти без пересмотра и фиксации причин - это уже не архитектурное управление, а консультационная модель. В таком случае разбор последствий сводится к коллективным обсуждениям, а управление техническим долгом - к формуле «так исторически сложилось». Возникает эффект деперсонализации ответственности: цена ошибки распределяется на всю команду, а ответственность за последствия оказывается размытой. С другой стороны, архитектурный комитет может тормозить системные изменения. Это происходит, когда участники не готовы брать на себя персональные риски, связанные с реализацией согласованных решений. Такие изменения откладываются под предлогом дополнительного обсуждения или недостаточной зрелости, которое в нужной форме так и не происходит. В результате достигаются компромиссы, достаточные для продолжения текущей работы, но недостаточные для эволюции системы. Фиксируются принятые риски и их причины, однако вектор развития остаётся не определённым. Со временем архитектурный комитет начинает работать ситуативно - как механизм разрешения конфликтов. Решения принимаются большинством, несогласие остаётся внутри, а система продолжает функционировать в существующих рамках. Если в системе с накопленным legacy всем становится комфортно - это, как правило, означает, что архитектура больше не формирует будущее, а лишь поддерживает текущую инерцию.