Странность, которую мы перестали замечать - почему в 1С два архитектора?
Я раньше об этом не задумывался. Ну есть в вакансиях «функциональный архитектор 1С» и «технический архитектор 1С» - и есть. Но с недавних пор я стал глубже изучать методологии разработки, и вспомнил об этом: а почему, собственно, архитектор у нас раздваивается? Две разные вакансии, два разных набора требований, иногда в одной и той же компании.
Ведь больше так никто не делает. Нет «функционального программиста» и «технического программиста». Нет двух видов тестировщика. Нет «технического руководителя отдела». Причем уникальна тут не только профессия, но и наша любимая 1С: «функционального Java-архитектора» или «технического Python-архитектора» не существует в природе - это даже звучит дико. А у нас есть две штатные роли. Почему именно у нас и именно архитектор разделился на две части?
Предупреждаю про жанр этой статьи. Дальше - не истина в последней инстанции, а расследование по открытым источникам, плюс мои размышления. Я вполне могу где-то ошибаться: будет хорошо, если поправите в комментариях.
Ответ на заданный вопрос, оказался интереснее, чем я ожидал. И начинается он совсем не в 1С.
Это пришло из ERP, а не из разработки
Сразу дам ответ. Пара функциональный/технический - вообще не из мира программирования. Это классика внедрения ERP, и придумали ее задолго до 1С - в мире SAP.
В SAP существует ровно такая же пара:
- Функциональный консультант - знает бизнес-модули (финансы, кадры, логистика, производство), понимает процессы заказчика и настраивает систему под них. Он про бизнес.
- Технический (ABAP) консультант - пишет код, делает доработки и интеграции, разбирается во внутренностях платформы. Он про технику.
Функциональный приносит требования бизнеса, технический превращает их в работающую систему. Так устроено любое крупное внедрение SAP, Oracle или Dynamics - и устроено давно, задолго до наших споров об архитекторах 1С.
Дальше произошло вот что. Когда 1С пошла в крупный корпоративный сегмент - туда, где раньше единолично правит SAP, - она пришла на поле с уже сложившейся культурой внедрения. Заказчики, методологии, да и сами люди - многие приходили из SAP-проектов. И вместе с этим полем 1С впитала его роли. Со временем фирма «1С» закрепила их официально - в собственной методологии 1С:ТКВ (Технология корпоративного внедрения), где «функциональный архитектор» и «технический архитектор» прописаны как штатные роли проекта.
То есть слово «архитектор» в нашем «функциональном архитекторе» - это вообще не про software architecture. Это про роль в ERP-проекте, унаследованную от SAP-консалтинга.
Проверяем гипотезу: а как у других?
Красивая теория, давайте ее проверим. Если раскол действительно пришел из мира внедрения ERP (тут я имею в виду конечно не конфигурацию 1С:ERP Управление предприятием, а вообще класс программного обеспечения Enterprise Resource Planning, планирование ресурсов предприятия), он должен находиться везде, где есть ERP, и отсутствовать там, где ее нет.
Сначала общая классификация.
Большой международный ИТ. Мировая практика классифицирует архитекторов минимум по двум осям - и ни одна из них не сводится к паре «функциональный/технический».
Первая ось - по масштабу и близости к реализации. Enterprise Architect отвечает за то, куда движется ИТ-ландшафт всего предприятия; Solution Architect проектирует конкретное решение под задачу; Technical Architect - за то, как это реализовать и эксплуатировать. От стратегии к железу, три уровня разделения.
Вторая ось - по доменам, как в TOGAF: Business, Data, Application, Technology, и под каждый домен бывает свой архитектор - от Business Architect до Data Architect.
Обе оси - общепринятые, по ним написаны книги и выстроены сертификации (тот же TOGAF). А вот пары «функциональный/технический» среди них нет вообще.
А это не Business Architect ли? Резонное возражение - тот же Business Architect из TOGAF вроде бы и есть наш функциональный. Сходство и правда есть: оба на стороне бизнеса, оба не про код, оба переводят потребности заказчика в устройство системы. Business Architect - самый близкий родственник функционального. Но роль все-таки другая, и разница как раз показывает принцип деления.
TOGAF разделяет архитектуру по доменам-слоям: бизнес, данные, приложения, технологии - четыре горизонтальных пласта одной и той же системы. Их архитекторы не конкуренты, а соседи по этажам: каждый ведет свой слой сверху донизу. Да и сам Business Architect тут - скорее про уровень предприятия и стратегию (карты способностей, потоки создания ценности), чем про настройку конкретной системы под конкретного заказчика.
Пара «функциональный/технический» живет в одном месте - в практике внедрения ERP, где functional и technical consultant - базовые роли любого проекта.
ERP-мир делит, в отличии от TOGAF, по другой линии - «настраивать против программировать». Функциональный и технический - это не два слоя, а два способа участия в одном внедрении. Функциональный забирает всю бизнес-сторону разом: процессы, настройку модулей пакета под них, первичные данные - то, что в TOGAF разошлось бы сразу по нескольким доменам. Технический забирает все, что требует кода: доработки, интеграции, производительность. То есть пара «функциональный/технический» не ложится ни в один домен TOGAF - она идет поперек, схлопывая четыре мировых домена в два по принципу «ближе к бизнесу против ближе к машине». А почему так - понятно из природы работы: ERP не строят с нуля, его настраивают. Когда систему не проектируют, а конфигурируют под заказчика, главный раздел проекта не «данные против приложения», а «сконфигурировать против дописать код». Вот по этому принципу пара и разделяется - и вот почему Business Architect не соответствует функциональному архитектору.
Также я пошел изучать вакансии.
Российский ИТ вне ERP. Открываем вакансии банков и продуктовых компаний - и видим кальку с международной модели: «архитектор решений», «системный архитектор», «корпоративный архитектор», «архитектор ИТ-инфраструктуры». Функционального архитектора там нет. Вообще нет.
Российский ERP вне 1С. А вот тут - есть! В вакансиях по SAP спокойно встречаются «функциональный архитектор SAP» и «функциональный архитектор ERP». Российский SAP-мир пользуется ровно той же парой, что и мы, слово в слово.
Картина сходится: пара «функциональный/технический» следует не за платформой 1С, а за словом ERP. Есть внедрение ERP - есть функциональный архитектор, и неважно, SAP это или 1С. Нет ERP - роль исчезает, остаются solution, system и enterprise. Так что наши два архитектора - не самобытность 1С, а прописка в ERP-культуре. Что и требовалось доказать.
Технология корпоративного внедрения (1С:ТКВ)
Небольшое отступление. До этого расследования я про Технологию корпоративного внедрения (1С:ТКВ) не знал вообще ничего - при том, что в 1С я со времен 7.7. Если вы тоже слышите эту аббревиатуру впервые (подозреваю, нас таких большинство) пара слов о ней не помешает.
Текущая редакция - 1С:ТКВ 2.0, синхронизирована с PMBOK и отечественными стандартами по управлению проектами. По ней идут официальные онлайн-курсы, а сама технология продается как пополняемая база знаний по подписке (сервис «ПрофКейс» на сайте 1С:Консалтинг) - то есть это не пыльный PDF, а поддерживаемый продукт. Причем Технология корпоративного внедрения - часть действующей линейки из трех методологий: ТСВ (стандартное внедрение, минимум доработок), ТБР (быстрый результат, по сути agile) и ТКВ (корпоративное - крупные проекты с серьезной доработкой и изменением архитектуры). Роли функционального и технического архитектора закреплены не во времена оны, а в действующей версии.
Пишут о ней и за пределами экосистемы: в 2024-м про ТКВ вышла научная статья, на профильных площадках разбирают ее роли и фазы. При этом на самом Инфостарте отдельного объясняющего материала про Технологию корпоративного внедрения я не нашел: она всплывает фоном в статьях про управление проектами, а разбора «что это и зачем» нет. Тема толком не освещена.
Когда это вообще началось
Я попробовал раскопать, с какого года в 1С завелись архитекторы. Единой даты не нашлось - роль появлялась постепенно.
В 2000-е слова «архитектор» в 1С-мире практически не было. Были «специалист», «эксперт», «руководитель проекта» и привычная франчайзинговая табель о рангах. Показательно, что в официальной сертификации 1С грейда «архитектор» нет до сих пор. Причем сама логика аттестаций любопытна: «1С:Специалист» по платформе - это, по сути, экзамен программиста (задачи, код, механизмы), а «1С:Специалист» по типовой конфигурации - уже экзамен аналитика (методология, учет, как правильно применить типовую). Вендор различает программиста и аналитика - тот самый шов, по которому потом разделятся архитекторы, - но самого архитектора между ними так и не завел. Проверять «умение принимать архитектурные решения» экзаменом никто не берется.
Начало 2010-х. Появляется методология управления проектами. У 1С заводится линейка «технологий управления проектами» - и, судя по веб-архиву (Wayback Machine), довольно рано. Обучающий курс «1С:Бизнес-Школа. Управление проектами» доступен уже в 2010-м, а к 2011-му на consulting.1c.ru оформлена методическая витрина: первая из будущих трех технологий - ТБР (Технология Быстрого Результата) - уже названа, работает сертификация «руководитель проектов» и «руководитель корпоративных проектов». А вот архитекторов в ролях еще нет - и, забегая вперед, не появится еще долго.
2012-2013. Рождается первая Технология корпоративного внедрения. Точную дату релиза я не нашел, но вилка получается такая: методология опирается на ГОСТ Р 54869-2011 по проектному менеджменту (вышел осенью 2011-го), а осенью 2013-го главный редактор журнала «Управляем предприятием» Константин Зимин уже разбирает ее аксиомы, фазы и роли в двух больших статьях. И вот что поразительно: в списке из 19 ролей той первой Технологии корпоративного внедрения архитекторов нет. Ни функционального, ни технического. Проектирование архитектуры есть - но как этап жизненного цикла, а не как человек. «Спецификацию требований и архитектуру ИС» разрабатывает системный аналитик. Архитектура без архитектора. Запомните эту деталь, она нам еще пригодится.
С той первой Технологией корпоративного внедрения вообще вышла детективная история - для меня, пожалуй, главный сюрприз всего расследования. Действующая редакция, оказывается, уже вторая, а первой словно и не было. В инфописьмах фирмы «1С» ее нет - я перерыл: первое упоминание технологии в письмах сразу с номером 2.0. Само имя ТКВ, если покопаться в веб-архиве, висит на витрине технологий consulting.1c.ru уже в 2017-м - но без всякого номера версии и без состава ролей: просто «есть такая технология». А детальные следы именно первой редакции тают на глазах: иллюстрации к статьям Зимина лежали на том же consulting.1c.ru (что, кстати, выдает близость журнала к самой фирме), сегодня ссылки ведут в никуда, и даже веб-архив картинок не застал. Похоже, первая редакция жила в партнерских материалах, а до полноценного публичного релиза - с номером, ролями, продажей по подписке - дотянула уже только вторая. Если застали первую живьем - расскажите в комментариях.
2014. Профессию замечает государство: выходит первый профстандарт 06.003 «Архитектор программного обеспечения» (приказ Минтруда № 228н от 11.04.2014; действующая редакция - 2021 год).
Вторая половина 2010-х. Слово расползается по проектам и вакансиям - функциональных и технических архитекторов привозят с собой люди из ERP-консалтинга. К 2020-му термин уже настолько в обиходе, что на Инфостарте выходит статья «Кто такой архитектор? Системный или функциональный?». Вопрос в заголовке - уже сам по себе диагноз: слово есть, а понимания, что оно означает, нет.
2020. Выходит ТКВ 2.0 (инфописьмо № 26746 от 27 января 2020 года о начале продаж онлайн-продукта «1С:База знаний по методологиям внедрения и сопровождения») - и в ней функциональный и технический архитектор уже штатные роли проекта. Порядок интересный: сначала роль прижилась в проектах - и только потом попала в документ, а не наоборот.
С 2021-го - закрепление. Фирма «1С» открывает Центры проектных компетенций, где «технический архитектор» - уже должность в самой фирме, множатся курсы «Архитектор 1С». А с 2022-го уход SAP делает роль еще и дефицитной.
Маршрут получился такой: слово пришло в 1С не снизу, от разработчиков, и не от вендора через сертификацию. Оно вошло сбоку - из практики корпоративных внедрений, а методология лишь оформила сложившееся. Наши архитекторы - дети ERP-проектов, а не платформы.
Почему архитекторский раскол у нас прижился
Хорошо, импортировали практику ERP. Но почему раскол прижился у нас? Тут уже сработала специфика самой 1С. У меня три объяснения.
Платформа забрала всю середину. В обычной разработке архитектор проектирует систему снизу наверх: слой данных, взаимодействие компонентов, инфраструктуру. В 1С почти все это уже решено за нас - платформой и БСП. Слой данных, ORM, формы, клиент-сервер, механизмы обмена - уже готовое. Работы «спроектировать приложение с нуля» практически нет. А что остается? Две вещи: с одной стороны - положить бизнес-процессы предприятия на конфигурацию, с другой - заставить платформу держать нагрузку, поддерживать интеграции и релизы. Середину забрала платформа, остались два полюса. Вот вам и два архитектора - и почти полное отсутствие «архитектора приложения» как самостоятельной роли, которая в большой разработке есть.
Два отдельных источника кадров. В 1С исторически есть две почти не пересекающихся породы людей. Первая - предметники и консультанты, вчерашние бухгалтеры и экономисты, которые пришли в 1С со стороны учета и «настраивают без программирования». Вторая - разработчики, которые пишут код на встроенном языке. Сообщества даже культурно разные: свои конференции (посмотрите хотя бы на инфостартовские), свои чаты, свои задачи. И когда на проекте понадобился архитектор, профессия просто раскололась по этому шву: функциональные чаще вырастали из консультантов и аналитиков, технические - из разработчиков. Чаще - не значит всегда: есть интеграторы, у которых доработки проектируют программисты, и тогда именно из них получаются отличные функциональные архитекторы. Но самого раздела это не отменяет. В обычной разработке все начинают программистами, шва нет - оттого нет и двух архитекторов.
Очень тяжелый домен. 1С-конфигурации обеспечивают в том числе регламентированный учет, который меняется вместе с законодательством. Владеть этим доменом - отдельная полноценная профессия, не сводимая к владению платформой. Бухгалтерия, расчет зарплаты, производство, маркировка, прослеживаемость - в каждой теме можно утонуть, и каждый год появляется что-то новое. Поэтому глубокая бизнес-экспертиза и глубокая платформенная экспертиза физически не помещаются в одну голову на большом проекте. Их и разнесли на двоих - не из любви к иерархии, а потому что иначе не унести.
Деталь, которая объясняет все
Один факт расставил для меня все по местам. В обзорах внедренцев пишут: в методологии 1С:ТКВ функциональный архитектор - обязательная роль, а в SAP-проектах он - опциональный. Оговорюсь: сам текст ТКВ 2.0 продается по подписке, и сверить формулировку с первоисточником я не смог - если у вас есть доступ к ПрофКейсу, подтвердите или опровергните в комментариях. Но логика за этим утверждением стоит убедительная, судите сами.
Казалось бы, должно быть наоборот: SAP больше, серьезнее, дороже. Но нет. Причина в природе систем. Типовые конфигурации 1С куда более пластичные и «дорабатываемые»: под каждого клиента бизнес-процессы фактически собираются заново, вариативность огромная. У SAP модули жестче, там функциональный чаще «настраивает в рамках рельсов».
А чем пластичнее система, тем острее нужен человек, который держит в голове, что и зачем мы строим, - иначе гибкость превращается в хаос. Вот почему у нас функциональный архитектор не просто существует, а возведен в обязательную роль. Это плата за гибкость платформы и конфигураций.
Почему это стало еще актуальнее
SAP и прочие западные ERP из России ушли. Их место в крупном корпоративном сегменте занимает - кто бы сомневался - 1С. По оценкам рынка, доля отечественных ERP уже перевалила за половину, и львиная ее часть приходится на 1С. То есть ровно те проекты, где раньше работала SAP-команда с функциональными и техническими консультантами, теперь делаются на 1С.
И что происходит с людьми? Они не испаряются. Бывшие SAP-консультанты, руководители проектов, методологи переходят на 1С и приносят с собой привычную ролевую модель: то же разделение труда, те же слова, те же ожидания «а где у нас функциональный, а где технический». Выходит парадокс: технически мы уходим от SAP, а структурно становимся на него все больше похожи. Чем активнее 1С замещает SAP в крупняке, тем прочнее в 1С-мире закрепляется SAP-овская модель двух архитекторов.
Так что два архитектора - это растущая норма.
Что это значит на практике
Ладно история и тенденции. Что с этим делать обычному человеку на проекте?
Если вы нанимаете или нанимаетесь - не ищите «архитектора вообще». Сначала определитесь, какой слой вам нужен. Нужно положить процессы холдинга на ERP, развести учет по компаниям, выбрать между типовым механизмом и доработкой по сути бизнеса - это функциональный. Нужно заниматься производительностью, проектировать интеграции, выстроить релизный процесс - это технический. Одно объявление «требуется архитектор 1С» без уточнения слоя - почти гарантия, что заказчик сам не до конца понимает, кто ему нужен.
Если вы нанимаете обоих - сразу решите, кто кому что должен. Классический источник трения: функциональный придумал процесс, технический говорит «так платформа не потянет», и оба наставивают на своей праводе. Встречал такую позицию: двум архитекторам на проекте не место, конфликт мнений неизбежен, поэтому функциональный должен подчиняться техническому. Понять ее можно, но мне ближе другая модель - не «кто главнее», а «кто на каком слое принимает решение»: функциональный отвечает за то, ЧТО система делает, технический - за то, КАК это жизнеспособно реализовать, и у них есть регламент, как сводить спорные решения. Подчинение одного слоя другому конфликт не решает, а просто загоняет внутрь: бизнес-решения начинают приниматься по технической логике.
Главный риск - провал посередине. Между «что» и «как» есть зазор, и если каждый архитектор окопался на своем слое, общую картину не держит никто. Тот самый «архитектор приложения», которого платформа вроде бы сделала ненужным, иногда все-таки нужен - хотя бы как общая ответственность двоих за стык. На больших проектах нужны оба архитектора и явный механизм их стыковки. На маленьких (ТСВ, ТБР) обычно хватает одного человека-гибрида - и это нормально, плодить роли там, где проект их не требует, не надо.
Итог
Сложить все вместе - и «загадка двух архитекторов» перестает быть загадкой:
- корпоративный сегмент 1С - это бизнес по внедрению ERP, а ERP-внедрение во всем мире организовано вокруг пары «функциональный/технический»;
- 1С взяла эту модель готовой из SAP-мира и закрепила в 1С:ТКВ;
- платформа забрала середину архитектуры, оставив два полюса;
- два раздельных кадровых источника (предметники и разработчики) дали этим полюсам готовых исполнителей;
- пластичность типовых сделала функционального архитектора не роскошью, а необходимостью;
- а импортозамещение прямо сейчас разгоняет всю эту конструкцию, перетаскивая на 1С и крупные проекты, и SAP-овскую культуру ролей.
А расскажите в комментариях: у вас на проектах эти двое - разные люди или один человек, выполняющий две роли? И кто кому, по-вашему, должен подчиняться - функциональный техническому или наоборот? Но самое интересное для меня - согласны ли вы с самой версией, откуда взялся этот раскол. Если видите его иначе или застали своими глазами, как все складывалось, - поправьте меня.
Ссылки
- 1С:ТКВ (Технология корпоративного внедрения), фирма «1С»: consulting.1c.ru/technologies/tkv
- К. Зимин, «Технология корпоративного внедрения. Часть 1. Аксиомы, модель жизненного цикла» (10.09.2013): upr.ru
- К. Зимин, «Технология корпоративного внедрения. Часть 2. Роли, фазы жизненного цикла» (12.11.2013 - разбор первой ТКВ, еще без архитекторов): upr.ru
- Functional vs Technical SAP consultants: redglobal.com
- 1С и SAP: отличия внедрения ERP (Хабр): habr.com/ru/articles/801257
- Кто такой архитектор по сути: «Ваш архитектор - не архитектор. Доказано Минтрудом»
Снимки consulting.1c.ru в веб-архиве (Wayback Machine):
- «1С:Бизнес-Школа. Управление проектами» (05.12.2010): web.archive.org
- «Методическая поддержка управления проектами», названа ТБР (17.05.2011): web.archive.org
- Линейка ТСВ / ТБР / ТКВ, ТКВ названа по имени (26.09.2017): web.archive.org