Подготовка к сложному интеграционному проекту в субъектах КИИ

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

Отечественный разработчик гибридной интеграционной платформы и партнер по цифровизации бизнеса с опытом проведения интеграционных проектов более 28 лет — Bercut, делится знанием, как качественно подготовиться к реализации такого проекта. В частности, как, следуя определенным правилам и проверенной методологии, нивелировать потенциальные риски для бизнеса, сократить сроки проведения проекта и получить ожидаемый результат в виде удобного в эксплуатации решения.  

Спрос на интеграции 

Одним из самых актуальных на рынке трендов, который пронизывает все сферы экономики страны и затронул едва ли не все существующие сегменты бизнеса, является тренд на импортозамещение. В особенности он коснулся субъектов критической информационной инфраструктуры (КИИ), к которым относятся финансовые учреждения, операторы связи и некоторые другие организации. На сегодняшний день большинство этих учреждений работают с СУБД Oracle, и с первого января 2025 года государственный регулятор обязует их перейти на отечественный софт. Для этого компаниям потребуется заменить не только технологический стек, но и часть оборудования. Таким образом, замена иностранного продукта станет поводом для пересмотра и внедрения нового подхода к построению ИТ-ландшафта организации, важную роль в котором будут играть новые интеграции. 

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

Ранее архитектура ИТ-продуктов выглядела как монолит — единое целое. Решение могло представлять собой некую базу данных, в которой находилась масса различных неотделимых друг от друга функциональностей, что приводило к сложности их масштабирования. Многофункциональная система, наполненная сотнями запросов, сценариев и задач, требовала больше оборудования, а высокая связанность компонентов усложняла ее адаптивность. Ко всему прочему, архитектура таких решений делала трудной их дальнейшую поддержку и развитие: чтобы добавить в монолит новую функциональность, требовалось разобраться во множестве взаимосвязей и погрузиться в каждую деталь, чтобы исключить возможное влияние компонентов друг на друга. На изучение этих взаимосвязей уходила основная часть времени, что увеличивало T2M любого интеграционного проекта, усложняло реализацию новых фичей и анализ инцидентов. Это стало предпосылкой для внутренней децентрализации решений и стимулировало переход организаций к модульной или микросервисной архитектуре. 

По мере увеличения количества цифровых сервисов и используемых в ИТ-ландшафте разрозненных систем расширялась и их функциональность. Решения стали сложнее, изобретательнее и разнообразнее, как и технологии, на которых они разработаны. Как следствие, на один уровень с созданием новых продуктов вышли вопросы поддержки и своевременной модернизации технологического ландшафта, обеспечения его единообразия и целостности для легкого управления и масштабирования. 

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

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

Подготовка к интеграционному проекту

Каждая организация, планирующая проведение интеграционного проекта, уже имеет некий набор сервисов и систем в своем ИТ-контуре. Часть из них приобретена у вендора, другие созданы разработчиками in-house, третьи — собраны из различных продуктов и внедрены интегратором. Чтобы не потеряться во всем этом многообразии и качественно подготовиться к проведению интеграционного проекта, стоит помнить о четырех шагах: 

1. Прежде всего важно разобраться, что на самом деле есть у компании. Для этого необходимо провести глубинный анализ и сформировать реестр, в который будут внесены все продукты и сервисы, которыми владеет компания. 
2. В реестре необходимо указать, для каких целей используются эти сервисы. Рекомендуется определить их статус и каталогизировать по типам: активны или не активны, используются или выводятся из эксплуатации, или, возможно, находятся в процессе разработки. Это позволит организации четко разобраться с тем, что в настоящий момент происходит и что имеется в наличии для дальнейшего переиспользования. 
3. Вместе с тем важно понять, в каком виде предоставляется интерфейс каждого сервиса. Это могут быть микросервисы REST или веб-интерфейс. Могут встречаться и нестандартные проприетарные протоколы, которые потребуют дополнительных работ для интеграции с ними. Без предварительного понимания таких специфических деталей двигаться в тайминге по интеграционному проекту будет сложно. 
4. Каждый продукт реализован в определенной логике. Последовательность тех или иных процессов — обработки данных, формирования запросов или нотификаций — должна быть где-то реализована и описана в BPM-нотации в виде бизнес-процесса или Java-кода. В BRMS-системах входящие события, запросы и принципы реализации, а также реакции на эти события формализуются и описываются через UI.  
   

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

