К статье
Практический материал

Разработка и Конфигурация · 11 мин

1С архитектор: кто это и чем он занимается

Кто такой 1С архитектор: роль в проекте, ключевые задачи, отличия от разработчика и консультанта, навыки, карьерный путь и типичные ошибки при выборе специалиста.

1С архитектор — это специалист, который проектирует структуру информационной системы на платформе 1С:Предприятие до того, как начнётся её разработка или доработка. Он определяет, какие подсистемы и объекты конфигурации понадобятся, как они будут связаны между собой, как обеспечить производительность и возможность дальнейшего развития решения без полной переделки.

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

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

Что входит в зону ответственности архитектора 1С

Основная работа архитектора начинается до написания кода. Он анализирует требования бизнеса, оценивает объёмы данных и нагрузку, а затем принимает проектные решения: какие объекты метаданных создать, какую типовую конфигурацию взять за основу, что доработать, а что реализовать отдельным расширением или внешним сервисом.

Ключевые задачи архитектора:

  • проектирование модели данных: справочники, документы, регистры сведений и накопления, их связи и измерения;
  • выбор архитектурного подхода: доработка типовой конфигурации, расширения, собственная разработка, комбинация нескольких баз;
  • проектирование интеграций: обмены между базами 1С, взаимодействие с сайтами, CRM, WMS, банками и сервисами;
  • оценка и обеспечение производительности: индексы, блокировки, регламентные задания, разделение нагрузки;
  • определение стандартов разработки для команды и контроль их соблюдения;
  • планирование обновлений: как сохранить возможность обновлять типовую конфигурацию при наличии доработок.

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

Чем архитектор отличается от разработчика и консультанта

Эти роли часто путают, потому что на практике один человек может их совмещать. Однако фокус у них разный. Консультант разбирается в предметной области — учёте, логистике, расчёте зарплаты — и переводит потребности бизнеса на язык требований к системе. Разработчик реализует эти требования кодом. Архитектор стоит между ними и отвечает за целостность технического решения.

РольГлавный вопросРезультат работы
КонсультантЧто должна делать система для бизнеса?Требования, постановки задач, методика учёта
АрхитекторКак это устроить, чтобы работало и развивалось?Модель данных, схема подсистем, проектные решения
РазработчикКак это реализовать в коде?Работающие механизмы, обработки, отчёты

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

Когда компании нужен архитектор, а когда достаточно разработчика

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

  • планируется внедрение с нуля или миграция с устаревшей конфигурации на новую;
  • одновременно работать будут десятки и сотни пользователей, объёмы данных велики;
  • нужны обмены с несколькими внешними системами в реальном времени или по расписанию;
  • конфигурация уже сильно доработана, обновления превратились в проблему;
  • над системой работает команда из нескольких разработчиков, и их решения конфликтуют;
  • система должна масштабироваться: новые филиалы, юрлица, направления бизнеса.

Если же задача — добавить печатную форму, поправить отчёт или настроить типовой обмен, достаточно квалифицированного разработчика. Избыточное проектирование для мелкой задачи — пустая трата времени и бюджета.

Маршрут решения

Как выбрать действие

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

Навыки и знания, необходимые архитектору 1С

Архитектор вырастает из практики, поэтому базовое требование — уверенный опыт разработки на платформе 1С:Предприятие. Поверх этого нужны компетенции, которые выходят за рамки написания кода.

Технический минимум включает: глубокое знание объектов метаданных и механизмов платформы, понимание работы СУБД (MS SQL Server, PostgreSQL), принципов индексирования и блокировок, опыт построения обменов данными, знание типовых конфигураций и их внутреннего устройства. Важно понимать, как решение поведёт себя под нагрузкой, а не только в тестовой базе с тремя документами.

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

ОпытУчастие в проектах сопоставимого масштаба

Просите описать архитектуру завершённых проектов и принятые компромиссы

МышлениеГоворит о последствиях решений, а не только о механизмах

Спросите, чем плох выбранный подход и когда он не подойдёт

ДокументацияФиксирует решения письменно

Попросите пример проектного документа или схемы подсистем

Типовые решенияЗнает устройство типовых конфигураций

Уточните опыт работы именно с вашей конфигурацией и её доработкой

Типичные архитектурные ошибки в проектах 1С

