Интеграция без хаоса: почему настроить обмены между системами недостаточно

• источник и получателя данных;

• состав передаваемых атрибутов и правила преобразования;

• условия запуска и периодичность обмена;

• требования к обработке ошибок и повторным попыткам;

• правила контроля дубликатов, если повторная обработка возможна;

• требования к журналированию и мониторингу;

• ответственных за сопровождение и изменение сценария.

Это не универсальный шаблон технического задания: состав требований зависит от конкретного обмена. Но без такого описания трудно обеспечить предсказуемую работу интеграционного контура после запуска.

Три варианта внедрения: от обследования до комплексного проекта

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

В SOFROS мы выделяем три основных подхода к работе.

Обследование: сначала разобраться, что есть

Обследование подходит, когда необходимо получить объективную картину текущего состояния интеграционного ландшафта.

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

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

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

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

Техническое внедрение: требования определены, нужно реализовать решение

Этот вариант подходит заказчику, который уже понимает, какие интеграции необходимы, и располагает согласованными требованиями.

Задача исполнителя — проанализировать техническое задание, уточнить детали реализации, настроить платформу и реализовать предусмотренные сценарии обмена.

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

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

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

Комплексное внедрение: от бизнес-потребности к работающему контуру

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

Работа начинается не с настройки платформы, а с анализа бизнес-процессов и текущей архитектуры.

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

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

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

Далее формируется целевая схема интеграционного взаимодействия, определяются сценарии обмена и правила обработки данных.

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

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

Что происходит после запуска?

Запуск интеграций — не конец проекта. Именно после начала промышленной эксплуатации становится понятно, насколько удобно решение для повседневной работы.

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

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

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

DATAREON Platform поддерживает кластерную архитектуру, в том числе режим Active-Active и горизонтальное масштабирование. Но эти возможности необходимо соотнести с требованиями конкретного проекта, инфраструктурой заказчика и характером интеграционной нагрузки. Само наличие кластерной конфигурации не заменяет проработку сценариев отказа и восстановления.

Есть и ещё один аспект — документирование.

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

Один документ редко одинаково хорошо решает обе задачи.

Поэтому в комплексных проектах SOFROS предусматривает подготовку технических и пользовательских материалов.

Low-code не отменяет инженерную работу

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

В проектах SOFROS многие типовые задачи решаются штатными low-code-механизмами DATAREON Platform. Код требуется там, где стандартных возможностей недостаточно: например, для специфической обработки данных или взаимодействия с нестандартными системами.

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

Low-code снижает трудоёмкость реализации, но не снимает с команды ответственность за архитектуру и качество решения.

Поэтому в работе SOFROS мы используем готовые проверенные подходы там, где они подходят задаче, и адаптируем их при необходимости.

Если стандартного коннектора недостаточно, возможна его доработка или создание индивидуального решения для взаимодействия с конкретной системой.

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

Передача компетенций заказчику

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

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

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

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

В комплексных проектах SOFROS уделяет внимание обучению и передаче методологических материалов.

Практические занятия могут проводиться с использованием сценариев и примеров из инфраструктуры заказчика. Такой подход помогает сформировать основу для дальнейшего развития системы внутри компании.

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

Вместо заключения

Интеграционный проект можно оценивать по-разному.

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

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

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

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

Выбор зависит от исходного состояния ИТ-ландшафта, определённости требований и задач бизнеса.

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