Разработка и Конфигурация · 12 мин
Что делает архитектор 1С: роль, задачи и навыки
Разбираем, чем занимается архитектор 1С: проектирование решений, интеграции, нагрузка, код-ревью, отличия от разработчика и когда он нужен компании.
Архитектор 1С — это специалист, который отвечает не за отдельные доработки, а за целостность всей системы автоматизации: как устроены конфигурации, как обмениваются данными базы, выдержит ли решение рост объёмов и числа пользователей. Если разработчик решает задачу «сделать документ и отчёт», архитектор решает задачу «спроектировать так, чтобы через два года систему не пришлось переписывать с нуля».
Роль архитектора становится критичной, когда в компании несколько баз 1С (ERP, ЗУП, Бухгалтерия, WMS, CRM), десятки интеграций с внешними сервисами и сотни одновременно работающих пользователей. В такой среде цена ошибочного проектного решения — блокировки, медленные отчёты, расхождение данных между системами и дорогостоящие переделки.
Ниже разберём конкретные задачи архитектора 1С, его отличия от ведущего разработчика, типовые артефакты работы и признаки того, что компании пора нанимать или привлекать такого специалиста.
Чем архитектор 1С отличается от разработчика и аналитика
В небольших проектах роли часто совмещаются: ведущий разработчик фактически выполняет функции архитектора. Но по мере роста системы различия становятся принципиальными. Разработчик отвечает за реализацию конкретных задач в рамках заданной архитектуры, аналитик — за сбор требований и постановку задач, архитектор — за то, как все части системы связаны между собой и какие ограничения накладывает платформа.
Ключевой признак архитектурной работы — решения принимаются до написания кода и влияют на множество задач сразу. Например, выбор между расширением конфигурации и прямой доработкой типового кода, между планом обмена и шиной данных, между хранением остатков в типовых регистрах и выделенном механизме — это архитектурные решения, последствия которых проявляются месяцами.
| Критерий | Разработчик 1С | Архитектор 1С |
|---|---|---|
| Горизонт решений | Текущая задача, спринт | Месяцы и годы жизни системы |
| Результат работы | Код, объекты метаданных | Проектные решения, схемы, стандарты |
| Типичный вопрос | «Как реализовать эту функцию?» | «Стоит ли это делать в этой системе и как не сломать смежные?» |
| Ответственность | Работоспособность своей доработки | Целостность, производительность, развиваемость всего решения |
Проектирование решения: выбор конфигураций и границ систем
Первая крупная задача архитектора — определить, из каких систем будет состоять ландшафт автоматизации и где пройдут границы между ними. Практически всегда это компромисс: одна монолитная база упрощает отчётность, но усложняет обновления и масштабирование; распределённая архитектура гибче, но требует продуманных обменов и контроля целостности данных.
Типичные вопросы на этом этапе: разворачивать ли ERP целиком или начать с отдельных подсистем; вести ли зарплату в ЗУП с выгрузкой в бухгалтерию или в одной базе; где должен жить мастер-данные по номенклатуре и контрагентам; какие функции оставить во внешних системах (сайт, WMS, CRM), а какие перенести в 1С.
Как выбрать подход к ландшафту
Архитектор фиксирует эти решения документально: схема систем, перечень мастер-данных с указанием системы-источника для каждого справочника, матрица потоков данных. Без такой фиксации через год никто не сможет ответить, почему контрагенты заводятся в CRM, а договоры — в ERP.
Интеграции и обмены данными
Интеграционный контур — самая хрупкая часть большинства внедрений 1С. Архитектор определяет транспорты (HTTP-сервисы, RabbitMQ, Kafka, файловые обмены, EnterpriseData), форматы сообщений, принципы идемпотентности и поведение при ошибках: что делать, если сообщение не доставлено, доставлено дважды или пришло с устаревшими данными.
Отдельное решение — синхронность. Синхронный вызов внешнего сервиса из транзакции проведения документа — классическая ошибка, приводящая к блокировкам и зависанию пользователей при недоступности внешней системы. Архитектор закладывает очереди, регистры сведений-«отложенные задачи» и регламентные задания-диспетчеры вместо прямых вызовов.
Ещё одна зона ответственности — мониторинг обменов: журналы ошибок, контрольные сверки остатков и оборотов между системами, регламент восстановления после сбоя. Архитектор определяет, какие сверки должны выполняться автоматически и кто получает оповещения при расхождениях.
Производительность и масштабирование
Архитектор закладывает производительность на этапе проектирования, а не «оптимизирует потом». Это включает выбор состава регистров и их индексов, решения по итогам и агрегатам, разделение оперативного и аналитического контура, правила работы с большими таблицами (партиционирование, архивация старых периодов, свёртка базы).
На действующей системе архитектор анализирует узкие места через технологический журнал, замеры производительности и счётчики СУБД, а затем принимает решения: переписать запрос, изменить структуру регистра, вынести тяжёлый отчёт в копию базы или на отдельный сервер СУБД, пересмотреть режим блокировок (управляемый режим, разделение итогов).
Как проверить здоровье архитектуры
Стабильное время, слабо зависящее от числа одновременных пользователей
Время растёт нелинейно, появляются конфликты блокировок и таймауты
Очереди не накапливаются, ошибки обрабатываются автоматически с повторными попытками
Растущий backlog сообщений, ручная «подчистка» очередей как регулярная практика
Обновление типовой части занимает часы, доработки вынесены в расширения
Обновление — многодневный проект с ручным сравнением тысяч объектов
Стандарты разработки и код-ревью
Архитектор устанавливает правила игры для команды: соглашения об именовании объектов, структуру подсистем, правила использования расширений, требования к работе с привилегированным режимом, шаблоны обработки ошибок и журналирования. В зрелых командах эти правила закрепляются в хранилище конфигурации и проверяются автоматически (например, через EDT с настроенными проверками и SonarQube).
Код-ревью архитектора отличается от ревью ведущего разработчика фокусом: не стиль кода, а соответствие решения архитектуре. Проверяется, не создаёт ли доработка скрытую зависимость между подсистемами, не нарушает ли принципы обмена, не деградирует ли производительность типовых операций, корректно ли работает при разделении данных и в модели сервиса.
- 1Собрать вводные: бизнес-процесс, прогноз объёмов данных и пользователей, ограничения по лицензиям и инфраструктуре
- 2Сформировать 2–3 варианта решения с оценкой стоимости внедрения и поддержки каждого
- 3Зафиксировать выбранный вариант в документе: схема, обоснование, отвергнутые альтернативы и причины
- 4Провести прототип на реалистичных объёмах данных для рискованных решений
- 5Передать решение команде с контрольными точками ревью и критериями приёмки
Работа с типовыми конфигурациями: дорабатывать или нет
Одно из самых дорогих решений в проектах 1С — объём изменения типового кода. Архитектор определяет политику доработок: что делается расширениями, что — внешними обработками и отдельными подсистемами, а что допустимо менять в типовом коде с обязательной маркировкой и документированием.
Практическое правило, которое отстаивает архитектор: каждая прямая доработка типового модуля должна иметь письменное обоснование, почему нельзя обойтись расширением или изменением процесса. Без этой дисциплины конфигурация за пару лет превращается в необновляемую, и компания оказывается заложником собственной системы.
Навыки и инструменты архитектора 1С
Помимо глубокого знания платформы 1С:Предприятие (механизмы блокировок, фоновые задания, сервисная модель, расширения), архитектору нужны компетенции за пределами 1С: SQL и особенности работы MS SQL Server, PostgreSQL или Oracle; очереди сообщений и протоколы интеграций; основы инфраструктуры — кластер серверов 1С, балансировка, резервное копирование.
Из методических инструментов полезны: систематика проектирования интеграций (паттерны обмена, идемпотентность, eventual consistency), техники оценки нагрузки, практики документирования архитектурных решений (ADR — architecture decision records), знание типовых конфигураций на уровне устройства подсистем, а не только пользовательского интерфейса.
Когда компании нужен архитектор 1С
Есть объективные признаки того, что без архитектурной функции система начнёт деградировать. Если вы узнаёте два-три пункта из списка ниже — привлечение архитектора окупится предотвращёнными переделками.
- В компании три и более базы 1С с обменами, и никто не может нарисовать полную схему потоков данных.
- Обновление конфигурации откладывается более чем на полгода из-за объёма доработок.
- Пользователи регулярно жалуются на блокировки и «зависания» в часы пик.
- Одна и та же информация вводится вручную в несколько систем.
- Команда разработки больше трёх-четырёх человек, и их решения начинают конфликтовать.
- Планируется переход на новую конфигурацию (например, с УПП на ERP) или слияние баз после реорганизации.
На старте крупного внедрения архитектор нужен с первого дня — именно ранние решения (структура баз, мастер-данные, интеграционная шина) потом дороже всего менять. На действующей системе разумный формат — аудит архитектуры с планом поэтапного устранения проблем, а не попытка «всё переписать».
Что важно запомнить
Архитектор 1С отвечает за целостность системы: границы конфигураций, схемы обменов, производительность, стандарты разработки и политику доработок типового кода. Его решения принимаются до написания кода и окупаются отсутствием дорогих переделок. Чем больше баз, интеграций и разработчиков — тем выше потребность в этой роли.
Частые вопросы
Чем архитектор 1С отличается от ведущего разработчика?
Ведущий разработчик обеспечивает качество кода команды и решает сложные технические задачи в рамках заданной архитектуры. Архитектор определяет саму архитектуру: состав систем, интеграционные схемы, стандарты и ограничения. На практике один человек часто совмещает обе роли, но функции различны: одна — про решения, другая — про реализацию.
Нужен ли архитектор, если у нас одна типовая база и два разработчика?
Отдельный специалист обычно не нужен, но архитектурные решения всё равно кто-то должен принимать осознанно: политика доработок, правила обменов, подход к расширениям. Достаточно, чтобы эти вопросы регулярно обсуждались и фиксировались, а не решались стихийно каждым разработчиком по-своему.
Какие сертификаты подтверждают квалификацию архитектора 1С?
Формального сертификата «архитектор» в линейке 1С нет. Обычно ориентируются на «1С:Эксперт по технологическим вопросам» (производительность и масштабируемость), «1С:Профессионал» и «1С:Специалист» по платформе и прикладным решениям, а также опыт завершённых проектов сопоставимого масштаба.
Сколько времени занимает архитектурный аудит действующей системы?
Зависит от масштаба: для одной-двух баз с несколькими интеграциями обычно достаточно нескольких недель — анализ метаданных, технологического журнала, схем обменов и интервью с командой. Результат — карта проблем с оценкой рисков и план устранения по приоритетам.
Может ли архитектор быть внешним консультантом, а не сотрудником?
Да, это распространённая практика: внешний архитектор проектирует решение и проводит ключевые ревью, а сопровождением занимается внутренняя команда. Важно, чтобы проектные решения были задокументированы и переданы команде — иначе после ухода консультанта система снова начнёт развиваться стихийно.
Что должно входить в документацию архитектуры 1С?
Минимальный набор: схема систем и потоков данных, перечень мастер-данных с системами-источниками, описание интеграций (транспорт, формат, поведение при ошибках), реестр доработок типового кода с обоснованиями и журнал архитектурных решений. Документация должна обновляться при каждом значимом изменении, иначе она быстро теряет ценность.