iscra_fmAlexTheRaven Архитетор с поставщиками, бизнесом, руководством ИТ НЕ взаимодействует . С ними взаимодействует руководитель отдела разработки. Совмещение этих ролей одним человеком чревато потерей компетенции как минимум в одной из них. В результате проваливается либо одно,либо другое, либо (что чаще) и то, и другое сразу.

Если же "чистый" архитектор - босс аналитиков, то в ПО будет не то, что нужно Заказчикам, а то, что хочет реализовать архитектор . И не факт, что такое ПО получится потом продать Заказчикам, чтобы было из чего заплатить команде з/п.

Вы наверное хотели сказать обратное, но опечатались.
Если не опечатлись, то опыт действительно печальный. Сочувствую, искренне.
Не опечатался. Общепринятая практика при ведении крупных проектов со "спиральным" жизненным циклом ПО (RUP, MSF) - именно такая. Насколько я знаю, опыт не печальный, а вполне успешный.

По-видимому, Вы под архитектором понимаете "генерального конструктора", который в одном лице и аналитик, и архитектор, и менеджер проекта, и руководитель с точки зрения "представительских функций".

Это эффективно работает, если:
- проект небольшой (до 10 человеко-лет)
- команда небольшая (до 10 человек)
- методология разработки - "гибкая", каждый сотрудник совмещает несколько функций: аналитик, например, может тестировать, а разработчик - заниматься внедрением (кстати и то, и другое в небольших проектах чрезвычайно полезно)
- человек "всё в одном" имеет светлую голову и возможность работать по 14 часов в сутки.

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

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

В одном случае много лет делают чрезвычайно прогрессивную архитектуру и экспериментируют с массой новых (иногда - откровенно абсурдных) идей. Очень много времени уходит на "наведение изящества" и рефакторинг. Но ничего "готового к продаже" ещё не выпустили (а брали обязательства сделать "коробку" за год). Их инвесторы обладают настоящим бизнес-ангельским терпением :) .

Во втором случае всё несколько лучше. Генеральный конструктор считает, что он единственный знает, что нужно Заказчикам. На самом деле, иногда он оказывается прав, т.к. довольно хорошо знает потребности нескольких Заказчиков, хотя довольно специфических и исключительно по опыту многолетней давности. Масса времени уходит на повышение удобства внедрения, приделывание "потенциальных возможностей расширения системы" и всевозможных "прикольных фич для гиков". Но этими возможностями на самом деле никто из Заказчиков давно не пользуется, т.к. контингент пользователей сменился. К тому же у системы есть конкуренты, которые всё, что в системе нужно дорабатывать феерическими shell-скриптами, мучительно править в конфигурационных файлах, извлекать из гигабайтных логов, давно умеют "из коробки, через GUI, тремя щелчками мышкой".