Комментарии 10
НЛО прилетело и опубликовало эту надпись здесь
:) Добрый день, прокомментирую, как человек, развивающий Solution Architecture в EPAM.
>>По моим наблюдениям, они и сейчас успешно справляются с этой ролью, например, в
>> форме архитектурного совета из избранных спецов из разных команд компании…
Да, такое нередко имеет место быть. И группа инженеров может коллегиально играть роль архитектора, если у них в сумме широкий опыт и они способны договариваться до цельного решения. И делать это вполне успешно.
>>Уважаемый Автор, если моя модель неэффективная, поправьте меня, пожалуйста,
>> укажите на конкретную ошибку в рассуждениях выше!
Эта модель может вполне иметь место быть и успешно работать. Если инженеры в команде достаточно зрелы в плане опыта с технологиями и в плане коммуникаций. И, да, две светлые головы всегда лучше одной. :) Однако, это, как мне кажется, скорее будет работать в продуктовых компаниях, где команда годами развивает один продукт — тут есть и устоявшийся контекст для работы команды, и люди «притерлись» друг к другу, и процессы сложились.
Solution Architect как отдельная роль хорош тогда, когда динамика работы — высокая. Т.е. контекст (заказчик, проект, вид активности и даже технологический стек с бизнес-доменом) может меняться несколько раз в год, и нужен кто-то, кто в целом описанные шаги (за исключением пункта 1 — тут бизнес-аналитик почти всегда нужен) будет делать сам от начала и до конца и отвечать за результат единолично. Например, на pre-sale активности, или на discovery-фазе, где группа больше 2-3 инженеров — это уже много. Да и на обычном проекте состав команды бывает очень разный, далеко не всегда в него будут включать все роли. Плюс, на production-проекте архитектор несет полную ответственность за архитектуру, что позволяет избежать ситуации «у семи нянек дитя без глаза». Это я пытаюсь объяснить мое понимание того как вообще Solution Architect возник.
Т.о., и ваша модель работает в определенных случаях, и Solution Architect как отдельная роль тоже часто нужен.
В целом же, несколько лет глубокого погружения в развитие этой дисциплины у нас, набюдение за коллегами, их работой и мнением заказчиков дают мне возможность сказать, что роль Solution Architect является вполне успешной и востребованной. По крайней мере пока. :)
С уважением, Дмитрий.
>>По моим наблюдениям, они и сейчас успешно справляются с этой ролью, например, в
>> форме архитектурного совета из избранных спецов из разных команд компании…
Да, такое нередко имеет место быть. И группа инженеров может коллегиально играть роль архитектора, если у них в сумме широкий опыт и они способны договариваться до цельного решения. И делать это вполне успешно.
>>Уважаемый Автор, если моя модель неэффективная, поправьте меня, пожалуйста,
>> укажите на конкретную ошибку в рассуждениях выше!
Эта модель может вполне иметь место быть и успешно работать. Если инженеры в команде достаточно зрелы в плане опыта с технологиями и в плане коммуникаций. И, да, две светлые головы всегда лучше одной. :) Однако, это, как мне кажется, скорее будет работать в продуктовых компаниях, где команда годами развивает один продукт — тут есть и устоявшийся контекст для работы команды, и люди «притерлись» друг к другу, и процессы сложились.
Solution Architect как отдельная роль хорош тогда, когда динамика работы — высокая. Т.е. контекст (заказчик, проект, вид активности и даже технологический стек с бизнес-доменом) может меняться несколько раз в год, и нужен кто-то, кто в целом описанные шаги (за исключением пункта 1 — тут бизнес-аналитик почти всегда нужен) будет делать сам от начала и до конца и отвечать за результат единолично. Например, на pre-sale активности, или на discovery-фазе, где группа больше 2-3 инженеров — это уже много. Да и на обычном проекте состав команды бывает очень разный, далеко не всегда в него будут включать все роли. Плюс, на production-проекте архитектор несет полную ответственность за архитектуру, что позволяет избежать ситуации «у семи нянек дитя без глаза». Это я пытаюсь объяснить мое понимание того как вообще Solution Architect возник.
Т.о., и ваша модель работает в определенных случаях, и Solution Architect как отдельная роль тоже часто нужен.
В целом же, несколько лет глубокого погружения в развитие этой дисциплины у нас, набюдение за коллегами, их работой и мнением заказчиков дают мне возможность сказать, что роль Solution Architect является вполне успешной и востребованной. По крайней мере пока. :)
С уважением, Дмитрий.
НЛО прилетело и опубликовало эту надпись здесь
>> Кстати, был и опыт подключения Архитектора решений,- кроме абстракций,
>>>использующихся в презентации готовящегося проекта, пользы от него никакой не было,
>>>скорее вред и потери времени от заходов в тупики и плагита идей…
Ну, как и любая профессия, эта работа чувствительна к тому каков человек, ее выполняющий. В нашем понимании, архитектор должен оставаться hands-on с технологиями до самых верхних уровней квалификации включительно. Теоретики не приветствуются. Что означает пользу и применимость результатов работы на практике. Видимо, коллега из вашего примера как раз «теоретик» :(
>>>использующихся в презентации готовящегося проекта, пользы от него никакой не было,
>>>скорее вред и потери времени от заходов в тупики и плагита идей…
Ну, как и любая профессия, эта работа чувствительна к тому каков человек, ее выполняющий. В нашем понимании, архитектор должен оставаться hands-on с технологиями до самых верхних уровней квалификации включительно. Теоретики не приветствуются. Что означает пользу и применимость результатов работы на практике. Видимо, коллега из вашего примера как раз «теоретик» :(
НЛО прилетело и опубликовало эту надпись здесь
>>1. Перед кем Архитектор решений ответственен, т.е. кто обязан его
>> контролировать и какими компетенциями для этого должен обладать?
В нашем понимании, он ответственен перед работодателем. Который несет фин.ответственность перед заказчиком по заключенному контракту. В случае нашей компании, контроль заключается в собеседованиях при найме на работу, после чего он основан на отзывах коллег и представителей заказчика о работе архитектора, оценкой на assessment-комитетах если архитектор идет на следующий уровень.
>>2. Когда и как осуществлять контроль деятельности (и её результатов)
>> Архитектора решений?
Как я уже сказал — в основном контроль основан на отзывах коллег и представителей заказчика. Эти отзывы даются в любой момент времени и доступны ресурсному менеджеру, который и принимает решение о том что делать — увеличивать размер годового бонуса, ставить вопрос об увольнении и т.д.
>>Я правильно понял про «production-проект», что Вы предлагаете это делать на >> фазе эксплуатации, там лучше всего это оценят пользователи, админы
>> поддержки, интеграторы?
Не очень понял ваш вопрос. Архитектор на проекте нужен всегда на старте, в первые несколько месяцев. Потом он нужен меньше и меньше. И ответственность архитектор несет за свои решения и за полную поддержку команды в процессе разработки. В процессе тестирования все проблемы должны быть вскрыты, т.е. до фазы эксплуатации при компетентной команде (включая архитектора), архитектурные проблемы доехать не должны. Кроме того, принципиальные технические решения часто имеет смысл проверять с помощью коротких и быстрых proof-of-concept, где как раз архитектор должен быть очень даже hands-on чтобы лично убедиться в том, что предлагаемый подход будет работать так как требуется.
>> 3(риторический вопрос). Допустим, в будущем, когда потребуется сделать
>> небольшую важную доработку системы очень большой ценой из-за негибкого
>> решения, какую ответственность понесет Архитектор решений, работающий
>> в уже другой компании?
Увы, никакую. Так оно везде в мире. Вот сейчас у бельгийского заказчика принято решение «уволить» созданное пару лет назад решение. Кто-то же у них его проектировал. Кто-то же принимал решение на стороне бизнеса потратить деньги. По сути, как оказалось, напрасно. И, насколько я знаю, никого не наказывали. Бизнес просто вынужен «проглотить» это.
«Чинится» это долгосрочно образовательными программами для архитекторов, менторингом. Кроме того, неплохо работает парная работа.
>> контролировать и какими компетенциями для этого должен обладать?
В нашем понимании, он ответственен перед работодателем. Который несет фин.ответственность перед заказчиком по заключенному контракту. В случае нашей компании, контроль заключается в собеседованиях при найме на работу, после чего он основан на отзывах коллег и представителей заказчика о работе архитектора, оценкой на assessment-комитетах если архитектор идет на следующий уровень.
>>2. Когда и как осуществлять контроль деятельности (и её результатов)
>> Архитектора решений?
Как я уже сказал — в основном контроль основан на отзывах коллег и представителей заказчика. Эти отзывы даются в любой момент времени и доступны ресурсному менеджеру, который и принимает решение о том что делать — увеличивать размер годового бонуса, ставить вопрос об увольнении и т.д.
>>Я правильно понял про «production-проект», что Вы предлагаете это делать на >> фазе эксплуатации, там лучше всего это оценят пользователи, админы
>> поддержки, интеграторы?
Не очень понял ваш вопрос. Архитектор на проекте нужен всегда на старте, в первые несколько месяцев. Потом он нужен меньше и меньше. И ответственность архитектор несет за свои решения и за полную поддержку команды в процессе разработки. В процессе тестирования все проблемы должны быть вскрыты, т.е. до фазы эксплуатации при компетентной команде (включая архитектора), архитектурные проблемы доехать не должны. Кроме того, принципиальные технические решения часто имеет смысл проверять с помощью коротких и быстрых proof-of-concept, где как раз архитектор должен быть очень даже hands-on чтобы лично убедиться в том, что предлагаемый подход будет работать так как требуется.
>> 3(риторический вопрос). Допустим, в будущем, когда потребуется сделать
>> небольшую важную доработку системы очень большой ценой из-за негибкого
>> решения, какую ответственность понесет Архитектор решений, работающий
>> в уже другой компании?
Увы, никакую. Так оно везде в мире. Вот сейчас у бельгийского заказчика принято решение «уволить» созданное пару лет назад решение. Кто-то же у них его проектировал. Кто-то же принимал решение на стороне бизнеса потратить деньги. По сути, как оказалось, напрасно. И, насколько я знаю, никого не наказывали. Бизнес просто вынужен «проглотить» это.
«Чинится» это долгосрочно образовательными программами для архитекторов, менторингом. Кроме того, неплохо работает парная работа.
Интересная информация и ссылки.
Хотя оглавление намекает на описание именно Solution Architecture, про эту роль меньше половины. Да и ощущение, что идет реклама ЕПАМ или чисто роль архитекторов в ЕПАМЕ, а не общая информация
Хотя оглавление намекает на описание именно Solution Architecture, про эту роль меньше половины. Да и ощущение, что идет реклама ЕПАМ или чисто роль архитекторов в ЕПАМЕ, а не общая информация
Еще лет 10 лет назад роль архитектора решений (Solution Architect) на проектах выполняли сами разработчики.
Ребята, ну не нужно такого писать. Или это статья из 90х? А то получается опять «ИТ еще молодая индустрия, поэтому все проблемы роста простительны» и можно строить всякую ерунду.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Большой гайд по профессии архитектора решений (+список полезных ссылок)