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

Мы задумались – можно ли сохранить проверенную бизнес-логику, не переписывая накопленный за десятилетия код, и одновременно сделать платформу открытой для современных технологий?

Эту задачу мы и хотели решить при разработке «Галактика Сверхновая». Заглядывайте под кат и узнаете, как устроено это разделение: почему ядро осталось консервативным, а расширения можно писать на Python, Java и C#, и как метаданные стали основой для интеграций и ИИ.

Почти за четыре десятилетия в кодовой базе «Галактики» накопилось больше 50 млн строк. За этими цифрами – не просто объём, а проверенные расчёты, отраслевые правила, особенности российского учёта и тысячи сценариев, отработанных на реальных предприятиях. Переписывать всё с нуля мы не стали: слишком много ценной логики пришлось бы выбросить.

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

• монолитность – любое изменение в одной части системы рискует задеть другие;

• vendor lock-in – заказчик попадает в зависимость от вендора;

• внутренний язык разработки – редкие специалисты, сложный поиск кадров;

• долгие внедрения – путь от бизнес-требования до работающей функции занимает месяцы.

Впрочем, для тяжёлой ERP транзакционная целостность и предсказуемость важнее погони за архитектурными трендами. Поэтому мы не стали переписывать монолит на микросервисы только потому, что «так сейчас модно», а выбрали эволюционный подход. Сохранили критическое ядро: модель данных, транзакции, бизнес-операции и контракты, на которых держатся действующие внедрения. А новые возможности, прежде всего, средства расширения, API-шлюзы, инструменты работы с метаданными, свежие пользовательские интерфейсы и ИИ-конвейер – вынесли в управляемые слои.

Так появилась «Галактика Сверхновая» – не новая «коробка» вместо старой ERP, а слой развития, который должен связать зрелое ядро с современными интерфейсами, открытыми API, распространёнными языками программирования и ИИ-инструментами.

За всеми этими архитектурными проблемами стоят простые и понятные бизнесу вещи: долгие внедрения, дорогое переобучение сотрудников, новые серверы и базы данных, постоянный поиск редких разработчиков и бесконечная поддержка того, что уже есть. Всё это – деньги, поэтому мы проектировали «Галактика Сверхновая» так, чтобы свести эти затраты к минимуму.

Как выглядит разделение UI, бизнес-логики и ядра

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

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

Часть компонентов может работать в одном процессе с ядром, часть – как отдельные сервисы. Граница проводится не по принципу «монолит или микросервис», а по ответственности и риску.

Вот как это выглядит:

Разделение слоёв не означает автоматического обновления «без единой секунды простоя». Оно решает более практичную задачу: уменьшает площадь конфликта между вендорским кодом и доработками заказчика.

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

Почему C#, Java и Python – и как они исполняются

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

А вот метрика Pass@1 для разных языков – чем выше значение, тем лучше модель понимает язык.

Еще одна из причин, почему мы открыли точки расширения для C#, Java и Python, – вопрос кадров. Логично, что молодые разработчики не идут в проекты с проприетарными языками, потому что это сильно сужает их карьерные возможности.

Мы как разработчики прекрасно их понимаем, но заказчики вряд ли скажут нам спасибо, если после внедрения им придется годами собирать и/или обучать команду со знанием VIP. Поэтому мы оставили его языком ядра, а расширения разрешили писать на том, что предлагает рынок.

Как разные языки уживаются в одной ERP

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

• C# работает через встраивание CLR в процесс платформы;

• Java – через управляемый вызов JVM;

• Python – через встроенный интерпретатор или изолированный runtime, в зависимости от сценария.

Ключевое здесь – не конкретное API загрузки среды, а одинаковая модель доступа. Расширение работает от имени текущего пользователя, в рамках его сессии и транзакции, через контролируемый слой SN Data, а не через прямой SQL.

Сама точка расширения регистрируется в репозитории платформы. У неё есть версия, зависимости, набор разрешений, описание входных и выходных данных, события активации и правила развертывания. Метаданные и декларативные изменения интерфейса можно включать без пересборки всей ERP. Исполняемый модуль тоже не требует сборки ядра, но его активация проходит управляемо: проверка пакета, публикация, при необходимости – перезапуск конкретного процесса или сервиса. Мы сознательно не обещаем «горячее подключение» для любого кода: безопасность и предсказуемость важнее эффектной демонстрации.

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

API First, метаданные и целостность данных

Многие слышали про API First, а начнем с того, что это значит в контексте ERP. По сути, мы сначала проектируем контракт бизнес-операции: что на входе, что на выходе, какие ошибки, права, идемпотентность и транзакционные границы, и только потом пишем код.

