Золотая середина интеграции

Госкорпорация "Росатом" выходит на рынок с новым продуктом – корпоративной шиной данных Multi-D ESB . Продукт уже проверен в реальной работе – АО АСЭ, управляющей компании инжинирингового дивизиона Росатома. Дивизион занимает первое место в мире по портфелю заказов и количеству одновременно сооружаемых в разных странах мира сложнейших инженерных объектов - атомных электростанций. Multi-D ESB поддерживает функционирование нескольких сотен информационных систем и лежит в основании платформы, обеспечивающей управление жизненным циклом этих сложных объектов для их реализации в заданные стоимость и сроки. Об опыте разработки и реализации крупного интеграционного проекта рассказывает Олег Покровский, директор по продуктам Multi-D – решениям для цифрового управления сложными инженерными объектами.

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

Самый распространенный подход, используемый во многих компаниях на начальной стадии любого интеграционного проекта –– настройка взаимодействия между информационными системами методом "точка-точка" по мере необходимости. Данная модель обычно используется как наиболее простой, но временный подход в силу последующей трудоемкости управления и недостаточной надежности. Также часто вместо интеграции используется повторный ввод данных – в каждую информационную систему пользователь вновь вносит нужную для работы сервиса информацию.

По мере развития компании, усложнения и диверсификации бизнеса, растет и количество информационных систем, нуждающихся в обмене данными. Управление множеством интеграций "точка-точка" становится очень сложным и дорогостоящим: растут потери данных, как и расходы на содержание разработчиков, необходимых для поддержания работоспособности точечных интеграций. В этот момент перейти на интеграцию на основе шины ESB (Enterprise Service Bus) – технически необходимое решение.

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

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

Сегодня Multi-D ESB полностью внедрена в Инжиниринговом дивизионе ГК "Росатом" и мы можем уверено говорить о результатах:

- сокращение времени протекания процессов с 24 часов до 11 часов;

- сокращение количества запросов данных с 87 до 64;

- сокращение количества итераций на верификацию получателем передаваемых данных с 4 до 1;

- сокращение количества ошибок при вводе данных на 73%;

- сокращение трудозатрат в 2,5 раза;

- сокращение времени передачи информации о датах и статусах контрактации в 13,3 раза.

Общий экономический эффект от использования шины - экономия до 4,5 человеко-часов в день на каждой операции передачи данных или в среднем 5,6 млн. руб. в год за одну интеграцию. Совокупный прогнозируемый эффект до 2029 года от запланированных интеграций ожидается в размере 903,4 млн. руб.

Исходя из своего опыта, подчеркну: выбирая то или иное интеграционное ПО, компании следует ориентироваться на свои потребности и перспективы. Единственное универсальное требование, или, скорее, рекомендация: "отечественность" продукта. Уход с российского рынка зарубежных вендоров не оставляет иного выбора. Даже те, у кого уже было установлено импортное ПО, лишившись техподдержки, вынуждены оперативно искать замену на отечественном рынке. Замечу, что есть и компании, просто обязанные заменить иностранный продукт на российское решение к определенному сроку.

Надо ли, чтобы шина обеспечивала обработку запросов в реальном времени, как, например, у сотовых операторов? Нужно ли обеспечивать передачу больших массивов данных и их обработку в реальном времени или нет? Немаловажна способность продукта к масштабированию. Будет ли компания расширяться, достаточно ли у нее вычислительных ресурсов, насколько легко реализуются функции оптимизации продукта – это накладывает свои требования к будущему ПО. Объем обрабатываемой в компании информации может выходить за пределы одного, даже кластеризованного экземпляра базы данных. И здесь принципиальна возможность распределять данные между различными физическими базами и хранить их в формах, оптимальных с точки зрения приложения-владельца. Еще очень важна надежность и безотказность. Здесь показателем может служить опыт и наработка. Если продукт совсем сырой, не опробованный, так сказать, "в бою", то спешить с его приобретением не стоит. Что касается реализованной архитектуры, то, как утверждают эксперты, и трудно с ними не согласиться, сейчас требования к приложениям могут меняться довольно часто. А это значит, что "оптимальность" архитектуры и дизайна может быть достигнута только в краткосрочной перспективе.

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

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

К разработке шины мы подошли гибко, адаптивно объединив как opensource инструменты интеграции, так и собственные наработки в развитом общем интерфейсе администрирования. Multi-D ESB выгодно отличают мощные возможности масштабируемости и высокая отказоустойчивость. Стек технологий подбирался не уникальный, а зарекомендованный, проверенный временем (ядро – Apache Camel), с большим пользовательским опытом, наработками, большим количеством специалистов на рынке, имеющими опыт работы с этим ПО. Архитектурные решения, примененные в нашей шине, мы зарегистрировали в Роспатенте как изобретения.

Multi-D ESB имеет гибкую гибридную архитектуру, не микросервисную в классическом понимании. Шина реализована как модульная система с глубокой интеграцией компонентов, позволяющая гибко сконфигурировать конечную архитектуру интеграционного решения исходя из уникальных задач пользователя. Например, кому-то важно обрабатывать большие объемы данных (большие пакеты), а кому-то множество небольших запросов, кому-то важно не потерять ни одного пакета, а кому-то важнее скорость. Такая гибридная архитектура менее затратна с аппаратной точки зрения по сравнению с микросервисной, а также требует меньшей квалификации команды поддержки. Например, при настройке несложных интеграций навыки кодинга не нужны. Для настройки сложных интеграций могут потребоваться Java-программисты для написания адаптеров, оптимизирующих интеграционный проект.

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

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

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