Агенда

Добрый день, дорогие читатели!

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

Цели интеграции

У любой задачи должна быть достижимая цель, в рамках которой эта задача выполняется. Любая интеграция систем – это совокупность целей или одна конкретная цель. Как правило цель определяется бизнес-потребностью, например, система А должна быть интегрирована с системой B для поддержания бизнес-процесса по передаче данных в ФНС или для обеспечения новых функциональностей, например, интеграция с банковской системой эквайринга – для обеспечения оплаты за услуги.

Интеграция подобна сборке шестеренок в сложном техническом механизме (сгенерировано нейросетью Алиса, Яндекс)
Интеграция подобна сборке шестеренок в сложном техническом механизме (сгенерировано нейросетью Алиса, Яндекс)

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

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

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

Итак, в рамках подготовительного этапа к реализации интеграции необходимо:

  • Установочная встреча с бизнесом, где определяются исходные задачи по интеграции.

  • Определяются задачи интеграции и ее цели под фиксирование в протоколе (далее из целей интеграции формируется название решений).

  • Определяется пространство, где бизнесу доступна аналитика интеграции.

  • При необходимости помочь коллегам с доступами к артефактам.

  • Определяется порядок взаимодействия с бизнесом по задачам интеграции.

В результате должны появиться как минимум следующие артефакты: карточка проекта, протоколы, пространство, ряд встреч в календаре.

Контекст интеграции

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

Ниже представляю пример контекстной диаграммы.

Простая изображение контекстной диаграммы, не требует детализации
Рисунок 1 – Простая схема контекстной диаграммы (переиспользовано из статьи https://habr.com/ru/articles/933584/)

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

При интеграции систем важно сделать организационные уточнения – необходимо определить, кто за что отвечает, таким образом должна быть подготовлена матрица ответственности. Необходимо установить круг заинтересованных лиц, определить их роли, обязательно собрать контакты. Очень важно определить порядок соблюдения договорённостей и сроков реализации задач в рамках интеграции. Если процесс вашей компании предполагают согласование артефактов перед реализацией задачи, то важно определить перечень документации, подлежащей, согласованию. Определить согласовантов.

Итак, в рамках установления контекста задач интеграции необходимо:

  • Определение смежных Систем интеграции.

  • Установочные встречи с представителями смежных Систем.

  • Разработка матрицы ответственности. Уточнить, кто за что отвечает в проекте.

  • Определение контекста интеграции (контекстная диаграмма C0, свободная форма).

  • Валидация контекста интеграции у архитекторов Систем, участвующих в интеграции.

  • Установка круга заинтересованных лиц, определение ролей, установка контактов.

  • Определение порядка для соблюдения договоренностей и сроков.

  • Определение перечня документации, подлежащей согласованию.

  • Определение согласовантов документации (можно методом исключения из пробной публикации).

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

Ресурсы, бэклог и реквизиты

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

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

Таким образом, важно:

  • Обеспечение общего пространства для бэклога задач Систем, участвующих в интеграции.

  • Декомпозиция задач (уделять особое внимание).

  • Установление приоритетов задач. Определить, какие задачи являются критически важными и должны быть выполнены в первую очередь.

  • Определение ресурсов команды.

  • Установка сроков и рисков перемещения сроков.

  • Совместная валидация бэклога всеми лидами Систем, участвующих в интеграции.

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

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

Архитектура

Здесь еще раз подчеркну важность определения контекстов взаимодействия систем (см. раздел Контекст интеграции).

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

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

В рамках архитектуры интеграции отмечу, что важно:

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

  • Валидация решений аналитики.

  • Сопровождение подготовки документации, подлежащей согласованию.

  • Готовить ADR.

Аналитика

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

  • Сбор требований бизнеса.

  • Определить способы обмена данными, подготовить решение по выбору инструментов или обосновать предложенный вариант. Передать решение на валидацию архитекторам Систем.

  • Установить требования по форматам и структурам обмена данными. Провалидировать с командами смежных Систем.

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

  • Подготовить интеграционное решение (здесь особенное внимание уделить выбору артефактов и декомпозиции задач по аналитике)

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

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

  • Определить перечень сценариев аудита ИБ.

  • Предварительно провалидировать решение у архитекторов Систем.

  • Представить решение на грумминге с бизнесом. Согласовать решение.

  • Регулярное обновление требований. При необходимости реагировать своевременно на изменения в решениях (форматы сообщений, способы взаимодействия...)

Разработка

С точки зрения разработки в рамках проектирования интеграции и реализации необходимо:

  • Обеспечивать «техническую глубину» поддержки проектирования.

  • Валидировать артефакты постановок до взятия в работу.

  • Налаживать взаимодействие с разработчиками смежных Систем (переиспользование кодовой базы)

  • При очередной итерации разработки делать коммит в dev ветку. Запрашивать валидацию реализации у аналитики.

  • Запрашивать все необходимые сведения у аналитики.

  • В идеальном случае: Планирование версий продукта. Определение этапов выпуска продукта с определенным набором функционала.

  • В идеальном случае итеративно со смежными командами тестировать разработанные функциональности.

Итог

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

Надеюсь, вам была полезна публикация.

Комментарии (1)


  1. reset44
    26.10.2025 07:13

    Больше похоже на план действий, а не чек-лист.