Разработали целевую схему интеграции систем для производственного предприятия. Внедрили технологию ESB и запустили 48 потоков

Клиент

ООО «Электрорешения» (торговая марка EKF) занимается разработкой, производством и продажей электрооборудования и комплексных энергоэффективных решений для промышленных предприятий. EKF сотрудничает с крупнейшими российскими корпорациями нефтегазовой промышленности, производственными, логистическими и транспортными компаниями, а её продукция реализуется в 20 странах. Масштаб бизнеса постоянно увеличивается, что неизбежно отражается на его IT-ландшафте: растёт объём данных, курсирующих между системами, и число интеграций.

Задача: обеспечить актуальные данные во всех системах и отказоустойчивость архитектуры

Масштабируя IT-архитектуру, команда EKF хотела предупредить проблемы масштабирования своей IT-архитектуры. По мере увеличения объёма используемых данных могли возникнуть следующие сложности:

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

Команда EKF пришла к выводу о необходимости внедрения брокера сообщений Kafka, которому предстояло доверить передачу данных между системами и контроль качества доставки информации.

С этой задачей EKF обратились к KT.Team.

Опрашивая команду EKF в ходе предпроектного этапа, KT.Team уточнила запрос клиента: наладить процесс обеспечения актуальности данных во всех системах и добиться отказоустойчивости IT-архитектуры.

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

Поэтому совместно с клиентом мы разделили проект на два этапа:

• этап аналитики и планирования;
• этап внедрения.

Решение: спроектировать внедрение ESB безопасно, контролируемо и с понятным бизнес-результатом

Результат 1: выделили зоны ответственности систем

Предыдущий опыт работы KT.Team на проектах по внедрению ESB показал, что зачастую в компаниях отсутствует актуальная и полная карта потоков и интеграций as is. Каждый руководитель направления и ведущий IT-специалист экспертно понимает, как выстроены взаимосвязи конкретно в его направлении и конкретно с его системой. Об остальных фрагментах карты интеграций они имеют общее представление, которое позволяет взаимодействовать с другими подразделениями.

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

Поэтому первые 10 встреч с командой EKF мы посвятили построению и уточнению схемы as is. В рамках этой схемы зафиксировали зоны ответственности всех систем, которые включёны в контур EKF.

В ходе предпроектного исследования команда EKF обозначила вместе с KT.Team, какая из систем является источником для конкретного типа информации, а какая — получателем. Это позволило определить места, в которых информация могла дублироваться или противоречить сведениям в системе-источнике. Снижение скорости обмена информацией могла спровоцировать возникновение дополнительных проблем.

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

Результат 2: команда клиента синхронизировала понимание, в каком состоянии находится IT-контур компании

Каждый из ключевых IT-специалистов EKF на момент старта проекта обладал глубокой экспертизой по своему участку работы, однако полной, достоверной и общедоступной карты IT-контура компании не существовало.

По итогам 10 встреч команды KT.Team и EKF совместно построили карту интеграций, актуальную на момент начала проекта, объединив и обогатив локальные схемы, ранее составленные сотрудниками EKF.

Сформировав общую картину IT-контура, ключевые IT-специалисты EKF получили идентичное понимание того, как выглядит IT-ландшафт компании и какие в нём есть потенциальные проблемы — в целом по компании, а не только по отдельным областям.

Созданная схема помогла зафиксировать то, что осложняет процесс обмена данными:

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

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

Результат 3: спроектировали новую карту интеграций со слабой связанностью и высокой отказоустойчивостью

Ещё на ранних этапах общения с KT.Team команда EKF рассказала о ряде распространённых кейсов из своей практики, которые ей приходилось регулярно отрабатывать. Например, если по какой-либо причине была недоступна ERP, дистрибуторы не могли сделать заказ на портале, т. к. не видели ассортимент.

Подобные проблемы можно предотвратить с помощью асинхронного обмена данными и разделения хранилищ для разных типов информации.

Новая схема интеграций была спроектирована в соответствии с этими принципами. Для каждой из систем определены домены — зоны её ответственности — и типы данных, источником которых она является.

Информация передаётся асинхронно: сначала — в слой хранилища, затем — в систему-получатель. Таким образом удалось избавиться от взаимной зависимости систем, входящих в IT-контур.

Проектируя новый IT-контур совместно с командой EKF, мы проговаривали, как именно будет организовано хранение данных, как будут разделены микросервисы и как будет выстроено их взаимодействие.

• С систем снята функция взаимной передачи данных (в том числе посреднической), как результат — многократно ускоряется выгрузка обновлений, сокращается лаг между обновлением информации в системе-источнике и её загрузкой в системы-потребители.
• Системы мониторинга и логирования, входящие в ESB, позволяют фиксировать возникающие инциденты (что и в какой момент случилось с данными) и оперативно сообщать об их появлении сотрудникам технической поддержки. Это обеспечивает возможность своевременной отработки обнаруживаемых неполадок.
• Загрузка и выгрузка данных происходит по триггерам или с установленной частотой (в зависимости от бизнес-процесса). Путь каждого сообщения отслеживается автоматически — информация не будет потеряна.

На этом же этапе команда консультантов:

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

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

Результат 4: предоставили сравнение четырёх ESB-решений, что позволило клиенту выбрать систему по ключевым для него параметрам

Команда KT.Team подготовила сравнительный анализ инструментов, с помощью которых можно настроить нужную клиенту интеграцию. На первом этапе сравнили четыре решения: DATAREON, Mule, Talend, WSO2 — по 50 ключевым параметрам, в числе которых: язык разработки адаптеров, наличие библиотеки готовых коннекторов, отказоустойчивость, поддержка разнообразных форматов и протоколов, распределение ролей и доступов, возможности масштабирования и т. д.

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

Результат 5: разделили процесс внедрения ESB-слоя на этапы с понятной длительностью и ценностью каждого из них

Команда KT.Team разработала дорожную карту внедрения ESB-слоя с указанием обоснованной длительности всех этапов в часах — для каждого коннектора и потока по отдельности. Внедрение разделили на несколько этапов, по итогам каждого из которых EKF получает понятную ценность и работающий IT-контур. При планировании этапов внедрения учитывали возможности внутренней команды EKF и оценивали бюджет на привлечение аутсорс-команд.

Этапы определены так, чтобы ввод каждого из них был безопасен для IT-контура компании и предыдущих внедрённых потоков.

Трудоёмкость каждого этапа указана в часах — EKF может сравнить эту оценку с предложениями других интеграторов и выбрать подходящего подрядчика.

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

Это позволило команде EKF определить необходимый бюджет и приоритеты выполнения дальнейших работ.

Итоги

• IT-специалисты EKF совместно с консультантами KT.Team перевели в формат сервисной карты понимание текущей архитектуры.
• Синхронизировано понимание команды о том, как и почему будет меняться архитектура интеграций.
• Команда знает, какими этапами будет внедряться ESB и какую ценность EKF получает на каждом из них.
• Команда EKF определила необходимый бюджет и приоритеты выполнения дальнейших работ.
• Внедрение ESB-слоя начато двумя командами: EKF и KT.Team.

‍