Когда интеграции начинают мешать развитию ИТ-ландшафта

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Мы много лет занимаемся интеграциями с 1С и другими корпоративными системами. И всё чаще видим ситуацию, когда обмены работают, но любое изменение превращается в отдельный проект: нужно выяснить, какие системы затронет новая логика, где выполняются преобразования и почему данные в разных базах перестали совпадать.

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

Данные передаются, но остаются несогласованными

В производственных, строительных и инжиниринговых компаниях одни и те же справочники используются в ERP, CRM, кадровых и бухгалтерских системах. При этом объекты могут иметь разные идентификаторы, а правила их создания и изменения — различаться. В результате возникают дубли, расхождения в реквизитах и ошибки при повторной загрузке.

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

Добавление очередного обмена здесь не всегда помогает. Сначала нужно определить, какая система отвечает за актуальность каждого справочника, как сопоставляются объекты и какие правила действуют при их изменении. Затем — решить, как организовать обмены, чтобы эти правила не дублировались в разных системах. ESB может централизовать маршрутизацию, преобразования и контроль доставки, но не заменяет MDM и не определяет за компанию, какая система является источником истины.

Новые системы подключаются, а зависимости накапливаются

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

Похожая ситуация возникает при развитии крупного корпоративного ландшафта. Изменение формата документа или замена одной системы затрагивает несколько обменов, а оценить последствия сложно: логика распределена между конфигурациями 1С, регламентными заданиями и отдельными сервисами.

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

Когда эксплуатация становится отдельной задачей

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

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

От отдельных обменов — к управляемой архитектуре

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

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

Продолжим тему на вебинаре

29 сентября в 12:00 мы вместе с EvApps проведем вебинар «Как выстроить управление корпоративными данными: архитектура, технологии и команда».

Сергей Скирдин

технический директор ИТ-интегратора «Белый код»

Альфред Столяров

CEO EvApps

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

• Как понять, действительно ли компании нужна ESB?

• Какие требования стоит сформулировать до выбора платформы?

• Как распределить ответственность между архитектурой данных, интеграционным слоем и командой?

• Что предусмотреть для разработки и дальнейшей эксплуатации потоков?

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

«Как выстроить управление корпоративными данными: архитектура, технологии и команда» — 29 сентября в 12:00 мск

Зарегистрироваться на вебинар

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

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