Зачем это нужноПочему архитектура не успевает за продуктовыми командами
Команды выпускают изменения каждые две недели, а архитектурный документ обновлялся в прошлом году. Либо команды его не читают, либо архитектор превращается в очередь, в которой стоят все.
Ловушка знакомая. Либо большой проект архитектуры до старта, который устаревает к моменту утверждения, либо «мы agile, архитектура не нужна» — и через два года клубок зависимостей, где стоимость координации выше стоимости разработки. O-AA (Open Agile Architecture), стандарт The Open Group, описывает третий путь: архитектура как непрерывная деятельность, встроенная в ритм поставки. Материал стандарта — не слои предприятия, а строительные блоки самой практики: agile-стратегия, agile-организация, управление, продуктовая, операционная и программная архитектура, — и техники поддержки: предметно-ориентированное проектирование, event storming, картирование потока ценности и клиентского пути.
Отличительный ход O-AA — начинать с клиента, а не с систем: две аксиомы стандарта — фокус на клиентском опыте и мышление снаружи внутрь. Организация должна зеркалить архитектуру (аксиома 12), иначе побеждает оргструктура; команды — автономные, кросс-функциональные и выровненные на один поток ценности. Решения записывают с основаниями (ADR), нефункциональные требования превращают в исполняемые функции пригодности, каталог утверждённых технологий заменяют направляющими ограждениями. Документацию не отменяют — сокращают до того, что удерживает смысл, ответственность и ограничения. В реестре O-AA стоит около корпоративной архитектуры: это стандарт о том, как вести архитектурную работу, а не метамодель предприятия, — поэтому он сочетается с TOGAF и ArchiMate, а не заменяет их.
У O-AA архитектура — способность организации, а не документ перед стартом: решения принимают в ритме поставки и сохраняют их основания.
