Сколько стоит внедрение ESB-слоя и как формируется стоимость владения ESB?

В предыдущих статьях о ESB-решениях эксперты KT.Team рассказали, для чего нужны такие решения (см. статью «Инструмент, который поможет сохранить молодость бизнеса→»), какие из них популярны на российском рынке (см. статью «Сравнение ESB-решений, популярных на российском рынке. Часть 2: особенности систем→») и какие этапы предстоит пройти при внедрении ESB (см. статью «От спагетти до гибкой архитектуры за 5 шагов: этапы внедрения ESB-слоя→». Допустим, вы уже определились, что внедрение сервисной шины станет лучшим решением ваших проблем. Следующий шаг — понять, каких усилий и ресурсов оно потребует.

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

Мы поможем разобраться с часто возникающими вопросами.

• Из каких шагов состоит внедрение ESB и сколько времени оно занимает?
• Из чего складывается стоимость внедрения ESB-решений и владения ими?
• Какие специалисты нужны для внедрения и поддержки ESB? Что обычно делают своими силами, а для чего чаще привлекают подрядчиков?
• Каковы наиболее распространённые ошибки при внедрении ESB и как их избежать?

Причины внедрения ESB

Как правило, компании приходят к внедрению middleware-слоя, поработав по одному из двух типичных сценариев.

Сценарий первый: IT-архитектура компании долгие годы разрасталась вокруг монолитной системы формата «всё в одном». В первые годы жизни компании она закрывала все потребности бизнеса в части IT-обеспечения, затем команда дописывала и дорабатывала её… пока в конце концов отказ от любой из частей этой системы не стал слишком сложным и дорогим. Но при этом IT-департамент (и другие подразделения компании) прекрасно понимает, что на рынке есть гораздо более гибкие, удобные и лёгкие в поддержке системы для конкретных бизнес-процессов компании. И сейчас перед вами стоит задача заменить тяжеловесный монолит на отдельные сервисы и микросервисы.

Сценарий второй: IT-архитектура уже состоит как минимум из десятка систем, объединённых интеграциями вида «точка – точка». Добавление в такой контур новых систем — дорого и долго, а поддержание работоспособности существующих интеграций — высокозатратно. При этом данные из старых систем выгружаются в сложных и неудобных форматах. Слой middleware вам нужен для того, чтобы распутать интеграции и сделать архитектуру более гибкой и лёгкой в поддержке и обновлении.

При этом в IT-департамент постоянно обращаются другие подразделения с регулярно повторяющимися проблемами и задачами:

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

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

Обо всём — по порядку. Для начала разберёмся с последовательностью действий при внедрении ESB-слоя.

Предпроектное обследование

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

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

Что касается практики KT.Team — в нашей компании предпроектная аналитика является отдельной услугой. Как правило, аналитический этап занимает от двух до четырёх недель (в зависимости от масштабов существующей IT-архитектуры, количества и сложности потоков данных) и обходится приблизительно в 1,4 млн руб.

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

Так, на проектах, сопоставимых по масштабам, внедрение middleware без предварительного аналитического этапа занимало 1200–1500 часов разработки, правок и доработок, а с предпроектным исследованием — 600 часов.

Этапы внедрения ESB

Мы выделяем пять этапов внедрения ESB в IT-архитектуру предприятия.

Подробнее об этих этапах и их длительности мы рассказываем в статье «От „спагетти“ до гибкой архитектуры за пять шагов: этапы внедрения ESB-слоя», здесь же опишем их вкратце.

Первый этап — выбор места хранения вашего ESB-слоя. Мы предлагаем приступить к этому этапу до выбора технологического стека, т. к. существующие правила и юридические требования могут ограничить вас в выборе основной системы и дополнительных компонентов. Так, например, make подойдёт, только если вы согласны работать через облако. А WSO2 может быть установлена и на выделенных серверах компании.

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

Третий этап — выбор стека компонентов ESB. Здесь вам предстоит выбрать (самостоятельно или с привлечением интегратора): хранилище сообщений (например, брокер сообщений или база данных); системы логирования и мониторинга; хостинг для развёртывания остальных компонентов — собственный или облачный (IaaS-провайдер).

Существуют специализированные SaaS-решения для построения ESB, которые предоставляют хостинг и стек готовых компонентов. Большинство таких SaaS — зарубежные.

Четвёртый этап — развёртывание и настройка компонентов ESB. Как правило, он длится около полутора месяцев до запуска MVP. Завершив развёртывание и конфигурирование компонентов, IT-команда начинает формировать первые потоки данных между приложениями. На этом этапе шина сосуществует с привычной архитектурой и интеграциями. Как правило, команда начинает с самого сложного потока и затем создаёт остальные на его основе.

Продолжительность и, соответственно, стоимость работ могут сильно варьироваться, но — по нашему опыту — в среднем проект внедрения ESB до уровня MVP обходится в 1,5–3 млн руб.

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

Стоимость внедрения и владения ESB

При внедрении и эксплуатации ESB неизбежно возникают следующие расходы.

• Приобретение лицензий для тех компонентов, которые не являются свободно распространяемым программным обеспечением. Так, например, ESB Mule является open-source-продуктом, но отдельные его компоненты (Anypoint ) доступны только в рамках платной годовой подписки.
• Организация IT-инфраструктуры: покупка и амортизация оборудования, аренда серверной стойки в дата-центре или приобретение серверов, IaaS, SaaS и т. д.

Стоимость владения лицензиями и содержания инфраструктуры на проекте среднего размера составляет 100–300 тыс. руб. в месяц.

Оптимальная команда для внедрения ESB

Если вы планируете внедрять ESB силами собственной команды, вам обязательно потребуются следующие специалисты:

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

Важный нюанс: команда должна быть знакома с low-code-подходом, а ещё лучше — непосредственно с ESB. Опыт создания правильных интеграций через middleware позволит избежать «ошибок новичков» и не допустить удорожания проекта.

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

Оптимальная команда для эксплуатации ESB

Для регулярной эксплуатации внедрённой шины требуется как минимум один специалист уровня citizen developer, которому поручаются следующие задачи:

• разбор инцидентов и решение возникающих проблем;
• внесение изменений в имеющиеся интеграции;
• создание новых потоков интеграций.

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

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

Кейсы внедрения ESB из опыта KT.Team

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

Кейс первый: российская компания в отрасли тяжёлого машиностроения

Размер компании: более 10 тыс. человек, свыше 10 производств.

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

Срок внедрения: два месяца от подписания контракта до запуска MVP.

Фазы внедрения:

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

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

Задействованные специалисты в штате подрядчика: проектный менеджер, техлид, разработчик ESB-интеграций.

Хостинг: собственные серверы (24-ядерный процессор, 30 Гбайт оперативной памяти, SSD-накопитель ёмкостью 480 Гбайт).

Технологический стек для имплементации ESB:

• коннекторы и визуальная среда разработки интеграций — WSO2;
• брокер сообщений — Apache Kafka;
• логирование и мониторинг — ELK Stack;
• дашборды и уведомления — Grafana.

Платные лицензии: не требуются, все компоненты относятся к категории свободного программного обеспечения.

Стоимость услуг интегратора: 3 млн руб. — пилотный проект.

Кейс второй: производство и продажа китайских товаров в России через собственную e-commerce-платформу, сетевой ретейл и маркетплейсы

Размер компании: более 300 человек.

Объём нагрузки: поддержка ERP для более чем 10 каналов продаж, 50 категорий и 300 подкатегорий товаров.

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

Срок внедрения: четыре месяца от подписания контракта до запуска проекта.

Фазы внедрения:

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

Задействованные специалисты в штате заказчика: руководитель проекта, ERP-программист.

Задействованные специалисты в штате подрядчика: проектный менеджер, техлид, разработчик ESB-интеграций.

Хостинг: предоставлен облачным провайдером.

Технологический стек для имплементации ESB:

• коннекторы и визуальная среда разработки интеграций — WSO2;
• брокер сообщений — RabbitMQ;
• логирование и мониторинг — ELK Stack;
• дашборды и уведомления — Grafana.

Платные лицензии: не требуются, все компоненты относятся к категории свободного программного обеспечения.

Стоимость услуг интегратора: 4,5 млн руб. — пилотный проект.

Стоимость инфраструктуры: 100 тыс. руб. в месяц.

Наиболее распространённые ошибки при внедрении ESB

Первая ошибка — осуществление интеграции приложений без подсистем логирования и мониторинга. В конечном счёте компания, внедрившая такой урезанный ESB-слой, будет узнавать об инцидентах реактивно. Представьте ситуацию: логисты должны отправить заказчику оплаченный товар, но не находят его на складе и сообщают о несоответствии фактических складских остатков данным в WMS.

Вторая часто совершаемая ошибка — реализация в ESB сложных механизмов интеграции. Возьмём в качестве примера онлайн-магазин. Для отправки карточки товара на маркетплейс требуются данные об остатках, цене и позиции, которые хранятся в трёх разных системах. Информация о складских остатках обновляется раз в 15 секунд (около 40 тыс. раз в неделю), о цене — раз в час (168 раз в неделю), о позиции — раз в неделю.

• Если при каждом изменении сведений в карточке товара запрос будет приходить во все три системы, возникнет избыточный обмен данными. В большинстве случаев меняются только остатки, что генерирует еженедельные по 40 тыс. обращений в каждую из трех систем, суммарно — 120 тыс. При этом PIM-система с информацией о товарах обрабатывает в 40 тыс. раз больше запросов, чем действительно необходимо!

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

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

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

Ещё один подводный камень, о который легко споткнуться при внедрении сервисной шины, связан с использованием SaaS с оплатой за запрос, взимающих оплату не за месяц, а за запрос. Нужно рассчитать будущие расходы исходя из предполагаемой нагрузки. С этим поможет выстроенная схема to-be-архитектуры, позволяющая оценить примерное число обращений к каждой из систем и приблизительное количество переданных пакетов информации. Если их оценочная стоимость уже сейчас превышает стоимость виртуальных серверов за ту же единицу времени — очевидно, что выбор следует сделать в пользу последних.