Интеграционные подходы

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

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

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

ИТ-Решение (Бизнес-Решение) - это комплекс аппаратно-технических, программных и организационных средств, реализующий или поддерживающий работу конкретного бизнес-процесса.

Например, у нас есть сеть магазинов питания, куда необходимо доставлять продукты на продажу, вопрос логистики не прост и содержит в себе перечень проблем, от оптимизации маршрута доставки продуктов, до учёта погруженных-доставленных товаров. Схема решения всех этих проблем может быть как отдельными бизнес-процессами, так и представлена в виде одного общего бизнес процесса. Зависеть это будет от организационной структуры компании. Объём работ включенных в ИТ-решение тоже может быть разный, он может включать в себя как какую-то отдельную проблему, так и всю проблематику конкретного бизнес процесса. На мой взгляд такая структура напрямую связана с законом Конвея, ведь работу по конкретным процессам очень удобно разбивать по отдельным организационным группам, которые и будут сопровождать бизнес процессы. Я сознательно делаю фокус на людях и процессах, потому что ИТ-решение подчистую не сопряжено с разработкой нового софта, основа - это закрытие потребностей некоторого бизнес процесса. К примеру, учёт тех же товаров можно вести посредством excel, и это тоже будет ИТ-решением (причем возможно вполне эффективным для небольшого бизнеса). У нас даже будет полный комплекс составляющих: процесс (учёт товаров), люди (кладовщики, сметчики, погрузчики), данные (ведомости, перечень товаров, накладные и т.п.), ПО (excel), инфраструктура(связанные в простую сетевую топологию складские ПК) и т.д.

ИТ-Система — составляющая ИТ‑решения, я бы сказал, что это ИТ‑решение без слоя бизнеса, она включает кодовую базу проекта, артефакты в nexus‑е, пайплайны сборки, скрипты, конфиги, данные СУБД, бэкапы, характеристики серверов и т. п. Иными словами всё, что нужно для корректной работы информационной части системы, но исключая орг. структуру вокруг системы (далее, ИТ‑система иногда будет идти под названием информационной системы).

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

• Интеграции между процессами: например A2A или B2B;

• Интеграции данных: например репликации и миграции данных;

• Пользовательские интеграции: например UI-интеграции;

• Физические интеграции: например реализация какой-то сетевой топологии;

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

1. Ad‑hoc (от случая к случаю) — нет какого‑то системного подхода к проведению интеграций, процесс выглядит достаточно сумбурно, его либо нет вообще, либо хоть и присутствуют компетентные люди, но нет методологии проведения интеграций, исполнители выбираются случайно, результат плохо прогнозируем и вероятно сильное дублирование работы.

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

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

4. Адаптируемый — интеграции воспринимаются как элемент по цифровизации бизнес процессов, есть стратегическое планирование и отдельный орган (например, интеграционный комитет) для формализации требований к интеграциям, наличие этого органа позволяет проводить планирование межсистемных интеграций в определённом горизонте и контролировать требования к ним. Любая команда может выдвинуть свои предложения и защитить их перед интеграционным комитетом. За счёт этого происходит минимизация затрат и усилий на будущую проработку интеграций. Хотя в моменте мы конечно тратим ресурсы на предварительную проработку.

Как оценить на каком уровне находится развитие подходов к интеграциям в вашей компании? Предлагаю следующий чек‑лист для оценки:

1. Оцените среднее время на реализацию типового интеграционного сценария;

2. Какое число повторно используемых интерфейсов и контрактов на систему;

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

4. Количество специально создаваемых сервисов для реализации интеграций;

5. Цикломатическая сложность системы до и после проведения интеграции;

6. Наличие канонического формата для обмена сообщениями;

7. Наличие стандартных платформ для интеграций в компании и отношение количества интеграций через них к интеграциям без них;

8. Наличие мониторинга на интеграции;

9. Отношение реализованных интеграций к числу формализованных потребностей в интеграциях;

10. Возможность автоматического подключения технических систем посредством конвейера сборки;

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

Жизненный цикл

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

Мы начнём с жизненного цикла (ЖЦ) интеграции, как он выглядит?:

1. Выявление бизнес потребности к интеграции;

2. Определение шагов процесса для интеграции;

3. Фиксация интеграции с представителями других ит-систем;

