Хто такий архітектор, чим займається і як ним стати. Обговорюємо на 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. Он вычленяет элементы, которые могут быть переиспользованны между большими системами.

Алексей Белогуров: На самом деле, иногда в проекте 5–10 разработчиков и один архитектор, который его сопровождает. Или даже вообще не будет архитектора, если есть решение, сделана качественная документация.

Як стати архітектором

Що потрібно вміти, який досвід мати і як вчитись? (19:28)

Антон Шевчук: В первую очередь нужно пробовать свои силы в новых технологиях и бизнес-доменах, не боятся общаться с заказчиком. Потом уже получать знания по тем пробелам, которые обнаружите. В общем, не стоит бояться брать челленджи, ответственность, надо постоянно учиться.

Алексей Белогуров: Начнем с того, что ты морально хочешь стать архитектором и уже созрел. Ты готов писать не только код, а иногда и документацию. Есть ребята, которых я называю «вечные сеньоры». В этом нет ничего плохого, но это те люди, которые или не готовы, или не хотят брать ответственность на себя, им более комфортно писать код, чем общаться с клиентом.

У нас есть ІТ-академия, я ментор на Architect Program, где состоявшиеся техлиды проходят эту программу. Она длится четыре месяца. Там мы даем базовые знания по методологии, документации, учим, как проводить дискавери, пресейлы, работать с естимейтами, и это все сопровождается практическими кейсами. Понятно, что это малая доля того, что вообще можно дать. Потом набиваются шишки и зарабатывается собственный опыт, но это хотя бы первые шажки, которые мы помогаем делать будущим архитекторам.

Александра Дудка: Соглашусь, что это стратегическое решение, которое должен принять человек, потому что архитектура — это не логическое продолжение, не следующая ступенька за техлидом или Senior Software Engineer, это больше смена трека. То, чем мы занимаемся каждый день, выходит за рамки написания кода, и зона ответственности гораздо выше, чем на позиции мидла или сеньора.

Антон Шевчук: Мы — представители больших компаний. И у каждого есть программа обучения, в том числе для архитектора. Я не могу сказать, что таких программ обучения нет в маленьких компаниях, но в больших это поставлено на конвейер.

Алексей Белогуров: В маленьких компаниях еще тяжело наработать свой первый опыт. У тебя есть определенный стек, свой домен, и ты знаешь проект как свои пять пальцев. Ценность кросс-архитекторов в том, что за год они могут поменять 4–5 проектов, получить знания в разных областях.

Де брати клієнтів

Питання про пресейл і діскавері. Як до вас доходять клієнти та ліди? (13:30)

Алексей Белогуров: У нас есть отдельно позиция Sales, и они — первая точка соприкосновения с клиентом. Потом идет RFP (request for proposal), но не всегда он написан идеально. Зачастую тут появляется несколько архитекторов или технических специалистов, которым надо выяснить, чего хочет клиент. После первых созвонов (мы их называем пресейлами) мы понимаем, что кто-то тут лишний, а кого-то неплохо бы добавить. Если после этого есть необходимость дискавери, то мы инициируем эту фазу. Обычно, если это большие проекты и есть много неизвестных, то есть смысл еще тратить пару недель на интенсивное дискавери, задокументировать это все, сделать эстимейты. И после дискавери мы переходим к стадии имплементации, на которой либо архитектор не нужен, либо он может быть на half-time.

Александра Дудка: На пресейл-стадии иногда бывает, что приходит RFP, но это может быть тендер, где есть ограниченное количество созвонов с клиентом, либо их не может быть априори по определенным причинам. И на архитекторов возлагается большая ответственность: имея только RFP, не задавая наводящих вопросов и не интервьюируя клиента, они должны все-таки предоставить решение, оценить его и, соответственно, привести к победе через тендер. Бывают такие сложные задачи.