Базовым интерфейсом для новых интеграций стал REST со спецификацией OpenAPI. SOAP мы оставили там, где у заказчика уже есть промышленный контур и переписывать его бессмысленно, а GraphQL используем для сложных чтений и цифровых рабочих мест, но не как замену транзакционным API.

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

• схему хранения;

• API-спецификацию;

• элементы интерфейса;

• проверки;

• часть документации.

Именно поэтому генерация на естественном языке становится воспроизводимой: ИИ-агент работает не с абстрактным текстом, а с формальным словарём платформы.

Как обеспечивается целостность данных

Целостность данных обеспечивается простым правилом: мы запретили обход ядра. Любая доработка работает через слой SN Data и сервисные контракты, наследуя проверку прав, блокировки, аудит и транзакционную модель.

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

Чтобы было понятнее, как мы разграничиваем действия, вот матрица безопасности для основных сценариев:

Эти правила действуют для всех – от разработчика до ИИ-агента. Именно поэтому мы можем позволить генерацию кода и работу с данными без постоянной ручной проверки: даже если агент сделает странный шаг, система его не пропустит. Это и есть та основа, которая позволяет нам доверять искусственному интеллекту в «Галактика Сверхновая». Кстати, самое время о нем поговорить.

ИИ: участник инженерного конвейера, а не отдельный чат

Мы не привязываем ИИ к одной конкретной модели – заказчик сам выбирает LLM, которую разрешает его служба безопасности, и это важнее любых рейтингов. Для промышленной ERP гораздо критичнее возможность заменить поставщика, определить класс данных, вести журнал вызовов и ограничить инструменты, доступные агенту.

Основной стек генерации строится вокруг RAG и управляемого agentic workflow. RAG даёт модели актуальный контекст: документацию, метаданные ERP, API-контракты, правила кодирования, примеры расширений и ограничения проекта. Агентный процесс мы сделали не для того, чтобы просить одну модель «сразу написать всё», а чтобы разложить работу на проверяемые этапы.

Пайплайн генерации: от постановки до поставки

Процесс генерации кода идёт по этапам, каждый из которых контролируется:

1. Постановка. Аналитик описывает сущность, операцию или отчёт на русском языке. Система проверяет термины по словарю и уточняет неоднозначности.

2. Проектирование. ИИ-агент использует метаданные, модель прав, события и API-контракт. Проводится валидация схемы, зависимостей и совместимости версий.

3. Генерация. Создаются код расширения, экран, спецификация API и тестовые заготовки. Проходят компиляция, статический анализ и проверка запрещённых вызовов.

4. Испытания. Пакет разворачивается на стенде и проходит unit-, integration- и regression-тесты. Проверяются транзакции, роли, миграции и производительность.

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

6. Поставка. Одобренное расширение публикуется в целевой среде через стандартный CI/CD с возможностью отката и мониторингом после выпуска.

Как это работает на практике? Представьте, что вы аналитик и вам нужно описать новую бизнес-операцию. Вы пишете на русском языке: «добавить заявку на превышение бюджетного лимита, обязательное согласование финансовым контролёром и уведомление руководителя». Система связывает эту формулировку со справочниками и ролями, создаёт сущность, экран, API и обработчик маршрута, но результат не попадает в production по нажатию Enter – он идёт через обычный процесс разработки с веткой, сборкой, тестами, ревью и выпуском.

Чем ИИ помогает в работе

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

Метрики ИИ должны измерять не количество сгенерированных строк. Для разработки полезны lead time от постановки до стенда, доля принятых без существенной переработки изменений, дефекты после выпуска и объём ручного возврата. Для эксплуатации – время обработки документа, доля автоматического распознавания, число ложных срабатываний, объём операций, оставшихся человеку, и экономия рабочего времени. Без таких метрик ИИ быстро превращается в дорогую демонстрацию.

Модель предлагает, человек решает

Безопасность строится вокруг принципа «модель предлагает – система проверяет – человек утверждает». Генерируемый код проходит те же проверки, что и код разработчика: компиляцию, SAST, анализ зависимостей, unit- и интеграционные тесты, проверку прав, миграций и производительности. Дополнительно фиксируются модель, версия контекста и действия ИИ-агента.

LLM сама по себе не понимает предприятие. Она не знает, что такое конкретный вид накладной, где проходит граница полномочий или почему операция должна быть атомарной. ИИ становится полезным только тогда, когда у него есть структурированный контекст и безопасные инструменты. В «Галактика Сверхновая» эту основу дают метаданные, API First, ролевая модель, транзакционные операции и журнал событий.

