<не уверен, что это сюда, но не нашёл раздела "сравнение методологий">

Вышел у меня на днях спор: кто такой системный архитектор?

Я говорил, что это как у нас, это такой программист-тренер, который (как минимум):

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

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

При этом архитектор может попросить уточнить требования, но сам их не диктует, аналитиками не управляет, с Заказчиками не беседует, roadmap единолично не задаёт.

А мне два человека, называющих себя, по-видимому, системными архитекторами, говорили, что архитектор - это вообще "всё-в-одном", в т.ч. владелец проекта:

• сам с Заказчиками и более высокими начальниками "на высоком уровне" общается
• "на высоком уровне, стратегически" определяет, что система будет уметь, из чего состоять, как работать
• выдаёт задачи аналитикам "опиши то так, опиши это этак"
• организовывает и согласовывает работу всех остальных.

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

Дамы и господа, как у кого разработка с точки зрения роли системного архитектора устроена? У кого к какому варианту склоняется, и что из этого получается?

"на высоком уровне, стратегически" определяет, что система будет уметь, из чего состоять, как работать

А мне всегда казалось, что только Заказчик определяет, ""на высоком уровне, стратегически" определяет, что система будет уметь", и даже не Аналитик и МП, а тем более Архитектор.

Я работал по классической схеме Заказчик->Аналитик->Архитектор->Разработчик->...
Причем, Архитектор был как явный, когда писались Архитектурные Решения, так и неявный, когда эту роль играл наиболее опытный Разработчик и он делал наиболее сложные куски.

ИМХО и другие варианты возможны, тем более у нас, т.к. единой терминологии нет. Например, у нас Аналитиком могут называть и Архитектора и Постановщика Задач и Бизнес-Аналитиком и ...

IMHO архитектор создает, управляет построением и контролирует архитектуру разрабатываемой системы Собственно, это ключевой момент при выделению роли архитектора и определении необходимых навыков.
Это во-первых.
Во-вторых, источником информации для архитектора являются требования к системе, которые идут от аналитика (преобразовавшего требования заказчика в некий формализованный вид),
В-третьих, источником требований также являются возможности имеющегося материала - существующие в распоряжении архитектора компоненты. (хотя у нас обычна практика, когда таковых вообще не имеется, в связи с этим одна из задач архитектора обеспечить их наличие/разработку).
В-четвертых, архитектор не управляет в прямом смысле персоналом (разработчиками), он определяет (!) решение и отвечает за это. А разработчики реализуют (!) это решение. Поэтому прикинуть трудоемкость архитектор конечно может (из опыта), но фактическую оценку дает ответственный за разработку программист (опять же у нас так обычно построена работа). Так что не архитектор за это отвечает.

Важно: порядок формирования и обсуждения решения может быть любым, как сверху (как бы это ни было неприятно и неудобно для программирующей братии), так и снизу.

И не забываем, что архитектура системы нужна не сама для себя, а для реализации системы, УДОВЛЕТВОРЯЮЩЕЙ ПРИНЯТЫМ (утвержденным, согласованным) ТРЕБОВАНИЯМ!

А мне всегда казалось, что только Заказчик определяет, ""на высоком уровне, стратегически" определяет, что система будет уметь", и даже не Аналитик и МП, а тем более Архитектор.

Вопрос "кто определяет" в приведенной трактовке спорный, все перечисленные лица скорее участвуют в процессе разработки требований к системе (не забываем, что требования к системе бывают разные, а не только функциональные)

Я работал по классической схеме Заказчик->Аналитик->Архитектор->Разработчик->...
Причем, Архитектор был как явный, когда писались Архитектурные Решения, так и неявный, когда эту роль играл наиболее опытный Разработчик и он делал наиболее сложные куски.

Правильно, Архитектор (как и другие участники) - это РОЛЬ! Способы реализации этой роли могут быть весьма разнообразны. Аналогично и по другим приведенным примерам...

И, наконец, ответ на исходный вопрос: как лучше?
Лучше так, как работает как бы банально это не звучало. У нас бывают случаи, когда подобную роль играет человек, который и швец, и жнец, и на дуде игрец - и при этом у него всё получается, в таких случаях его можно не трогать. А если есть проблемы, т.е. человек не справляется - тогда надо раскидывать ролевые функции по другим участникам (к сожалению, они обычно воспринимают это дело в штыки).

P.S. Советую посмотреть на роль архитектора при строительстве зданий и т.п., что он делает и чего не делает. С программной индустрией очень схоже. Отличаются материалы и методы реализации :о)))

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

Архитектор - человек, разрабатывающий эту картину в виде документа, пакета документов или модели.

бери шире - системы.

Например, в большой степени зависит именно от архитектуры и архитектора способность работы системы в режиме реального времени или какие-то другие неочевидные и зачастую нефункциональные (а даже и функциональные) особенности системы

А как обстоят дела с самым главным критерием - [финансовым] результатом?

Встречались ли Вы на практике с ситуациями, когда

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

2) Все были ориентированы на требования, архитекторы могли делать что-либо только в рамках требований, и
2.а) всё получилось, система нормально работала и удовлетворяла нужды Заказчиков
2.б) система превратилась в безумное bloatware, и несмотря на формальное удовлетворение требований, была такой нецелостной, некачественной и без внутренней идеи, что никому не была нужна?

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

была ситуация и 2.а и 2.б

Обычно кого назвали архитектором, тот и есть. То есть у всех по своему.

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

Один комментарий ... Архитектура - это собственно структура и связи. А их описание - это architecture description.

А Вы что-нибудь знаете о том, как устроена разработка у больших и успешных, наподобие Microsoft, Google, Oracle, SAP? Autodesk, Corel, Borland, Symantec, Novell, Electronic Arts и других "богатых и знаменитых"? Какие у них используются методологии, есть ли там роль "авторитарный суперархитектор"?

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

Я пока только с 2.а сталкивался.
И у нас архитектор - точь в точь как и у AlexTheRaven.

Насчет гугла надо Дениса Бескова спросить.

Насчет гугла надо Дениса Бескова спросить.

Ага, я тоже клюнул на эту первоапрельскую шутку.

Добрый день

По поводу роли архитектора и его активностей в проекте.

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

Это и логично т.к. в процессе разработки ПО, что ни говори кодирование и проектирование первично - без них системы не будет вообще (разработка требований и тестирование очень желательно, но не обязательно).

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

В проектах же с четко регламентированными активностями для каждой роли в проекте и хорошо поставленными процессами, управление проектом и требованиями становится выделенным и архитектор занимается лишь перечисленными Вами активностями (в моих проектах они  + - такие же )

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

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

Ida,

Я работаю в компании CMM Level 3  в России

Два года назад принимал участие в сертификации нашей компании на  CMMI Level 5 SCAMPI B

Насколько я знаю Luxoft имеет CMMI Level 5

Гигантский скачок в развитии индустрии что ли проспала...
Или теперь сертификация подешевела... антикризисные расценки.

Однозначно проспала. В России даже собственный CMMI оценщик уже появился.

http://ocenchiki.ru/2009/pervyj-v-rossii-ocenshhik-po-cmmi/