Антон Шевчук: В первую очередь нужно понять, чего хочет заказчик, в чем его бизнес-идея и на чем он будет зарабатывать деньги. Можно наломать дров на этом этапе, потом сидеть и пытаться вытянуть функциональные и нефункциональные требования, а клиент после предыдущей сессии вопросов-ответов уже устал, у него есть и другие компании, которые тоже претендуют на тендер. Это все ложится на плечи в том числе архитектора.

Алексей Белогуров: Чем архитектор отличается от техлида — это тем, что он думает критериями бизнеса, а не только критериями кода, модульности, поддерживаемости. Это человек, который помогает клиенту развивать бизнес. И один из самых первых вопросов, которые надо задать заказчику: как мы можем вам помочь развить бизнес, какие у вас цели? Задача архитектора — найти и предложить решения, которые принесут профит для клиента.

Александра Дудка: У каждого из нас есть опросники, которые мы используем в повседневной работе, чтобы расспрашивать клиента, что же ему нужно. Но иметь опыт в предметной области — очень важно. Зачастую понимание каких-то тонкостей помогают задать вопрос, который может вскрыть большой пласт функционала или особенностей конкретного клиента. Поэтому развивать нужно не только технические навыки, но и познания в бизнес-доменах.

Чим вимірюють ефективність архітекторів

Як визначають KPI архітекторів, на які показники орієнтуються? (27:40)

Алексей Белогуров: Если мы берем пресейл, то самый важный критерий успеха — получил сделку или нет. Но, если мы говорим про дискавери или фарминг, то как таких KPI у нас нет. Если клиент счастлив и после дискавери говорит: «Хочу, чтобы этот чувак саппортил мою команду», то, наверное, это самый хороший показатель.

Александра Дудка: KPI связаны с тем, привели или не привели заказ, расширили команду или нет. Это все бизнес-метрики. С пресейлом сложно, зачастую клиенты приходят и не готовы к тому, во что их идеи и фантазии выливаются. Архитектор тут уже не виноват, но, с другой стороны, важно включать гибкость. Мы можем предложить больше вариантов, разбивать на разные фазы поставки и все равно выходить с заказом и начинать разработку.

Антон Шевчук: У нас тоже нет формализованного KPI для архитектора, но для того, чтобы понять, насколько ты хорош или нет, можно смотреть на то, взлетел ли проект. Идти к команде, узнавать фидбэк по своей работе.

Як часто розроблена початково архітектура змінюється в процесі

Як часто архітектура, яка була задумана на початку проєкту, «доживає» до його фіналу? (30:25)

Алексей Белогуров: Есть две ситуации. Если ты разработал архитектуру и клиент говорит, что ему больше не нужен архитектор, или еще почему-то ты не продолжаешь работать с этим заказчиком и проектом, то вряд ли архитектура доживет до конца. Если мы говорим о short-term проектах на 3–6 месяцев, то там испортить что-то тяжело.

Архитектура может меняться, и это нормально, потому что за годы у проекта могут меняться бизнес-требования. Изначально мы планировали под одни нагрузки, бизнес стал успешен и те нагрузки, на которые рассчитывали 2–3 года назад, сейчас в 10 раз больше, соответственно, архитектуру надо менять. Это нормальная эволюция архитектуры.

Антон Шевчук: Хорошая архитектура готова к изменениям и достаточно гибкая. Я не сталкивался с ситуациями, где бы архитектура не выдержала проверку, пришлось все стереть и писать все с чистого листа.

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 и так далее. Выбираете архитекторов, на которых вы хотите быть похожи или информация от которых вам заходит лучше всего, и периодически поверхностно смотрите, что происходит в мире технологий.

Если вглубь, то это РОС, какая-нибудь практика на реальном проекте либо, если проект не позволяет, на своих учебных проектах. Еще можно попытаться написать техническую статью, но глубокую.

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

👍НравитсяПонравилось7
В избранноеВ избранном6
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube

54 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Кажется случилось что-то типа
0. Большие продуктовые компании ещё 50 лет назад столкнулись с проблемой управления сложностью в больших проектах. Специалистов которые умеют этой сложностью управлять назвали Software Architects
1. Украинские галеры наткнулись на лычьку которая стоит дороже Senior
2. Оказалось что на местном рынке спецов особо нет, так как на е-шаурмичных, которыми лидеров рынка в основном занимаются, они особо не растут. Да и не нужны
3. Выделили специфическую для аусорса и назвали ее Solution Architect — пусть будет созвучно с тем что подороже
4. Profit!

Самих-то не смущает что ваши «архитекторы» не существуют в мире где нет «заказчиков», и почему-то все топ книги из раздела Software Architecture на Amazon рассказывают скорее про System Design а не про то как с умным видом сыпать баз-вордами чтобы оправдать цены сеилзов?

UPD. Серьезно, вы делаете ценную для аусорса работу, но называйте себя, например, Sales Architects — у сообщества сразу все претензии отпадут

Тебя не поймут те, кто с лычкой Solution Architect из ТОП-аутсорса) он такой) именно Солюшены, именно они вовсю говорят о том, что «это не следующий уровень развития техлида».

Один вот мне рассказал, что архитекторы могут не участовать в реализации конечного солюшена, а отдавать эту работу техлидам или в будущем неким principal engineer. Осталось дождаться, когда очередную статью напишет Solution Architect из EPAM, например, о том, насколько важно уметь выявлять у заказчика нефункциональные требования (наряду с BA, который функциональные требования обычно выявляет).

Вот тут, например, человек хорошо объяснил что стереотипно думают девелоперы, а что в реальности.
dou.ua/...​rums/topic/33377/#2123962
И вопросы о том, почему Senior Solution Architect-ы становятся в 30 лет отпадут. Здесь вертикальный рост решает, а не техническая экспертиза.

В приведенном вами посте хорошее описание того чем занимаются люди в обсуждаемой статье, но не нужно, пожалуйста, обобщать новомодный трэнд больших украинских аутсорверов до всеобъемлющей «реальности»

Самих-то не смущает что ваши «архитекторы» не существуют в мире где нет «заказчиков»

В великих банках та інших конторах, які існують 30+ років, зазвичай є архітектори.
«Замовник» є завжди, але правильно їх називають «бізнес стейкхолдери», основним уособленням такого замовника є «проджект спонсор».

и почему-то все топ книги из раздела Software Architecture на Amazon рассказывают скорее про System Design а не про то как с умным видом сыпать баз-вордами чтобы оправдать цены сеилзов?

Перші 2, що мені видало:
1) Fundamentals of Software Architecture: An Engineering Approach — забита базвордами, а ще має розділи Negotiation and Leadership Skills та Developing a Career Path
1) Software Architecture in Practice (SEI Series in Software Engineering) 4th Edition — цю взагалі вважають біблією, вона про всілякі драйвери, тактики, вимоги/якісні атрибути, про те як малювати діаграмки та таблички :)

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

1) Fundamentals of Software Architecture: An Engineering Approach забита базвордами по тому что там авторы в отдельные главы пытаются впихнуть темы для раскрытия которых другие авторы пишут целые книги. По этому книга и называется Fundamentals — она не учит применять перечисленные архитектурные практики — она о том какие практики вообще бывают. Главы «Leadership Skills» и «Developing a Career Path» 23я и 24я из 24 :)
2) Software Architecture in Practice не смотрел, но то что вы описали это все равно не о том как помагать сеилзам (то что описано в статье) а о том как создаются архитектурные артефакты. Что, конечно, тоже важно и имеет место быть в работе архитектора

это все равно не о том как помагать сеилзам

Ти так ґавріш, как бута ета штота плахоє ©

Software Architecture in Practice не смотрел, но то что вы описали это все равно не о том как помагать сеилзам (то что описано в статье) а о том как создаются архитектурные артефакты

