Как мигрировать с зарубежной интеграционной шины и не положить бизнес: опыт ЕМДЕВ и Энтакси
После 2022 года многие российские компании внезапно обнаружили, что их «центральная нервная система» — интеграционная шина — живёт на чужой, больше не поддерживаемой платформе. Западные решения официально ушли с рынка, а бизнес по‑прежнему крутится вокруг интеграций 24/7. Вопрос быстро перестал быть теоретическим: продолжать работать на неподдерживаемом ПО опасно, а резкая замена грозит остановкой ключевых процессов. Ниже — как ЕМДЕВ выстраивает миграцию на российскую платформу так, чтобы бизнес этого почти не заметил.
Почему интеграционная шина — это «боль», а не просто middleware
В типичной крупной компании шина данных связывает десятки и сотни систем: ERP, CRM, WMS, платёжные сервисы, банковские приложения, порталы партнёров. Через неё проходит всё: от заказов и платежей до обмена с регуляторами.
Когда основой этой архитектуры становится продукт, который перестал обновляться и поддерживаться в России, компания попадает в ситуацию «заложника». Возникают четыре ключевые проблемы:
- безопасность: нет обновлений, уязвимости копятся;
- регуляторика: риски несоответствия российским требованиям;
- развитие: сложно или невозможно строить новые интеграции;
- зависимость: рынок экспертизы по старым продуктам сужается, стоимость поддержки растёт.
С каждым годом «жить как есть» становится всё дороже. Точка отказа предсказуема: в какой‑то момент обновить один из критичных контуров или внедрить новый сервис уже невозможно без разрезания старой шины.
Что осложняет миграцию с SAP PI/PO и IBM Integration Bus
Важно понимать: SAP PI/PO и IBM Integration Bus — это не просто очереди и маршруты. В них «зашита» бизнес‑логика.
- В SAP PI/PO логика разбросана по маппингам (XSLT, Java), процессам, адаптерам.
- В IBM IIB значительная часть сценариев реализована в message flow на ESQL и специфичных форматах.
Универсального конвертера нет. Нельзя нажать «export» в одной системе и «import» в другой. Фактически каждая интеграция — мини‑проект: её нужно описать, перепроектировать, реализовать и заново протестировать.
При этом большинство таких связей работают круглосуточно, часто с финансовыми или регуляторными последствиями при сбое. Любой простой — деньги и репутационные риски.
Энтакси: кто такой ЕМДЕВ и чем российская платформа отличается от западных
ЕМДЕВ — российский вендор и интегратор, который с 2010 года занимается только интеграционными проектами. Продукт Энтакси задумывался как замена западным ESB вроде IBM Integration Bus, MuleSoft, Oracle Service Bus и webMethods.
Ключевые моменты:
- российская разработка, включена в реестр Минцифры;
- стек полностью на базе открытого кода: Apache Karaf, Apache Camel, ActiveMQ Artemis, PostgreSQL;
- развёртывание на виртуальных машинах, в Docker и Kubernetes;
- упор на подход с минимальным кодированием: аналитик может собирать маршруты в визуальном интерфейсе.
Для бизнеса это означает две вещи:
- нет санкционных и юридических ограничений по использованию;
- легко найти и вырастить специалистов: документация и технологии открытые, не «чёрный ящик».
Что Энтакси умеет «из коробки»
Функционально Энтакси закрывает типовой набор задач, которыми занимались SAP PI/PO и IBM IIB:
- синхронные и асинхронные интеграции: веб‑сервисы, очереди, файлы, Kafka;
- статическая и интеллектуальная маршрутизация на основе содержимого сообщений;
- трансформация данных через XSLT и визуальный маппинг (AtlasMap);
- гарантированная доставка и транзакционная обработка;
- встроенные коннекторы к 1С, SAP, системам ЭДО, REST и SOAP сервисам;
- единый механизм обработки ошибок, логирования и аудита;
- встроенные сценарии переноса конфигураций по цепочке DEV–TEST–PROD;
- мониторинг через веб‑консоль и Grafana;
- обеспечение безопасности интеграций.
Важно, что разработка маршрутов не привязана исключительно к программистам. Значительную часть типовых интеграций может собирать системный аналитик, опираясь на шаблоны и визуальные инструменты. Это ускоряет проекты и снимает бутылочное горлышко по ресурсам.
Главный принцип миграции: две шины работают параллельно
Критическая идея методологии ЕМДЕВ — не пытаться за одну ночь «свалить» старую шину и поднять новую. Используется подход, близкий к strangler fig pattern: старая система продолжает обслуживать трафик, а рядом живёт и набирает функциональность новая.
Переключение происходит поэтапно, небольшими порциями, уже после тестов и сравнения результатов. Это радикально снижает риск «момента X», когда единая точка переключения может привести к массовому падению сервисов.
Этап 1. Аудит и инвентаризация: без карты миграция не взлетит
Первый шаг — честно посмотреть, что у вас на шине происходит на самом деле.
Что делает команда:
- собирает полный реестр интеграций: какие системы связаны, какие форматы, протоколы, объёмы;
- раскладывает интеграции по критичности: от «без них стоим» до «можно отключить на время»;
- оценивает инфраструктуру: ресурсы, отказоустойчивость, требования по безопасности;
- формирует ТЗ по группам интеграций;
- рисует целевую архитектуру: как всё должно выглядеть после миграции.
На этом этапе рождается «дорожная карта» — без неё миграция превращается в череду пожарных работ. Практика показывает: качественная аналитика на старте снимает большинство проблем на следующих стадиях.
Этап 2. Развёртывание Энтакси рядом со старой шиной
Дальше Энтакси поднимается в том же контуре, где работает текущая шина:
- для пилота часто берут компактную сборку «всё в одном контейнере»;
- для боевой среды — отдельный брокер, отказоустойчивые конфигурации, кластер;
- если инфраструктура готова, — развёртывание поверх Kubernetes или Deckhouse.
Развёртывание автоматизируется: скрипты, сценарии установки, воспроизводимые стенды. Хороший пример — проект в Светогорском ЦБК (Sylvamo), где отказоустойчивый контур развернули именно таким образом.
Ключевой момент: на этом шаге действующие бизнес‑интеграции никто не трогает. Всё работает как раньше.
Этап 3. Пилот: сначала самые критичные интеграции
Контринтуитивный, но рабочий подход: первыми на новую платформу переносятся самые критичные интеграции. Почему так?
- на старте у команды максимум внимания, ресурсов и поддержки руководства;
- на сложных сценариях быстро вскрываются все тонкости архитектуры и организационные провалы;
- после успешного пилота доверие к проекту резко растёт.
Технически это выглядит так:
- интеграцию реализуют в Энтакси;
- прогоняют через функциональные тесты;
- проверяют вместе с реальными системами‑поставщиками и потребителями;
- проводят нагрузочное тестирование;
- включают режим «двойного прохождения»: сообщение обрабатывают и старая, и новая шина, результаты сравниваются.
Лишь когда результаты стабильно совпадают, трафик аккуратно переводят на новую реализацию. Старый маршрут пока не удаляется — он остаётся как страховка на переходный период.
Этап 4. Поточная миграция: домен за доменом
После того как пилот доказал жизнеспособность подхода, начинается «конвейер»:
- интеграции группируют по доменам: финансы, логистика, HR, взаимодействие с контрагентами и т.д.;
- по каждому домену формируется очередь переноса;
- команда последовательно переносит, тестирует и переключает маршруты.
На этом этапе большую роль играет библиотека готовых коннекторов Энтакси — более 300 компонентов для 1С, SAP, файловых интеграций, REST/SOAP, Kafka, S3‑совместимых хранилищ и прочего.
Визуальный маппинг и готовые XSLT‑шаблоны позволяют перевоспроизводить многие преобразования без ручного написания кода. В результате время на перенос одной интеграции сокращается, а риски ошибок снижаются.
Этап 5. ОПЭ: всё уже работает на новой шине, старая — в резерве
Когда все запланированные интеграции перенесены, проект не считается завершённым автоматически. Наступает период опытно‑промышленной эксплуатации (обычно 2–4 недели):
- весь боевой трафик идёт через Энтакси;
- старая шина переведена в режим горячего резерва;
- по метрикам и логам отслеживают долю успешных сообщений, задержки, ошибки.
Команда проверяет, как новая шина ведёт себя под реальной нагрузкой, как разворачиваются инциденты и как быстро они закрываются. По итогам этого периода принимается решение окончательно отключить старую платформу.
Этап 6. Документация, обучение и жизнь «после миграции»
Когда шина встала на промышленную опору, наступает не менее важная часть — передача компетенций:
- заказчик получает полный комплект проектной документации;
- проводится обучение внутренней команды: архитекторы, администраторы, разработчики/аналитики;
- выстраиваются регламенты поддержки и развития.
Для компании это точка, где зависимость от зарубежного вендора и редких специалистов по SAP PI/PO или IBM IIB сменяется контролируемой историей с понятной российской платформой и доступной экспертизой.
Энтакси vs SAP PI/PO и IBM IIB: что важно именно российскому бизнесу
Если отойти от таблиц и сравнить платформы по сути, картина такая.
- Доступность и регуляторика. SAP и IBM официально не работают в России, Энтакси разрабатывается здесь и включена в реестр отечественного ПО — это критично для госсектора и КИИ.
- Лицензирование. Западные решения — дорого, часто с привязкой к ресурсам. У Энтакси есть варианты срочных и бессрочных лицензий, что проще подстроить под бюджет и CAPEX/OPEX‑модель.
- Команда. SAP PI/PO и IIB ориентированы на разработчиков. Энтакси позволяет значительную часть работы передать аналитикам, что снижает требования к штату узкоспециализированных программистов.
- Технологический стек. В SAP/IBM — закрытые компоненты и собственные языки сценариев. В Энтакси — XML DSL на Apache Camel и общепринятый open source‑стек, который легко изучать и поддерживать.
Основные риски миграции и как их приручить
Любой человек, который делал интеграционные проекты, знает: риски не в технологиях, а в стыках.
Что чаще всего идёт не так:
- теряются сообщения при переключении;
- искажаются данные при трансформации;
- новая платформа не выдерживает нагрузку;
- команда не успевает набрать компетенции;
- всплывает несовместимость протоколов и форматов;
- появляются вопросы по информационной безопасности и соответствию регуляторике.
Методология ЕМДЕВ бьёт по этим рискам точечно: двойная маршрутизация и гарантированная доставка, многоступенчатое тестирование, нагрузочные проверки до переключения, обучение персонала, широкая библиотека коннекторов и работа в схемах с повышенной защищённостью.
Почему «подождём ещё год» — самый рискованный сценарий
Миграция с зарубежной ESB — это не модный тренд, а вопрос управляемости ИТ‑ландшафта. Чем дольше тянуть:
- тем больше растёт технический долг;
- тем сложнее найти специалистов по старым технологиям;
- тем выше регуляторные и безопасностные риски;
- тем дороже обходится «серое» сопровождение.
Компании, которые начали переход в 2023–2024 годах, уже работают на независимой платформе и используют её как опору для дальнейшей цифровой трансформации. Те, кто продолжает откладывать решение, платят всё больше за поддержку и одновременно теряют скорость изменений.