Большинство проблем в долгоживущих системах 1С — следствие решений, принятых на старте без учёта будущего. Знание типовых ошибок помогает и заказчику контролировать подрядчика, и специалисту вырасти в архитектора.

Типичные ошибки
01
Прямая доработка типовых объектов вместо расширений — каждое обновление превращается в ручное слияние кода на дни и недели
02
Проектирование регистров «на вырост» с избыточными измерениями — раздувание таблиц и деградация производительности
03
Хранение данных в неподходящих объектах, например периодических данных в реквизитах справочника, — потеря истории и невозможность корректной отчётности
04
Обмены «в лоб» без очередей и контроля ошибок — при сбое данные теряются или дублируются незаметно
05
Отсутствие документации — через год никто, включая автора, не помнит, почему решение устроено именно так

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

Как стать архитектором 1С: практический маршрут

Прямого пути «с нуля до архитектора» не существует: роль предполагает накопленный опыт ошибок и успешных решений. Реалистичный маршрут выглядит так.

Порядок действий
  1. 1
    Освойте разработку на платформе: объекты метаданных, язык запросов, СКД, расширения
  2. 2
    Поработайте 2–4 года разработчиком на реальных проектах с типовыми конфигурациями
  3. 3
    Изучите устройство СУБД и механизмы производительности: индексы, блокировки, планы запросов
  4. 4
    Возьмите на себя проектирование отдельных подсистем и обменов, защищайте решения перед командой
  5. 5
    Изучите методики ведения проектов и стандарты разработки, освойте документирование решений
  6. 6
    Проведите архитектурный аудит существующей системы — это лучшая тренировка системного взгляда

Полезно изучать чужие решения: типовые конфигурации — это готовые примеры архитектуры, выстроенной под большие нагрузки и массовое сопровождение. Разбор того, почему в типовой конфигурации механизм устроен именно так, даёт больше, чем абстрактная теория.

Подтвердить квалификацию помогают сертификаты фирмы «1С» — например, «1С:Специалист» по платформе и «1С:Эксперт по технологическим вопросам». Сам по себе сертификат не делает архитектором, но проверка знаний по технологическим вопросам близка к реальным задачам этой роли.

Хороший признак зрелого архитектора — он предлагает не самое «правильное» решение в теории, а то, которое компания способна сопровождать своими силами. Идеальная архитектура, которую некому поддерживать после ухода исполнителя, на практике хуже простой и понятной.
ПЗ
Практическое замечание

Как проверить результат работы архитектора

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

Контрольные точки

Как проверить результат

Проектная документация
Норма

Есть схема подсистем, модель данных, описание интеграций и обоснование выбора

Тревожный признак

Решения существуют только устно или в переписке

Обновляемость
Норма

Доработки вынесены в расширения, типовые объекты изменены минимально и это зафиксировано

Тревожный признак

Массовые правки типового кода без реестра изменений

Производительность
Норма

Решения проверены на объёмах, близких к боевым; есть оценка роста данных

Тревожный признак

Всё тестировалось только на пустой или демонстрационной базе

Передаваемость
Норма

Другой разработчик может разобраться в системе по документации

Тревожный признак

Систему понимает только её автор

Итог

Что важно запомнить

1С архитектор проектирует систему до её реализации и отвечает за её целостность, производительность и развитие. Он нужен на крупных внедрениях, миграциях и при накопленном техническом долге; для мелких доработок достаточно разработчика. Качество его работы проверяется документацией, обновляемостью конфигурации и поведением системы под реальной нагрузкой.

Частые вопросы

Чем архитектор 1С отличается от ведущего разработчика?

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

Нужен ли архитектор для внедрения типовой конфигурации без доработок?

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

Сколько времени занимает путь от разработчика до архитектора?

Обычно требуется несколько лет практики: сначала уверенная разработка, затем опыт самостоятельного проектирования подсистем и участия в крупных внедрениях. Формального срока нет — решающее значение имеет разнообразие проектов и опыт разбора последствий собственных решений.

Что такое архитектурный аудит и когда его заказывать?

Это независимый разбор существующей системы: структуры данных, доработок, обменов, производительности. Его заказывают, когда обновления стали мучительными, система тормозит, уходит ключевой разработчик или планируется масштабное развитие. Результат — перечень проблем и план их устранения с приоритетами.

Может ли архитектор работать удалённо и на этапе только проектирования?

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