Разработка и Конфигурация · 9 мин
Что должен знать архитектор 1С
Какие знания и навыки нужны архитектору 1С: платформа, СУБД, интеграции, производительность, типовые решения и проектирование подсистем.
Архитектор 1С — это специалист, который проектирует структуру информационной системы на платформе «1С:Предприятие» до того, как разработчики начнут писать код. Он отвечает за выбор конфигурации, состав подсистем, схемы обмена данными, требования к производительности и границы доработок. Ошибка на уровне архитектуры обходится дороже всего: переделывать заложенные в основу решения приходится вместе с данными, интеграциями и обученными пользователями.
Роль архитектора отличается от роли ведущего разработчика. Разработчик решает, как реализовать конкретный механизм, архитектор — какие механизмы вообще должны существовать, как они связаны и какую нагрузку выдержат. Поэтому набор компетенций здесь шире, чем «хорошо знать встроенный язык»: требуются знания платформы на глубинном уровне, СУБД, интеграционных технологий, типовых конфигураций и методологии проектирования.
Глубокое знание платформы «1С:Предприятие»
Основа компетенции — понимание объектной модели платформы: справочники, документы, регистры сведений, накопления, бухгалтерии и расчёта, планы обмена, бизнес-процессы и задачи. Архитектор должен знать не только назначение каждого типа объектов, но и то, как платформа хранит их данные, какие индексы создаются автоматически и какие операции приводят к блокировкам.
Отдельный блок — механизмы платформы, влияющие на архитектуру: управляемые блокировки, разделение данных, фоновые задания, расширения конфигурации, подсистемы и функциональные опции. Например, решение «доработать типовую конфигурацию напрямую или через расширение» — архитектурное: от него зависит стоимость будущих обновлений.
Архитектор обязан понимать различия режимов работы — файловый и клиент-серверный, тонкий и веб-клиент, — и ограничения каждого. Решение, приемлемое для файловой базы на десять пользователей, может быть недопустимым для кластера с сотнями одновременных сеансов.
Знание типовых конфигураций и стандартов разработки
Архитектор не проектирует «с нуля» то, что уже решено в типовых продуктах. Нужно знать состав и устройство основных конфигураций — ERP, УТ, БП, ЗУП, КА, — их ключевые подсистемы, типовые механизмы проведения документов, закрытия периода и расчёта себестоимости. Это позволяет принимать решение «использовать типовое / доработать / разработать своё» на основе фактов, а не предположений.
Обязательна практика работы с библиотекой стандартных подсистем (БСП): она задаёт единые механизмы хранения контактной информации, работы с файлами, рассылки отчётов, версионирования и многого другого. Проектирование собственных аналогов вместо использования БСП — типичная ошибка, увеличивающая стоимость сопровождения.
Полезно ориентироваться в системе стандартов и методик разработки фирмы «1С»: требования к коду, интерфейсам, хранению настроек и локализации. Соблюдение стандартов упрощает передачу проекта другой команде и сертификацию решения, если она планируется.
СУБД, запросы и производительность
Архитектор отвечает за то, чтобы система работала под реальной нагрузкой. Для этого нужно понимать, как запросы на встроенном языке транслируются в SQL, что такое план запроса, селективность индекса и эскалация блокировок. Требуется практическое знакомство хотя бы с одной промышленной СУБД из поддерживаемых платформой — MS SQL Server или PostgreSQL: настройка, обслуживание индексов, мониторинг.
Ключевые архитектурные решения в этой области: выбор структуры регистров (периодичность, измерения, режимы итогов), разделение оперативного и аналитического учёта, проектирование обменов так, чтобы они не блокировали работу пользователей. Ошибка в структуре регистра накопления может привести к тому, что отчёт по остаткам будет выполняться минутами вместо секунд.
Как проверить качество архитектурного решения
Проведение документов и построение основных отчётов укладывается в согласованные нормы времени под целевой нагрузкой
Время операций растёт непропорционально объёму данных
Конкурентная работа пользователей не вызывает массовых конфликтов блокировок
Регулярные ошибки «Конфликт блокировок» при параллельной работе
Типовая конфигурация обновляется штатно, доработки вынесены в расширения
Каждое обновление требует ручного сравнения с сотнями изменённых объектов
Архитектор должен уметь пользоваться инструментами диагностики: технологическим журналом, замерами производительности, средствами мониторинга СУБД. Это нужно не только для устранения проблем, но и для проверки проектных гипотез до внедрения.
Интеграции и обмен данными
Практически ни одна система на 1С не существует изолированно. Архитектор должен знать основные технологии обмена: планы обмена и универсальный формат EnterpriseData, HTTP- и SOAP-сервисы, веб-сервисы расширений, файловые обмены, очереди сообщений (RabbitMQ, Kafka) для высоконагруженных сценариев, а также механизмы взаимодействия с внешними компонентами.
Проектирование интеграции включает выбор модели: синхронный вызов или асинхронная очередь, периодический обмен или событийная выгрузка. Архитектор определяет, какая система является мастер-системой для каждого справочника, как разрешаются конфликты и как обеспечивается идемпотентность — защита от дублирования данных при повторной отправке сообщений.
Как выбрать способ интеграции
Проектирование решений и оценка трудоёмкости
Архитектор переводит бизнес-требования в техническую модель: схему объектов метаданных, потоки документов, роли и права доступа, состав подсистем. На этом этапе важно умение задавать заказчику уточняющие вопросы: какой объём данных ожидается через год, сколько пользователей работает одновременно, какие операции критичны по времени.
Оценка трудоёмкости — отдельный навык. Архитектор должен декомпозировать решение на задачи, оценить их в часах с учётом рисков и аргументировать оценку перед заказчиком. Систематическая недооценка ведёт к срыву сроков, переоценка — к потере доверия и бюджета.
Важно документировать решения: схема обменов, перечень доработок с обоснованием, ограничения и допущения. Без документации архитектура существует только в голове одного человека, что является серьёзным проектным риском.
Права доступа, надёжность и сопровождение
Проектирование ролевой модели — обязанность архитектора: состав ролей, разделение полномочий, ограничение доступа на уровне записей (RLS) там, где это действительно необходимо. Избыточное применение RLS заметно влияет на производительность запросов, поэтому решение принимается осознанно, с проверкой на реальных объёмах.
Надёжность включает стратегию резервного копирования, план восстановления, поведение системы при недоступности связанных сервисов. Архитектор определяет, что произойдёт с проведением документа, если внешний сервис не отвечает: откат транзакции, очередь повторных попыток или отложенная обработка.
Наконец, архитектор проектирует сопровождаемость: модульность, единые соглашения по именованию, минимум скрытых зависимостей между подсистемами. Система, которую невозможно безопасно изменять, считается неудачной независимо от того, насколько красиво она спроектирована.
Что важно запомнить
Архитектор 1С соединяет глубокое знание платформы, типовых конфигураций, СУБД и интеграций с умением проектировать под нагрузку, оценивать трудоёмкость и фиксировать решения в документации. Главный критерий зрелости — способность предвидеть последствия решений для производительности, обновлений и сопровождения.
Частые вопросы
Чем архитектор 1С отличается от ведущего разработчика?
Ведущий разработчик отвечает за качество кода и работу команды в рамках заданных решений. Архитектор определяет сами решения: структуру метаданных, схемы обменов, границы подсистем и компромиссы между гибкостью, скоростью и стоимостью сопровождения.
Нужно ли архитектору 1С знать языки программирования кроме встроенного?
Строго обязательным это не является, но знание SQL практически необходимо, а базовое понимание языков, на которых пишутся смежные системы (например, для чтения API и скриптов интеграции), заметно упрощает проектирование обменов.
Как проверить, что архитектурное решение выдержит нагрузку?
До внедрения выполняют нагрузочное тестирование на копии с объёмом данных, близким к целевому: замеряют время ключевых операций и поведение при параллельной работе пользователей. Решения, проверенные только на пустой базе, считаются непроверенными.
С чего начать путь к роли архитектора, если я разработчик 1С?
Начните с углубления в механизмы платформы: блокировки, регистры, планы обмена, расширения. Затем изучите устройство типовых конфигураций и БСП, освойте диагностику производительности и попробуйте самостоятельно спроектировать небольшую подсистему с документированием решений.
Когда доработку лучше делать расширением, а когда в основной конфигурации?
Расширение предпочтительно всегда, когда его механизмов достаточно: добавление объектов, обработчиков, форм. Изменение основной конфигурации оправдано только там, где расширение технически не поддерживает нужный сценарий, и такие места должны быть задокументированы.
Нужны ли архитектору сертификаты 1С?
Сертификаты «1С:Специалист» по платформе и прикладным решениям подтверждают базовый уровень и полезны при трудоустройстве, но не заменяют опыт проектирования реальных систем. Решающим остаётся портфолио принятых архитектурных решений и их последствий.