IMHO:
1) проверять требования аналитика на корректность и реализуемость, вводить ограничения
2) проектировать компоненты, структуры данных и алгоритмы, которые будут обеспечивать выполнение требований
3) помогать менеджеру проекта в постановке и распределении задач
4) консультировать программистов.

А6дуллаh3<...> Архитектор - босс аналитиков. Рисует крупными блоками, проверяет нарисованное или приходящее снаружи, поставщиками, бизнесом, руководством ИТ.
Да ладно :) . У аналитика есть информация о том, что нужно Заказчику. А у архитектора - насколько это реализуемо при текущем уровне технологий и компетенции команды, и насколько укладывается в существующую архитектуру. Да, требования согласуются с архитетором, но в управленческой иерархии аналитик и архитетор - на одном уровне. И кстати, на одном уровне с программистами и тестировщиками. Да-да.

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

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

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

Но если аналитики подчиняются продавцам - тоже ерунда получается, в результате образуется bloatware из реализаций на скору руку противоречивых "срочных хотелок" Заказчиков, которым никто не может сказать "нет".

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

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

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

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

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

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

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

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

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

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