Solution architecture что это
Архитектура и архитекторы
Относительно давно посетил семинар посвященный управлению архитектурой и ее контролю и все хотел описать полученные знания, так как информации было много, и большая ее часть была весьма полезна. Могу сказать, что представления мои об архитектуре сильно расширились, и тема оказалась более глубокой и широкой, нежели я себе ее представлял. Но это и хорошо, есть отправные точки, которые можно будет самостоятельно проработать в будущем. Итак, заканчивая с лирикой, хочу предоставить краткий конспект по архитектуре.
Бизнес архитектура, она же Enterprise, является представлением того, как эффективно воспроизвести цели бизнеса и стратегию путем создания, улучшения и объединения ключевых требований, принципов и моделей для успешного развития бизнеса и достижения поставленных целей. Определение взято из английской википедии. Архитекторы уровня Enterprise должны ориентироваться на бизнес потребности и проводить анализ потоков данных, т.е. покрывают два указанных пункта. Архитекторы уровня Solution занимаются технологическими аспектами проектов. Так же стоит упомянуть не обозначенных здесь Infrastructure Architect, людей, которые занимаются глобальным развитием и анализом технических возможностей по реализации проектов.
Отличия Enterprise Architect от Solution Architect
EA разрабатывает глобальный план работы приложения, взаимодействия его с другими приложениями. SA работает над конкретным ПО. При этом EA постоянно следит за тем, как именно развивается приложение и может вносить коррективы в концептуальные части приложение.
Например, в какой-то момент появляется потребность в новом приложении Х, которое использует данные, которые генерирует приложение А. В таком случае ЕА принимает решение о выделении части приложения А в отдельный сервис, который будет поставщиком данных для приложения Х. Таким образом может быть заметно сокращена работа по реализации нового приложения.
Из представленного примера легко прийти к заключению о том, что EA должен очень хорошо прорабатывать, анализировать и следить за тем, как работают все приложения вместе, иметь всю информацию в наглядном и структурированном виде, для того, чтобы можно было принимать описанные решения. Повторное использование сервисов и данных, помнить или знать специфику данных и сервисов, все это входит в ответственность EА.
На мой взгляд, SA должен быть практикующим программистом, так как требуется знать достаточно хорошо продукты и фреймворки с которыми предстоит работать, знать ограничения и сильные стороны технологий которые будут использованы. В свою очередь EA точно так же не оторван от мира технологий, так как надо знать концептуальные различия в общих технологиях, быть в курсе тенденций их развития. Так как принятые решения в глобальном плане развития ПО могут похоронить все последующие проекты, либо сделать их разработку долгой и трудной, если выбор будет не соответствовать технологической структуре бизнеса.
Уровни ответственности и влияния
На данной, схеме показаны зависимости и отношения между разными уровнями архитектурного планирования. Влияние их друг на друга. Комментировать не стоит, я думаю.
Про каждый элемент из списка можно погуглить отдельно, но в целом понятно, что они означают. Остается наверно выбрать наиболее удобный формат представления.
Работа архитекторов
Некоторые люди высказывались о том, как построен процесс принятия решений в их компаниях. Например, при утверждении плана на год обязательно участие архитекторов, которые стараются сделать анализ возможности реализации в необходимые сроки. Определяют какие проекты потребуют наибольшего вложения сил, какие могут стать потребителями только и не потребуют много ресурсов.
Определенных средств для разработки и контроля никто не называл. Так или иначе, используется компиляция средств из Visio, SharePoint, Wiki.
Для меня остаются открытыми вопросы того как оценивать тенденцию в росте данных, механизмы управления данными. Лучшие практики по миграции архитектур, как идет работа систем при модернизации. Много, много вопросов возникает практического характера, которые я постараюсь выяснить у практикующих людей, с которыми познакомился на семинаре. Если будет результат, то напишу дополнительно.
Из дополнительного материала можно порекомендовать TOGAF9 и блог Nick Malik.
Solution Architect: Кто Это и Какие у Него Обязанности
Содержание
Многие компании заранее могут увидеть, что проект окажется неудачным. Соответственно, они имеют шанс изменить результат и достигнуть успеха. Это требует внезапной трансформации большинства процессов в соответствии с новыми требованиями рынка.
Такая трансформация требует особой экспертизы и набора практик для согласования бизнес-фокуса с технологическими решениями. В противном случае, изменение методов работы не даст улучшения эффективности.
Поэтому, в любой компании, которая нацелена на развитие, развита архитектура решений. Это практика проектирования, описания и управления решениями в зависимости от задач и проблем бизнеса.
Подобная практика породила соответствующую должность – архитектор решений. Это Лицо, ответственное за руководство практикой и представление общего технического видения конкретного решения. Работа архитектора решений включает в себя множество аспектов и обязанностей, о которых и пойдет речь в статье.
Из чего состоит архитектура программного продукта
В первой из них основной фокус – построение экосистемы и решение стратегических проблем высшего уровня (объединение ключевых требований, анализ потоков данных и т.д.). Бизнес архитектура приводит к понимаю того, какие техническая средства необходимы для поддержания программного продукта.
Архитектура решений – промежуточная составляющая между бизнес-процессами и технологическими решениями. Она включает в себя поиск технических решений для разных задач, описание структуры и поведения ПО, определение функций и этапов для каждого решения.
Технологическая архитектура включает в себя инженерные проблемы. Иными словами, это аппаратная составляющая программного продукта. Она описывает системное ПО, стандарты на программно-аппаратные средства, системы управления и т.д.
Исходя из этого мы видим, что в ИТ архитектуре есть три соответствующих уровня должностей – Enterprise Architect (EA), Solution Architect (SA) и Technical Architect (TA).
Роль архитектора решений
За простым «как делать» в работе архитектора решений кроется множество задач, таких как выбор фреймворков для работы, контроль за развитием программного продукта, решением спорных ситуаций у разработчиков. Почему же так важна эта работа?
Кроме того, именно архитектор решений отвечает за соблюдение всех требований в ходе разработки. Он же должен изучить ограничения проекта, чтобы проанализировать допустимые альтернативы и снизить риски.
В общем, архитектор решений – это связующее звено между технической группой и руководителем проекта. Он обеспечивает скорость и точность передачи информации, а также контролирует ключевые процессы разработки.
Какими навыками должен обладать архитектор решений
Архитектор решений – это не высшее и не низшее звено в процессе разработки программного продукта, но без него невозможно получить необходимый результат. Именно поэтому, архитектор решений должен обладать как общими навыками управления проектам, так и исключительными способностями.
Экспертная коммуникация. Роль SA – обеспечить выполнение проекта в срок. Поэтому он должен быть в состоянии четко донести технические аспекты, риски, проблемы и преимущества каждого решения.
SA – это центральный элемент для всех сторон, вовлеченных в решение, от бизнес-аналитиков и до разработчиков. Соответственно, он должен уметь объяснить выбранные подходы на всех уровнях. При этом, ему необходимо обладать человеческими качествами для предоставления советов и объяснений, ведения переговоров и оказания положительного влияния.
Управление рисками. Как снизить риски? Необходимо уметь пользоваться тестами производительности, безопасности, взаимодействия с пользователем и другими. Если SA не способен проанализировать показатели подобных тестов, то его работа окажется безуспешной.
Технические знания. SA не сможет дать совет или объяснить какое-то решение, если он не обладает достаточными знаниями в технических аспектах проекта. Такая должность подразумевает понимание всех технических дисциплин, которые задействованы в разработке.
Ориентация на детали. В ходе разработки программного продукта очень важна скрупулезность. Но такая черта характера у всех развита по-разному. Архитектор решений – это человек, который должен уделять наибольшее внимание деталям. Ведь именно они определяют возможные риски, а также помогают разделить ценные и незначительные элементы программного продукта.
Рациональное распределение. Для обеспечения быстрого и качественного результата нужно большое количество ресурсов. Но если их распределить неправильно, то итог все-равно будет негативным. Архитектор решений должен иметь информацию о всех доступных ему ресурсах и использовать их наиболее оптимальным путем.
Аналитические навыки. Разработка решений требуют понимания того, как связаны различные части бизнеса. Потому SA должен разобраться в корпоративной стратегии и реализовать все бизнес-процессы, которые определяют способы достижения целей компании. Таким образом, архитектор решений постоянно должен проводить аналитическую работу на разных уровнях бизнеса.
Обязанности архитектора решений
В общем, архитектор решений – это человек, который отвечает не только за разработку, но и за практическую реализацию идей. Он должен иметь четкое представление о продукте и понимать, какую пользу этот продукт принесет бизнесу. Кроме того, архитектор решений транслирует это видение всей команде разработчиков кода, чтобы они могли создать программный продукт.
Неотъемлемой частью разработки является выбор технологического стека. Архитектор решений обязан принимать участие в этой процедуре. Главная цель в данном случае – найти, какой стек будет наиболее подходящим для конкретного проекта.
Почему компании платят архитекторам решений
Таким образом, компании платят за оптимизацию бизнес-процессов и создание условий для масштабирования. Сколько? В среднем – 100 тысяч долларов в год. При этом, архитектор решений не получает меньше 80 тысяч. А вот максимальный показатель уже зависит от страны и компании, в которой работает человек. К примеру, в Австралии, в 2019 году максимальная оплата труда SA составила 106 тысяч долларов, в то время, как в США – 196 тысяч.
Заключение
Архитектура решений лежит в основе любого ИТ-проекта, независимо от того, применяется ли такая практика или нет. Преднамеренно внедряя архитектуру решений, компания создает структуру, которая объединяет технологии, ресурсы и навыки команды с определенными бизнес-целями.
Прежде, чем начинать работу над новым проектом, необходимо изучить структуру компании и основные требования. Конечно, можно сделать это лично. Но можно делегировать все соответствующие полномочия архитектору решений. Его роль и значимость будет замечена моментально.
Как дорасти до уровня Solution Architect
Меня зовут Роман Шрамков, я занимаю позицию Technology Director в компании EPAM. Одна из моих зон ответственности — растить архитекторов, которые могут решать любые архитектурные задачи и самостоятельно находить свежие решения для наших заказчиков.
В статье я расскажу, в чем заключается роль Solution Architect, какие ключевые задачи выполняет такой специалист и как разработчику дорасти до этого уровня.
Выступление Романа Шрамкова на одном из Java Meet-up
Роль архитектора
Я бы начал с того, кем не является Solution Architect. Часто думают, что это самый квалифицированный разработчик или эксперт, который лучше всех знает технологический стек проекта. Это не совсем так. Безусловно, архитектор должен хорошо разбираться в технологиях проекта и понимать, что такое хороший код. Но у него есть и особенная функция, которую не выполняют разработчики и эксперты: он отвечает за формирование, документирование и коммуникацию общего технического решения для всей системы.
Чтобы было более понятно, что я имею в виду, рассмотрим аналогии из других индустрий. Например, в чем заключается роль архитектора в строительной сфере, чем он отличается от прораба, каменщика или штукатура? Посмотрим на это глазами клиента. Я как заказчик буду привлекать к работе архитектора в том случае, если мне надо что-то построить, а я сам не являюсь экспертом в строительстве и понимаю, что не могу сам продумать все детали на профессиональном уровне.
При этом я обращусь к архитектору на самом первом этапе проекта, когда я еще не начал что-то строить и даже закладывать фундамент. У меня есть идея — к примеру, построить спортивный стадион. И мне интересно, можно ли вообще реализовать мой проект так, как я задумал, и если можно, то каким образом.
Придя к такому профессионалу, я ожидаю, что он задаст мне правильные вопросы: «Что именно вы строите? Для каких целей?». Потому что, например, стадион для футбола и арена для соревнований по легкой атлетике будут иметь разную форму и разные функциональные зоны. Идем дальше: если это футбольный стадион, то кто там будет играть, национальная сборная или школьная команда? От этого зависит размер площадки, количество посадочных мест для болельщиков.
Когда архитектор выяснил ключевые функциональные и нефункциональные требования к проекту, он разрабатывает концепцию решения и делает эскиз будущей постройки. Затем — презентует решение заказчику, чтобы тот убедился, что это действительно то, что нужно. Это высокоуровневая (то есть общая, не детализированная) архитектура решения. На этом же этапе, как правило, обсуждают бюджет: архитектор дает примерные оценки стоимости проекта.
После того, как концепцию согласовали, архитектор берется за более детальные чертежи — например, прорисовывает схему вентиляции или электропроводки. При этом он не может знать абсолютно все стандарты и прикладные нюансы, поэтому на этом этапе привлекает к проекту профильных инженеров. Они вместе создают так называемый низкоуровневый (то есть детализированный) дизайн будущей постройки.
В IT распределение ролей аналогичное, хотя и имеет свои особенности. Solution Architect выясняет потребности заказчика, разрабатывает концепцию программного решения, а затем передает проект тимлидам разных направлений для технической реализации.
Ключевая разница заключается в том, что процесс, который я описал выше, — очень вотерфольный. В строительной сфере сначала создают полную проектную документацию и только после этого приступают к возведению объекта. В IT мы подходим к разработке софта гибко, часто сделать финальную архитектуру сходу слишком сложно. Архитектор вместе с командой двигается итеративно, сопровождая проект на этапе реализации, постоянно уточняя требования и внося необходимые элементы в архитектуру, помогает команде решать технические сложности, возникающие по мере движения.
Ключевые задачи Solution Architect
Прояснение требований к проекту и коммуникация с заказчиком. Чаще всего это происходит на этапе пресейла или дискавери. Архитекторы помогают составить коммерческое предложение заказчику — для этого много общаются с ним напрямую, часто ездят в командировки, чтобы посмотреть на работу бизнеса изнутри. Иногда, если нужно, к этому добавляется еще и консультирование заказчика по техническим вопросам или технический аудит существующих решений.
Технологическое исследование и прототипирование. Обычно на старте проекта архитектору могут быть неизвестны некоторые нюансы применения необходимых технологий, поэтому возникает необходимость глубже изучить и разобраться в возможностях и ограничениях тех или иных решений. Для этого он разрабатывает прототипы — маленькие части системы, которые нужны для того, чтобы убедиться, что те идеи, которые придумывает архитектор, действительно являются рабочими.
Архитектура конечного продукта. Сформировав техническое решение, Solution Architect презентует его заказчику и согласовывает все детали. На этом этапе архитектор подготавливает описание высокоуровневой архитектуры или каких то ее частей, находящихся в проработке.
Детальную документацию по низкоуровневому дизайну в современном IT делают не так часто. Связано это с тем, что Solution Architect в гибких проектах плотно коммуницирует с командой, объясняет архитектуру, ее идеи, возможности и ограничения. Низкоуровневый дизайн делается по ходу разработки и сразу попадает в код. В свою очередь, команда дает обратную связь об архитектуре, все ли получается реализовать и какие есть сложности.
Общий контекст (helicopter view). В большинстве проектов каждая команда работает над своей частью решения, и для крупных систем должен быть кто-то, кто понимает картину архитектуры в целом, общие принципы и соглашения.
Именно Solution Architect — тот человек, который смотрит на разработку системы как бы сверху. У него есть четкая картина архитектуры будущего продукта и всех ее частей, которую он «прорисовывает» в виде различных схем, диаграмм и представлений.
Конечно, один человек не может детально разбираться во всем. Главная задача архитектора — видеть общий контекст и правильно координировать работу различных технических направлений. Например, если при миграции нужно будет учесть какие-то рекомендации специалиста по безопасности, то архитектор проекта должен проконтролировать, что об этом не забыли.
Выступление Евгения Моспана из Java Competence Centre, EPAM и Alex Lomov, Cybergizer, Cloud Foundry Engineer на SEC 2018
Как стать архитектором
Solution Architect — естественная следующая ступенька для сегодняшних senior разработчиков или тимлидов, которые хотят развиваться как инженеры. Как правило на этих ролях люди уже имеют глубокое знание хотя бы одного технологического стека, они вовлечены в низкоуровневый дизайн компонентов и понимают, что вывод в прод и эксплуатация системы требуют намного больше, чем просто написание кода, который запускается.
Для подготовки таких специалистов есть курсы (у EPAM курсы двух уровней — Solution Architecture School и Solution Architecture University). Можно найти опытного архитектора и советоваться с ним в вопросах архитектуры и развития. Также можно присоединиться к комьюнити архитекторов, чтобы узнавать о новых технологиях, участвовать в architecture katas (упражнение на дизайн решений) и других полезных мероприятиях.
Если вы развиваетесь самостоятельно, то следующие шаги помогут вам вырасти в архитектора решений:
1. Расширяйте кругозор. Интересуйтесь различными аспектами того, как разрабатывается и вводится в эксплуатацию система, тем, что происходит после того, как код уже написан и система работает. Как система деплоится на прод, как она интегрирована с другими системами заказчика, каким образом запланирован перевод на новую систему, как система будет поддерживать этот переход в промежуточный период.
2. Работайте с бизнесом и менеджментом. Участвуйте в обсуждениях бизнес-целей и проблем клиентов, смотрите на задачи не только с точки зрения кода и технологий, но и с точки зрения проекта в целом. Привносите в проектные и бизнес-обсуждения техническую точку зрения, но делайте это с пониманием интересов и проблем других участников проекта.
3. Прокачивайте навыки коммуникации и презентации. В отличие от тимлидов, фокус которых — технологии и разработка, архитектор — одна из ключевых фигур в общении с заказчиком и проектным менеджментом. В его зоне ответственности — переговоры и презентация технических решений от идеи до конечной реализации. Этот специалист должен уметь хорошо объяснять и отстаивать свою точку зрения, а также слушать и понимать собеседника. Конечно, это не получится без хорошего уровня английского.
4. Разберитесь с базовыми практиками в архитектуре. Архитектура — не новая дисциплина, по ней написано много книг. Обязательно познакомьтесь с ними и возьмите на заметку определенные подходы: работа с функциональными и нефункциональными требованиями, рисование понятных диаграмм, грамотное составление технической документации проекта.
Необходимые знания также можно почерпнуть из ряда фундаментальных книг об архитектуре:
Если вы нацелены на построение архитектуры сложных энтерпрайз-проектов, я советую получить сертификацию от американского SEI или европейского Iasa. Тут важна не столько сама «корочка», сколько процесс подготовки — он поможет систематизировать знания. Кстати, у SEI есть целая серия книг, которые описывают ключевые практики, — их тоже можно использовать как базу.
Хочу отметить, что рост в архитектора доступен не только для разработчиков. Например, QA у нас могут развиваться в направлении QA Architect, которые строят систему оценки качества для продукта; DevOps — могут развиваться в System Architects, которые проектируют CICD и различную автоматизацию; бизнес-аналитики могут расти в Product Managers, а проектные менеджеры, которые не против углубиться в техническую часть, — в Delivery Managers.
Каким был мой путь
Конечно же, никто из нас одним прекрасным утром вдруг не просыпается архитектором — развитие происходит постепенно. Человек нарабатывает опыт на разных проектах, учится смотреть на систему и технологии максимально широко, не зацикливаясь на одном стеке или инструменте.
В нашей компании однажды пришли к тому, что для того, чтобы получить хороший проект нужно давать заказчику не просто экспертизу разработчиков, которые умеют писать код, а консультантов, которые смогут посоветовать определенные решения исходя из потребности бизнеса. Мне было интересно вовлекаться в эти активности и принимать участие в формировании первоначальной концепции будущего решения на старте.
Постепенно я понял, что уже могу сам решать большинство вопросов при проектировании будущей системы. Кроме этого, я научился вовлекать других людей в решение технических задач по более узким направлениям, строить архитектурные команды на проектах. Так после 10 лет работы только с кодом у меня появился новый вызов, взять на себя обязанности Software Architect и затем — Solution Architect.
Сейчас я занимаю позицию Director of Technology: выступаю в роли посредника между бизнесом клиентов и техническими командами, но уже не в одном проекте, а на уровне компании. Подробнее об этом я рассказывал в рубрике «Как я работаю» на DOU.
Перспективы карьерного развития
В каждой компании могут быть разные карьерные пути. Сперва расскажу на примере EPAM. У нас есть три карьерных уровня:
Сама по себе позиция Solution Architect — это уже отличный карьерный шаг для инженера: вы попадаете в B-track, где от вас ожидается определенный уровень зрелости и где вас ждет соответствующий уровень задач.
В свою очередь, карьерный путь архитектора состоит из пяти ступенек:
Если вы работаете в менее крупной компании, то позиция Solution Architect хороша тем, что сочетает в себе высокую техническую экспертизу и определенную управленческую компетенцию. С этой позиции вы можете развиваться в разных направлениях. Во-первых, вы можете расти как успешный архитектор решений и быть востребованным на рынке и в компании на ключевых позициях в самых сложных и интересных проектах, особенно на старте. При определенной доле опыта и менеджерских амбициях, вы можете замахнуться на позицию CТO компании и помогать строить правильную технологическую стратегию ее развития. Во-вторых, вы сможете развиваться как консультант или пресейл специалист, который больше работает с клиентами и часто путешествует он-сайт.
Если у вас есть вопросы о позиции Solution Architect, пишите в комментариях, постараюсь ответить.
Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.