А можна цитати в яких стверджується, що робота архітектора «допомогати сейлсам»?
В секції «Чим займається Architect» я прочитав про всілякі з’ясування вимог, потреб бізнеса підготовку документації для імплементації.

А можно спросить, у тебя же такая же должность в компании — Solution Architect. Какие твои основные обязанности?

Це те, з чого я почав іще на Ютубі — коли люди підміняють реальність власними уявленнями і кричать, що реальність це на*обка.
Вони там чесно кажуть, що є архітектори-мисливці (пресейли), а є фермери, і в тій розмові було більше саме про мисливців. Але нашим любителям системного дизайну простіше знецінити роботу мисливця і протиставити її міфічній «чесній» розробці, що саме по собі досить забавно.

Тогда они должны были пригласить хоть одного архитектора-фермера чтоб всем смотрящим угодить) но какую лычку тогда бы он имел? И из какой компании был бы?

Тогда они должны были пригласить хоть одного архитектора-фермера чтоб всем смотрящим угодить)

Взагалі-то редакція мала б написати статтю, опрацювавши різні аспекти роботи деякої спеціалізації (в нашому випадку архітектор), сформувати деяку класифікацію специфічну для нашого ринку.
Але це пісець як дофіга роботи — треба зібрати думку хоча б 10-20 чоловік (самі архітектори і менеджери топ 3-5 компаній, при тому не лише аутсорс) і ще купа публікацій та матеріалів з інтернету. Для мене це було б десь місяць роботи.
Постити інтерв’ю набагато простіше і дешевше — 1-3 робочих дня.

хоть одного архитектора-фермера ... но какую лычку тогда бы он имел?

В епамі це може бути як лід девелопер (д4) так і солюшн архітектор (Б1 або рідко Б2), зараз наче ще впеціально виділяють софтвар архітектор. В присейлсах також можуть приймати участь від Д4. Власне яке значення має личка?

Я понял. Ты склоняешь к тому, что среди Солюшен могут быть и фермеры и мыслители с той же лычкой. Получается должность одна, а фактически обязанности другие. Одни больше выявлением требований занимаются, другие вот этим system design.

Одни больше выявлением требований занимаются, другие вот этим system design.

Та блін.
Нафіга з’ясовувати вимоги? На основі чого робити system design?

Ты читал что я писал ранее? Нефункциональные требования разве не ваша обязанность? Или как в книге описаны quality attributes?

Мне вот другое интересно. Если в аутсорс компанию заходит проект с маленьким бюджетом (fixed price). Нужен ли в таком случае вообще Солюшн архитект? Или берём типовые вещи, шаблоны и можно уже имплементацией заниматься? Просто ну о каких атрибутах качества можно говорить, если в тех случаях делают без Юнит тестов, без должного времени на проектирование, а максимально быстро и дёшево? Хотя ответ тут думаю очевиден — получится то, что не хотел заказчик, и вероятность что проект загнётся не дойдя до продакшн большая.

Самих-то не смущает что ваши «архитекторы» не существуют в мире где нет «заказчиков», и почему-то все топ книги из раздела Software Architecture на Amazon рассказывают скорее про System Design а не про то как с умным видом сыпать баз-вордами чтобы оправдать цены сеилзов?

Не читав «Software architecture in practice» detected.
Їжачку зрозуміло, що таке потрібно саме в софті на замовлення, але ця історія давно розкладена по поличках самими ж американцями.
Взагалі, нам важко зрозуміти одне одного, бо вам чомусь здається, що власний IT-проєкт це догма і по замовчуванню там всі все розуміють, а на практиці це просто спрощена стартапна структура (в мене з сестрою, сіньйором на одному pre-IPO в СФ, про це часті дискусії), але в реальному світі так, буває не лише софт на зовнішнє замовлення, а й великий бізнес, який хоче, щоб IT-відділ зробив йому харашо. Я в такому свого часу починав, мій безпосередній начальник був у тому всьому ні в зуб ногою, тому я розумію, про що все це...

