Мое видение о том, зачем архитектору уметь кодить заключается прежде всего в итеративности разработки. В BDUF это не критично. А в итеративных разработках - критично.
Многие знатоки архитектуры утверждают (и я убедился в этом на практике), что, если velocity начал проседать, то он проседает с быстротой экспоненты. Если velocity проседает, то значит есть проблемы на уровне системной архитектуры. Именно об этом и говорит 9-й принцип Agile Manifesto (обсуждали в соседнем чате). И эти проблемы должен кто-то исправить, иначе в бюджете может образоваться дыра неуправляемых масштабов. За кривую экономики разработки отвечает архитектура.
Вторая причина зачем нужно уметь кодить - чтобы помогать разработчикам реализовывать решения. У разработчиков часто возникает страх перед неизведанным, и они стараются ходить обходными путями, когда испытывают неуверенность. Скажем так, среднестатестический разработчик на рынке не сделает Event Sourcing самостоятельно в разумные сроки. Ему минимум месяц-два нужно только готовиться к подобной реализации. И архитектор должен или подготовить команду заблаговременно, чтобы команда успела ознакомиться с теорией и типовыми реализациями, или подключиться к процессу разработки, чтобы команда не завалила сроки. Не обязательно кодить, но он должен понимать и предвидеть потребности команд, и быть готовым выступить куратором, или снабдить информацией, требуемой для реализации.
Из моего личного опыта - когда проект имеет неплохое внутреннее качество (в РФ бывают неплохие проекты), то velocity обычно можно увеличить в течении года раз в 5. Т.е. на ту же сумму можно доставить в 5 раз больше business value. А если проект имеет неудовлетворительное внутреннее качество (что я часто наблюдал на заокеанском рынке), то там только за первые полгода зачастую можно улучшить экономику разработки на пару порядков.
Если velocity слишком низкое - то кто будет тогда реализовывать принимаемые решения? А за кривую velocity отвечает, как я говорил уже ранее, - архитектура.
Самый лучший руководитель, которого я когда либо встречал в своей жизни, был главный инженер одного горно-обогатительного комбината. Невероятно эрудированный человек и тиран. Его все уважали и боялись одновременно. Как-то раз я наблюдал, как он в оперативной диспетчерской комбината разговаривал по телефону со слесарем аварийного водоподъема, и рассказывал ему каким гаечным ключом и какую гайку тот должен открутить. Кстати, интересный момент, который его характеризует - он жил в предоставленном комбинатом жилье, ездил на служебной машине (своей у него не было), и в возрасте 65 лет он каждое утро в 6 утра пробегал несколько километров. Я от этого человека многому научился.
» Вторая причина зачем нужно уметь кодить - чтобы помогать разработчикам реализовывать решения
» И архитектор должен или подготовить команду заблаговременно, чтобы команда успела ознакомиться с теорией и типовыми реализациями
Да, активно исповедую этот подход.
Если говорить не "архитектор" тут, а "играющий тренер" - то это ок, архитектурной составляющей не так много - но много R&D с связанного с ним.
Использую, когда важен результат - но явно видно, что команда не будет готова говорить про "то, что не относится к CJM/USM".
Другими словами, когда замечаешь "туннельный синдром" у команды, и есть время и ресурс - то стоит помочь ребятам увидеть "то, что тебе никогда не расскажет заказчик, так как сам про это не знает".