Хто такий архітектор, чим займається і як ним стати. Обговорюємо на DOU Live
Про те, що визначає роль Software Architect, обговорили з Олександрою Дудкою, Software Architect в Sigma Software, Антоном Шевчуком, Solutions Architect в NIX, та Олексієм Білогуровим, Solutions Architect в Softserve. Публікуємо тези розмови (повний запис можна переглянути нижче).
Чим займається Architect
Хто такий архітектор та які функції він виконує? (1:50)
Антон Шевчук: Как Solution Architect, я общаюсь с заказчиком. Моя основная функция — это выяснить, что ему необходимо, и перевести это на язык требований. После того как разобрался в пожеланиях заказчика, я должен предложить некое решение, которое поможет в бизнесе, и это решение сопровождать в дальнейшем на этапе разработки.
Алексей Белогуров: Я бы поделил архитекторов на farming и hunting. Этапом пресейла и дискавери занимаются хантеры, которые охотятся на клиентов и добывают новые проекты. Тут важны софт-скилы, это более мачурные архитекторы. Зачастую этот же человек и сопровождает проект.
Также мы можем выделить farming-архитекторов, они не участвуют в пресейлах и дискавери, но в то же время они на long-term развивают проекты и сопровождают их в разработке и могут годами находится на этих проектах.
Александра Дудка: Не всегда выходит сопровождать проект, после того как закончилась стадия пресейла или дискавери. Одна из ключевых функций архитектора — это составление технической документации для команды, которая будет реализовывать проект. Чем она лучше отвечает на вопросы, почему использовано именно этот подход к архитектуре, а не другой, тем проще команде будет разрабатывать. Это одна из ролей архитектора — заниматься документацией: воплощать требования в текст, диаграммы, которые понятны для коллег.
Які бувають архітектори
Є багато типів архітекторів: Solution, Application, Enterprise, Cloud тощо. У чому полягає різниця між ними? (5:02)
Алексей Белогуров: Сейчас архитекторов много, так как у нас много технологий и направлений. Даже в архитектурном мире, если есть сложный дискавери, в нем может участвовать несколько архитекторов. У одного экспертиза по Big Data, у другого по Cloud, поэтому я могу примерно рассказать, как это выглядит у нас в компании. Мы стандартизируем своих архитекторов, и начинается с самого базового — это Application Architect. Это человек, который может самодостаточно делать документацию, драйвить проект, но работает в пределах одного домена и в пределах одного языка программирования.
На самом деле, терминология может отличаться, и если вы едите к клиенту на дискавери, то есть смысл уточнить, что именно он понимает под этим словом.
Далее идет Solution Architect — это человек, который может сопровождать кросс-доменные проекты. У него экспертиза и в Java, и в Node.js, и в JavaScript. Потом Senior Solution Architect и Principal Architect — это «большие дяди», которые участвуют в консалтингах с большими энтерпрайз-клиентами. Они уже являются законодателями архитектурных стандартов в компании и развивают эту экспертизу.
Александра Дудка: В нашей компании Sigma Software есть три градации: Project Аrchitect, Software Architect и Solution Architect. Project похож на Application Architect из градации, о которой выше рассказал Алексей. Software Architect — это человек, который может участвовать в proposal, спроектировать систему, документацию и так далее. И Solution Architect — это специалист, который занимается product line. Он вычленяет элементы, которые могут быть переиспользованны между большими системами.
Алексей Белогуров: На самом деле, иногда в проекте
Як стати архітектором
Що потрібно вміти, який досвід мати і як вчитись? (19:28)
Антон Шевчук: В первую очередь нужно пробовать свои силы в новых технологиях и бизнес-доменах, не боятся общаться с заказчиком. Потом уже получать знания по тем пробелам, которые обнаружите. В общем, не стоит бояться брать челленджи, ответственность, надо постоянно учиться.
Алексей Белогуров: Начнем с того, что ты морально хочешь стать архитектором и уже созрел. Ты готов писать не только код, а иногда и документацию. Есть ребята, которых я называю «вечные сеньоры». В этом нет ничего плохого, но это те люди, которые или не готовы, или не хотят брать ответственность на себя, им более комфортно писать код, чем общаться с клиентом.
У нас есть ІТ-академия, я ментор на Architect Program, где состоявшиеся техлиды проходят эту программу. Она длится четыре месяца. Там мы даем базовые знания по методологии, документации, учим, как проводить дискавери, пресейлы, работать с естимейтами, и это все сопровождается практическими кейсами. Понятно, что это малая доля того, что вообще можно дать. Потом набиваются шишки и зарабатывается собственный опыт, но это хотя бы первые шажки, которые мы помогаем делать будущим архитекторам.
Александра Дудка: Соглашусь, что это стратегическое решение, которое должен принять человек, потому что архитектура — это не логическое продолжение, не следующая ступенька за техлидом или Senior Software Engineer, это больше смена трека. То, чем мы занимаемся каждый день, выходит за рамки написания кода, и зона ответственности гораздо выше, чем на позиции мидла или сеньора.
Антон Шевчук: Мы — представители больших компаний. И у каждого есть программа обучения, в том числе для архитектора. Я не могу сказать, что таких программ обучения нет в маленьких компаниях, но в больших это поставлено на конвейер.
Алексей Белогуров: В маленьких компаниях еще тяжело наработать свой первый опыт. У тебя есть определенный стек, свой домен, и ты знаешь проект как свои пять пальцев. Ценность кросс-архитекторов в том, что за год они могут поменять
Де брати клієнтів
Питання про пресейл і діскавері. Як до вас доходять клієнти та ліди? (13:30)
Алексей Белогуров: У нас есть отдельно позиция Sales, и они — первая точка соприкосновения с клиентом. Потом идет RFP (request for proposal), но не всегда он написан идеально. Зачастую тут появляется несколько архитекторов или технических специалистов, которым надо выяснить, чего хочет клиент. После первых созвонов (мы их называем пресейлами) мы понимаем, что кто-то тут лишний, а кого-то неплохо бы добавить. Если после этого есть необходимость дискавери, то мы инициируем эту фазу. Обычно, если это большие проекты и есть много неизвестных, то есть смысл еще тратить пару недель на интенсивное дискавери, задокументировать это все, сделать эстимейты. И после дискавери мы переходим к стадии имплементации, на которой либо архитектор не нужен, либо он может быть на half-time.
Александра Дудка: На пресейл-стадии иногда бывает, что приходит RFP, но это может быть тендер, где есть ограниченное количество созвонов с клиентом, либо их не может быть априори по определенным причинам. И на архитекторов возлагается большая ответственность: имея только RFP, не задавая наводящих вопросов и не интервьюируя клиента, они должны все-таки предоставить решение, оценить его и, соответственно, привести к победе через тендер. Бывают такие сложные задачи.
Антон Шевчук: В первую очередь нужно понять, чего хочет заказчик, в чем его бизнес-идея и на чем он будет зарабатывать деньги. Можно наломать дров на этом этапе, потом сидеть и пытаться вытянуть функциональные и нефункциональные требования, а клиент после предыдущей сессии вопросов-ответов уже устал, у него есть и другие компании, которые тоже претендуют на тендер. Это все ложится на плечи в том числе архитектора.
Алексей Белогуров: Чем архитектор отличается от техлида — это тем, что он думает критериями бизнеса, а не только критериями кода, модульности, поддерживаемости. Это человек, который помогает клиенту развивать бизнес. И один из самых первых вопросов, которые надо задать заказчику: как мы можем вам помочь развить бизнес, какие у вас цели? Задача архитектора — найти и предложить решения, которые принесут профит для клиента.
Александра Дудка: У каждого из нас есть опросники, которые мы используем в повседневной работе, чтобы расспрашивать клиента, что же ему нужно. Но иметь опыт в предметной области — очень важно. Зачастую понимание каких-то тонкостей помогают задать вопрос, который может вскрыть большой пласт функционала или особенностей конкретного клиента. Поэтому развивать нужно не только технические навыки, но и познания в бизнес-доменах.
Чим вимірюють ефективність архітекторів
Як визначають KPI архітекторів, на які показники орієнтуються? (27:40)
Алексей Белогуров: Если мы берем пресейл, то самый важный критерий успеха — получил сделку или нет. Но, если мы говорим про дискавери или фарминг, то как таких KPI у нас нет. Если клиент счастлив и после дискавери говорит: «Хочу, чтобы этот чувак саппортил мою команду», то, наверное, это самый хороший показатель.
Александра Дудка: KPI связаны с тем, привели или не привели заказ, расширили команду или нет. Это все бизнес-метрики. С пресейлом сложно, зачастую клиенты приходят и не готовы к тому, во что их идеи и фантазии выливаются. Архитектор тут уже не виноват, но, с другой стороны, важно включать гибкость. Мы можем предложить больше вариантов, разбивать на разные фазы поставки и все равно выходить с заказом и начинать разработку.
Антон Шевчук: У нас тоже нет формализованного KPI для архитектора, но для того, чтобы понять, насколько ты хорош или нет, можно смотреть на то, взлетел ли проект. Идти к команде, узнавать фидбэк по своей работе.
Як часто розроблена початково архітектура змінюється в процесі
Як часто архітектура, яка була задумана на початку проєкту, «доживає» до його фіналу? (30:25)
Алексей Белогуров: Есть две ситуации. Если ты разработал архитектуру и клиент говорит, что ему больше не нужен архитектор, или еще почему-то ты не продолжаешь работать с этим заказчиком и проектом, то вряд ли архитектура доживет до конца. Если мы говорим о short-term проектах на
Архитектура может меняться, и это нормально, потому что за годы у проекта могут меняться бизнес-требования. Изначально мы планировали под одни нагрузки, бизнес стал успешен и те нагрузки, на которые рассчитывали
Антон Шевчук: Хорошая архитектура готова к изменениям и достаточно гибкая. Я не сталкивался с ситуациями, где бы архитектура не выдержала проверку, пришлось все стереть и писать все с чистого листа.
Architecture description language
Як ви вважаєте, чи потрібно архітекторам знати architecture description language? Rapid? SIS ML? Archimate? Acme? (42:26)
Александра Дудка: В практике мне приходилось работать только с UML-нотацией, это то, что применимо к любому проекту. Другие хорошо знать, но я не сталкивалась с ними.
Алексей Белогуров: Их можно знать, но, если не знаете, ничего страшного, их можно загуглить и разобраться, о чем идет речь.
Когда мы пишем документацию, то должны задумываться, для кого это делаем. Зачастую, если у клиента есть свои стандарты или требования, мы подстраиваемся под них и делаем это в других нотациях.
Документация должна быть понятной и написанной для тех людей, которые будут с ней работать. Например, если это инфраструктурный раздел, то он должна быть написан для девопсов. Это могут быть обычные иконки с AWS, но любой девопс, который возьмет эту диаграмму, должен понять, как задеплоить эту структуру, у него не должно возникать дополнительных вопросов.
Если это более хайлевельные диаграммы, контекст- или бизнес-диаграммы, они должны быть максимально простыми и не техническими, потому что их смотрят люди бизнеса, С-level, а им неинтересны скучные нотации.
Стандарти архітектури
Чи потрібно архітекторам в сервісних компаніях вивчати TOGAF, Zachman? Як вони можуть допомогти в архітектурному дизайні, міграції тощо? (47:56)
Алексей Белогуров: Методология не привязана ни к стеку, ни к типу компании. Это лишь способы получения требований, способы дизайна архитектуры. Если это большая компания, которая делает архитектурные решения, или если это разовая инвестиция, то проще попросить консультантов, чтобы они сделали и не инвестировать в это время. Если это постоянно развивающаяся компания, которая хочет иметь на борту своих архитекторов и делать свои солюшены — есть смысл. Не имеет значения, это SEI или TOGAF, они довольно похожи.
Возвращаясь к вопросу, что мне делать, чтобы обращать внимание на архитектуру, а не на код — вот как раз упомянутые методологии и стандарты меняют точку зрения, заставляют по-другому посмотреть на требования и на ту последовательность, как их лучше собирать.
Розвиток архітектора
Куди можна розвиватися архітектору? (53:03)
Алексей Белогуров: Мы тоже ищем ответ на этот вопрос. Я скажу по примеру своих коллег: в архитектуре можно расти годами и десятилетиями. В нашей компании есть люди, которые уже 10 лет в архитектуре, развиваются как специалисты, растут по карьерной лестнице. Если мы говорим, что же дальше за пределами компании, пусть даже самой большой, то это либо путь в CTO, либо в создание своей компании, либо независимый консалтинг.
Антон Шевчук: Обычно предполагается, что ты будешь расти вширь, знать все больше технологий. Ситуация такая, что в нашем мире даже новые бизнес-домены появляются. Можно обучаться на протяжении многих десятилетий, а там, глядишь, и капусту начнешь выращивать. Еще не паханое поле.
Як прокачати «архітекторську навичку»
Як почати думати про архітектуру, а не про код? (39:19)
Алексей Белогуров: Мне помогло начать думать критериями бизнеса и критериями денег, то есть как я могу помочь клиенту в его бизнесе. Самое хорошее упражнение — поставить себя на место клиента. Я сейчас плачу большие деньги, что бы я хотел сделать в этом проекте, чтобы это принесло еще больше денег: поменять фреймворк 2.0 на 2.1, улучшить перформанс или снизить инфраструктурные траты в клауде и так далее.
Если мы говорим об архитекторе, то нужно прокачивать софт-скилы.
Александра Дудка: Методология, о которой мы не раз упоминали, помогает идти не от кода, а от высокого уровня проблемы, постепенно спускаясь к мелким техническим деталям. Поэтому анализ Quality Attribute Workshop позволяет думать немного по-другому, не вникая в детали кода.
А архітектор взагалі існує?
Чи є майбутнє в архітектора як ролі? (58:39)
Алексей Белогуров: Я видел много проектов, где архитектура не была проработана заранее. Проект взлетал, но приходили большие дяди и ломали голову, как же это пофиксить. Поэтому жадный платит дважды.
Мне кажется, что эта роль только развивается. У нас сейчас много клаудов, ML, Big Data, вся инфраструктура, весь IT-сектор только растет. Так же растут требования к уровню разработчиков и архитекторов.
Антон Шевчук: Кто-то на проекте все равно берет на себя роль Application Architect. Просто у него нет бейджика «архитектор». Определенный техлид взял на себя роль архитектора, принял решение по архитектуре, несет за него ответственность.
Як вивчати нові технології ефективно
Як вчитись? (1:06:42)
Александра Дуда: Методом проб и ошибок. Без этого никак. Часто бывает, что в рамках дискавери необходимо сделать РОС, и он может подразумевать использование тех или иных технологий, с которыми в компании никто ранее не работал. И нужно пощупать, попробовать, перед тем как рекомендовать либо отвергать подход.
Алексей Белогуров: Я бы разделил это на две категории — вширь и вглубь. Есть вещи, о которых мы слышим и знаем, что они есть на рынке, появились новые тренды, фреймворки и так далее. Тут довольно просто: вы подписываетесь на все рассылки, которые вам интересны: InfoQ, Habr, Medium и так далее. Выбираете архитекторов, на которых вы хотите быть похожи или информация от которых вам заходит лучше всего, и периодически поверхностно смотрите, что происходит в мире технологий.
Если вглубь, то это РОС, какая-нибудь практика на реальном проекте либо, если проект не позволяет, на своих учебных проектах. Еще можно попытаться написать техническую статью, но глубокую.
Антон Шевчук: А еще слушайте своих молодых и энергичных ребят, потому что они приносят новые интересные технологии, ведь им хочется попробовать новое, возможно, они устали работать в энтерпрайз-проекте, в котором стек технологии выбрали пять лет назад, и они могут принести что-то интересное. Прислушивайтесь к людям, это может быть полезно не только для вас, но и для проекта в целом. Активно слушайте.
