Солюшн должен все в одно лицо под ключ, если объем небольшой, сроки горят, а других ресурсов нет или дольше их выбивать чем сделать :)

И потом тех поддержке помогать ещё.

Игорь, тут еще вопрос о функции архитектуры и конкретных ролях. То есть  Solution Architect , как человек отвечающий в большей степени за правильную коммуникацию технических решений не обязан писать код. Но если Архитектор действительно хочет выстроить эффективную в долгосрочном периоде архитектурную функцию, то он обязан опускаться до уровня кода. Если посмотреть книги, где затрагиваются аспекты Эволюционной Архиетектуры, то  дизайн ПО там занимает чуть ли не центральную роль. Например нельзя сделать эффективную MSA, если нет развитой культуры разработки, где люди не понимают как правильно применять DDD, Hexagonal Architecture и т.д.

И алертинг на себя завязать, чтобы поменьше спать по ночам.

а ведь такое явление как "пиджак" в армии появилось задолго до "башни из слоновой кости" у айтишников

Найму 5 таких.

В моё время это всё сваливалось на админа )

Таких 5 тоже не помешает))

Они инженеры эксплуатации как космонавты на самом деле) На пилота имеет право учить колледж, а не вуз, потому что пилот не проектирует самолеты.

Еще раз, Андрей. Все, что ты говоришь про то, что важно - правильно. Никто с этим не спорит, вот решительно никто. Просто теперь приземли это на систему разделения труда, где есть два уровня управления архитектурой - Software Architect (а еще Infrastructure Architect, Security Architect, etc) и Solution Architect.

Ну по факту это моя задача правильно применить DDD и прочие паттерны. Понятно, что их выполнение в коде я не проверю, но тут будет достаточно и проверок на уровне контрактов.

Так же и с кодом. В сам код я не залезу, но набросать схему CI/СD процесса я в состоянии. Договориться о покрытии кода всякими тестами на сборках тоже осилю. Т.е. дорогу покажу, заборы поставлю. За ручку в нужном направлении не проведу, это правда. И покраску забора (подгон тестов под статистику, а не под смысл) тоже могу не заметить.

С другой стороны, я могу это и софтами компенсировать. Например, настроив коммуникации с теми самыми разработчиками, которые в код умеют. Они мне сами про проблемы и расскажут. Вот если таких разработчиков просто нет... тогда проблема.

Да вот это как раз и проблема, что все эти книжки уходят в дизайн, который очень сильно зависит от конкретной экосистемы и, зачастую, вообще не существенен (зависит от проекта, конечно). Я вообще стараюсь различать архитектуру и дизайн кода, это про разное (и может даже противоречить).
И зачем для MSA нужен DDD/Hexadecimal внутри конкретного сервиса - вообще не понятно, там обычно вообще нет разницы, как написан конкретный сервис, важнее что между сервисами.

Вот вы все про код, да про код. А с моей позиции в работе архитектора очень много разносторонней аналитики. Подготовка принятия решений это серьёзная работа. Особенно когда от принятого решения зависит работа сотен людей.
Когда вы будете качественно выполнять работу подготовки Solution, у вас просто не останется времени на выяснение деталей в коде. Оставьте это ведущим разработчикам, поверьте, они сделают эту работу не хуже.

Это как с продактами: один занимается микроменджментом в команде, указывая кому куда какой пиксель подвинуть,
а другой действительно занимается аналитикой продукта, расчетом бизнес-модели

А потом все начинают рассказывать почему MSA не работает и не надо ли снова делать монолит...

Ну так MSA не работают обычно не из-за того, что внутри сервиса, а как раз из-за проблем между сервисами.
Вот ни разу не видел проблем в MSA из-за неиспользования гексогоналки в отдельном сервисе )

Угу. А для некоторых решений нужно архитектору еще и группу разработчиков придавать для экспериментов или реверс-инжиниринга.

Идеального солюшена не существует. Это всегда решения с серьезно ограниченным горизонтом. Корп архитектура вполне может предусматривать поколения солюшена. Т.е. сегодня пилим на экосистеме 1С, завтра на PHP, послезавтра на java. И отсюда следует, что солюшен должен осознавать разумное качество своей работы.

Ну это в большой компании с обширным набором legacy-систем. Здесь же шла речь про не очень большую. И кто-то должен выстроить архитектурный процесс. Без кода будет сложно.

А что значит "не очень большая"?

Если человек 10, то там техлида достаточно.
А если 100, то уже solution arch не до кода.