Данная статья посвящена в первую очередь начинающим ИТ аналитикам, которые хотят верхнеуровнево разобраться, как необходимо описывать интеграции между системами и как процесс выглядит в целом. Просьба учесть, что часть терминов написана своими словами и намерено упрощена для лучшего понимания. Я думаю, что статья может быть также полезна менеджерам проектов, ИТ-лидам, менеджерам процессов и разным другим менеджерам, работающим в ИТ.
Перед тем, как рассказать, как могут выглядеть требования к интеграции, я бы хотел обратить внимание, что эта самая интеграция должна быть представлена на общей Корпоративной Архитектуре. Процесс управления изменениями и обновление архитектурных артефактов может отличаться в разных компаниях, поэтому бывает, что архитектурная служба (и\или служба интеграции) даже не знает о планируемом новом потоке между двух приложений, поэтому я рекомендую аналитику в первую очередь убедится, что поток присутствует на общей корпоративной архитектуре и о нём знают соответствующие подразделения.
Шаг 1. Спроектировать интеграционный поток (сделать архитектуру интеграций)
Обычно проектирование интеграционных потоков – это не работала аналитика, этим скорее занимает корпоративный архитектор (или бизнес-архитектор), но это точно важная часть общего процесса, которую следует понимать. Во многих компаниях аналитики с более высокими грейдами, как минимум участвуют в разработке корпоративной архитектуры.
Первым делом предлагаю пройти базовую теорию и выделить 2 вида интеграционного обмена данными между приложениями:
Синхронный обмен – это когда одно приложение направляет сообщение в другое приложение и ожидает ответ, продолжает работать только после получения ответа.
Асинхронный – это когда одно приложение направляет сообщение в другое приложение и не ожидает ответа, а продолжает работать.
Тут важно отметить, что на текущий момент чисто синхронные и чисто асинхронные интеграции встречаются достаточно редко и в требованиях к интеграции уже даже не пишут, что это за вид обмена, но очень важно понимать различия.
Вторым делом важно различать разные типы интеграций с точки зрения технологии и протоколов обмена (паттерны интеграции по типу обмена данными):
Файловый обмен - системы обмениваются между собой файлами, которые имеют определённую структуру.
Удалённый вызов - паттерн, который в своей основе использует технологии по удалённому вызову функций и процедур другого приложения (примеры технологий - gRPC, SOAP. Пример архитектурной стиля - REST)
Сейчас это два основных паттерна, которые используются.
Зачастую, отражение интеграционных потоков происходит уже в рамках бизнес-архитектуры, но важно понимать, что бизнес архитектуру очень часто путают с корпоративной архитектурой предприятия. Давайте разберёмся.
Бизнес-архитектура - это общая, целостная модель работы предприятия (компании), которая объединяет в себя операционные процессы, стратегию развитию, и информационные технологии, человеческие ресурсы и другие аспекты, влияющие на бизнес.
Таким образом, бизнес-архитектура (business architecture, BA) нацелена на отражение модели бизнеса т.е. тех процессов и инструментов с помощью которых бизнес существует на рынке. В бизнес-архитектуре зачастую отражают ИТ решения, как имеющийся финансовый актив, а не с точки зрения технической реализации.
Корпоративная архитектура (Enterprise architecture, EA) - нацелена на стандартизацию и организации Информационных Технологий компании в соответствии с её бизнес-целями с учётом постоянной Цифровой трансформации, а также управлением ИТ-ресурсами.
Самой удобной нотацией (методологией) для моделирования бизнес-архитектуры и корпоративной архитектуры является ArchiMate .
Просьба обратить внимание, что в ней есть элементы «Бизнес», «Стратегия», «Мотивация», которые предназначены для описания именно бизнес-модели компании.
В моём опыте, я не встречал, чтобы для описания бизнес-архитектуры использовалась отдельная специализированная нотация. Чаще всего всё делается в рамках общей Корпоративной Архитектуры.
У Корпоративной архитектуры есть 2 основных жизненных этапа:
Целевая Корпоративная архитектура (та архитектура, которую планируется реализовать и внедрить).
Текущая Корпоративная архитектура (которая существует на текущий момент).
Важно учесть, что интеграционные потоки, которые отражены в целевой КА могут быть концептуальными и соответственно меняться.
Итак, в этом шаге мы разобрались, что интеграции начинаются с проектирования корпоративной архитектуры, которая в свою очередь учитывает бизнес модель компании. На КА представлено влияние бизнеса на системы и их взаимное использование друг другом (т.е. связи между системами – интеграции).
Шаг 2. Архитектура решения и разработка диаграммы компонентов (UML)
Когда вы убедились, что необходимый интеграционный поток есть на корпоративной архитектуре его требуется перенести в целевую архитектуру самого программного продукта. Для этих целей я предпочитаю использовать UML - диаграмму компонентов.
Диаграмма компонентов нужна в первую очередь для того, чтобы показать из каких частей состоит программный продукт и как именно это части взаимодействуют между друг другом. В своей работе я предпочитаю использовать продуктовый подход, поэтому и разработка диаграмм осуществляется в рамках продукта, а не отдельно взятой системы. Продукт может состоять из нескольких систем и сервисов, нет смысла для каждого отдельного сервиса готовить отдельную диаграмму компонентов, особенно если этих компонентов не много (например, само приложение и база данных).
В рамках данного шага я хотел показать, что после разработки Корпоративной Архитектуры необходимо спустится на уровень ниже и продумать какие именно данные будут передаваться из одного компонента в другой, а также утвердить технологию.
Отдельно важно отметить, что на данном этапе уже должно быть принято решение о том, какую именно технологию необходимо использовать для интеграции т.е. какой способ реализации будет выбран. Это задача Архитектура решения совместно с Корпоративным Архитектором. Обычно общие требования к технологическому стеку спускает Корпоративный Архитектор, процесс принятия решений зависит от процессов компании.
Шаг 3. Разработка требований к самой интеграции
На текущем этапе у аналитика уже должно быть понимания какой тип интеграции необходимо использовать и какой протокол обмена данными. Всю эту информацию необходимо отразить в общих требованиях к интеграции, которые могут выглядеть следующим образом:
Общие требования к интеграции:
Тип взаимодействия и протокол. Например, файловый обмен по FTP (FTPS) или удалённый вызов через протокол HTTP.
Описание взаимодействующих систем, назначение интеграции. В данном разделе необходимо описать общее назначение двух систем, которые требуется интегрировать и назначение самой интеграции. Какую бизнес-цель данная интеграция преследует, для чего она нужна и какой результат позволит достичь.
Сценарий интеграции. Подробное описание сценария интеграции т.е. в какой момент времени начинается обмен данными, кто его инициирует, что ожидает получить в ответ. Каким является положительный результат обмена данными, а какой отрицательный. Описание условий запуска интеграции, расписание запуска. Ожидаемая нагрузка на интеграционный поток.
Для визуализации сценария интеграции удобно использовать диаграмму последовательности, которая изображена ниже.
После подготовки общего описания, которое поможет смоделировать процесс обмена данными, необходимо подготовить подробное текстовое описание интеграции. Удобнее всего это сделать в виде таблицы, которая должна содержать информацию описанную ниже.
Описание запросов:
Название параметра, например: api_key
Формат данных (или тип параметра), например: строка
Пример данных, например: b1234asd0-kasd-2456-4467-46783b55f5f6
Максимальную длину параметра в запросе, например: 255
Описание параметра - т.е. описание логики заполнения, например: api_key обязательный для заполнения параметр, необходим для подключения к API
Пример запроса
Описание ответов:
Код ответа, например: 100
Название ответа, например: Продолжить
Описание ответа, например: Система успешно приняла запрос, он находится в обработке. Система готова принимать другие запросы.
Пример ответа.
Просьба учесть, что пример выше в больше степени относится к описанию обмена по протоколу HTTP, но логика описания подходит и для других протоколов.
В разных компаниях форматы требований отличаются и в рамках данной статьи я ставил цель описать общий подход к их подготовке. Надеюсь, что информация будет полезна. Буду рад любой структурированной критике. Спасибо, если дочитали, и удачи.
