Классические шины — это блокер цифровой трансформации, а не её энейблер. Рост числа сервисов, переход к микросервисной архитектуре и необходимость быстрой адаптации требуют большей гибкости и новых подходов к интеграции. Теперь связывать цифровые системы между собой необходимо в условиях постоянного роста объёма данных.
Из статьи вы узнаете, почему мы в MWS отказались от классических интеграционных шин, что выбрали взамен и как здесь используется ИИ.
Барьеры интеграции
За многие годы внутри МТС сформировалась классическая «спагетти»-архитектура. Разные системы были связаны друг с другом множеством несогласованных интеграций, построенных по разным принципам и с использованием разных технологий. Это создавало хаос, увеличивало стоимость изменений и делало развитие инфраструктуры крайне затруднительным.
В компании одновременно существовало несколько поколений интеграционных решений:
• WSO2;
• Oracle ESB;
• самописные интеграционные компоненты;
• Kafka и другие open‑source‑решения.
Такое технологическое разнообразие приводило к высокой фрагментации. Подключение новых систем становилось длительным, дорогим и трудоёмким процессом. Чтобы интегрировать очередной сервис, требовалось:
• участие выделенных интеграционных команд;
• согласование с ИБ;
• ручное открытие сетевых доступов;
• учёт различий между множеством интеграционных платформ.
Разработка интеграций, включающих более трёх–четырёх шагов оркестрационной логики, превращалась в сложный процесс. Для создания и сопровождения таких сценариев требовались специалисты, хорошо разбирающиеся в разнородных технологиях и особенностях существующей архитектуры.
Инфраструктура не обеспечивала необходимых механизмов надёжности: не было полноценного георезервирования, сквозного трейсинга запросов и единой системы мониторинга, позволяющей проследить путь запроса от начала до конца
В таких условиях было сложно оперативно выявлять и устранять проблемы, а иногда даже понять, где именно произошёл сбой.
Классические интеграционные шины — вчерашний день цифровой трансформации
ИТ‑среда меняется под влиянием нескольких факторов. С одной стороны, усиливается экономическое давление: бюджеты сокращаются, и компаниям приходится искать более эффективные подходы к развитию инфраструктуры. С другой — сохраняется необходимость импортозамещения, что требует замены устаревших или недоступных решений на функциональные аналоги. При этом бизнес по‑прежнему ожидает быстрых изменений, появления новых функций и ускорения темпа интеграций.
Рассматривая возможные архитектурные решения, мы задумались, стоит ли опираться на классическую интеграционную шину. Однако быстро поняли, что этот путь нам не подходит. Причины следующие.
1. Вендорлок — источник затрат
Любая классическая вендорская шина представляет собой сложный продукт, требующий узкоспециализированных знаний. Компания оказывается в ситуации, когда недостаточно обучить несколько сотрудников — приходится формировать и постоянно содержать целые отделы для обслуживания конкретного проприетарного решения. В результате формируется критическая зависимость бизнеса от группы экспертов. Без этого дорогостоящего ресурса становятся невозможными развитие, модификации и расширение интеграционной архитектуры, что значительно увеличивает TCO.
2. «Бутылочное горлышко» разработки
Команда, владеющая проприетарной технологией, неизбежно превращается в единственную точку входа для всех интеграционных задач. Поскольку таких задач в современной компании десятки и сотни, возникает очередь. Бизнес-инициативы блокируются на пороге: без интеграции через ключевую шину невозможно продвинуться дальше.
Остаются два невыгодных варианта: либо увеличивать штат дорогих специалистов, либо мириться с хроническими задержками. Так классический подход напрямую тормозит цифровую трансформацию, увеличивая lead time до критических значений и подрывая конкурентную скорость бизнеса.
3. Ограниченная поддержка протоколов
Классические решения изначально создавались с учётом требований прошлого и плохо адаптируются к современным сценариям — они с трудом масштабируются и поддерживают лишь ограниченный набор протоколов. Если вся архитектура основана на легаси‑системах, это может казаться приемлемым. Однако бизнес не стоит на месте: в ландшафте постоянно появляются новые системы. Они оказываются «за бортом» централизованной интеграции.
Современные цифровые продукты требуют поддержки актуальных протоколов: SSE, gRPC, GraphQL, MCP, A2A. С их помощью реализуются передовые сценарии интеграции, обеспечивается высокая скорость обмена данными и создаются новые пользовательские возможности. Однако классическая шина чаще всего просто не умеет работать с такими технологиями.
4. Узконаправленная функциональность
На практике нередко компания приобретает интеграционную шину, рассчитывая сделать её единым центром интеграционной архитектуры. Но вскоре выясняется, что часть необходимых протоколов не поддерживается, некоторые сценарии невозможно реализовать, а новые продукты не вписываются в рамки её возможностей. В итоге шина покрывает лишь небольшой сегмент задач, а для современных, высокопроизводительных и событийных потоков всё равно приходится внедрять Kafka или другие инструменты.
Ранее такие технологии, как ESB (классическая шина), APIM и ETL, существовали как отдельные продукты с выделенными командами. Современным компаниям требуется решение, которое позволяет выполнять любые интеграционные задачи и в то же время снижает сложность и общую стоимость владения.
5. Медленный Time to Market
Ещё один важный аспект — скорость вывода новых продуктов на рынок. Интеграционная платформа не должна становиться узким местом, замедляющим развитие. Напротив, она должна помогать командам быстро подключать сервисы, экспериментировать и запускать новые сценарии.
MWS Octapi — интеграционная платформа нового поколения
Мы выбрали путь создания интеграционной платформы нового поколения, в которой любая команда может самостоятельно быстро сделать интеграцию. Для этого мы внедрили:
Self‑Service подход
Чтобы не ждать узконаправленных специалистов, команда должна быть способна сама сделать необходимую интеграцию.
Архитектуру, в которой каждая интеграция работает изолированно
Такая изоляция обеспечивает локализацию последствий ошибок: если команда допустит ошибку в настройках или логике, воздействие будет ограничено только её собственным контуром. Этот архитектурный принцип позволяет безопасно масштабировать количество команд и интеграций, не ставя под угрозу стабильность всей системы.
Поддержку широкого спектра современных протоколов
Речь идёт не только о поддержке классических протоколов вроде SOAP/XML, REST. Сегодня командам требуется полноценная поддержка API Management, event‑driven‑интеграций и Service Mesh. Такая универсальность позволяет внутренним командам, независимо от их технической зрелости, использовать платформу и выбирать оптимальный способ взаимодействия.
ИИ-агента
Low-code инструменты призваны помогать создавать интеграции быстрее и без привлечения разработки. Однако на практике для начала работы необходимо изучить документацию и разобраться с нюансами выполнения различных задач. Поэтому мы добавили ИИ-агента.
ИИ-агент значительно снижает порог входа в процесс интеграции различных систем: объясняет, как выполнить нужную интеграцию, даёт ссылки на документацию, находит необходимые API, пишет сложную трансформационную логику и даже самостоятельно строит интеграции по запросу пользователя.
ИИ-помощник построения интеграций
На рисунке представлен интерфейс low‑code инструмента MWS Octapi, который позволяет быстро и гибко собирать самые разные сценарии взаимодействия между системами благодаря встроенным адаптерам к 1С, SAP и многим другим. Интерфейс напоминает современные инструменты вроде Llama‑powered‑решений или Bolt‑подходов, где используется вайб-кодинг.
Логика работы меняется повсеместно: всё больше пространства в интерфейсе занимает диалог с ботом, которому пользователь формулирует задачу, уточняет детали и просит доработать или изменить определённые элементы. Мы применяем тот же принцип: разработчик или аналитик описывает задачу на бизнес‑языке, а система автоматически интерпретирует запрос: генерирует код, создаёт заготовку интеграции или даже формирует готовый модуль.
Симбиоз ИИ‑помощника и low‑code, по нашим данным, ускоряет разработку сложных оркестрационных сценариев в 5–10 раз.
Будущее интеграции: Agent Mesh
Сейчас мы движемся от классической шины данных к концепции Agent Mesh. Переход логичен: во множестве процессов появляются интеллектуальные агенты, которым требуется иная логика взаимодействия и иной уровень контроля.
Платформа, оснащённая ИБ‑инструментами, механизмами управления доступом и возможностью точно понимать, кто на что подписан и какие данные потребляет, становится естественной средой для работы ИИ‑агентов. Мы можем не только регистрировать таких агентов внутри системы. Поддержка протокола MCP и автоматическое создание MCP-сервера на базе API позволяет превращать привычные API в «руки» для ИИ — управляемые действия, которые агенты могут выполнять в рамках заданных правил и политик.
Результаты
Переход к новой интеграционной платформе дал всему МТС ощутимые результаты.
Сокращение интеграционной команды
Одним из ключевых результатов внедрения MWS Octapi стала значительная экономия ресурсов — затраты на команду разработки интеграций фактически равны нулю.
У нас есть небольшая команда сопровождения — всего шесть человек. Они отвечают за мониторинг, стабильность и оперативное реагирование на инциденты. Все остальные задачи по созданию интеграций выполняют продуктовые команды. Они работают с необходимой им скоростью: если интеграцию нужно запустить сегодня, команда запускает её сегодня.
Снижение Time to Market до минут
Раньше процесс был долгим и многоступенчатым: требовалось назначить встречу, согласовать требования, подготовить документацию, перейти к разработке, затем к доработкам, исправлению ошибок, уточнению устаревшей документации и повторным обсуждениям. Всё это значительно увеличивало сроки вывода продукта на рынок.
Теперь процесс выглядит так: команда заходит на платформу, находит нужный API или готовый интеграционный модуль, запускает его либо конфигурирует необходимую логику с помощью low-code, и интеграция сразу начинает работать.
Уменьшение стоимости разработки
Разработка интеграционного сценария «с нуля» требовала участия целой команды: аналитика, который готовил документацию; разработчика, создававшего код; тестировщика; DevOps‑специалиста, настраивающего пайплайн; а также значительного времени на исправление ошибок и согласования.
Сейчас эти затраты почти полностью исключены: продуктовая команда заходит на платформу, собирает интеграцию из готовых модулей как из «кубиков» и запускает её.
Гибкость и управляемость
Мы прошли путь от использования классической монолитной шины, которая заметно тормозила технологическую трансформацию, к гибкой и управляемой архитектуре. Монолитные интеграционные решения уступили место распределённой платформе, построенной по принципам GitOps.
Автоматизация и ускорение
Благодаря ИИ‑компонентам и low‑code‑подходу процессы создания и развёртывания новых интеграционных сервисов ускоряются в разы. Инструменты автоматизации минимизируют ручной труд, сокращают время разработки и обеспечивают более высокое качество решений. В результате формируется по‑настоящему масштабируемая цифровая среда.
Переход к Agent Mesh
Платформа MWS Octapi — это фундамент для внедрения ИИ‑агентов, которые могут самостоятельно выполнять интеграционные задачи, взаимодействовать друг с другом и обеспечивать новый уровень автономности и управляемости внутри компании. Чтобы узнать подробности о создании ИИ-агентов на платформе, посмотрите наш вебинар.
Таким образом, поставив цель заместить решения иностранных вендоров, мы не просто создали альтернативу. Мы разработали современную, технологичную, устойчивую интеграционную платформу, позволяющую быстро настраивать интеграционные цепочки под потребности пользователей. Как продукт, платформа MWS Octapi теперь доступна всем пользователям.
