Как стать автором
Обновить

Базовое проектирование и разработка требований к интеграции систем (для начинающих аналитиков)

Время на прочтение6 мин
Количество просмотров36K

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

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

Шаг 1. Спроектировать интеграционный поток (сделать архитектуру интеграций)

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

Первым делом предлагаю пройти базовую теорию и выделить 2 вида интеграционного обмена данными между приложениями:

  1. Синхронный обмен – это когда одно приложение направляет сообщение в другое приложение и ожидает ответ, продолжает работать только после получения ответа.

  2. Асинхронный – это когда одно приложение направляет сообщение в другое приложение и не ожидает ответа, а продолжает работать.

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

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

  1. Файловый обмен - системы обмениваются между собой файлами, которые имеют определённую структуру.

  2. Удалённый вызов - паттерн, который в своей основе использует технологии по удалённому вызову функций и процедур другого приложения (примеры технологий - gRPC, SOAP. Пример архитектурной стиля - REST)

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

Зачастую, отражение интеграционных потоков происходит уже в рамках бизнес-архитектуры, но важно понимать, что бизнес архитектуру очень часто путают с корпоративной архитектурой предприятия. Давайте разберёмся.

Бизнес-архитектура - это общая, целостная модель работы предприятия (компании), которая объединяет в себя операционные процессы, стратегию развитию, и информационные технологии, человеческие ресурсы и другие аспекты, влияющие на бизнес.

Таким образом, бизнес-архитектура (business architecture, BA) нацелена на отражение модели бизнеса т.е. тех процессов и инструментов с помощью которых бизнес существует на рынке. В бизнес-архитектуре зачастую отражают ИТ решения, как имеющийся финансовый актив, а не с точки зрения технической реализации.

Корпоративная архитектура (Enterprise architecture, EA) -  нацелена на стандартизацию и организации Информационных Технологий компании в соответствии с её бизнес-целями с учётом постоянной Цифровой трансформации, а также управлением ИТ-ресурсами.

Самой удобной нотацией (методологией) для моделирования бизнес-архитектуры и корпоративной архитектуры является ArchiMate .

Картинка № 1 - Обзор нотации ArchiMate
Картинка № 1 - Обзор нотации ArchiMate

Просьба обратить внимание, что в ней есть элементы «Бизнес», «Стратегия», «Мотивация», которые предназначены для описания именно бизнес-модели компании.

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

У Корпоративной архитектуры есть 2 основных жизненных этапа:

  1. Целевая Корпоративная архитектура (та архитектура, которую планируется реализовать и внедрить).

  2. Текущая Корпоративная архитектура (которая существует на текущий момент).

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

Итак, в этом шаге мы разобрались, что интеграции начинаются с проектирования корпоративной архитектуры, которая в свою очередь учитывает бизнес модель компании. На КА представлено влияние бизнеса на системы и их взаимное использование друг другом (т.е. связи между системами – интеграции).

Шаг 2. Архитектура решения и разработка диаграммы компонентов (UML)

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

Картинка № 2 - концептуальный пример диаграммы компонентов
Картинка № 2 - концептуальный пример диаграммы компонентов

Диаграмма компонентов нужна в первую очередь для того, чтобы показать из каких частей состоит программный продукт и как именно это части взаимодействуют между друг другом. В своей работе я предпочитаю использовать продуктовый подход, поэтому и разработка диаграмм осуществляется в рамках продукта, а не отдельно взятой системы. Продукт может состоять из нескольких систем и сервисов, нет смысла для каждого отдельного сервиса готовить отдельную диаграмму компонентов, особенно если этих компонентов не много (например, само приложение и база данных).

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

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

Шаг 3. Разработка требований к самой интеграции

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

Общие требования к интеграции:

Тип взаимодействия и протокол. Например, файловый обмен по FTP (FTPS) или удалённый вызов через протокол HTTP.

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

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

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

Картинка № 3 - Диаграмма последовательности (Sequence diagram - UML)
Картинка № 3 - Диаграмма последовательности (Sequence diagram - UML)

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

Описание запросов:

  1. Название параметра, например: api_key

  2. Формат данных (или тип параметра), например: строка

  3. Пример данных, например: b1234asd0-kasd-2456-4467-46783b55f5f6

  4. Максимальную длину параметра в запросе, например: 255

  5. Описание параметра - т.е. описание логики заполнения, например: api_key обязательный для заполнения параметр, необходим для подключения к API

  6. Пример запроса

Описание ответов:

  1. Код ответа, например: 100

  2. Название ответа, например: Продолжить

  3. Описание ответа, например: Система успешно приняла запрос, он находится в обработке. Система готова принимать другие запросы.

  4. Пример ответа.

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

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

Теги:
Хабы:
Всего голосов 7: ↑7 и ↓0+7
Комментарии8

Публикации

Истории

Работа

Ближайшие события

22 – 24 ноября
Хакатон «AgroCode Hack Genetics'24»
Онлайн
28 ноября
Конференция «TechRec: ITHR CAMPUS»
МоскваОнлайн
2 – 18 декабря
Yandex DataLens Festival 2024
МоскваОнлайн
11 – 13 декабря
Международная конференция по AI/ML «AI Journey»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань