Сколько по времени занимает внедрение ESB, каковы выходы на каждом этапе?

К внедрению ESB-слоя компании походят с разным набором задач и разной проблематикой. Клиенты KT.Team, которые планируют внедрение ESB, чаще всего указывают такие причины:

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

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

Но, как писали Брайан Фут и Джозеф Йодер в статье Big ball of mud, «если вы считаете, что построить правильную архитектуру дорого, посчитайте, сколько вам стоит плохая архитектура».

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

Этапы внедрения ESB-шины и общая длительность проекта

Проект по внедрению ESB-шины можно разделить на три больших этапа:

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

Точно предсказать длительность проекта довольно сложно: она зависит от количества систем и потоков. В среднем без учета предпроектного периода внедрение ESB-слоя занимает полтора-два месяца до запуска MVP.

Откуда тогда берутся кейсы про полтора–два года (в лучшем случае)? Однозначного ответа нет. Иногда запуск MVP обновлённой архитектуры затягивается, потому что нужно связать десятки и сотни систем и выстроить тысячи коннекторов. Но чаще такой срок связан с тем, что пропущен этап предпроектного обследования. Как следствие, проект реализации не учитывает важных деталей по взаимосвязи систем, источникам и потокам данных, требованиям к пропускной способности middleware и т. д. Проектной команде приходится «на ходу» вносить изменения в проект, менять приоритеты, возвращаться к уже готовым потокам и переосмысливать их.

Почему так происходит? Чаще всего, причина в том, что в компании нет единого выстроенного центра знаний по всем процессам и взаимосвязям. Каждый из инженеров глубоко понимает свой участок: кластер систем и интеграций. Но полной картины нет ни у кого, потому что нет и потребности в ней.

Закрыть это слепое пятно позволяет предпроектный этап внедрения ESB-слоя.

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

Длительность: от 30 рабочих часов до 2–3 недель (в зависимости от количества систем и сложности проекта).

Результаты этапа:

Фиксация требований к новой архитектуре

Первая задача, которая стоит перед командой внедрения, — понять, с какой проблемой пришел клиент и какие требования к системе должны покрываться внедрением ESB. Само по себе внедрение никогда не является целью — только средством для решения проблем или бизнес-задач.

Например, стартап по автоматизации получения путевых листов для автопарков, обращаясь в KT.Team, хотел упростить будущее масштабирование и снизить количество ошибок при передаче данных. Рост количества партнёров приводил к перегруженности системы уже на первом десятке подключенных таксопарков, так как прямая интеграция занимала много памяти на серверах компании.

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

Проанализировав запросы клиента, команда KT.Team составила список требований к новому решению:

• опрос одного таксопарка должен требовать меньше памяти;
• добавление нового контрагента должно быть простым и быстрым;
• у контрагента не должно быть прямого доступа к серверу и базе данных клиента;
• данные нужно получать каждые 20 минут или чаще.

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

Аналитика существующей архитектуры

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

• команда и так знает, как всё работает, и
• разработать новую архитектуру важнее, чем разбираться в старой.

Это справедливо, но с некоторыми оговорками. Как правило, команда действительно знает, как взаимосвязаны системы и как работают действующие интеграции. Но — локально, то есть отдельные инженеры «до запятой» знают свой участок архитектуры и весьма туманно представляют себе остальные её части. Единого представления, скорее всего, нет нигде.

Чем это опасно? Велик риск перенести старые проблемы в новый ландшафт. А ведь основная задача внедрения ESB — не «внедрить», а «улучшить».

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

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

Фаза аналитики — одна из самых трудоемких и времязатратных в рамках предпроектного этапа внедрения. Но впоследствии она позволяет сэкономить в три-пять раз больше времени, чем на неё затрачено.

Выбор инструментов для реализации

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

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

Сетевая компания, специализирующаяся на распространении эко-продуктов, обратилась к команде KT.Team для внедрения ESB-слоя. Основными требованиями заказчика были: разгрузить систему-источник (CMS), устранить проблему дубликатов сообщений в системе, сделать систему более отказоустойчивой и обеспечить защиту от ошибок при доставке сообщений.

Перед стартом проекта мы провели аналитику и выбрали инструментарий для проекта:

• брокер сообщений Kafka
• Mule c возможностью кластеризации в качестве основы шины
• система логирования Elastiсsearch Logstash Grafana

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

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

Благодаря внесенным изменениям, проект решения стал более функциональным и смог покрыть все требования заказчика. Финальная конфигурация была согласована, и мы перешли на этап реализации.

Построение и согласование проекта архитектуры будущего решения

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

Чтобы минимизировать риск затягивания проекта, откатов и переделок, KT.Team разработала бизнес-процесс по подготовке к реализации интеграций:

• После получения требований заказчика и первичного анализа проекта, проектный менеджер и разработчик отрисовывают логику работы коннектора в виде BPMN-схемы.

• Следующий этап — брейншторм команды на предмет возможных путей оптимизации логики: сокращения издержек, ускорения разработки и упрощения реализации.
• Схема корректируется с учетом проверенных гипотез.
• Если работоспособность интеграции подтверждается, а дополнительные вводные отсутствуют, software-архитектор команды валидирует BPMN-схему.
• Логика решения обсуждается и согласовывается с заказчиком.
• Если проект архитектуры полностью согласован, команда приступает к разработке.

Этап разработки решения

Средняя длительность: около 40 часов одного разработчика на один поток. Общая длительность зависит от сложности и количества потоков, а также от количества разработчиков в команде внедрения.

Основные результаты этапа:

• Системы сконфигурированы, выстроен маппинг между взаимосвязанными сущностями

Конфигурирование промежуточного слоя часто требует большого объема работы по маппингу. Например, когда в системе-источнике 200 атрибутов, а в системе-приемнике — 100, часть из них составные, а некоторые берутся из другой системы-источника. Или системы содержат разные типы данных и разные поля. Всю логику надо выстроить и учесть, чтобы данные не терялись и попадали в системы-приемники в нужном объёме.

• Разработан самый сложный поток

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

Если команда пропустила или недостаточно проработала предпроектный этап, именно сейчас это начнет сказываться на скорости и качестве внедрения ESB.

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

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

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

Этап создания документации для поддержки решения

Средняя длительность: 25–30 часов (в зависимости от сложности проекта)

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

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

Подробно составленная документация позволяет команде заказчика самостоятельно настраивать новые интеграции и поддерживать старые, в том числе и усилиями citizen-developer’ов — опытных пользователей, которые не являются разработчиками.

Резюме

• В среднем, внедрение ESB-слоя занимает около 1,5-2 месяцев до запуска MVP без учета предпроектного этапа. Однако на практике длительность сильно отличается на разных проектах и зависит от сложности текущей и планируемой архитектуры решения, появления в ходе реализации новых вводных или требований заказчика, количества специалистов в команде внедрения.
• Обычно самыми времязатратными этапами являются предпроектный этап (аналитика и проектирование архитектуры будущего решения) и разработка самого сложного потока.
• От глубины проработки предпроектного этапа в больше степени зависят скорость, эффективность реализации проекта, корректность подбора инструментов.
• Установленный бизнес-процесс для интеграций со стороны команды внедрения поможет увидеть «узкие места» решения еще до начала разработки и избежать откатов и затягивания сроков.

‍