Ага. Хотя мне опять же вспоминается Грегор Хоп:

Frequently you will hear the
following comment from these folks: “I used to be technical”. I can’t
help but retort: “I used to be a manager” (it’s true) or “Why did you
stop? Were you no good at it”? If you want to be more diplomatic
(and philosophical) about it, cite Fritz Lang’s movie Metropolis
where the separation between penthouse and engine room almost
led to a complete destruction of the city before everyone realized
that “the head and the hands need a mediator”

#whois Head of R&D в Protectimus. Развиваем свой продукт в области двухфакторной аутентификации

Всем привет! В настоящий момент я рукль технической команды (а вообще ПМ), пилим узконишевую CRM/CMS для правообладателей. #whois

www.jobserve.com
"2,021 jobs for architect positions in the UK"

solution architect - это роль в проекте, которая должна быть равновесной (техническая ответсвенность) координатору проекта (административная ответственность). Обычно solution architect поставляется из архитектурной группы, которую возглавляет enterprise architect. А руководитель группы разработки поставляет в проект своих вdevelopers.

Ну это секторная специализация для business architect и, также, solution architect

Ну в production уже идет разделение отвественности - архитектор, в основном, "надзирает".

А также, enterprise application architect, enterprise business architect, etc.

Растить - интересными задачками в сильной команде

"погружаться в код" - иногда приходится погружаться в ад

В смысле?

погружаться в код, который просто так непонятен и "писатели" не могут его объяснить.

При работе с унаследованными системами разбираться в чужом коде это типовая аналитическая задача. Провести грамотный рефакторинг сложнее.

Вообще я писал про глубокое погружение в написание кода. Можно, но фокус совсем другой

Поэтому главное требование к коду - понятность для тех, что его не писал. "погружение в написание кода" - ну это уже конфликт интересов.

Предлагаю здесь не разводить флейм по поводу качества кода. Понятность весьма поверхностная характеристика кода, требующая конкретизации.

Ну это как известное "Не верю"

Мне кажется, критерий "сложный домен" слишком туманный, чтобы метрику хоть какую приторочить. В первом приближении видится количество и высота уровней абстрвкций. Архитектор должен покрывать те уровни которые не могут быть покрыты разработчиками снизу и аналитиками с бизнесами сверху. Точнее - зацепить их и транслировать изменения в обе стороны. Учитывая естественный человеческий предел в 7+-2 можно прикинуть высоту пирамиды абстракций в средней компании. А что до мест где архитекторов нет - там меньше абстракций и лучше трансляция .кмк.