Про интеграции. Часть 1. Интеграционные подходы
Интеграционные подходы
Динамика развития межсистемных интеграций в крупных компаниях в чём-то повторяет известный закона Мура, примерно каждые 1.5–2 года в них происходит, по меньшей мере, двукратное увеличение межсистемных интеграций. По большей части это эмпирическое наблюдение, но внутренние статистики пары крупных компаний его подтверждают. Причины этого разнообразны, где-то произошла декомпозиция уже работающих ИТ-систем, где-то изменились бизнес-процессы и выяснилось, что их можно более полно автоматизировать, таким образом родились новые ИТ-решения. Список причин возникновения новых интеграций большой и для любой крупной компании, вопрос контроля интеграций, централизованных инструментов, паттернов и подходов по их реализации становится всё более актуальным.
Целью серии текстовя вижу попытку структуризации известной мне информации в области межсистемных интеграций, их проектирования, сопровождения, паттернов и подходов. Я постараюсь изложить своё видение данного процесса. По возможности я буду ссылаться на другие статьи и книги по данной теме. В конце статьи приведу набор ссылок на работы других авторов, которые, на мой взгляд, дополняют содержание статьи. Текст по больше части ориентирован на архитекторов и аналитиков, однако и другим специалистам, работающим в IT-сфере, может оказаться полезным. Также буду благодарен любому читателю и особенно его комментариям к моему тексту.
Для начала введём несколько понятий, они нам пригодятся в дальнейшем, хотя и могут встречаться, в зависимости от контекста, в немного в разных формулировках.
ИТ-Решение (Бизнес-Решение) — это комплекс аппаратно-технических, программных и организационных средств, реализующий или поддерживающий работу конкретного бизнес-процесса.
Например, у нас есть сеть магазинов питания, куда необходимо доставлять продукты на продажу, вопрос логистики не прост и содержит в себе перечень проблем, от оптимизации маршрута доставки продуктов, до учёта погруженных-доставленных товаров. Схема решения всех этих проблем может быть как отдельными бизнес-процессами, так и представлена в виде одного общего бизнес процесса. Зависеть это будет от организационной структуры компании. Объём работ включенных в ИТ-решение тоже может быть разный, он может включать в себя как какую-то отдельную проблему, так и всю проблематику конкретного бизнес процесса. На мой взгляд такая структура напрямую связана с законом Конвея, ведь работу по конкретным процессам очень удобно разбивать по отдельным организационным группам, которые и будут сопровождать бизнес процессы. Я сознательно делаю фокус на людях и процессах, потому что ИТ-решение подчистую не сопряжено с разработкой нового софта, основа — это закрытие потребностей некоторого бизнес процесса. К примеру, учёт тех же товаров можно вести посредством excel, и это тоже будет ИТ-решением (причем возможно вполне эффективным для небольшого бизнеса). У нас даже будет полный комплекс составляющих: процесс (учёт товаров), люди (кладовщики, сметчики, погрузчики), данные (ведомости, перечень товаров, накладные и т.п.), ПО (excel), инфраструктура (связанные в простую сетевую топологию складские ПК) и т.д.
ИТ-Система — составляющая ИТ‑решения, я бы сказал, что это ИТ‑решение без слоя бизнеса, она включает кодовую базу проекта, артефакты в nexus‑е, пайплайны сборки, скрипты, конфиги, данные СУБД, бэкапы, характеристики серверов и т. п. Иными словами всё, что нужно для корректной работы информационной части системы, но исключая орг. структуру вокруг системы (далее, ИТ‑система иногда будет идти под названием информационной системы).
Интеграция — Я дам более точную формулировку ближе к концу статьи, пока ограничимся простой, а уже дальше попробуем её переформулировать. Итак, интеграция — это процесс объединения нескольких ИТ‑систем в единый механизм для достижения общей цели. Почему так? Всё дело в том, что понятие достаточно широкое и интеграции можно определять по разному:
Интеграции между процессами: например A2A или B2B;
Интеграции данных: например репликации и миграции данных;
Пользовательские интеграции: например UI-интеграции;
Физические интеграции: например реализация какой-то сетевой топологии;
В зависимости от зрелости компании, подход к интеграциям также будет различаться, давайте рассмотрим основные этапы развития подходов к интеграциям:
Ad‑hoc (от случая к случаю) — нет какого‑то системного подхода к проведению интеграций, процесс выглядит достаточно сумбурно, его либо нет вообще, либо хоть и присутствуют компетентные люди, но нет методологии проведения интеграций, исполнители выбираются случайно, результат плохо прогнозируем и вероятно сильное дублирование работы.
На уровне разработчиков (прозрачная интеграция) — бизнес или его представители могут выявить потребность в интеграции, но не могут договориться об ответственности за её реализацию, а практики проведения интеграции зафиксированы словесно или в лучшем случае имеются инструменты для интеграции в рамках организационных доменов. Пользователи системы помогают с выявлением потребности в интеграции, тут уже можно прогнозировать затраты и усилия.
Системный подход — интеграционная архитектура признается отдельной и важной дисциплиной в рамках компании, также наличествует центр компетенций по проведению интеграций к которому можно обратиться с запросом ресурса, за счёт чего в компании имеются эксперты по интеграциям, выделенные для конкретного направления, внедряются и развиваются передовые практики по управлению интеграциями, которые позволяют экономить ресурсы при их реализации. Однако я встречал и определенную критику такого подхода + на мой взгляд, возникают проблемы с наличием такого рода специалистов на рынке. Как мне видится, компромиссным решением этой проблемы, может быть развитие архитектурной функции в целом, на которую и будет возложен контроль в проектах за соблюдением соглашений по интеграциям. В любом случае, для этой стадии развития характерно, что есть конкретные правила организации интеграционного процесса, перечень необходимых артефактов и соблюдение определенных требований, которое проверяется и регулируется за счёт конкретных людей.
Адаптируемый — интеграции воспринимаются как элемент по цифровизации бизнес процессов, есть стратегическое планирование и отдельный орган (например, интеграционный комитет) для формализации требований к интеграциям, наличие этого органа позволяет проводить планирование межсистемных интеграций в определённом горизонте и контролировать требования к ним. Любая команда может выдвинуть свои предложения и защитить их перед интеграционным комитетом. За счёт этого происходит минимизация затрат и усилий на будущую проработку интеграций. Хотя в моменте мы конечно тратим ресурсы на предварительную проработку.
Как оценить на каком уровне находится развитие подходов к интеграциям в вашей компании? Предлагаю следующий чек‑лист для оценки:
Оцените среднее время на реализацию типового интеграционного сценария;
Какое число повторно используемых интерфейсов и контрактов на систему;
Сколько нарушений стандартов и политик по интеграциям (например, в вашей компании все системы такого типа должны интегрировать посредством некоторой шины данных, но при этом есть системы, которые используют прямые интеграции);
Количество специально создаваемых сервисов для реализации интеграций;
Цикломатическая сложность системы до и после проведения интеграции;
Наличие канонического формата для обмена сообщениями;
Наличие стандартных платформ для интеграций в компании и отношение количества интеграций через них к интеграциям без них;
Наличие мониторинга на интеграции;
Отношение реализованных интеграций к числу формализованных потребностей в интеграциях;
Возможность автоматического подключения технических систем посредством конвейера сборки;
Если у вас имеются проблемы с 8 и более пунктами, то вероятно ваша компания находится ещё на ранней стадии развития интеграционных подходов и изложенное далее может оказаться для вас полезным. Все рекомендации являются попыткой улучшить показатели из этого чек-листа.
Жизненный цикл
Введем понятие жизненного цикла. Давайте предположим, что мы занялись проработкой некоторой межсистемной интеграции и у нас нет представления о том с чего начать.
Мы начнём с жизненного цикла (ЖЦ) интеграции, как он выглядит?:
Выявление бизнес потребности к интеграции;
Определение шагов процесса для интеграции;
Фиксация интеграции с представителями других ит-систем;
Проработка моделей, интеграционных интерфейсов и сценариев интеграций;
Планирование работ;
Реализация решения;
Тестирование и дальнейший аудит интеграции;
Эксплуатация;
Отражение фактических настроек в документации/системе моделирования/архитектурном репозитории;
Схема ЖЦ Интеграции по ролям
Это ЖЦ интеграции в вакууме, понятно, что скорее всего в небольших компаниях нет ресурсов для создания и поддержания зрелых подходов к интеграциям, их также может не быть если компания сфокусирована на разработке одного моно-продукта, в рамках работы над которым нет необходимости в реализации новых интеграций, по крайней мере в обозримом будущем. Набор ролей может отличаться, а оказание сервиса и проектирование архитектуры системы могут выполнять разработчики. Но общие принципы и набор действий будет стремиться к этому циклу, следование такой очередности помогает выявить проблемы на ранних этапах проработки. Отмечу, что я не призываю использовать каскадный подход в проработке интеграций, это вполне может быть реализовано в гибкой методологии.
Введём ещё пару терминов:
Шаблон — это класс интеграции, в книге Enterprise Integration Patterns упоминаются 4 основных шаблона по типу обмена данными: файловый, посредством бд, очереди сообщений и удаленный вызов. Однако можно рассматривать шаблон и более широко, как структурно — интеграция точка‑точка/звезда и т. п. или по ключевому для интеграции методу data‑centric, functional‑centric и т. д.).
Интеграционный Контракт — это экземпляр класса интеграции (конкретный вид интеграции);
Интеграция — использование экземпляра класса для решения бизнес задач (имплементация на реальную интеграцию);
Инструменты интеграций — это готовые шаблоны для реализации интеграционных контрактов как технические, так и аналитические.
Что включает в себя интеграционный контракт?
Данные о процессе, для которого выполняется интеграция;
Состав передаваемых данных;
Протокол взаимодействия;
Требуемый режим передачи (мгновенно, ежесуточно, раз в месяц и т.п.);
Список людей, кого информировать об ошибках;
Сервисную команду (кто будет обслуживать интеграцию, в случае ошибок);
Инициатора интеграции;
В качестве одного из основных требований к разработке интеграции в компании, я предлагаю ведение какой-нибудь интеграционной базы со сквозными идентификаторами интеграционных контрактов, если этого не сделать, то спустя некоторое время вы не сможете разобраться, какие, в принципе, в вашей компании есть интеграции, потому что они будут только в сообщающихся сосудах головного мозга наиболее старых участников интеграционных процессов. Что очень не надёжно.
Рассмотрим различные классы шаблонов интеграций для ИТ-систем.
Взгляд ИТ-специалиста на шаблоны интеграций
Каковы их плюсы и минусы?
Интеграция данных:
(+): многообразие средств для контроля, богатый набор средств разработки и внедрения, хорош для огромных объёмов данных;
(-): Отчужден от слоя бизнес-логики, трудно отслеживать жизненный цикл отдельных интеграций и переиспользовать их, возможна рассинхронизация, недоступность и блокировка данных.
Интеграция приложений:
(+): многообразие решений, технологий, языков программирования. Богатый набор средств разработки и возможность реализации качественной архитектуры взаимодействия интегрируемых решений;
(-): тяготение к интеграциям по типу point-to-point, проблемы с переиспользованием и масштабированием, ориентирование разработчиков на формат работы с отдельными сообщениями;
Событийная интеграция:
(+): производительность, стриминговый подход, низкая связность между подписчиками и отправителями, хорошо применим в сфере телекоммуникаций и IoT;
(-): некосистентность данных, потери событий, отсутствие бизнес-контекста, подчастую — низкая зрелость решений, низкая надёжность в части ИБ.
Какие вопросы стоит задавать, чтобы выбрать конкретный шаблон?
Каково назначение интеграции: Это реализация взаимодействия систем по событию? Будет ли поддержка транзакционности? Участвует ли в процессе пользователь? Мы реализуем распределенный бизнес процесс или нет? Будет ли репликация данных? А миграция данных? Как осуществляется первоначальная загрузка данных? Система передаёт данные в режиме реального времени? Или по расписанию? Мы передаём большие объёмы данных? Интегрируемые системы находятся в диалоге?
Определяем итерфейсы: Сообщения небольших объёмов? На сколько сложная интеграционная логика? Требуется ли преобразование протоколов? Нужно ли обогащать или выкусывать данные? Нужно ли трансформировать структуру данных?
Какой транспорт планируем использовать: данные идут поверх транспортного уровня (сразу поверх TCP/IP или UDP) или поверх прикладного (HTTP, FTP, SMTP)?
Каковы гарантии доставки: Синхронно? Асинхронно? Гарантируем доставку сообщения? Допускаем ли дублирование? Это лонг-пулинг соединение?
Сроки и трудозатраты: На сколько сжатые сроки? На сколько ограничен бюджет? Возможно ли вносить изменения в системы отправителя и/или в систему получателя? На сколько типизирован поток данных?
ИБ: Как системы авторизуют друг друга? К взаимодействую систем имеется доступ третьей стороны?
Мы рассмотрели основные подходы к интеграциям, обозначили круг проблем, с которыми встречаются компании и наметили пути к их решению.
В следующих статьях рассмотрим интеграционные контракты, поговорим про инструменты интеграций, затронем протоколы взаимодействия, обсудим артефакты на этапе проработки архитектуры.
Ссылки для дополнительного ознакомления:
Типы интеграции — какие они бывают?;
Типы системной интеграции;
А вдруг кто не знал… Синхронный или асинхронный обмен;
Зачем нужны очереди сообщений в микросервисной архитектуре: разбираем преимущества и недостатки;
Сценарии интеграции приложений — у автора целый цикл статей по данной теме;
Интегрируй это — набор заметок про интеграции;
Хоп, Вульф: Шаблоны интеграции корпоративных приложений. Проектирование, создание и развертывание решений — основополагающая работа по данной теме.