Наличие перечня всех микросервисов и компонентов с их описанием в едином реестре, а также принципами работы их API серьезно повлияет на скорость моделирования интеграционного проекта. Имея реестр и описание API, проще понять, какие артефакты из существующих можно переиспользовать, тем самым ускорив разработку и сократив T2M для каждой новой функциональности. 

Legacy или унаследованные системы 

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

Привести к единообразию, общепринятой и понятной методологии взаимодействия систем со строящимися проектами могут корпоративные платформы интеграции (ESB).

 Например, в гибридной интеграционной платформе Bercut, как и во многих других платформах, существует специальная сущность — адаптер. Компонент выполняет функцию адаптации от единообразного подхода, принятого на платформе, ко всевозможным проприетарным протоколам и интерфейсам. Если компании необходимо стандартизировать взаимодействие с legacy-системами за счет обвязки ее современным API, именно адаптер позволит подключиться к сервисам через Open API. Независимо от того, на каком коде они написаны — Java, C++ или на чистом C, — адаптер превратит вызовы REST-протоколов в тот набор вызовов, параметров и последовательностей, которые нужны именно этой проприетарной системе.

Безопасность 

Для внутренних DMZ-продуктов (Demilitarized Zone) вопросы безопасности могут быть не так критичны, но при насыщенном ИТ-ландшафте задачи авторизации и аутентификации сервисов или процессов играют не последнюю роль. От них зависит общая управляемость и риски возникновения проблем, связанных с влиянием существующих процессов друг на друга. 

Например: существует сервис, который продуктивен под определенной нагрузкой и на определенном железе. Чтобы избежать ситуации, в которой к сервису, без согласования с сотрудником, отвечающим за его работу, без тестирования и резерва по HW, подключают продукт с 10 тыс. запросов секунду, в результате чего он деградирует, системы должны быть ограждены друг от друга при помощи API management систем, в частности, с использованием API Gateway. 

API Gateway пропускает через себя запросы, выполняя функцию авторизации и аутентификации. К тому же он может ограничивать нагрузку или обеспечить балансировку. Тогда сотруднику, планирующему подключиться к какой-то из систем, потребуется пройти процедуру верификации, получить авторизационные права, что делает эту нагрузку уже ожидаемой. 

Преимущества использования интеграционных платформ 

1. Большинство платформ уже имеют готовые адаптеры к общепринятым технологиям, например, очередям или базам данных. Также в решении могут использоваться продуктовые адаптеры вроде адаптеров для СRM, 1C или различных мессенджеров.
2. Каждая платформа имеет собственный инструментарий. Это могут быть различные утилиты, среды разработки, в которых у сотрудников есть возможность создавать адаптеры для проприетарных систем. 
3. Платформы предоставляют массу сопутствующих возможностей, например, функциональность для упрощения работы с базами данных, кодогенератор, который по контенту базы данных позволит получить сервис или универсальный адаптер, гарантированная доставка, шифрование, long-running процессы.
4. В рамках создаваемого на платформе продукта все будет единообразно. Сотрудники будут работать с однотипным с точки зрения технологий, протоколов, интерфейсов и микросервисов технологическим стеком.
5. Интеграционные платформы зачастую оснащены инструментами для моделирования продуктов уже в виде бизнес-процессов или, как в случаях с BRMS-системами, в виде сценариев обработки событий, что ускоряет T2M, упрощает тестирование и создание MVP. 
   

Реализовать и суметь поддерживать

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

Как избежать подобной ситуации? 

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

Интеграционный проект будет гораздо проще поддержать и эксплуатировать, если он 
основан на единообразном подходе или реализован на специализированной интеграционной платформе. 

Заключение 

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

«С полной информацией об активах компании, находящихся в ИТ-контуре, и четким пониманием, какая интеграционная шина ляжет в основу его развития, интеграционный проект приобретает понятную и прогнозируемую форму. Тем временем сотрудники могут заняться уже более практической задачей — создавать требования в виде конкретных use-кейсов, раскладывая их на логику реализации, и не переходить при этом на более сложные технологические уровни» —, комментирует Руководитель направления платформы в Bercut, Константин Коптяев. 

Скачайте чек-лист по подготовке к интеграционному проекту, кликнув по данной ссылке.