И тут тоже самое говорится, что Архитектор — это тот, кто поговорит с кастомером и нарисует картинки архитектуры поверхностной? Как в треде про архитектора в 29 лет? Если там нет спора о микросервисах или монолитах — смотреть не стоит.

Ліл, точно те, що я написав нижче :-D

Я и хотел ответить на это) просто я думал кто-то скажет, что Айяйяй ты не знаешь кто такие Solution Architect, тебе не понять. Примечательно, что из трёх человек как раз System Architect и нет, взяли представителей галер, а в более мелких компаниях есть CTO/System Architect в основном.

Примечательно, что из трёх человек как раз System Architect и нет, взяли представителей галер, а в более мелких компаниях есть CTO/System Architect в основном.

1) В чому для вас різниця або краще дайте визначення System, Software та Solutions Architect? (Мета не розвести срач, а зрозуміти базові визначення, щоб розмовляти про одне й те саме)
2) В «малих конторах» скоріше за все не буде посади архітекта, але буде «чувак який все знає» (він і буде виконувати роль архітекта).
3) Давайте визначимось з тим в чому полягає роль СТО. З того що я стикався, то залежно від розміру контори теж можуть бути принципово різні задачі.

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

Ты тоже ведёшь к тому, что я ничего не понимаю)
(Мета не розвести срач, а зрозуміти базові визначення, щоб розмовляти про одне й те саме)

Іноді я навіть хочу вірити, що на доу так багато людей, які просто не знають українську мову, але «не варто пояснювати злим умислом, те що можна пояснити тупістю»

Причем тут украинский язык вообще??

в одном из штатов в США, осуждённый ранее педофил, заселяясь в квартал, должен о своём факту оповестить всех соседей. Ну может человек за тупость тем же мотивом предупредил. Чудны дела вселенной )

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

Солюшн архитектор решает будет ли монолит или микросервисы?

Так. І що це змінює?

А пишет он какой-то базовый фундамент приложения по типу разбиения на слои как заложено в Clean architecture, к примеру? Вот тут скорее всего другой уже архитектор выполняет работу. Насколько я понял, есть такие архитекторы, которые только рисуют диаграммы, а код не пишут вообще. Это относится к тому же виду (Солюшнс)?

К тому же я знаю, что ты из EPAM. А в меня только от названия уже тошнить начинает. Поэтому, закрыли тему.

К тому же я знаю, что ты из EPAM.

Вау! І як же вам відкрились такі потаємні знання?
Невже ви спромоглись клікнути на профіль, а потім ще й на посилання на лінкедін?
Аплодую!

2) В «малих конторах» скоріше за все не буде посади архітекта, але буде «чувак який все знає» (він і буде виконувати роль архітекта).

Это абсолютная правда.

1) В чому для вас різниця або краще дайте визначення System, Software та Solutions Architect?

Нет таких однозначных определений — это не звания в армии, которые всеми понимается однозначно, майор это всегда майор. Могу поделиться примерно с тем, чем сталкивался лично я (дисклеймер — не утверждаю что это единственно возможное/верное разделение).

Подразумевая что у нас есть реально большой проект:

— Software architect — в общем случае отвечает за стандартизацию разработки на уровне отдельного приложения/сервиса (типа, используем фреймворк(и) A,B,C версий X,Y,Z , такие-то дополнительные библиотеки, стандартная структура проекта — такая-то, для логирования используется то-то, экспепшены обрабатываются так-то, конфигурационные файлы имеют такую-то стурктуру, юнит-тесты пишутся так-то и т.п.). Также может еще иметь и более узкую специализацию — front/back/db, или по языкам например.
В принципе, может и должен писать код, но не в контексте бизнес-задач, а референсный, должен проводить регулярный code review

