В данной статье рассматривается профстандарт архитектора ПО (06.003).
Ссылки на первоисточники:
профстандарт "Архитектор ПО" https://classinform.ru/profstandarty/06.003-arhitektor-programmnogo-obespecheniia.html
профстандарт "Разработчик ПО" https://classinform.ru/profstandarty/06.001-programmist.html
Добрый день, уважаемые коллеги!
Данной статьей я преследую цель ознакомить аудиторию с профстандартом архитектора программного обеспечения, чтобы дискуссии/диалоги велись с единым пониманием терминов, а также для расширения общего кругозора тех экспертов, кому это необходимо.
Считаю, что ознакомление с данным стандартом будет полезно как тем, кто уже не первый год работает как архитектор, так и тем, кто только планирует стать на этот увлекательный путь!
В стандарте достаточно однозначно приведены обязанности, требуемое образование, и необходимый опыт (Про образование подготовлю отдельную статью, о которой сообщу отдельно).
Буду благодарен за дискуссию по данной теме, жду ваших комментариев!
«Не нужно выдумывать велосипед»
В который раз возвращаюсь к старой теме, что архитектор не пишет код. А тот, который пишет, скорее является лидером команды (team lead), который совмещает в себе сразу несколько обязанностей, имеет не самую большую команду, или в команде отсутствует разграничение ответственности, и такой архитектор морально не готов/не хочет перейти на следующий уровень абстракций.
На этот раз хочу рассмотреть этот вопрос с точки зрения профстандарта архитектора программного обеспечения, и провести аналогию с профстандартом разработчика (06.001) и другими источниками. В частности, пример из Linkedin по запросу «Solutions architect».
На мой взгляд эти аргументы железные.
Стандарт архитектора ПО утвержден 30.08.2021 и действует с 1 марта 2022 года до 2028 года.
Т.е. фактически это молодой стандарт, и как таковой специальности до этого не существовало, а полномочия таких экспертов были размазаны по другим специальностям.
Сейчас в ВУЗах преподают дисциплины, в названии которых присутствует термин «архитектура». Например, «архитектура вычислительных систем» - про микропроцессоры, или «Проектирование программного обеспечения» - про подготовку компонентных диаграмм программных/автоматизированных систем, и др. Таким образом сразу открывая горизонты перед молодым поколением.
«Руководитель среднего звена»
Вернусь к стандарту. Сразу хочется обратить внимание, что цель деятельности архитектора, заявленная в профстандарте – это проектирование, мониторинг и контроль. Проведу параллель по моим наблюдениям в Linkedin – как правило, Solutions architect относится к руководителю среднего звена.
Аналогично и в профстандарте: деятельность относится либо к группе занятий руководителя службы или подразделения, или все-таки к разработчикам, но с оговоркой, что если не удалось отнести их к другой группе.
Т.е. можно сделать вывод, что архитектор – это не специалист, закончивший институт, и который без сомнения много умеет (но пока что недостаточно), а эксперт, имеющий за плечами опыт работы с крупными системами или ИТ-ландшафтами. Крупными, потому что некрупным архитектор не нужен.
Далее в стандарте представлены обобщенные трудовые функции:
Управление архитектурой изолированной (неинтегрированной) программной системы;
Управление архитектурой интегрированного программного обеспечения;
Управление архитектурой единой информационной среды.
Т.е. фактически в стандарте приведена классификация систем, что системы бывают монолитные, или интегрированные, или очень сильно интегрированные.
И далее трудовые функции сгруппированы по роли/масштабу/опыту архитектора:
Архитектор;
Ведущий архитектор;
Главный архитектор.
И каждая из этих ролей явно сопоставлена с обобщенной трудовой функцией (указал их чуть выше) – т.е. Архитектор работает с изолированной системой, Ведущий архитектор – с интегрированной системой, а Главный архитектор – с единой информационной средой.
Конечно же в стандарте также приведены рекомендации по образованию архитекторов. Для всех уровней архитектуры приведена рекомендация по повышению квалификации по моделированию систем. Об этом я напишу отдельно, чтобы сейчас не увеличивать время на чтение. Обещаю, это будет увлекательно!
«Что я должен делать»
Дальше я не буду перечислять все трудовые функции архитектора, заявленные в стандарте. Надеюсь, что вы самостоятельно ознакомитесь с ними. Со своей стороны я только сгруппирую основные функции архитектора и положу глаголы функций в облако тегов:
Выявление и согласование требований … с точки зрения архитектуры;
Выбор и моделирование …;
Разработка разделов …;
Контроль реализации и испытаний … с точки зрения архитектуры;
Сопровождение эксплуатации … с точки зрения архитектуры;
Создание и согласование требований … с точки зрения архитектуры.
Стандарт достаточно подробно описывает каждую трудовую функцию, а именно:
Какие трудовые действия трудовая функция включает;
Умения, необходимые для выполнения трудовой функции;
Знания, необходимые для выполнения трудовой функции;
А также другие характеристики.
«Что я не должен делать»
А теперь давайте посмотрим на обобщенные трудовые функции из профстандарта разработчика программного обеспечения (06.001 https://classinform.ru/profstandarty/06.001-programmist.html):
Разработка и отладка программного кода;
Проверка работоспособности и рефакторинг кода программного обеспечения;
Интеграция программных модулей и компонентов и проверка работоспособности выпусков программного продукта;
Разработка требований и проектирование программного обеспечения
Вот вам и разница!
«Доброе слово рабочей группе»
По моему мнению, эксперты, которые готовили данный стандарт, довольно четко и ясно очертили круг задач архитектора. И если на рынке труда встречаются комбинированные варианты архитектора-разработчика-аналитика (без сомнения, архитектор должен быть знаком на собственном опыте с такими задачами) – то это скорее либо специфика отдельного предприятия, либо попытка подмены понятия, либо экономия бюджета, либо другие возможные варианты. Это поиск универсального солдата.
Хотелось бы в качестве заключения озвучить, что сам я минимум раз в год погружаюсь в лабораторную среду, рассматриваю языки, на которых ранее не писал, или начинаю разворачивать ПО, с которым раньше не работал. И даже иногда подумываю, почему бы по новой для меня исследуемой технологии не поработать месяца три так называемым Джуниором. Периодически ностальгирую по коду!
Но потом откуда-то появляется много новой работы по прямому назначению, так что большое спасибо за ознакомление со статьей, откланиваюсь и ухожу проектировать крупные системы!
До новых встреч, уважаемые коллеги! Жду ваших комментариев!
Комментарии (29)
ialexander
01.11.2023 22:32-1А как насчёт Solution Architect, являющийся частью Sales команды в качестве технического специалиста и помогающий будущему клиенту понять как покупаемое клиентом ПО может использоваться клиентом. Эту роль вряд ли можно назвать руководителем среднего звена.
pashigorev Автор
01.11.2023 22:32+2Эту роль можно смело назвать менеджером по продажам. Представьте архитектора зданий который ходит по квартирам и рассказывает какие поклеить обои. Не хотел резко, но как аналогия норм
Dynasaur
01.11.2023 22:32+1Представьте архитектора, который встречается с заказчиком небоскрёба до того как его построят для того, чтобы согласовать ожидания, требования и будущий облик. Или вы думаете, заказчику не нужна вся эта ерунда и нечего обсуждать с архитектором, достаточно только с девочкой из маркетинга попить кофе?
pashigorev Автор
01.11.2023 22:32Ладно, хожу с козырей, раз дела уже дошли до небоскреба. Представьте, как он (архитектор) прибежал на встречу по теме нового небоскреба с другой встречи по строительству избушки.
Вот мой посыл: работодатель платит большие деньги архитектору, например, 1000 руб./час * 8 = 8000 руб./сутки.
Строительство избушки принесет работодателю выгоду 1500 руб., а встреча займет 2-4 часа.
Поэтому в целом да, архитектор на предпродажке может быть, и должен быть, но если один клиент купил, а другой не купил, а работодатель платит деньги архитектору, а мог бы оптимизировать эти затраты и платить специалисту грамотному, но попроще, то человек, который помогает определиться клиенту с продажей - вряд ли архитектор, он менеджер по продажам, потому что его KPI зависит от продажи.
Dynasaur
01.11.2023 22:32+2Так себе у вас козыри. Исправление ошибок, допущенных на раннем этапе проекта на последующих обходится на порядки дороже. Вы сэкономили на оплате недели работы архитектора на пресейле, ура! В итоге он не понял что хотел заказчик и построил небоскрёб, а заказчику нужен был бассейн на 58м этаже. А ещё вентиляцию на крышу из подвала - там будет ресторан.Теперь будем в готовое здание впердоливать бассейн и дополнительную вентиляцию. За чей счёт? Экономия!
И согласование это процесс двусторонний. Архитектор мог бы сразу отговорить от бассейна на 58м этаже по тому, что это слишком сложно и дорого. А предложил бы бассейн в фундаменте. Но не отговорил и не предложил. Сэкономили!
pashigorev Автор
01.11.2023 22:32Это вопросы к менеджеру, который продал небоскреб, и к Заказчику, который согласился на это. У Заказчика вообще есть 58 этаж? Менеджер сам может в этом убедиться? Пусть делает свою работу и составляет график проекта, а не отрывает грамотных людей от работы.
По поводу вентиляции не скажу, не спец, у меня только ИТ
funca
01.11.2023 22:32Архитектор ПО это наверное software architect, который занимается архитектурой собственно приложения - на уровне пакетов, модулей, компонентов, классов.
Следующий уровень systems architect. Он делает так, чтобы разные приложения и информационные системы в организации работали вместе.
Solution architect это мостик между бизнесом и решениями его бизнесовых проблем. Он строит свои решения уже на уровне capabilities организации (которые включают в себя не только айтишные функции). Стоит ли ему писать код? Ну ни кто не запрещает, но это действительно не его основная задача.
pashigorev Автор
01.11.2023 22:32поддерживаю! В последнее время меня еще стал интересовать термин "системный архитектор", и вот такая игра понятиями вводит в заблуждение
VDacc
01.11.2023 22:32+3Могу немного рассказать про роль в рамках американских компаний. Последние 5 лет имел роль L6 архитектора в компании из fortune 20. Для контекста, мой орг насчитывал 70 человек в 3 странах. Мы поддерживали 3 платформы с миллионными QPS и реализовывали десятки E2E решений в год для определенного круга бизнес задач. Я напрямую репортил L8 синьор директору, периодами VP.
Для платформ я был system architect. Основные обязанности были: 1) Предоставление виденья развития на следующие 1-5 лет. 2) Выявление и документирование и внедрение инженерных стратегий на основе архитектурных записей. 3) Помогать продуктовым и инженерным менеджерам с квартальным планированием. 4) Ревью дизайн документов. Можно заметить, что я не занимался дизайном решений сам. У платформ есть тех лидеры и несколько стафф инженеров, для которых проектная работа важнее в плане роста. Но я контролировал, какие решения выбирает команда и как они согласуются со стратегиями и виденьем.
Для E2E решений я был solution architect. Обычно в проекте участвовало 50-60 человек из 10-15 команд. Но были у меня и проекты на 400 человек. Основные обязанности: 1) Сбор требований для проекта 2) Разработка модели 3) Согласование с безопасниками и юристами 4) Согласование со всеми командами и лидерами. Для больших проектов согласование может быть в формате офф-сайт на 100+ человек на 2-3 дня, как правило, в долине, но однажды был в Нью-Йорке. 5) Помощь в планировании 6) Помощь с внезапными вопросами в процессе реализации. 7) Ретроспектива и обновление стратегий/видения. Опять же отличается от описанного в статье. Дизайн, реализация, тестирование и поддержка ложатся на плечи лид инженеров из соответствующих команд. Контроль выполнения, решение комуникационных проблем и "мотивирование" успеть в срок лежит на TPM. У TPM, как правило, 1-3 важных проекта на квартал, у них есть на это время. У моей команды обычно было 10-15 важных проекта на квартал. Я либо сам участвовал, либо спонсировал своих падаванов.
Еще в обязанности входит менторинг, обучение команды и прочие technical excellence. Обычно мне на квартал давали 2-3 человека, и еще двое помогали мне на постоянной основе. Я хостил минимум один коричневый мешок в квартал. Плюс иногда отвечал за technical excellence проекты, например, смещение акцента с юнит тестов на интеграционные и внешние функциональные. Такой проект обычно включает несколько презентаций и близкую работу с тех лидами в течении квартала.
Можно заметить, что горизонт планирования у меня был квартал. Это означает, что надо мной было еще 2 уровня архитекторов. Надо мной был архитектор ответственный за 10к орг. Ее горизонт планирования в районе года. Обычно я с ней созванивался пару раз в неделю. Над ней был еще круг из 3х архитекторов, чьи позиции эквивалентны VP+, они ответственны за стратегические решения, которые повлияют на компанию в следующие 3+ года, может десятилетия.
По поводу должен ли архитектор писать код. На первом интервью с рекрутерои на L6+ вам скажут, что ожидают от линейных инженеров на этой позиции 70% проектной работы и 30% написания кода. Как архитектор, я иногда пилил маленькие проверки идей в последний месяц квартала, если удача была на моей стороне. Но никто не просил меня писать код. Я пытался хотя бы делать код ревью ключевых фич в моих проектах чтобы поддерживать связь с реальностью.
pashigorev Автор
01.11.2023 22:32L6 - это level 6? Мне интересно было бы посмотреть на такую градацию. Может есть рекомендации куда посмотреть?
trueMoRoZ
01.11.2023 22:32В гугл
pashigorev Автор
01.11.2023 22:32Серьезно? А как же рекомендации? А как же дискуссия? Не надо ссылку, на какой документ обратить внимание?
Batalmv
01.11.2023 22:32+2Работаю солюшен аритектором уже лет 15. Продуктивный код не пишу ... тут понятно, так как чтобы это делать, надо делать регулярно.
Но в рамках PoC собрать чего-то новое - почему бы и нет. Тут как раз лучше руками почувствовать как это новое выглядит
Есть важный аспект, который пропущен. Это закрытие gap'ов в команде. Часто делаешь что-то что просто некому во время внедрения, пока не найдет/обучишь альтернативу
Dynasaur
01.11.2023 22:32+1Меня закидают тапками, но я работал архитектором решения и код не писал. Во всяком случае по своему решению. Это разная работа. У архитектора хватает чем заняться, а код есть кому писать.
pashigorev Автор
01.11.2023 22:32Точно! Ему нужно проектировать вентиляцию на 85 этаже!
Мое мнение - что стандарт очень нужный, просто на рынке полно вакансий для универсальных солдат. Тапки кидать не буду.
sergey-gornostaev
01.11.2023 22:32Помню, как мне предложили эту должность со словами "Придётся 40 часов в неделю сидеть на созвонах". Действительно, хватает чем заняться.
Dynasaur
01.11.2023 22:32ну да. Только не "сидеть на созвонах", а активно согласовывать противоречивые требования и решения. И от качества этой работы зависит что вы в итоге построите - франкенштейна или гармоничное решение, где все части будут согласованы и к месту. Если у вас все крутят гайки и никто не видит общей картины - то будет франкенштейн. "К пуговицам претензии есть?" (с)
sergey-gornostaev
01.11.2023 22:32Я наверняка не буду оригинален в том, что большинство сберовских созвонов вообще не нужны и могут быть заменены парой-тройкой писем или задачей в Jira, и большая часть их времени бесполезна чуть более, чем полностью.
Dynasaur
01.11.2023 22:32Я не сидел на сберовских созвонах, ничего о них сказать не могу. Но чтобы построить большую и красивую систему, надо очень много нюансов обсудить, согласовать и сбалансировать. Каждое поле, каждая галочка имеет свой смысл и влияет на поведение системы, каждая должна быть на своём месте и работать ровно так, как надо. А как надо? Это кто-то должен продумать и всех заинтересованных убедить, что именно так будет лучше всего. И сточки зрения потребителей и сточки зрения технической. И всё должно следовать какой-то единой концепции. Это большая работа, в основном на совещаниях, да. Но это очень интересная и важная работа. Мне было очень интересно этим заниматься.
BugM
А потом появляется очередная статья. "Я крутой архитектор и не умею писать код (я не про уровень студента, а про уровень хорошего сеньора. l5 Гугла примерно). Почему меня никто не берет на работу?" Собственно вот поэтому и не берут.
pashigorev Автор
Ну не, эта статья про другое. Если увидите такое, зовите, будем вместе отрабатывать
serjeant
Работал в Сбере несколько лет назад, в нашей команде архитектором был человек, без опыта работы разработчиком. Было очень тяжело.
pashigorev Автор
Человека? Или Сбер?
В стандарте как раз описывается, что опыт кода должен быть.
Сейчас с коллегами тоже ведем дискуссию по этому стандарту, должен или не должен, и появляется тезис, что код для архитектора может быть инструментом для выполнения своих задач.
Вот пример от моего коллеги https://youtu.be/B7IqUR9yb0w?si=CX1UY8wHwmzy5q6I использования такого инструмента архитектором.
Тоже крутая штука!
sergey-gornostaev
Кстати, @rpiontik регулярно говорит и пишет, что архитектор программировать должен, а то потеряет контакт с реальностью. И под программированием он имел ввиду не только нотации DocHub, на сколько я его понял.
pashigorev Автор
Да, так и есть, держать руку на пульсе безусловно надо, главное не лезть в Продакшн продукта!
На ArchDays разговаривал со своим одногруппником, он тоже говорит что периодически пишет код (потому что умеет), но решает с помощью кода свои управленческие или архитектурные задачи.
А подход Романа в части architecture as a code мне тоже нравится, но это уже больше инструмент архитектора и решение вопросов архитектуры, а не непосредственно Продукта.
Поэтому пишите код в свое удовольствие!
BugM
Увы, именно так обычно все и получается.
Откуда вообще эта мысль что человек который не пишет код может понять как проект внутри должен быть устроен? Он же понятие имеет как реально себя ведет та или иная система, какие у них реальные ограничения и чем разработка хочет/не хочет пользоваться. Желания разработки весьма вероятно мотивированы чем-то.
Нарисовать пять квадратиков соединить их стрелочками и уйти в закат можно. Но смысл? Потом опять придут разработчики и сделают нормально. Или быстро, если так надо.