Большой гайд по профессии архитектора решений (+список полезных ссылок)

    Еще лет 10 лет назад роль архитектора решений (Solution Architect) на проектах выполняли сами разработчики. Теперь это отдельная профессия, довольно востребованная и активно обсуждаемая. Вместе с коллегами-архитекторами подробно разбираемся во всех деталях и рассказываем, как стать архитектором в EPAM.

    Начнем с азов: что означает слово «решение» в контексте 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
    EPAM
    Компания для карьерного и профессионального роста

    Comments 10

    • UFO just landed and posted this here
        +3
        :) Добрый день, прокомментирую, как человек, развивающий Solution Architecture в EPAM.

        >>По моим наблюдениям, они и сейчас успешно справляются с этой ролью, например, в
        >> форме архитектурного совета из избранных спецов из разных команд компании…

        Да, такое нередко имеет место быть. И группа инженеров может коллегиально играть роль архитектора, если у них в сумме широкий опыт и они способны договариваться до цельного решения. И делать это вполне успешно.

        >>Уважаемый Автор, если моя модель неэффективная, поправьте меня, пожалуйста,
        >> укажите на конкретную ошибку в рассуждениях выше!

        Эта модель может вполне иметь место быть и успешно работать. Если инженеры в команде достаточно зрелы в плане опыта с технологиями и в плане коммуникаций. И, да, две светлые головы всегда лучше одной. :) Однако, это, как мне кажется, скорее будет работать в продуктовых компаниях, где команда годами развивает один продукт — тут есть и устоявшийся контекст для работы команды, и люди «притерлись» друг к другу, и процессы сложились.

        Solution Architect как отдельная роль хорош тогда, когда динамика работы — высокая. Т.е. контекст (заказчик, проект, вид активности и даже технологический стек с бизнес-доменом) может меняться несколько раз в год, и нужен кто-то, кто в целом описанные шаги (за исключением пункта 1 — тут бизнес-аналитик почти всегда нужен) будет делать сам от начала и до конца и отвечать за результат единолично. Например, на pre-sale активности, или на discovery-фазе, где группа больше 2-3 инженеров — это уже много. Да и на обычном проекте состав команды бывает очень разный, далеко не всегда в него будут включать все роли. Плюс, на production-проекте архитектор несет полную ответственность за архитектуру, что позволяет избежать ситуации «у семи нянек дитя без глаза». Это я пытаюсь объяснить мое понимание того как вообще Solution Architect возник.

        Т.о., и ваша модель работает в определенных случаях, и Solution Architect как отдельная роль тоже часто нужен.

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

        С уважением, Дмитрий.
        • UFO just landed and posted this here
            +3
            >> Кстати, был и опыт подключения Архитектора решений,- кроме абстракций,
            >>>использующихся в презентации готовящегося проекта, пользы от него никакой не было,
            >>>скорее вред и потери времени от заходов в тупики и плагита идей…

            Ну, как и любая профессия, эта работа чувствительна к тому каков человек, ее выполняющий. В нашем понимании, архитектор должен оставаться hands-on с технологиями до самых верхних уровней квалификации включительно. Теоретики не приветствуются. Что означает пользу и применимость результатов работы на практике. Видимо, коллега из вашего примера как раз «теоретик» :(
            • UFO just landed and posted this here
                +2
                >>1. Перед кем Архитектор решений ответственен, т.е. кто обязан его
                >> контролировать и какими компетенциями для этого должен обладать?

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

                >>2. Когда и как осуществлять контроль деятельности (и её результатов)
                >> Архитектора решений?

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

                >>Я правильно понял про «production-проект», что Вы предлагаете это делать на >> фазе эксплуатации, там лучше всего это оценят пользователи, админы
                >> поддержки, интеграторы?

                Не очень понял ваш вопрос. Архитектор на проекте нужен всегда на старте, в первые несколько месяцев. Потом он нужен меньше и меньше. И ответственность архитектор несет за свои решения и за полную поддержку команды в процессе разработки. В процессе тестирования все проблемы должны быть вскрыты, т.е. до фазы эксплуатации при компетентной команде (включая архитектора), архитектурные проблемы доехать не должны. Кроме того, принципиальные технические решения часто имеет смысл проверять с помощью коротких и быстрых proof-of-concept, где как раз архитектор должен быть очень даже hands-on чтобы лично убедиться в том, что предлагаемый подход будет работать так как требуется.

                >> 3(риторический вопрос). Допустим, в будущем, когда потребуется сделать
                >> небольшую важную доработку системы очень большой ценой из-за негибкого
                >> решения, какую ответственность понесет Архитектор решений, работающий
                >> в уже другой компании?

                Увы, никакую. Так оно везде в мире. Вот сейчас у бельгийского заказчика принято решение «уволить» созданное пару лет назад решение. Кто-то же у них его проектировал. Кто-то же принимал решение на стороне бизнеса потратить деньги. По сути, как оказалось, напрасно. И, насколько я знаю, никого не наказывали. Бизнес просто вынужен «проглотить» это.

                «Чинится» это долгосрочно образовательными программами для архитекторов, менторингом. Кроме того, неплохо работает парная работа.
                • UFO just landed and posted this here
          0
          Интересная информация и ссылки.
          Хотя оглавление намекает на описание именно Solution Architecture, про эту роль меньше половины. Да и ощущение, что идет реклама ЕПАМ или чисто роль архитекторов в ЕПАМЕ, а не общая информация
            0
            >> Да и ощущение, что идет реклама ЕПАМ
            Ну, корпоративный блог для опосредованной рекламы, думаю, как раз и заводят. :) Сложно коллег корить за это.
            0
            Еще лет 10 лет назад роль архитектора решений (Solution Architect) на проектах выполняли сами разработчики.

            Ребята, ну не нужно такого писать. Или это статья из 90х? А то получается опять «ИТ еще молодая индустрия, поэтому все проблемы роста простительны» и можно строить всякую ерунду.

            Only users with full accounts can post comments. Log in, please.