— Solution architect — отвечает за создание документации по дизайну, достаточной для тим. лидов для дальнейшей постановки задач внутри команд для конкретного бизнес-домена ( типа, для подсистемы «управление пользователями» модель данных такая-то, микросервисы или приложения — такие-то, API — такие-то, с third-party системами интегрируемся так и так, процессы копторые необходимо реализовать — такие-то ). Код писать, в общем случае, не должен — работает с различными тулами для описания структур данных/API/UML

— System architect — наиболее неоднозначная позиция. Я встречал следующие вариации:
a) Главный по системе в целом, отвечает за все, по факту — в основном занят организационными функциями и выполняет роль арбитра в случае разногласий
b) Отвечает за low-level вещи, типа за выбор и конфигурацию конкретного оборудования, размещения в датацентре, конфигурирования сети, бэкапы и т.п. В свете соверменных тенденций может иногда называться cloud architect
c) Отвечает за вещи, общие для всего проекта (аутентификация, секьюрити, перформанс, СI/CD)
d) Просто другое название для solution architect

Нет таких однозначных определений — это не звания в армии, которые всеми понимается однозначно
(Мета ... а зрозуміти базові визначення, щоб розмовляти про одне й те саме)

Задача зрозуміти чому жоден з 3 не підійшов на позицію System Architect

Примечательно, что из трёх человек как раз System Architect и нет,

UPD

— System architect — наиболее неоднозначная позиция.

Ще часто так називають «головного адміна», личку архітектор для адмінів/девопсів. Це схоже на ваш варіант Ц, але не дуже.

Окей. Я к 13 годам написал на ассемблере среду разработки, движок, графический редактор, фреймворк игры и выпустил коммерчески успешную игру.
А еще я тимлидил QA (друзей со двора которые играли в нее)

Так что пожалуйста не надо этого вот всего дискриминации по возрасту.

Можно скоро снять передачу «архитекторка в 16»

архитекторка

Быстро извинитесь, правильно архитекториня

1000 извинений, не хотел задеть чувства юных синьорит, которые придут на кастинг.

кнопки репорт на вас нет

Слабо, я в 20 стал

В коментарях бомбило від того, що «про архітектуру» != «про системний дизайн». Хлопці хотіли срачику про розподілені моноліти і сховища даних, а їм про технічний погляд на очікування і можливості замовника.
Зіткнення з реальним світом завжди болючі. Насправді, розмова була, якщо говорити про кар’єру архітектора як про фінансову історію успіху, приблизно про те ж, про що й легендарні 300к в сусідній темі.

P.S. З усіх трьох найкраще враження справила пані Дудка. Відчувається системність і академізм університетського викладача.

так, варто було дати їм завдання з системного дизайну і в кінці показати, що вийшло у кожного

Ага, тут власне така тема, що чимало девелоперів чомусь вирішили, ніби архітектори мають відповідати їхнім очікуванням :-)
І та ж Дудка, з її досвідом, системністю і науковим ступенем, то болтологиня і взагалі то змова архітекторів — говорити, що їхня робота це не очевидний розвиток лідської компетенції. Просто архітектори не ті, подайте нам тих, які про контейнери з гейтвеями, вже!

Ага, тут власне така тема, що чимало девелоперів чомусь вирішили, ніби архітектори мають відповідати їхнім очікуванням :-)

Я б так не формулював, проблема системна.

Довгий час позиція архітектор подавалась як наступна сходинка після тімліда (саме того який про керування командою), як альтернативний шлях розвитку для тих хто не хоче йти в менеджмент. Вже зараз великі аутсорсери додають «рівні» типу експерт-девелопер. Тому думаю, що в найближчі 5 років до нас масово дійдуть посади стаф/прінсіпл інженер. І тоді люди з личками архітектора, скоріше за все, відійдуть у пресейлс, а архітектурою на фазі реалізації, тобто тим що ніяк не можуть сформулювати хейтери архітекторів, будуть займатись стаф/прінсіпл.

Друга части проблеми — це саме оця нездатність людей сформулювати, що вони очікують від тієї чи іншої позиції. Власне провести чітку границю між техлідом та архітектором (яких є багато різних). Влесне для мене солюшн архітектор має бути трохи делівері менеджером, хоча за класикою — це принципово різні посади (по менеджерах там теж повний бардак).

