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

4.7.2023

Содержание

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

К внедрению 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 без учета предпроектного этапа. Однако на практике длительность сильно отличается на разных проектах и зависит от сложности текущей и планируемой архитектуры решения, появления в ходе реализации новых вводных или требований заказчика, количества специалистов в команде внедрения.
  • Обычно самыми времязатратными этапами являются предпроектный этап (аналитика и проектирование архитектуры будущего решения) и разработка самого сложного потока.
  • От глубины проработки предпроектного этапа в больше степени зависят скорость, эффективность реализации проекта, корректность подбора инструментов.
  • Установленный бизнес-процесс для интеграций со стороны команды внедрения поможет увидеть «узкие места» решения еще до начала разработки и избежать откатов и затягивания сроков.

Другие статьи

Смотреть все

Как PIM-система помогает развивать продажи фармкомпаниям

Подробнее

Почему работающая микросервисная архитектура начинается с порядка в бизнес-процессах

Подробнее

Сервисная шина как эволюционное преимущество для развития компании

Подробнее

Смотреть все

Мы используем файлы cookie, чтобы предоставить наилучшие возможности сайта

Ок

Ваша заявка отправлена успешно

Отправить снова

Давайте обсудим ваш проект

С вами свяжутся персональные менеджеры

Форма для связи

Что-то пошло не так! Пожалуйста, попробуйте еще раз.
Ваша заявка отправлена успешно!

Отправить снова

Что-то пошло не так! Пожалуйста, попробуйте еще раз.

Контакты

+7 917 125-96-34

Whats App:

@kt_team_it

Telegram:

+7 495 204-14-33

Телефон:

Назначить встречу

Забронировать время встречи с помощью Google Calendar

Нужна консультация по ESB