Не секрет, что приоритетными направлениями импортозамещения, ход исполнения которых контролируется регуляторами, являются core-системы банков, базы данных, а также ИБ-решения. А вот о состоянии дел в иных IT-сегментах нечасто можно встретить исчерпывающие презентации.

Как проявляются проблемы с интеграционными решениями в финансах с точки зрения пользователя? Илья Гришанов, инженер компании Logrocon, примерно год назад в одном из своих выступлений красочно описал один из кейсов: «Традиционный механизм обмена информацией, например, в личных кабинетах на сайтах микрокредитных компаний часто приводит к сбоям и нестыковкам. Пользователи входят на личные страницы, получают информацию о дате предстоящего ближайшего взноса, сумме процентов, видят предлагаемые акции и т.д. Но вся эта информация получена из разных баз данных и передается разными интерфейсами, а информационные хранилища часто разработаны разными специалистами. В результате сведения передаются сложными маршрутами, и чем больше сервисов задействовано в информационном поле, тем больше сбоев операций происходит при пользовании приложением. Абонент вынужден терпеть длительные ожидания, многократно запускать сервис, и иногда он получает неактуальные данные на текущий момент времени».

Проблема известна всем, но решается она далеко не в первую очередь, хотя разговоров об обеспечении бесшовности клиентского пути и внедрении data-driven-подхода к управлению бизнесом ведется немало. Но в реальности этим вопросом озаботились за редким исключением лишь банки, страховщики и МФО из числа топ-10. В чем дело? Услышать версию причины этого от Ильи Орлова, руководителя группы разработки направления «Интеграционные решения» «К2Тех» и его доклад «Альтернатива зарубежным ESB: импортозамещение интеграционной шины на примере Roc Integration» пришло довольно много специалистов.

Илья Орлов («К2Тех»). Фото: Globus IT

Для кого и для чего?

Кому вообще нужны интеграционные шины (enterprise service bus, ESB)? По словам спикера, усилиями «К2ТЕХ» было проведено исследование по данной теме. По итогам анализа выделено три типа компаний, нуждающихся в них.

Во-первых, молодые быстрорастущие бизнесы, у которых непрерывно изменяется внутренний IT-ландшафт. В их число входят производители оборудования, IT-вендоры (включая тех, которые имеют банковские лицензии), стартапы и финтехи. Их объединяет стремление вывести свои продукты и сервисы на рынок максимально быстро, что серьезно усложняет технологический ландшафт.

Во-вторых, организации, на которые оказывают давление регуляторы в целях скорейшего импортозамещения иностранного ПО. Ситуация здесь характеризуются сроками дедлайнов, которые постоянно отодвигаются, но они есть. Поэтому рано или поздно решение о старте проекта придется принимать.

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

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

Есть ли альтернативы?

А можно ли вообще обойтись без нее? Да, можно. Такая IT-архитектура создавалась довольно давно многими компаниями, перед которыми в то время не стояла задача активно развивать набор сервисов и продуктов. В ней различные узлы связывались по принципу «каждый с каждым».

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

Со временем образовалась своеобразная IT-паутина, обслуживать и развивать которую становится дороже, чем разом перейти на новую архитектуру. До ухода западных вендоров так и делали.

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

Экономические причины тоже есть. Например, по данным «К2ТЕХ», стоимость поддержки ESB-шины на 70% ниже, нежели вообще без нее. Это происходит за счет синхронизации усилий команд внедрения, сокращения затрат на менеджмент, а главное, за счет переиспользования кода для организации интеграционного взаимодействия, поскольку технологический стек остается тем же.

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

Рынок — он такой

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

Жизнь показывает, что многие предпочитают откладывать до последнего звонка, надеясь на «бесплатный» open source, а также, что собственными силами с нуля разработать для себя любимого ESB на основе свободного ПО быстрее, чем за восемь месяцев, попросту невозможно. И чем крупнее бизнес, чем больше у него legacy, тем дальше вправо по времени уходят проекты, стремясь в конечном счете к бесконечности и по затратам, и по срокам. Это, вероятно, одна из основных причин того, что практически нет публичных кейсов об успешном внедрении ESB: «Хотели, как лучше, а получилось, как всегда».

А что нужно для правильного старта проекта?

Илья Орлов считает: «Начинать надо с выстраивания грамотного подхода к проектированию IT-архитектуры. К тому же необходима тщательно подобранная квалифицированная команда. И даже в таком случае требуются месяцы работы на выстраивание контуров целевой архитектуры, согласование с ИБ, тестирование и т.д.».

Если же организация, наигравшись с open source, выходит на рынок и готова к покупкам, то ее ждет неприятный сюрприз — сплошь и рядом наблюдается подмена понятий со стороны производителей. Например, вендор утверждает, что у него есть интеграционная платформа. Заказчик приходит к нему и просит интеграционную шину. Начинают разбираться, и выясняется, что на самом деле имеются лишь компоненты, заточенные под специфические задачи, например ETL или брокер сообщений. Готового решения нет, а дедлайны поджимают…

Равнение на кейсы

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

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

В качестве вывода по докладу имеет смысл привести цитату из пресс-релиза, посвященного замещению силами «К2Тех» платформы IBM на шину собственной разработки для международного банка: «Мы рекомендуем финансовым организациям внутренние ресурсы направлять на развитие банковских сервисов и повышение конкурентоспособности, а непрофильные функции закрывать готовыми надежными решениями. Почти всегда это быстрее и дешевле в перспективе».