Посты про роль архитектора вызвали просто бурю обсуждений в комментах. Попробую ещё с одной стороны зайти. Любой объект можно рассматривать с разных точек зрения и через разную оптику. Это называется концептуальная рамка: через призму каких концепций мы смотрим на объект, что мы в нем выделяем? Вот деятельность архитектора — это что? У нас был спор в рамке "проектирование"—"не проектирование", и из-за неопределенности этого "не-проектирования" дискуссия дальше не пошла, каждый предлагал что-то своё. Рамка оказалась недоопределена. Предлагалось деление на проектирование и сбор материалов для проектирования. Но мне кажется (из опыта работы архитектором и опыта работы с архитекторами), что архитектор не обязательно проектирует. Продуктом архитектора часто является не сама архитектура системы, а решения относительно архитектуры. Причём часто это могут быть решения о том, чего мы не делаем. Или что мы делаем не в системе. В общем, мы можем рассмотреть деятельность архитектора через рамку принятия решений. А можем ещё сильнее заострить, и задать вопрос — когда требуется принятие решений? Мне кажется, принимать решение нужно, когда есть конфликт. То есть, мы можем посмотреть через рамку конфликта. Ещё точнее — конфликта, связанного с техническими и функциональными свойствами системы. И архитектор не столько проектирует, сколько решает конфликты. А решать их можно по-разному: сотрудничать, побеждать, искать компромисс, избегать, приспосабливаться, находить взаимовыгодные решения. У нас в книге, кстати, есть кусок про конфликты, т.к. мой соавтор защитил диссертацию про конфликты в ИТ-проектах. Технический долг возникает как раз из-за компромиссов и избегания решения конфликтов. ТРИЗ дает советы, как решить конфликт (противоречие) с улучшением всех аспектов и удовлетворением всех сторон. Гипотеза: архитектор в принципе нужен там, где есть много конфликтов (в технических системах) и их нужно решать. From Channel [[Системный сдвиг]] https://t.me/systemswing/836 %% Forward By %%