Разработка и Конфигурация · 13 мин
Архитектор 1С: кто это и чем он занимается
Кто такой архитектор 1С, чем он отличается от разработчика, какие задачи решает и когда компании действительно нужен архитектор на проекте внедрения.
Архитектор 1С — это специалист, который проектирует структуру информационной системы на платформе «1С:Предприятие» до того, как разработчики начнут писать код. Он определяет, какие подсистемы и объекты конфигурации понадобятся, как они будут связаны между собой, как данные будут храниться и обмениваться с другими системами, и как решение будет масштабироваться по мере роста бизнеса.
Если проводить аналогию со строительством, то разработчик 1С — это бригада, которая возводит стены и прокладывает коммуникации, а архитектор — тот, кто чертит проект здания. Без проекта построить сарай ещё можно, но многоэтажное здание с сотнями пользователей и десятками интеграций без архитектурного проектирования почти гарантированно начнёт «трещать»: появятся дубли данных, медленные отчёты, конфликты при обменах и дорогие доработки.
Роль архитектора особенно востребована на крупных внедрениях — при переходе с устаревших конфигураций, консолидации нескольких баз в одну, построении распределённых систем для холдингов. В небольших проектах функции архитектора часто совмещает ведущий разработчик или руководитель проекта, но с ростом сложности системы выделенный архитектор становится необходимостью.
Чем архитектор 1С отличается от разработчика и консультанта
Разработчик 1С решает локальные задачи: создаёт документы, отчёты, обработки, дорабатывает типовые механизмы по конкретному техническому заданию. Консультант анализирует бизнес-процессы и помогает подобрать методологию учёта. Архитектор работает на уровень выше: он определяет, из каких блоков будет состоять система в целом, и отвечает за то, чтобы эти блоки не конфликтовали между собой.
Простой пример различия подходов. Задача — учитывать серии номенклатуры на складе. Разработчик добавит реквизиты и напишет проведение документа. Архитектор сначала решит: где хранить серии (в регистре сведений или в табличной части), как это повлияет на отчёты по остаткам, не сломает ли это обмен с WMS и как изменится объём базы через год работы. То есть он оценивает не только решение, но и его последствия для всей системы.
Основные задачи архитектора 1С
Круг обязанностей зависит от проекта, но типовой набор задач выглядит примерно одинаково. Архитектор проектирует модель данных: какие справочники, документы, регистры накопления и сведений понадобятся, какие измерения и ресурсы будут у регистров, как обеспечить целостность данных. От правильности этих решений напрямую зависит скорость проведения документов и построения отчётов.
Вторая большая область — интеграции. Архитектор выбирает способы обмена с внешними системами: через веб-сервисы, HTTP-запросы, файловые обмены, планы обмена, шину данных или брокеры сообщений. Для каждого обмена он определяет формат, частоту, обработку ошибок и поведение при недоступности одной из сторон.
Третья область — производительность и масштабируемость. Архитектор закладывает механизмы, которые позволят системе работать при росте числа пользователей и объёма данных: партионирование, разделение итогов, фоновые задания, вынос тяжёлых операций из транзакций. Также он определяет требования к серверной инфраструктуре и СУБД.
- Проектирование структуры конфигурации и модели данных.
- Выбор между типовым решением, доработкой и собственной разработкой.
- Проектирование интеграционных обменов и распределённых баз.
- Определение модели прав доступа и разграничения данных.
- Планирование производительности и требований к инфраструктуре.
- Контроль технического долга и ревизия решений разработчиков.
Какие решения принимает архитектор на практике
Типовая конфигурация или собственная разработка
Одно из первых решений на проекте — взять типовую конфигурацию (например, «1С:ERP» или «1С:Комплексная автоматизация») и доработать её, либо строить собственное решение. Архитектор оценивает покрытие бизнес-процессов типовым функционалом, стоимость доработок и, что критично, стоимость будущих обновлений. Сильно переписанная типовая конфигурация может сделать каждое обновление отдельным проектом.
Одна база или несколько
Для группы компаний архитектор решает, работать ли всем юрлицам в одной базе или развернуть отдельные базы с обменами. Одна база упрощает консолидированную отчётность, но усложняет разграничение доступа и требования к производительности. Несколько баз снижают риски, но требуют надёжных механизмов синхронизации нормативно-справочной информации.
Куда поместить нестандартный учёт
Когда часть процессов не укладывается в платформу, архитектор выбирает: доработать конфигурацию, вынести функционал во внешний сервис с обменом по API или использовать отраслевое решение. Ошибочное решение «впихнуть всё в 1С» часто приводит к тому, что система становится неподдерживаемой.
Как выбрать действие
Какие навыки и знания нужны архитектору 1С
Архитектор вырастает, как правило, из опытного разработчика, поэтому глубокое знание платформы «1С:Предприятие» обязательно: встроенный язык, механизмы СКД, запросы и их оптимизация, транзакции и блокировки, расширения конфигурации. Без этого невозможно оценить реализуемость и стоимость проектных решений.
Кроме платформы, требуется понимание смежных технологий: работа СУБД (MS SQL Server, PostgreSQL), основы нагрузочного тестирования, протоколы и форматы интеграций (REST, SOAP, JSON, XML), очереди сообщений. Архитектору нужно уметь читать планы запросов и находить узкие места производительности, иначе проектирование будет оторвано от реальности.
Не менее важны «мягкие» навыки. Архитектор защищает свои решения перед заказчиком и командой, пишет архитектурную документацию, проводит ревью. Ему приходится объяснять, почему дешёвое сейчас решение обернётся проблемой через год, и уметь находить компромисс между идеальной архитектурой и бюджетом проекта.
Просите рассказать о принятых архитектурных решениях и их последствиях, а не только о стеке
Хороший архитектор называет минусы своего же решения; плохой — обещает идеальный вариант
Попросите пример архитектурного документа или схемы обменов из прошлых проектов
Когда компании нужен архитектор 1С, а когда можно обойтись
Выделенный архитектор оправдан, когда проект включает несколько интеграций, миграцию данных из старых систем, десятки и сотни одновременно работающих пользователей, распределённую структуру предприятия или нестандартный учёт, не покрываемый типовыми решениями. В этих условиях цена архитектурной ошибки — переделка системы и остановка процессов — многократно превышает стоимость работы архитектора.
Обойтись без отдельного архитектора реально, если внедряется типовая конфигурация с минимальными доработками для небольшой компании, а интеграции ограничиваются стандартными обменами (например, с банком или сайтом по готовым механизмам). Здесь достаточно грамотного ведущего разработчика и методической поддержки.
Промежуточный вариант — привлечь архитектора не на весь проект, а на ключевые точки: проектирование на старте, ревизия решений перед запуском и аудит при появлении проблем с производительностью. Это дешевле полного сопровождения и при этом страхует от самых дорогих ошибок.
Типичные ошибки при работе с архитектурой 1С
Самая распространённая ошибка — начинать разработку без зафиксированной архитектуры. Решения принимаются в переписке и устно, через полгода никто не помнит, почему обмен устроен именно так, и любое изменение становится рискованным. Архитектурные решения должны быть документированы: схема подсистем, модель данных, регламент обменов.
Вторая ошибка — игнорировать нефункциональные требования. Система проектируется под «сейчас работает», без учёта роста данных. Через год документы проводятся по минуте, отчёты строятся часами, а переделка регистров на живой базе становится отдельным болезненным проектом.
Третья ошибка — избыточная архитектура. Не каждому проекту нужны микросервисы, шина данных и три контура резервирования. Усложнение «на вырост» без реальных предпосылок увеличивает бюджет и делает систему трудной в поддержке. Хороший архитектор отличается умением проектировать ровно под потребности с разумным запасом.
- 1Соберите требования: бизнес-процессы, число пользователей, объёмы данных, список внешних систем для интеграции
- 2Выберите базовое решение: типовая конфигурация, отраслевое решение или собственная разработка
- 3Спроектируйте модель данных: основные объекты метаданных, регистры, связи между ними
- 4Определите схему интеграций: форматы, частоту обменов, обработку ошибок и мониторинг
- 5Зафиксируйте нефункциональные требования: производительность, резервирование, разграничение прав
- 6Оформите архитектурный документ и согласуйте его с заказчиком и командой разработки
- 7Планируйте контрольные ревизии архитектуры на ключевых этапах проекта
Как проверить, что архитектура получилась рабочей
Качество архитектуры проверяется не красотой схем, а поведением системы под нагрузкой и при изменениях. Практические признаки удачной архитектуры: документы проводятся за приемлемое время на реальных объёмах, добавление нового обмена не требует переработки существующих, обновление типовой конфигурации занимает предсказуемое время, а новый разработчик может разобраться в структуре системы по документации.
Полезный приём — нагрузочное тестирование на объёмах, превышающих текущие в несколько раз, до запуска в эксплуатацию. Если система «проседает» уже на тестовых данных, архитектуру нужно пересматривать до ввода в промышленную эксплуатацию, а не после жалоб пользователей.
Как проверить результат
Проведение документов и построение основных отчётов укладывается в согласованные нормы
Время операций растёт непропорционально объёму данных
Новый обмен добавляется по существующему регламенту без изменения других обменов
Каждая новая интеграция требует переделки существующих
Обновление занимает предсказуемое время, доработки вынесены в расширения
Обновление требует ручного сравнения тысяч изменённых объектов
По документам можно восстановить схему системы без участия автора
Знания о структуре системы существуют только у одного специалиста
Частые вопросы об архитекторе 1С
Может ли ведущий разработчик совмещать роль архитектора?
Да, на небольших и средних проектах это обычная практика. Проблема возникает, когда проект крупный и разработчик физически не успевает и проектировать, и писать код — тогда страдает либо архитектура, либо сроки. Ориентир: если в команде больше трёх-четырёх разработчиков и есть несколько интеграций, роль архитектора лучше выделить.
Нужны ли архитектору сертификаты 1С?
Сертификаты «1С:Профессионал» и «1С:Специалист» подтверждают знание платформы и полезны как базовый фильтр, но не гарантируют архитектурного мышления. Важнее опыт завершённых внедрений и умение обосновать проектные решения с точки зрения рисков и стоимости владения.
На каком этапе проекта подключать архитектора?
Оптимально — на этапе обследования и до начала разработки. Подключение архитектора в середине проекта тоже возможно, но тогда часть решений придётся пересматривать, а это почти всегда дороже, чем заложить правильную структуру сразу.
Чем архитектор 1С отличается от системного аналитика?
Системный аналитик описывает, что система должна делать: требования, сценарии, макеты. Архитектор решает, как она будет это делать: структуру данных, механизмы, интеграции и ограничения платформы. На практике роли часто пересекаются, но зоны ответственности разные.
Сколько времени занимает архитектурное проектирование?
Зависит от масштаба: для небольшого проекта это может быть несколько дней работы, для крупного внедрения с миграциями и множеством интеграций — недели. Пытаться сократить этот этап до минимума не стоит: ошибки проектирования всплывают в эксплуатации, где их исправление обходится в разы дороже.
Что делать, если система уже работает, а архитектуры как таковой нет?
Проведите архитектурный аудит: зафиксируйте реальную структуру базы, обменов и доработок, найдите узкие места и технический долг. Затем составьте план постепенного приведения системы к управляемому виду — резкая переделка работающей системы рискованнее, чем поэтапная.
Что важно запомнить
Архитектор 1С проектирует систему до начала разработки: модель данных, интеграции, права и требования к производительности. Он нужен там, где цена ошибки высока — на проектах с интеграциями, миграциями и большими объёмами. Ключевые признаки хорошей архитектуры: предсказуемые обновления, расширяемые обмены и документация, по которой систему понимает не только её автор.