Данная статья посвящена в первую очередь начинающим ИТ аналитикам, которые хотят верхнеуровнево разобраться, как необходимо описывать интеграции между системами и как процесс выглядит в целом. Просьба учесть, что часть терминов написана своими словами и намерено упрощена для лучшего понимания. Я думаю, что статья может быть также полезна менеджерам проектов, ИТ-лидам, менеджерам процессов и разным другим менеджерам, работающим в ИТ.
Перед тем, как рассказать, как могут выглядеть требования к интеграции, я бы хотел обратить внимание, что эта самая интеграция должна быть представлена на общей Корпоративной Архитектуре. Процесс управления изменениями и обновление архитектурных артефактов может отличаться в разных компаниях, поэтому бывает, что архитектурная служба (и\или служба интеграции) даже не знает о планируемом новом потоке между двух приложений, поэтому я рекомендую аналитику в первую очередь убедится, что поток присутствует на общей корпоративной архитектуре и о нём знают соответствующие подразделения.
Шаг 1. Спроектировать интеграционный поток (сделать архитектуру интеграций)
Обычно проектирование интеграционных потоков – это не работала аналитика, этим скорее занимает корпоративный архитектор (или бизнес-архитектор), но это точно важная часть общего процесса, которую следует понимать. Во многих компаниях аналитики с более высокими грейдами, как минимум участвуют в разработке корпоративной архитектуры.
Первым делом предлагаю пройти базовую теорию и выделить 2 вида интеграционного обмена данными между приложениями:
Синхронный обмен – это когда одно приложение направляет сообщение в другое приложение и ожидает ответ, продолжает работать только после получения ответа.
Асинхронный – это когда одно приложение направляет сообщение в другое приложение и не ожидает ответа, а продолжает работать.
Тут важно отметить, что на текущий момент чисто синхронные и чисто асинхронные интеграции встречаются достаточно редко и в требованиях к интеграции уже даже не пишут, что это за вид обмена, но очень важно понимать различия.
Вторым делом важно различать разные типы интеграций с точки зрения технологии и протоколов обмена (паттерны интеграции по типу обмена данными), например:
Файловый обмен - системы обмениваются между собой файлами, которые имеют определённую структуру.
Удалённый вызов - паттерн, который в своей основе использует технологии по удалённому вызову функций и процедур другого приложения (примеры технологий - gRPC, SOAP. Пример архитектурной стиля - REST)
Всего есть четыре основных паттерна - общая база данных, файловый обмен, вызов удаленной процедуры и обмен сообщениями, но я не планировал останавливаться подробно на каждой из них, наверное это задача отдельной статьи.
Зачастую, отражение интеграционных потоков происходит уже в рамках бизнес-архитектуры, но важно понимать, что бизнес архитектуру очень часто путают с корпоративной архитектурой предприятия. Давайте разберёмся.
Бизнес-архитектура - это общая, целостная модель работы предприятия (компании), которая объединяет в себя операционные процессы, стратегию развитию, и информационные технологии, человеческие ресурсы и другие аспекты, влияющие на бизнес.
Таким образом, бизнес-архитектура (business architecture, BA) нацелена на отражение модели бизнеса т.е. тех процессов и инструментов с помощью которых бизнес существует на рынке. В бизнес-архитектуре зачастую отражают ИТ решения, как имеющийся финансовый актив, а не с точки зрения технической реализации.
Корпоративная архитектура (Enterprise architecture, EA) - нацелена на стандартизацию и организации Информационных Технологий компании в соответствии с её бизнес-целями с учётом постоянной Цифровой трансформации, а также управлением ИТ-ресурсами.
Самой удобной нотацией (методологией) для моделирования бизнес-архитектуры и корпоративной архитектуры является ArchiMate .
![Картинка № 1 - Обзор нотации ArchiMate Картинка № 1 - Обзор нотации ArchiMate](https://habrastorage.org/getpro/habr/upload_files/1ce/1ff/ffa/1ce1ffffa441d46ad2c6020cdc45b98e.png)
Просьба обратить внимание, что в ней есть элементы «Бизнес», «Стратегия», «Мотивация», которые предназначены для описания именно бизнес-модели компании.
В моём опыте, я не встречал, чтобы для описания бизнес-архитектуры использовалась отдельная специализированная нотация. Чаще всего всё делается в рамках общей Корпоративной Архитектуры.
У Корпоративной архитектуры есть 2 основных жизненных этапа:
Целевая Корпоративная архитектура (та архитектура, которую планируется реализовать и внедрить).
Текущая Корпоративная архитектура (которая существует на текущий момент).
Важно учесть, что интеграционные потоки, которые отражены в целевой КА могут быть концептуальными и соответственно меняться.
Итак, в этом шаге мы разобрались, что интеграции начинаются с проектирования корпоративной архитектуры, которая в свою очередь учитывает бизнес модель компании. На КА представлено влияние бизнеса на системы и их взаимное использование друг другом (т.е. связи между системами – интеграции).
Шаг 2. Архитектура решения и разработка диаграммы компонентов (UML)
Когда вы убедились, что необходимый интеграционный поток есть на корпоративной архитектуре его требуется перенести в целевую архитектуру самого программного продукта. Для этих целей я предпочитаю использовать UML - диаграмму компонентов.
![Картинка № 2 - концептуальный пример диаграммы компонентов Картинка № 2 - концептуальный пример диаграммы компонентов](https://habrastorage.org/getpro/habr/upload_files/2e4/502/83d/2e450283dfb1d25c1d12acb7012a8e96.jpg)
Диаграмма компонентов нужна в первую очередь для того, чтобы показать из каких частей состоит программный продукт и как именно это части взаимодействуют между друг другом. В своей работе я предпочитаю использовать продуктовый подход, поэтому и разработка диаграмм осуществляется в рамках продукта, а не отдельно взятой системы. Продукт может состоять из нескольких систем и сервисов, нет смысла для каждого отдельного сервиса готовить отдельную диаграмму компонентов, особенно если этих компонентов не много (например, само приложение и база данных).
В рамках данного шага я хотел показать, что после разработки Корпоративной Архитектуры необходимо спустится на уровень ниже и продумать какие именно данные будут передаваться из одного компонента в другой, а также утвердить технологию.
Отдельно важно отметить, что на данном этапе уже должно быть принято решение о том, какую именно технологию необходимо использовать для интеграции т.е. какой способ реализации будет выбран. Это задача Архитектора решения совместно с Корпоративным Архитектором. Обычно общие требования к технологическому стеку спускает Корпоративный Архитектор, процесс принятия решений зависит от процессов компании.
Шаг 3. Разработка требований к самой интеграции
На текущем этапе у аналитика уже должно быть понимания какой тип интеграции необходимо использовать и какой протокол обмена данными. Всю эту информацию необходимо отразить в общих требованиях к интеграции, которые могут выглядеть следующим образом:
Общие требования к интеграции:
Тип взаимодействия и протокол. Например, файловый обмен по FTP (FTPS) или удалённый вызов через протокол HTTP.
Описание взаимодействующих систем, назначение интеграции. В данном разделе необходимо описать общее назначение двух систем, которые требуется интегрировать и назначение самой интеграции. Какую бизнес-цель данная интеграция преследует, для чего она нужна и какой результат позволит достичь.
Сценарий интеграции. Подробное описание сценария интеграции т.е. в какой момент времени начинается обмен данными, кто его инициирует, что ожидает получить в ответ. Каким является положительный результат обмена данными, а какой отрицательный. Описание условий запуска интеграции, расписание запуска. Ожидаемая нагрузка на интеграционный поток.
Для визуализации сценария интеграции удобно использовать диаграмму последовательности, которая изображена ниже.
![Картинка № 3 - Диаграмма последовательности (Sequence diagram - UML) Картинка № 3 - Диаграмма последовательности (Sequence diagram - UML)](https://habrastorage.org/getpro/habr/upload_files/659/3c3/c5b/6593c3c5b7e972f5964a41667e59a893.png)
После подготовки общего описания, которое поможет смоделировать процесс обмена данными, необходимо подготовить подробное текстовое описание интеграции. Удобнее всего это сделать в виде таблицы, которая должна содержать информацию описанную ниже.
Описание запросов:
Название параметра, например: api_key
Формат данных (или тип параметра), например: строка
Пример данных, например: b1234asd0-kasd-2456-4467-46783b55f5f6
Максимальную длину параметра в запросе, например: 255
Описание параметра - т.е. описание логики заполнения, например: api_key обязательный для заполнения параметр, необходим для подключения к API
Пример запроса
Описание ответов:
Код ответа, например: 100
Название ответа, например: Продолжить
Описание ответа, например: Система успешно приняла запрос, он находится в обработке. Система готова принимать другие запросы.
Пример ответа.
Просьба учесть, что пример выше в больше степени относится к описанию обмена по протоколу HTTP, но логика описания подходит и для других протоколов.
В разных компаниях форматы требований отличаются и в рамках данной статьи я ставил цель описать общий подход к их подготовке. Надеюсь, что информация будет полезна. Буду рад любой структурированной критике. Спасибо, если дочитали, и удачи.