В связи с уходом вендоров отечественные компании испытывают сложности с продлением лицензий на зарубежные интеграционные продукты. Отток компетенций вызвал сложности с поддержкой ПО. Бизнес оказался в непростой ситуации. С одной стороны, сохраняется потребность в интеграции, а регуляторы диктуют необходимость перехода на отечественные альтернативы. С другой — существующие на локальном рынке решения пока имеют технические ограничения.
В данной статье я расскажу о том, как устроена интеграционная шина (enterprise service bus, ESB), для каких компаний она необходима, а также как выбрать и внедрить оптимальное решение, чтобы снизить затраты на поддержку интеграций.
Каким компаниям необходима интеграционная шина
Мы изучили рынок и пришли к выводу, что в текущих условиях потенциальных заказчиков можно условно разделить на три типа:
- компании, которые активно развиваются и нуждаются в сверхбыстром переходе на надежное решение, чтобы управлять корпоративным ИТ-ландшафтом и масштабировать его пропорционально росту бизнеса;
- компании, которым необходимо осуществить переход на отечественное ПО в обозначенный регулятором срок;
- компании, которые пока могут не менять сложившийся ИТ-ландшафт, однако в перспективе хотели бы сократить расходы на эксплуатацию интеграционных решений.
Одни заказчики внедряют интеграционную шину с самого начала построения своего ИТ-контура. Например, зарубежные компании, которые в свое время быстро выходили на российский рынок и столь же быстро масштабировались. Другие компании давно существуют на рынке, планомерно развиваются и расширяют ИT-ландшафт. Со временем сервисы и приложения, связанные посредством нескольких десятков взаимодействий, образуют сложную паутину систем. Стоимость их поддержки становится очень существенной, при этом растут риски потери данных. Здесь и появляется необходимость в интеграционной шине.
Как строится интеграционное решение: объяснение на пальцах
Предположим, что молодая амбициозная компания использует две системы — CRM с базой контактов и ERP, которая периодически запрашивает, какие новые клиенты появились в CRM. Наладить взаимодействие между ними достаточно просто: две команды договариваются, по какому протоколу системы будут работать, в каком формате и с какой периодичностью будут обмениваться информацией. Затем в контуре появляются HR-система и контакт-центр, которым также необходим доступ к данным о клиентах из CRM. Также HR-систему нужно связать с ERP для получения новых данных, а контакт-центр представляет собой коробочное решение без возможности доработки, но с доступом к базе данных. Получается, что договоренностями здесь уже не обойтись, и необходимо предложить еще одну точку взаимодействия для HR-системы и передачи данных в контакт-центр.
На этом этапе поможет как раз интеграционная шина. Для каждой системы формируется два потока: входящий и исходящий. Шина обеспечивает преобразование сообщений в нужный формат, контроль транзакций, маршрутизацию с учетом смысла, равномерное распределение нагрузки на сервисы и безопасность обмена данными, подстраивается под требования и возможности интегрируемых систем, позволяя избежать их доработок. Следующий шаг — настройка канонического формата на шине для унификации сообщений и ускорения процесса подключения систем. И финальный штрих в создании интеграционного слоя — внедрение
Как выбрать решение
Итак, когда вопрос о целесообразности внедрения шины уже не стоит, возникает следующий — что предпринять? Есть три возможных сценария: разработать интеграционную шину самостоятельно, дождаться, когда рынок предложит оптимальное решение, или выбрать готовый продукт. Каждый из них вполне реалистичен, однако имеет свои подводные камни.
По опыту, на разработку MVP собственной шины на Open Source-компонентах понадобится не менее восьми месяцев, затем около двух месяцев уйдет на устранение багов. Также необходима полноценная команда, которая грамотно подойдет к построению архитектуры.
Если у компании отсутствует необходимость в сверхбыстром переходе, можно начать с анализа рынка. На старте заказчику важно определиться, какой интеграционный продукт ему нужен. Некоторые заказчики отмечают, что решение, которое вендор заявляет как интеграционную платформу, по факту может оказаться брокером сообщений или ETL-инструментом. Присутствует риск, что заявленная функциональность, критичная для компании, существует только в дорожной карте, которую обещают реализовать в горизонте двух лет. А вендор в силу разных причин не всегда готов дорабатывать и развивать решение нужными темпами.
Если же интеграционное решение нужно здесь и сейчас, то к его выбору следует подойти со всей серьезностью и провести подготовительную работу:
- определить перечень критериев, запросить у вендоров информацию и провести сравнительный анализ решений;
- изучить кейсы внедрений и отзывы клиентов;
- запросить демонстрацию продукта, чтобы среди прочего оценить компетентность представителей вендора и убедиться в наличии ресурсов для реализации проекта;
- рассчитать с экспертами стоимость владения продуктом;
- заручиться гибким бэклогом и вендорской поддержкой.
Безусловно, решение о включении шины в контур, выбор подхода к внедрению и самого решения, остается за заказчиком. Путь этот может быть сложен и тернист. Я рекомендую всегда начинать с аудита текущих интеграционных потоков и проектирования целевого состояния. На следующем шаге необходимо оценить работоспособность и отказоустойчивость инфраструктуры. А также предоставить необходимые доступы, согласовать работу с командами или подрядчиками, которые сопровождают системы, находящиеся в контуре шины. Важный этап — полноценное тестирование, которое позволит своевременно устранить узкие места.
