От «спагетти» до гибкой архитектуры за 5 шагов: этапы внедрения ESB-слоя

Расскажем о том, какие этапы предстоит пройти компании, чтобы заменить прямые интеграции типа «точка - точка» интеграциями через ESB -слой. ESB для прозрачных и легко поддерживаемых интеграций

Пять этапов разработки и внедрения ESB -слоя

Сколько времени потребуется на разработку?

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

Поэтому к моменту, когда вместо двух «1С» для бухгалтерии и управления складом в неё входит уже 30-40 систем, IT-команде приходится работать с исторически сложившейся архитектурой формата «звезда», который также - и неслучайно - называют «спагетти». В этой статье эксперты KT.Team рассказывают, какие этапы предстоит пройти компании, чтобы заменить прямые интеграции типа «точка - точка» интеграциями через ESB -слой.

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

Фактически ESB берёт на себя роль тех же прямых интеграций.

Но интеграции типа «точка - точка» подразумевают, что CRM может отдавать одну и ту же информацию о клиентах 10, 20, 40 раз - если это предусмотрено, соответственно, в 10, 20 или 40 интеграциях. ESB забирает информацию один раз и раздаёт её системам-получателям столько раз, сколько необходимо.

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

Одно из преимуществ современных ESB -систем - простота на всех этапах.

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

Овладеть им может не только разработчик, но и достаточно продвинутый пользователь, или citizen developer.

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

На первый взгляд - довольно привлекательно.

Но коллеги - IT-специалисты возразят, что для внедрения ESB придётся перекроить всю архитектуру.

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

Говоря о пяти этапах, мы немного «умалчиваем».

Цифра пять относится непосредственно к числу этапов внедрения ESB -слоя.

Но им предшествует важный и ёмкий этап проектирования решения и интеграций.

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

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

Можно разбираться с этим этапом как самостоятельно, так и пригласив IT-консультанта, чтобы получить «взгляд извне».

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

Тогда выводы и предложения консультанта будут более практичными.

Предлагаем начать с этого этапа до выбора само́й системы. Почему?

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

Планируется ли в ближайшие три года кратное масштабирование компании или IT-архитектуры?

Собственный сервер даёт больше свободы в этом вопросе.

Важна ли для вас максимально быстрая настройка ESB ? У облачного варианта скорость развёртывания и настройки выше.

Насколько высоки требования к безопасности данных?

Сервер защищён от атак и потерь лучше.

Является ли стоимость хранилища важным ограничением?

Собственные серверы - более дорогой вариант.

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

Почти все они обладают графическим интерфейсом и построены в парадигме low- или no-code.

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

Если ваша архитектура предполагает, что какое-то действие повторяется во многих интеграциях (например, преобразование данных из формата № 1 в формат № 2), лучше выбрать систему с возможностью создания и переиспользования подпрограмм.

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

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

Если у вас есть ограничение на использование только отечественного ПО, вышеперечисленные продукты вам не подойдут.

Лучше обратить внимание на российский Datareon .

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

На «нулевом» этапе вы разбирали, как потоки данных выглядели в старой IT-архитектуре (модель as is), а сейчас вашей команде предстоит настроить новую архитектуру (модель to be).

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

Даже в практике В low-code-инструменте разработчики по-прежнему писали интеграции кодом вместо того, чтобы использовать средства графической среды.

Поэтому опыт работы с low-code (а лучше - опыт правильного построения интеграций) станет для команды внедрения плюсом.

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

Это как минимум сбережёт ваше время, которое при иных обстоятельствах ушло бы на знакомство с системой и обучение команды, и позволит избежать «ошибок новичков».

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

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