Третя частина — це «класова ненависть» (саме погане тут те що це виглядає саме як ненависть). З боку девелоперів це проявляється через зацикленість на написанні коду. З боку архітекторів у стереотипі, що девелопери не думають (не хочуть думати) про вплив і необхідність їх код для бізнес задач. Корені цього теж, напевне, в історії нашого ринку.

Спасибо за разъяснение. Значит привычное понятие «архитектор» должно у всех измениться, рынок изменился. Я уже тебе давал свое понимание, но на уровне реализации теперь архитектор вообще не участвует, как я понял.

Я уже тебе давал свое понимание

Де?
Ви спочатку почали грати в жертву, хоча вам явно написали, що мета побудувати спільну систему координат. А потім почали задавати питання на визначення того чи іншого атрибута та дали визначення того що не є архітектором, при тому воно ніяк не інвертується. А ще не ясно, що ви розумієте під поняттям «системний дизайн, де можна одразу писати код».

Власне відповіді на питання

В чому для вас різниця або краще дайте визначення System, Software та Solutions Architect?

ви так і не спромоглись дати.

Я уже тебе давал свое понимание, но на уровне реализации теперь архитектор вообще не участвует, как я понял.

---

но на уровне реализации теперь архитектор вообще не участвует, как я понял.

Ви справді не здані прочитати наступне речення?

І тоді люди з личками архітектора, скоріше за все, відійдуть у пресейлс, а архітектурою на фазі реалізації, тобто тим що ніяк не можуть сформулювати хейтери архітекторів, будуть займатись стаф/прінсіпл.

Якщо в майбутньому архітектори відійдуть від фази реалізації. то запитання:
Хто ж це зараз займається архітектурою системи під час констракшн фази (фази реалізації)?
І звідки вони будуть відходити?

Staff/Principal архитекторы участвуют на фазе реализации? А кто же тогда System архитектор? Дайте свое определение. Я не могу дать, у меня нет знакомых архитекторов разных, я просто хочу понять смысл архитектора, который не проектирует Солюшены именно как подпроекты (onion/clean architecture). Системный дизайн, где сразу можно писать код — это Архитектура ПО, если неправильно понял, поправьте. Я пытался донести, но реакции ноль.

Staff/Principle архитекторы участвуют на фазе реализации?
до нас масово дійдуть посади стаф/прінсіпл інженер

Іпать-копать.

А кто же тогда System архитектор? Дайте свое определение. Я не могу дать, у меня нет знакомых архитекторов разных, я просто хочу понять смысл архитектора

Ви почали використовувати термін System архитектор і не можете дати його визначення та просите іншу людину дати визначення терміна, який ви ввели?

Я особисто взагалі використовують спрощену системи ролей
dou.ua/...​ome-an-architect/#1975201

В більшості контор ця схема значно розширена.

Я обычный рядовой девелопер. Просто мне нужны экспертные мнения. Все говорят разными терминами. Так кто же всё-таки занимается любимой темой у девелоперов под названием Архитектура ПО, где выбираются всякие clean, onion, mvc, mvvm и т.д.?

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

Да и похоже решение идёт от команды во главе с техлидом. А архитектор решает задачи уровнем выше. Но опять же, важность архитекторов — мыслителей мне не понять с высоты своего полета скажем так.

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

А если команд не одна, а 10? И у всех свое видение.

Да и прошу прощения за путаницу, значит тот, о ком я думаю — это Principal Engineer. Ок, тогда слово «Архитектор» мне нужно забыть, мне не понять, как тут говорилось, о важности умения выявлять требования у заказчика применимо к слову «Архитектор». Этим я никогда заниматься не буду и не хочу. Видимо, все что я слышал в жизни максимум — это Software Architecture на уровне Visual Studio солюшена.

Подписаться на комментарии