Всегда интересовала роль архитектора в DDD и Agile ориентированной разработке. Такие фреймворки как Scrum и LeSS явно говорят, что не должно быть такой роли.
Многие авторы тем не менее выделяют такую роль, хотя оговаривают, что это именно роль, а не должность с погонами (анти-паттерн Ivory Tower Architect).

Что же должен делать архитектор, что мы ждем от него, какую добавленную ценность привносит в наш value stream? Что такое архитектура, в конце концов?

В древних манускриптах книгах можно встретить определение архитектуры, как нечто сложно и дорого меняемое. Но уместно ли говорить про дороговизну и сложность изменений в наше время микросервисов? Мы готовы переписать любой микросервис за месяц-два. Или архитектура это само решение использовать микросервисы? Тогда архитектор нужен только на старте проекта.

Мне очень отзывается пост Грегора Хопа, где он связывает необходимость частых изменений и готовность вашего проекта к этим изменениям. Собственно одна из задач архитектора подобрать такие подходы и решения, которые позволят недорого вносить изменения.

И DDD и Agile приветствуют вносимые изменения. Это наш реальный VUCA-мир. Делать софтверный проект годами по плану в комплексном домене (по Киневин) не выйдет, код сам по себе не имеет ценности, он нужен, только когда его предназначение совпадает с текущими бизнес-потребностями. И архитектура должна, конечно же, помогать.

Как у вас? Есть выделенные архитекторы? Как они работают с командой? Пишут ли они код? Насколько погружены в бизнес-домен?