Не знаю, но у него явно много свободного времени...

Бывает, что не у него много времени, а у команды мало времени и он как ресурс подключается иногда

Типичная девальвация названия позиции сопровождающаяся рейдерским захватом со стороны соседних. Тоже заебли писать рекрутеры, у которых архитектор это "кодер с IQ >80"
Тоже самое было с уборщицами в гостиницах. Не восстановлю всю цепь но там чё только не было, hospitality manager и т.д. и т.п.
Просто жизнь - вырастает новое тоже самое и называется по-новому
Как шифр в группе детей децва

не кафе, а лаунж-бар или гранд-кафе )

Скорость. Вы не сделаете ее так же быстро и качественно как практик, который есть и которому платят. Это из примитива. Расходы на коммуникацию оставим в пределах погрешности. Если они выше, значит что то не так с процессами.

А теперь возьмем выше - зона ответственности. Отсюда стоимость.
Эскалируем - когда CEO опускается до уровня таски, значит стоимость таски для компании неимоверно растет. Даст таска импакт в стоимость времени CEO (потенциального импакта альтернатив)? Однозначно нет. И не важно, будет он заниматься или нет альтернативой. Даже если он тупо пробездельничал, это выгодней компании, чем если он спустится на уровень таски.

Вот здесь соглашусь. Просто потому что пока ничего не делаешь - приходят в голову полезные мысли. А если в это время кодить, то и на этом собственно всё)

Или я не совсем вас понял, или мы вроде об этом выше и говорим?

Без практики кодажа скорость кодажа (как минимум) уходит, несомненно. Но зачем эта скорость архитектору?

По себе скажу, что обычный мидл напишет то же самое в раза 2 быстрее меня. Но только потому, что не задумывается о последствиях принимаемых решений. Архитектор не должен кодить на скорость, но в идеале должен понимать, как и где можно оптимизировать процесс, знать как нужно сделать в итоге.

Мое видение о том, зачем архитектору уметь кодить заключается прежде всего в итеративности разработки. В BDUF это не критично. А в итеративных разработках - критично.

Многие знатоки архитектуры утверждают (и я убедился в этом на практике), что, если velocity начал проседать, то он проседает с быстротой экспоненты. Если velocity проседает, то значит есть проблемы на уровне системной архитектуры. Именно об этом и говорит 9-й принцип Agile Manifesto (обсуждали в соседнем чате). И эти проблемы должен кто-то исправить, иначе в бюджете может образоваться дыра неуправляемых масштабов. За кривую экономики разработки отвечает архитектура.

Вторая причина зачем нужно уметь кодить - чтобы помогать разработчикам реализовывать решения. У разработчиков часто возникает страх перед неизведанным, и они стараются ходить обходными путями, когда испытывают неуверенность. Скажем так, среднестатестический разработчик на рынке не сделает Event Sourcing самостоятельно в разумные сроки. Ему минимум месяц-два нужно только готовиться к подобной реализации. И архитектор должен или подготовить команду заблаговременно, чтобы команда успела ознакомиться с теорией и типовыми реализациями, или подключиться к процессу разработки, чтобы команда не завалила сроки. Не обязательно кодить, но он должен понимать и предвидеть потребности команд, и быть готовым выступить куратором, или снабдить информацией, требуемой для реализации.

Из моего личного опыта - когда проект имеет неплохое внутреннее качество (в РФ бывают неплохие проекты), то velocity обычно можно увеличить в течении года раз в 5. Т.е. на ту же сумму можно доставить в 5 раз больше business value. А если проект имеет неудовлетворительное внутреннее качество (что я часто наблюдал на заокеанском рынке), то там только за первые полгода зачастую можно улучшить экономику разработки на пару порядков.

Если velocity слишком низкое - то кто будет тогда реализовывать принимаемые решения? А за кривую velocity отвечает, как я говорил уже ранее, - архитектура.

Самый лучший руководитель, которого я когда либо встречал в своей жизни, был главный инженер одного горно-обогатительного комбината. Невероятно эрудированный человек и тиран. Его все уважали и боялись одновременно. Как-то раз я наблюдал, как он в оперативной диспетчерской комбината разговаривал по телефону со слесарем аварийного водоподъема, и рассказывал ему каким гаечным ключом и какую гайку тот должен открутить. Кстати, интересный момент, который его характеризует - он жил в предоставленном комбинатом жилье, ездил на служебной машине (своей у него не было), и в возрасте 65 лет он каждое утро в 6 утра пробегал несколько километров. Я от этого человека многому научился.

Не помню чья была мысль, из Америки, от президентов их вроде. В вольном пересказе:
"У нас есть тысячи экспертов которые могу построить пирамиду, но ни одного, который сказал бы, стоит ли ее строить".

В тандеме со второй цитатой
"Пудун — не символ рыночной экономики, а памятник фараону".
Милтон Фридман (экономист).

Оставлю здесь. Дальше думайте сами. Вам код писать или что то другое.

Иван, чтобы к деталям не цепляться, один вопрос -- в вашем понимании, архитектор руководит разработкой?
Руководит в понятии.. руководитель, менеджер.

Нет. Разработкой руководит руководитель отдела разработки. Но архитектор принимает участие в процессе Collaborative Development, контролирует состояние внутреннего качества программы, и отвечает за то, чтобы программа достигла требуемых Quality-Attributes наименьшей стоимостью в балансе краткосрочных и долгосрочных интересов.

Реагировать на деградацию velocity должен именно архитектор, поскольку это вызвано падением внутреннего качества программы, и ни у кого другого нет достаточной компетенции для этого.

Тут хорошо пересекается со строительством. Архитектор (или конструктор, смотря какое строительство), не выписывает нарядов, но осуществляет архитектурный (конструкторский) надзор и несет за это ответственность.

Услышал.

А почему velocity жёстко с архитектурой связано, не уловил?

Абстрактно -- может, компания в стадии продажи конкуренту, и разработчики демотивированны ниже плинтуса?

Даже если они и демотивированы по такой причине, то деградация velocity будет в худшем случае линейной. А внутреннее качество программы влияет на velocity экспоненциально.

Отвечу вопросом. Что разработчик делает значительную часть времени в процессе разработки?

а с чего вы решили, что создание нового, ну например, продукта, обязательно включает разработку?

Про линейность -- не вижу оснований для такого предположения, если честно.

Ну не могут же они экспоненциально бездельничать)

этим всем пусть занимается системный архитектор. Из соседнего чата)

Совершенно верно. Я там где-то и говорил, что это дело системной архитектуры.