Начнем с азов: что означает слово «решение» в контексте IT?
Это продукт или комплекс продуктов, который решает конкретную техническую или бизнес-задачу. Решение нужно бизнесу, чтобы увеличить прибыль: оно либо повышает доходы, либо снижает издержки — к примеру, автоматизирует бизнес-процессы и тем самым снижает расходы на оплату труда. Решение встраивается в архитектуру предприятия и связывается с другими ее компонентами. Большинство проектов EPAM направлены на создание решений: разработка от начала и до конца или отдельных компонентов.
Выходит, на каждом проекте по разработке нужен архитектор?
Да. Архитектор отвечает за видение будущей системы. Он придумывает, как построить решение, чтобы оно работало эффективно и соответствовало потребностям заказчика.
Алексей Кожемякин (Director, Technology Solutions, EPAM Belarus):
«Как только инженер задумался о нуждах бизнеса — он ступил на путь Solution Architect».
Почему раньше обходились и без архитекторов?
Роль архитектора решений на проектах играла вся команда целиком, несколько ее членов или один разработчик с высокой квалификацией. Он мог быть сразу и разработчиком, и проектным менеджером, а заодно и архитектором. Со временем (и опытом) пришло понимание, что создание архитектуры слишком важная и объемная задача, чтобы заниматься ей по остаточному принципу.
В отличие от разработчика, архитектор мыслит абстракциями более высокого уровня. Он размышляет не о взаимодействии классов, а о взаимодействии компонентов решения – приложений, веб-сервисов и так далее. Хотя, если требуется, он должен без проблем «провалиться» в детали кода. Кроме этого, бизнес-сторона решения для архитектора важна так же, как и техническая. Разработчики часто фокусируются на технологиях и новых библиотеках, с которыми хочется познакомиться; архитектор же отталкивается от интересов и потребностей заказчика.
Так кто главнее: архитектор или разработчик?
Архитектура и разработка – разные и равноправные направления карьерного пути. Архитектор мыслит более абстрактно, но при этом реже прикасается к коду. К тому же не всегда продумывает все до мелких деталей. Часто команда разработки реализует архитектурную концепцию самостоятельно. А качественно реализовать дизайн решения – это так же важно, как и придумать этот дизайн.
Конкретнее: какими задачами занимается архитектор решений?
В первую очередь архитектор анализирует бизнес-цели заказчика, связанные с новым продуктом. Фокусируется на требованиях, которые повлияют на архитектуру, на программную часть решения и его компоненты. Затем проектирует решение и продумывает его дизайн. Архитектор определяет, из каких компонентов будет состоять продукт, нужно ли разрабатывать его составляющие с нуля или будет уместнее использовать готовые компоненты «из коробки».
Для некоторых частей решения SA делает proof-of-concept – небольшую экспериментально-исследовательскую задачу, чтобы понять, возможно ли реализовать тот или иной функционал.
Архитекторы участвуют в предпродажах, консультируют клиентов, проводят аудит архитектуры существующего решения – оценивают, насколько она эффективна для поставленных задач, можно ли ее оптимизировать, и если да, то как.
В EPAM, например, у архитекторов есть возможность часто менять проекты, что позволяет поработать в разных областях и сферах, напрямую общаться с людьми, непосредственно вовлеченными в основные бизнес- и технологические процессы в компании.
Владимир Казакевич (Senior Solution Architect, EPAM Belarus):
«Каждый понимает слово «бизнес» по-своему. И задача архитектора решений — вникнуть в бизнес заказчика настолько глубоко, насколько это возможно, а главное — результатом его работы должны быть решения, «заточенные» под конкретных заказчиков и их конкретные бизнес-проблемы».
А есть ли какие-то еще архитекторы?
Помимо архитекторов решений это:
Enterprise Architect – создает и поддерживают архитектуру целого предприятия, которая состоит из множества решений.
System Architect – выстраивает инфраструктурную сторону решения, фокусируясь на инфраструктурных облачных сервисах, на ПО, необходимом для поддержки решения после его развертывания.
Quality Architect – выстраивают стратегию тестирования и определяет подход к управлению качеством создаваемого продукта.
В EPAM, например, архитекторы решений пока в большинстве.
Кто может стать архитектором решений?
Как правило, в архитекторы решений вырастают ведущие разработчики. Кандидату следует иметь солидный багаж технических знаний, широкий кругозор, а также опыт руководства командой и проектом. Лидерство и отличные коммуникационные навыки – мастхэв архитектора, который часто становится связующим звеном между командой заказчика и компании. Одна сторона ожидает, что архитектор придет, вникнет в положение дел, все объяснит и поможет с принятием решения. Проектная команда, в свою очередь, ждет от SA решения о том, что и как нужно делать, и в какой последовательности.
Роман Шрамков (Director, Technology Solutions, EPAM Ukraine):
«Для того, чтобы бизнес и менеджмент увидел возможности для применения технологий, нужен настоящий гик, который объяснит им какие в этом преимущества и как это можно сделать».
Помимо разработчиков, попробовать себя в архитектуре решений могут бизнес-аналитики, деливери-менеджеры, проектные менеджеры, ресурсные менеджеры, а также тестировщики-автоматизаторы: для них есть даже специальная поддисциплина — Solution Architecture in Test Automation.
Cтоит отметить, что ожидания от такого специалиста у компании и коллег действительно серьезные. Если ошибку в разработке отдельного компонента можно исправить, то неверное решение и плохая архитектура – могут обернуться огромными потерями для обеих сторон.
Дмитрий Гурский (Lead Solution Architect, EPAM Belarus):
«У того, кто хочет стать архитектором, прежде всего, должно быть желание что-то создавать, строить. И это не навык, который можно прокачать, это внутренняя потребность — либо она есть, либо нет».
Какие образовательные программы для будущих архитекторов есть в EPAM?
Так как Solution Architect, как отдельная должность, появилась на рынке сравнительно недавно, ее понимание в разных компаниях отличается. В EPAM создан центр компетенций по архитектуре, команда которого формирует единое представление об этой роли, основываясь на опыте работы с клиентами, их бизнес-задачах и ожиданиях, лучших практиках, внутренних процессах и системах.
Программа, которую разработали практикующие архитекторы и СTOO компании постоянно обновляется. С одной стороны она учитывает индивидуальный опыт сотрудника, а с другой позволяет выбрать образовательный модуль кастомно.
Для начала можно присоединиться к Architecture Excellence Initiative – глобальному архитектурному сообществу EPAM, чтобы быть в курсе последних новостей и тенденций в области архитектуры. Участники комьюнити еженедельно общаются с архитекторами из более чем 25 стран. Оперативный обмен кейсами, доступ к обширной библиотеке и вебинарам, собранной коллегами – это сюда.
Дальше – обучение в Solution Architecture School. Это уникальная программа, которую в компании создавали с нуля: групповые занятия с лекциями и практикой ведут действующие архитекторы компании. Здесь все как в обычной школе – домашние задания, включающие разработку дизайна, постоянное общение с преподавателями и защита контрольной выпускной работы.
Что делать, если пришел в EPAM уже архитектором?
Архитекторы решений, которые пришли в компанию, могут пройти программу Solution Architecture Basics: это своеобразный помощник архитектора, включающий базовые темы, информацию о возможностях профессионального и карьерного развития, полезные контакты и гайды по инфраструктуре. Все, что поможет быстрее адаптироваться в компании.
Архитекторам буду рады в Global Solution Architecture Team – команде экспертов, которые активно участвуют в развитии дисциплины: разрабатывают лучшие практики в компании, координируют глобальные образовательные программы для архитекторов, консультируют коллег и клиентов.
Ну, а если не хочется останавливаться на достигнутом, можно стать студентом Solution Architecture University — трёхуровневой программы, которая помогает опытным архитекторам синхронизировать знания и заговорить на едином языке. У студентов есть возможность пройти сертификации в Software Engineering Institute, IASA Global и других ассоциациях, с которыми сотрудничает EPAM.
Еще одна инициатива — Solution Architecture Mentoring — менторами в которой выступают опытные архитекторы, технические директора и CTO компании. Менти вовлечены в переговоры с клиентами, вместе с наставниками работают над реальными проектами и задачами. Программа помогает архитекторам «прокачаться» в профессии и даже вырасти до уровня CTO.
Полезные ссылки для настоящих и будущих архитекторов:
Почитать об архитекторах решений в EPAM:
Интервью с CTO EPAM Эли Фельдманом
Lead Solution Architect Дмитрий Гурский об уровнях архитектуры в EPAM для dev.by
5 мифов о работе архитектора решений. Мнение Андрея Трубицына
Книги по теме «Архитектура решений»:
Software Architecture in Practice (3rd Edition)
Designing Software Architectures: A Practical Approach (SEI Series in Software Engineering) 1st Edition
Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspective
DevOps: A Software Architect’s Perspective (SEI Series in Software Engineering)
Implementing Domain-Driven Design
Видео:
The Hard Way to Architects from Front-enders
Authentic Reality: Creating Experiences for Today’s Customers
Blocking and Tackling: The Real Nuts and Bolts of Blockchain
Production Foundation Platform is a Bit More that a Data Lake
Happiness as a Service with Cloud Foundry and OpenShift
Комментарии (9)
DmitriyGurskiy
30.05.2019 14:34:) Добрый день, прокомментирую, как человек, развивающий Solution Architecture в EPAM.
>>По моим наблюдениям, они и сейчас успешно справляются с этой ролью, например, в
>> форме архитектурного совета из избранных спецов из разных команд компании…
Да, такое нередко имеет место быть. И группа инженеров может коллегиально играть роль архитектора, если у них в сумме широкий опыт и они способны договариваться до цельного решения. И делать это вполне успешно.
>>Уважаемый Автор, если моя модель неэффективная, поправьте меня, пожалуйста,
>> укажите на конкретную ошибку в рассуждениях выше!
Эта модель может вполне иметь место быть и успешно работать. Если инженеры в команде достаточно зрелы в плане опыта с технологиями и в плане коммуникаций. И, да, две светлые головы всегда лучше одной. :) Однако, это, как мне кажется, скорее будет работать в продуктовых компаниях, где команда годами развивает один продукт — тут есть и устоявшийся контекст для работы команды, и люди «притерлись» друг к другу, и процессы сложились.
Solution Architect как отдельная роль хорош тогда, когда динамика работы — высокая. Т.е. контекст (заказчик, проект, вид активности и даже технологический стек с бизнес-доменом) может меняться несколько раз в год, и нужен кто-то, кто в целом описанные шаги (за исключением пункта 1 — тут бизнес-аналитик почти всегда нужен) будет делать сам от начала и до конца и отвечать за результат единолично. Например, на pre-sale активности, или на discovery-фазе, где группа больше 2-3 инженеров — это уже много. Да и на обычном проекте состав команды бывает очень разный, далеко не всегда в него будут включать все роли. Плюс, на production-проекте архитектор несет полную ответственность за архитектуру, что позволяет избежать ситуации «у семи нянек дитя без глаза». Это я пытаюсь объяснить мое понимание того как вообще Solution Architect возник.
Т.о., и ваша модель работает в определенных случаях, и Solution Architect как отдельная роль тоже часто нужен.
В целом же, несколько лет глубокого погружения в развитие этой дисциплины у нас, набюдение за коллегами, их работой и мнением заказчиков дают мне возможность сказать, что роль Solution Architect является вполне успешной и востребованной. По крайней мере пока. :)
С уважением, Дмитрий.testopatolog
30.05.2019 16:45это, как мне кажется, скорее будет работать в продуктовых компаниях, где команда годами развивает один продукт
Про продуктовые компании не берусь утверждать. Приводил реальную действующую модель одного из филиалов компании, занимающейся разноплановыми масштабными проектами, связанными с разработкой автоматизированных систем конкретной отрасли. Кстати, был и опыт подключения Архитектора решений,- кроме абстракций, использующихся в презентации готовящегося проекта, пользы от него никакой не было, скорее вред и потери времени от заходов в тупики и плагита идей для выхода из них у команды проектирования и разработки, бессмысленных совещаний и прочей имитации бурной деятельности… но руководству он нравился.DmitriyGurskiy
30.05.2019 17:00>> Кстати, был и опыт подключения Архитектора решений,- кроме абстракций,
>>>использующихся в презентации готовящегося проекта, пользы от него никакой не было,
>>>скорее вред и потери времени от заходов в тупики и плагита идей…
Ну, как и любая профессия, эта работа чувствительна к тому каков человек, ее выполняющий. В нашем понимании, архитектор должен оставаться hands-on с технологиями до самых верхних уровней квалификации включительно. Теоретики не приветствуются. Что означает пользу и применимость результатов работы на практике. Видимо, коллега из вашего примера как раз «теоретик» :(testopatolog
30.05.2019 18:49на production-проекте архитектор несет полную ответственность за архитектуру
Уточните, пож-та:
1. Перед кем Архитектор решений ответственен, т.е. кто обязан его контролировать и какими компетенциями для этого должен обладать?
2. Когда и как осуществлять контроль деятельности (и её результатов) Архитектора решений? Я правильно понял про «production-проект», что Вы предлагаете это делать на фазе эксплуатации, там лучше всего это оценят пользователи, админы поддержки, интеграторы?
3(риторический вопрос). Допустим, в будущем, когда потребуется сделать небольшую важную доработку системы очень большой ценой из-за негибкого решения, какую ответственность понесет Архитектор решений, работающий в уже другой компании?DmitriyGurskiy
31.05.2019 09:56>>1. Перед кем Архитектор решений ответственен, т.е. кто обязан его
>> контролировать и какими компетенциями для этого должен обладать?
В нашем понимании, он ответственен перед работодателем. Который несет фин.ответственность перед заказчиком по заключенному контракту. В случае нашей компании, контроль заключается в собеседованиях при найме на работу, после чего он основан на отзывах коллег и представителей заказчика о работе архитектора, оценкой на assessment-комитетах если архитектор идет на следующий уровень.
>>2. Когда и как осуществлять контроль деятельности (и её результатов)
>> Архитектора решений?
Как я уже сказал — в основном контроль основан на отзывах коллег и представителей заказчика. Эти отзывы даются в любой момент времени и доступны ресурсному менеджеру, который и принимает решение о том что делать — увеличивать размер годового бонуса, ставить вопрос об увольнении и т.д.
>>Я правильно понял про «production-проект», что Вы предлагаете это делать на >> фазе эксплуатации, там лучше всего это оценят пользователи, админы
>> поддержки, интеграторы?
Не очень понял ваш вопрос. Архитектор на проекте нужен всегда на старте, в первые несколько месяцев. Потом он нужен меньше и меньше. И ответственность архитектор несет за свои решения и за полную поддержку команды в процессе разработки. В процессе тестирования все проблемы должны быть вскрыты, т.е. до фазы эксплуатации при компетентной команде (включая архитектора), архитектурные проблемы доехать не должны. Кроме того, принципиальные технические решения часто имеет смысл проверять с помощью коротких и быстрых proof-of-concept, где как раз архитектор должен быть очень даже hands-on чтобы лично убедиться в том, что предлагаемый подход будет работать так как требуется.
>> 3(риторический вопрос). Допустим, в будущем, когда потребуется сделать
>> небольшую важную доработку системы очень большой ценой из-за негибкого
>> решения, какую ответственность понесет Архитектор решений, работающий
>> в уже другой компании?
Увы, никакую. Так оно везде в мире. Вот сейчас у бельгийского заказчика принято решение «уволить» созданное пару лет назад решение. Кто-то же у них его проектировал. Кто-то же принимал решение на стороне бизнеса потратить деньги. По сути, как оказалось, напрасно. И, насколько я знаю, никого не наказывали. Бизнес просто вынужен «проглотить» это.
«Чинится» это долгосрочно образовательными программами для архитекторов, менторингом. Кроме того, неплохо работает парная работа.testopatolog
31.05.2019 13:49В процессе тестирования все проблемы должны быть вскрыты, т.е. до фазы эксплуатации
1. С одной стороны, а когда, если не на фазе эксплуатации Вы полагаете можно проверить, что решение Архитектора действительно повысило продуктивность у Заказчика, повысило управляемость и эффективность его бизнес-процессов и удовлетворяет их участников, способно решить потенциальные проблемы с наименьшими рисками?
2. С другой стороны, основные характеристики архитектуры: гибкость, масштабируемость, многократность использования и безопасность… Я правильно понимаю, что Вы на Тестировщиков возлагаете анализ и проверку безопасности сетевой топологии, уместности используемых протоколов, оптимальности выбора/построения аппаратной инфраструктуры, корректности декомпозиции системы на компоненты и модули в рамках эффективности их конфигурации/ развертывания/ мониторинга/ резервирования/ масштабирования..., универсальности форматов структур данных и организации их потоков, выбора оптимальных технологий реализации ПО… т.е. Вы, по сути, на Тестировщика и возлагаете роль контролера деятельности Архитектора решений, тем самым требуете от Тестировщика не меньших компетенций, дополнительно к тем, что непосредственно требуются от него для дизайна тестов, подготовки наборов данных и конфигураций, автоматизации функционального и тестирования производительности системы, ручного тестирования…?
dmitriyAltsyvanovych
30.05.2019 14:34Интересная информация и ссылки.
Хотя оглавление намекает на описание именно Solution Architecture, про эту роль меньше половины. Да и ощущение, что идет реклама ЕПАМ или чисто роль архитекторов в ЕПАМЕ, а не общая информацияDmitriyGurskiy
30.05.2019 17:03>> Да и ощущение, что идет реклама ЕПАМ
Ну, корпоративный блог для опосредованной рекламы, думаю, как раз и заводят. :) Сложно коллег корить за это.
testopatolog
Примечание 1: Несколько светлых голов в совете лучше одной архитектора решений.
По участию и обязанностям (которые типа вменяются архитектору решений) всё просто с привлечением обычных ролей:
1. сначала бизнес-аналитик выполняет глубокий анализ потребностей/целей заказчика, формирует функциональные требования;
2. затем системный архитектор обследует инфраструктуру заказчика, на которой будет разворачиваться решение, уточняет нефункциональные требования, планирует необходимые мощности/ресурсы;
3. далее программный архитектор проекта от команды, которая будет реализовывать решение, выполняет обследование систем интеграции, выясняет особенности интерфейсов и режимов эксплуатации;
Примечание 2: Каждый (из пп. 1..3) специфически заточенный профи, в сумме они достигают такой глубины познания, которой не постичь одному архитектору решений;
4. собранная инфа агрегируется/систематизируется и выносится на архитектурный совет, на котором формируется видение будущей системы (масштабируемой гибкой архитектуры системы, состоящей из взаимодействующих отказоустойчивых компонент и оптимальных технологий их построения с использованием имеющихся наработок) и передаётся в команду разработки программному архитектору проекта;
5. менеджер проекта постоянно находится в курсе интересов и потребностей заказчика, информирует его об архитектуре решения и согласовывает необходимые мощности/ресурсы для её будущего развертывания/эксплуатации;
6. архитектурный совет и в процессе разработки (меняющихся требований и прочих обстоятельств) может при необходимости привлекаться столько, сколько потребуется;
Примечание 3: С точки зрения риска выхода из проекта, архитектурный совет намного надежнее одного архитектора решений.
Уважаемый Автор, если моя модель неэффективная, поправьте меня, пожалуйста, укажите на конкретную ошибку в рассуждениях выше!
Желаю Вам успеха.