Enterprise-разработка ПО: сроки, бюджет, интеграция с legacy и требования регуляторов

Enterprise-разработка — это создание корпоративных систем с тысячами пользователей и глубокой интеграцией в существующую IT-инфраструктуру. Типичный проект с нуля идёт 9–18 месяцев. Автоматизация одного бизнес-процесса обходится в 2,5–8 миллионов, полноценная платформа под ключ — в 15–60. Поддержка добавляет 15–25% от сметы ежегодно.

Главное отличие от обычной разработки не в бюджете. Здесь половина архитектурных решений продиктована ограничениями: нагрузкой, требованиями ФСТЭК и 152-ФЗ и необходимостью жить рядом со старой системой, которую нельзя выключить.

Чем enterprise отличается от обычной разработки

Распространённое заблуждение: enterprise — это то же самое, но дороже и солиднее. Типа для больших компаний.

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

Что обычно заказывают:

• ERP — планирование ресурсов, ключевые процессы в одном пакете;
• CRM — взаимоотношения с клиентами, стандартизация продаж;
• HRM — найм, отпуска, обучение, расчёт зарплаты;
• BI — сбор и визуализация данных из ERP и CRM;
• SCM — цепочки поставок от закупки сырья до доставки;
• корпоративные порталы и системы документооборота.

Чаще всего это нефтегаз, ритейл, здравоохранение, телеком, производство, банки и страхование — то есть отрасли, где много данных, много филиалов и много регуляторики.

Сроки и бюджет enterprise-проекта

Порядок цифр, от которого можно отталкиваться.

Это порядок цифр. Точную оценку делаем после разбора задачи и перечня систем: Получить расчёт

Куда уходят эти 9–18 месяцев:

• сбор требований и аналитика — 1–2 месяца;
• проектирование архитектуры — 1 месяц;
• разработка по спринтам — 6–12 месяцев;
• нагрузочное тестирование и опытная эксплуатация — 1–3 месяца.

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

Теперь про то, что двигает цену. Три вещи:

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

Ни стека, ни города в этом списке нет. Enterprise дорожает от связей с внешним миром, а не от технологий внутри.

Как мы работаем на проектах такого масштаба. Анализ и проектирование идут с фиксированной сметой на этап, дальше разработка — по Time & Materials со сметой перед каждым спринтом.

На многолетнем проекте требования меняются гарантированно. Фикс на весь объём превращается либо в бесконечный спор об изменениях, либо в систему под требования двухлетней давности. T&M позволяет менять приоритеты без пересмотра контракта, а контроль бюджета остаётся у заказчика: оценка делается до начала каждой задачи.

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

Почему enterprise-проекты тормозят не на коде

Самое неприятное. Enterprise-проекты почти никогда не умирают от технической сложности. Их убивают две вещи, и обе нетехнические.

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

Обходится это так:

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

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

Вторая — интерфейс. И тут распространённая ошибка, которую совершают из лучших побуждений.

У корпоративной системы нет задачи вовлекать пользователя. Это не соцсеть, где надо удержать внимание. Сотрудник открывает систему, чтобы сделать работу и закрыть. Каждый лишний элемент, яркая типографика, модный эффект — это замедление.

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

Хороший enterprise-интерфейс скучный. Визуально простой, предсказуемый, без трендов. Особенно если человек сидит в нём по восемь часов.

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

Прототип делаем за три дня. Спор «что именно мы согласуем» переходит в разговор по конкретным экранам, и цикл принятия решения заметно короче.

Интеграция с унаследованными системами

Технически самая сложная часть enterprise-проекта. И самая недооценённая на этапе сметы.

Почему legacy-систему нельзя просто переписать с нуля: она в этот момент продолжает обслуживать бизнес. Её нельзя выключить на полгода, пока пишется новая. Значит, какое-то время они обязаны работать одновременно и обмениваться данными.

Типовой подход — middleware-слой. Между старым и новым ставится прослойка на базе брокера сообщений (Kafka, RabbitMQ) или ESB, которая переводит данные из одних форматов в другие. Старая система продолжает жить в своей парадигме, новая — в своей, а слой берёт на себя перевод.

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

Дальше — модульный переход. Не разом, а по частям: перевели один процесс, убедились, что работает, взяли следующий. При нормально спроектированной архитектуре такой переход занимает 3–6 месяцев.

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

