Бесшовная интеграция различных систем

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

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

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

• Объем данных огромен, а «окно» для миграции мало.
• Функционал новой системы не покрывает 100% старой.
• Бизнес-процессы чувствительны к любым сбоям (финансы, производство).

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

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

Для оценки совместимости систем, мы анализируем следующие основные параметры:

1. Соответствие модели данных двух систем, чтобы не возникало ситуации потери или нехватки данных
2. Наличие необходимого API для требуемых потоков передачи данных
3. Необходимая частота обмена данными
4. Необходимость взаимодействия с другими системами в рамках бизнес-процесса

Ответы на эти вопросы будут влиять как на выбор стратегии перехода, так и на выбор применяемых технологий интеграции. Также на выбор технологий интеграции влияет текущий ИТ ландшафт организации. Так, если уже существует интеграционная шина данных (ESB), то и новое взаимодействие лучше делать через нее. Но, тут снова есть нюансы, если период взаимодействия старой и новой системы относительно короткий, то может оказаться проще реализовать интеграцию «точка-точка» без доработки шины данных.

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

Читайте также

Инна Сенчугова: «Если решение не сокращает издержки и не снижает риски — зачем оно бизнесу?»

Сегодня ИТ-директор отвечает не только за технологии, но и за устойчивость бизнеса. «Сделать быстро» больше не означает «сделать правильно», а безопасность давно перестала сводиться к антивирусу. В интервью IT-World ИТ-директор Михайловского театра Инна Сенчугова рассказывает, почему бизнес все чаще требует измеримого эффекта и понятных рисков, как выбирать между готовым ПО и собственной разработкой, чтобы не попасть в зависимость от вендора, и зачем регулярно проводить аудит ИБ.

В случае, если обнаруживается несоответствие API систем, и мы понимаем, что их доработка — это «долго-дорого», то в таких случаях, мы часто используем технологию RPA (Robotic Process Automation), которая позволяет переносить данные между системами без необходимости их классической интеграции, а по сути, эмитируя действия пользователя. Эта же технология может использоваться для обеспечения стыковки систем на уровне бизнес-логики, когда требуется обеспечить постепенный переход с одной системы на другую без увеличения нагрузки на конечных пользователей.

При поэтапном переходе возникают две большие задачи:

1. Обеспечение единства и целостности данных
2. Обеспечить непрерывность процессов

За мой опыт универсальных решений выявить не удалось, все очень сильно зависит от конкретного проекта внедрения и систем, которые в нем участвуют. Всегда используются те или иные стандартные технологии, которые я уже упоминал выше. Выделить какую-то «серебряную пулю» у нас не получилось. Здесь в первую очередь приходится работать с теми рисками, которые могут возникнуть и уже в зависимости от них формировать конкретные технические решения, которые позволяют их снизить. При этом, важно не забывать про пользователей, ведь фокусируясь исключительно на технических решениях можно легко сломать «пользовательский путь», либо не учесть существенный рост нагрузки на пользователей, что приведет к существенному нарушению SLA по автоматизируемому процессу. Поэтому в команде, помимо технических специалистов, обязательно должны быть аналитики или консультанты, обеспечивающие связь бизнеса и разработки и проверяющие, что то, что создала техническая команда можно будет реально использовать и это не нарушит существующие процессы. Также в таких проектах очень большую роль играет руководитель проекта (или другой представитель управленческой компетенции), который обеспечивает синхронную работу всех участвующих в проекте команд, в частности команд старой и новой системы.

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

1. Функционал системы
2. Точки интеграционного взаимодействия
3. Нагрузку

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

Контроль процесса перехода можно разделить на несколько направлений:

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

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