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