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

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

Шаг 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)


  1. chumpa
    24.01.2023 15:09

    >Сейчас это два основных паттерна, которые используются

    Привет из 2023г! Обмен через кафку скажем куда отнести?


    1. Amelchenko Автор
      24.01.2023 15:24

      Привет! Спасибо за комментарий.

      Да, согласен, не полная формулировка. Я старался сделать статью проще, но этот важный момент упустил, как и нюансы использования ESB для крупных компаний.
      Правильнее сказать, что сейчас есть 4 основных паттерна: общая база данных, файловый обмен, вызов удаленной процедуры и обмен сообщениями. Кафка это брокер сообщений, а использование брокера часто уже выделяют в отдельный архитектурный паттерн в распределённых системах.


  1. klimkinMD
    25.01.2023 09:56

    Мне кажется, в статье нужна часть с примерами (обобщёнными) как практические реализации описываются "типами", "патернами", "компонентами". (Например, когда есть шина данных, DWH, Data Lake..., когда системы "отливают" данные по расписанию, ...)


    1. Amelchenko Автор
      26.01.2023 14:42

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


  1. SergeyT-hh
    25.01.2023 18:36

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


    1. Amelchenko Автор
      26.01.2023 14:51

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


  1. avf48
    26.01.2023 17:23

    ГОСТ Р ИСО 19440-2010 (ISO 19440:2007) ИНТЕГРАЦИЯ ПРЕДПРИЯТИЯ. КОНСТРУКЦИИ ДЛЯ МОДЕЛИРОВАНИЯ ПРЕДПРИЯТИЯ

    ГОСТ Р ИСО 15704-2008 Промышленные автоматизированные системы. Требования к стандартным арх-рам и метод-ям предприятия

    ГОСТ Р ИСО 19439-2008 Интеграция предприятия. Основа моделирования предприятия (GERA)

    ГОСТ Р 57318-2016 СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИНТЕГРАЦИЯ. Применение и управление процессами системной инженерии

    ГОСТ Р 57195-2016 Ядро и язык для методов системной и программной инженерии. Общие положения

    Как примеры, можно рассмотреть eTOM, BIAN, PODS... Наши наверное тоже есть, но лучше изучить стандарт.

    Схема такая: открывайте стандарт, смотрите группу и ТК, ищите, что было ещё сделано, в плане стандартизации, изучайте. Тот же SEBok, далеко не всем зайдёт, а без знания языка и подавно.

    ПС: И да, есть профстандарт на корпоративного архитектора, он сам всё сделает, если Профессионал. Это не работа аналитика.