Посты про роль архитектора вызвали просто бурю обсуждений в комментах. Попробую ещё с одной стороны зайти.

Любой объект можно рассматривать с разных точек зрения и через разную оптику. Это называется концептуальная рамка: через призму каких концепций мы смотрим на объект, что мы в нем выделяем?

Вот деятельность архитектора — это что? У нас был спор в рамке "проектирование"—"не проектирование", и из-за неопределенности этого "не-проектирования" дискуссия дальше не пошла, каждый предлагал что-то своё. Рамка оказалась недоопределена.

Предлагалось деление на проектирование и сбор материалов для проектирования.

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

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

А можем ещё сильнее заострить, и задать вопрос — когда требуется принятие решений? Мне кажется, принимать решение нужно, когда есть конфликт.

То есть, мы можем посмотреть через рамку конфликта. Ещё точнее — конфликта, связанного с техническими и функциональными свойствами системы.

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

У нас в книге, кстати, есть кусок про конфликты, т.к. мой соавтор защитил диссертацию про конфликты в ИТ-проектах.

Технический долг возникает как раз из-за компромиссов и избегания решения конфликтов. ТРИЗ дает советы, как решить конфликт (противоречие) с улучшением всех аспектов и удовлетворением всех сторон.

Гипотеза: архитектор в принципе нужен там, где есть много конфликтов (в технических системах) и их нужно решать.