ФСТЭК, 152-ФЗ и что это значит для архитектуры

Для российского enterprise это не приложение к проекту, а входное условие.

Основные документы:

• приказы ФСТЭК России № 17, 21, 239 — требования к защите информации в государственных и корпоративных информационных системах;
• 152-ФЗ «О персональных данных» — в том числе хранение персданных на серверах в РФ;
• ГОСТ Р 34.12-2015 — блочные шифры для защиты данных.

Что это означает практически:

Вот два последних пункта и есть причина, по которой безопасность нельзя прикрутить в конце.

Ролевая модель — это не таблица с галочками. Это ответ на вопрос «кто какую запись видит» в каждом запросе к базе. Журналирование — это не лог-файл, а требование восстановить, кто что сделал и когда, за весь период хранения.

Добавить это в готовую систему — значит переписать значительную часть логики работы с данными. Заложить с первого дня — значит просто спроектировать иначе.

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

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

Развёртывание без облачных зависимостей: Docker Swarm и Ansible. Разграничение доступа и журналирование закладываем в архитектуру с первого дня, а не добавляем перед сдачей.

Архитектура и стек

Микросервисная архитектура стала стандартом для enterprise не из моды.

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

Выигрыш проще всего показать на примере. В распродажу растёт нагрузка на платежи — вы добавляете ресурсы только платёжному сервису, не трогая остальную систему. Упал один сервис — остальное продолжает работать. Обновить нужно один модуль — обновляете один модуль.

Оркестрация обычно через Kubernetes.

Честная оговорка: микросервисы дороже в эксплуатации. Нужны DevOps-компетенции, мониторинг, распределённая трассировка. Для системы на пятьдесят пользователей это оверинжиниринг, и в таком случае монолит — нормальное решение.

Типовой стек по слоям:

• бэкенд — Go, Rust, Python: зрелая экосистема и производительность под нагрузкой;
• фронтенд — Svelte 5 / SvelteKit, HTMX;
• транзакционные данные — PostgreSQL, MySQL, Oracle;
• аналитика и большие объёмы — ClickHouse, MongoDB, векторные базы данных.

Стек в enterprise выбирается по доступности специалистов на горизонте пяти лет, а не по элегантности. Систему, которую делали полтора года, кто-то будет поддерживать ещё лет семь.

Почему Go. Это прямой ответ на вопрос «а найдём ли мы потом людей».

• Производительность под нагрузкой. На Go работает платформа с базой в 50 млн анкет: отклик страницы меньше 40 мс, 10 000+ запросов в секунду.
• Простая эксплуатация. Сервис собирается в один исполняемый файл, без тяжёлого окружения.
• Низкий порог входа. Язык небольшой, новый разработчик включается в поддержку быстро, и найти людей на горизонте пяти лет можно.

Аутсорс, аутстафф или своя команда

Три модели, и у каждой своя зона.

Аутсорс. Подрядчик берёт проект целиком: аналитику, разработку, QA, поддержку. Сам управляет командой и отвечает за сроки.

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

Аутстафф. Вы арендуете специалистов под управление своего CTO. Подходит сформированным командам, где не хватает узкой компетенции — DevSecOps, интеграция с SAP, конкретный стек.

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

Своя команда. Дешевле в долгосроке. Но тяжело и дорого собрать на старте: пара месяцев на поиск, зарплаты, бонусы, риск нанять не того.

Про выбор подрядчика — один нетривиальный критерий. Смотрите не свежие релизы в портфолио, а проекты годичной давности. Если они до сих пор работают и развиваются, значит архитектуру заложили нормально. Свежий красивый кейс не говорит ни о чём: проблемы enterprise-систем проявляются на втором году.

И ищите кейсы из своей отрасли. Команда, которая уже делала систему для вашей вертикали, знает регуляторику и типовые грабли — это экономит месяцы на входе.

Начните с аудита того, что у вас уже работает, и с честного ответа на вопрос, какой процесс болит сильнее всего. Enterprise-проект, который начинается с «нам нужна цифровизация», заканчивается предсказуемо.

Если масштаб меньше — смотрите заказную разработку ПО. Если задача во внутреннем контуре — корпоративный портал. Если речь о продажах контрагентам — B2B-платформа.