Поэтому ИИ-агент не должен «ходить в базу» и придумывать SQL. Он получает каталог разрешённых действий: прочитать документ, проверить лимит, сформировать проект операции, запросить согласование. Каждый инструмент имеет контракт, ограничения и ожидаемый результат.

Из чего складывается готовность системы к ИИ (AI Ready):

• Структурированные данные и метаданные. Модель должна понимать, что она видит: не просто набор таблиц и полей, а заказы, контрагентов, производственные операции, показатели и правила.

• Доступные API и актуальная документация. Функционал, который существует только внутри пользовательского интерфейса и не имеет стабильного программного вызова, недоступен для ИИ-агента.

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

• Метрики эффекта. Нужно понимать, сколько времени занимала задача раньше, сколько занимает сейчас, какая часть результата используется без доработки.

• Готовность команды. Инструмент не даст результата, если сотрудники не понимают, как его использовать.

Инфраструктура: PostgreSQL, отечественные ОС и облака

Итак, остался один немаловажный вопрос: на чем это все будет работать? Мы не стали закладываться на одну конкретную СУБД или операционную систему – и вот почему.

Основной промышленный контур «Галактика Сверхновая» оптимизируется под PostgreSQL и Postgres Pro, но между бизнес-логикой и СУБД существует драйверный слой. Это не значит, что мы абстрагировались от любой базы: перенос на другой продукт всё равно требует проверки типов, блокировок, планов запросов и процедур. Общий слой доступа снижает объём адаптации, но не отменяет особенностей конкретной СУБД.

Совместимость с отечественными ОС и СУБД мы проверяем не ручным запуском на случайной виртуалке. Для каждой поддерживаемой комбинации формируются базовые образы, выполняются установка и обновление, smoke- и регрессионные тесты, проверка криптографии, печати, интеграций, резервного копирования и восстановления. Для ключевых конфигураций добавляются нагрузочные испытания, переключение узлов и проверка деградации. Матрица строится по реальному спросу и критичности заказчиков – мы не тестируем всё подряд, а фокусируемся на том, что действительно нужно рынку.

Облачная архитектура – контейнеры, VM и облака

Мы строим гибридную облачную архитектуру: тяжёлое ядро и серверы приложений оставляем на физических или виртуальных машинах, а stateless-компоненты, API-шлюзы, интеграционные сервисы и ИИ-контур выносим в контейнеры и Kubernetes.

В целевой схеме мы предусмотрели частные облака и российских провайдеров, включая VK Cloud. Но это не значит, что данные обязательно уезжают во внешнее облако – тот же набор компонентов может работать в закрытом контуре заказчика.

Миграция без боли – как переносить существующую бизнес-логику

Самая опасная стратегия миграции – попытаться повторить старую ERP экран в экран и строка в строку. Так вы переносите в новую систему все исторические ограничения и одновременно создаёте риск большого взрыва при запуске.

Мы используем поэтапную схему:

1. Фиксируем процессы и данные, которые нельзя останавливать.

2. Вокруг legacy появляются API и события.

3. Отдельные домены выносятся в новые расширения и интерфейсы.

Код переносится несколькими способами:

• часть логики остаётся в ядре и вызывается через контракт;

• часть адаптируется в C#, Java или Python;

• повторяемые правила переводятся в метаданные и low-code;

• интеграции заменяются стандартными API.

Для миграции данных нужны профилирование, таблицы соответствий, пробные загрузки, сверка итогов и возможность повторного прогона. Публичная дорожная карта «Галактики» отдельно упоминала пакет миграции с SAP на «Галактику», но главный инструмент здесь не конвертер, а дисциплина повторяемой миграции.

Что дальше

Мы не собираемся останавливаться на том, что уже сделали. В планах – развивать все пять продуктовых направлений: технологическую платформу, ERP, ERP HR, EAM и MES. Сейчас мы сосредоточены на том, чтобы миграция с SAP занимала не годы, а месяцы, а заказчик мог дополнять интерфейсы и бизнес-логику без нас. И, конечно, продолжаем совершенствовать ИИ-инструменты – дальше будет больше.

Мы делаем платформу открытой, чтобы быстрее развиваться и лучше слышать, что нужно рынку: API, SDK, документация и учебные стенды доступны каждому. Если вам не хватает каких-то сценариев или есть идеи, как улучшить инструменты, – пишите в комментариях, мы всегда открыты к диалогу.

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