4. Проработка моделей, интеграционных интерфейсов и сценариев интеграций;

5. Планирование работ;

6. Реализация решения;

7. Тестирование и дальнейший аудит интеграции;

8. Эксплуатация;

9. Отражение фактических настроек в документации/системе моделирования/архитектурном репозитории;

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

Введём ещё пару терминов:

• Шаблон — это класс интеграции, в книге Enterprise Integration Patterns упоминаются 4 основных шаблона по типу обмена данными: файловый, посредством бд, очереди сообщений и удаленный вызов. Однако можно рассматривать шаблон и более широко, как структурно — интеграция точка‑точка/звезда и т. п. или по ключевому для интеграции методу data‑centric, functional‑centric и т. д.).

• Интеграционный Контракт — это экземпляр класса интеграции (конкретный вид интеграции);

• Интеграция — использование экземпляра класса для решения бизнес задач (имплементация на реальную интеграцию);

• Инструменты интеграций — это готовые шаблоны для реализации интеграционных контрактов как технические, так и аналитические.

Что включает в себя интеграционный контракт?

• Данные о процессе, для которого выполняется интеграция;

• Состав передаваемых данных;

• Протокол взаимодействия;

• Требуемый режим передачи (мгновенно, ежесуточно, раз в месяц и т.п.);

• Список людей, кого информировать об ошибках;

• Сервисную команду (кто будет обслуживать интеграцию, в случае ошибок);

• Инициатора интеграции;

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

Рассмотрим различные классы шаблонов интеграций для ИТ-систем.

Каковы их плюсы и минусы?

Интеграция данных:

(+): многообразие средств для контроля, богатый набор средств разработки и внедрения, хорош для огромных объёмов данных;

(-): Отчужден от слоя бизнес-логики, трудно отслеживать жизненный цикл отдельных интеграций и переиспользовать их, возможна рассинхронизация, недоступность и блокировка данных.

Интеграция приложений:

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

(-): тяготение к интеграциям по типу point-to-point, проблемы с переиспользованием и масштабированием, ориентирование разработчиков на формат работы с отдельными сообщениями;

Событийная интеграция:

(+): производительность, стриминговый подход, низкая связность между подписчиками и отправителями, хорошо применим в сфере телекоммуникаций и IoT;

(-): некосистентность данных, потери событий, отсутствие бизнес-контекста, подчастую - низкая зрелость решений, низкая надёжность в части ИБ.

Какие вопросы стоит задавать, чтобы выбрать конкретный шаблон?

Каково назначение интеграции: Это реализация взаимодействия систем по событию? Будет ли поддержка транзакционности? Участвует ли в процессе пользователь? Мы реализуем распределенный бизнес процесс или нет? Будет ли репликация данных? А миграция данных? Как осуществляется первоначальная загрузка данных? Система передаёт данные в режиме реального времени? Или по расписанию? Мы передаём большие объёмы данных? Интегрируемые системы находятся в диалоге?

Определяем итерфейсы: Сообщения небольших объёмов? На сколько сложная интеграционная логика? Требуется ли преобразование протоколов? Нужно ли обогащать или выкусывать данные? Нужно ли трансформировать структуру данных?

Какой транспорт планируем использовать: данные идут поверх транспортного уровня (сразу поверх TCP/IP или UDP) или поверх прикладного (HTTP, FTP, SMTP)?

Каковы гарантии доставки: Синхронно? Асинхронно? Гарантируем доставку сообщения? Допускаем ли дублирование? Это лонг-пулинг соединение?

Сроки и трудозатраты: На сколько сжатые сроки? На сколько ограничен бюджет? Возможно ли вносить изменения в системы отправителя и/или в систему получателя? На сколько типизирован поток данных?

ИБ: Как системы авторизуют друг друга? К взаимодействую систем имеется доступ третьей стороны?

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

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

Ссылки для дополнительного ознакомления:

1. Типы интеграции — какие они бывают?;

2. Типы системной интеграции;

3. А вдруг кто не знал... Синхронный или асинхронный обмен;

4. Зачем нужны очереди сообщений в микросервисной архитектуре: разбираем преимущества и недостатки;

5. Сценарии интеграции приложений — у автора целый цикл статей по данной теме;

6. Интегрируй это  — набор заметок про интеграции;

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