На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Когда меня спрашивают, как выбрать интеграционную платформу, я обычно советую не ограничиваться сравнением функций и демонстрацией вендора. Гораздо полезнее проверить платформу на конкретной задаче из собственного ИТ-ландшафта.
Недавно для одного из заказчиков мы провели такой пилот: вместо существующей цепочки COM-обменов проверили централизованную схему через DATAREON Platform. Всего три интеграционных потока позволили проверить не только саму платформу, но и ключевую архитектурную гипотезу — может ли одна из систем стать единым источником данных, а зависимость от промежуточной системы быть устранена.
На этом примере разберу, что именно имеет смысл проверять во время пилота ESB и почему пилот не должен превращаться в формальную передачу нескольких сообщений из точки А в точку Б.
От COM-интеграций к централизованной схеме
В пилотном проекте у заказчика была задача проверить централизованную схему интеграции. Ранее обмен данными между системами был построен через COM.
Процесс работы с объектом «Проект» выглядел так:
проект создавался в «1С:Документооборот»;
затем через COM передавался в «БИТ.ФИНАНС»;
в «1С БИТ» создавалась связанная номенклатурная группа;
после этого проект и номенклатурная группа передавались в «1С:ЗУП» также через COM.
Таким образом, «1С:ЗУП» получала данные о проекте не напрямую, а через «БИТ.ФИНАНС». Заказчик хотел проверить другую модель: определить «1С:Документооборот» как единый источник данных по проектам и организовать передачу информации через централизованный интеграционный слой DATAREON Platform.
В интеграционном контуре пилотного проекта использовались три системы: «1С:Документооборот», «БИТ.ФИНАНС» и «1С:ЗУП».
В проекте было три потока.
Первый передавал справочник «Проекты» из «1С:Документооборот» в «БИТ.ФИНАНС».
Второй — тот же объект «Проект» напрямую из «1С:Документооборот» в «1С:ЗУП».
Третий поток передавал номенклатурные группы из «БИТ.ФИНАНС» в «1С:ЗУП».
DATAREON Platform использовалась как единый интеграционный слой пилотного решения.
Ключевое изменение заключалось именно во втором потоке. Теперь «1С:ЗУП» могла получать проект напрямую из исходной системы, а не через «БИТ.ФИНАНС». При этом сама «БИТ.ФИНАНС» из процесса не исчезала. После получения проекта она по-прежнему выполняла свою функцию — формировала связанную номенклатурную группу, которая затем передавалась в «1С:ЗУП».
По итогам пилота мы подтвердили, что выбранная централизованная схема технически реализуема.
Почему схему лучше сначала проверить на пилоте
Когда проектируется новая интеграционная архитектура, на схеме все обычно выглядит достаточно убедительно. Но реальная жизнь начинается в тот момент, когда схема сталкивается с вашими реальными сценариями, конкретными объектами, структурами данных, правилами существующих систем и ограничениями инфраструктуры.
Пилот позволяет проверить собственные архитектурные решения. Например, можно ли изменить маршрут данных без нарушения существующего процесса. Достаточно ли возможностей платформы для преобразования и маршрутизации объектов. Не появляется ли новая зависимость вместо старой.
Если посмотреть на этот пилот шире, то три интеграционных потока позволили проверить сразу несколько предположений:
Можно ли передавать этот объект напрямую в «1С:ЗУП», исключив зависимость от «БИТ.ФИНАНС».
Можно ли сохранить существующую логику формирования номенклатурной группы в «БИТ.ФИНАНС» и при этом встроить эту систему в новую централизованную схему.
Еще одна причина, почему я рекомендую пилот, — он помогает отделить реальные требования от предполагаемых. До начала работы заказчик может считать критичными одни возможности платформы, а после первых интеграций выясняется, что гораздо важнее другие. Такие вещи плохо проверяются по презентациям и сравнительным таблицам. Зато очень быстро проявляются на реальной задаче.
Как подойти к пилоту
Реализовать самостоятельно или найти для этого подрядчика? Какие есть нюансы в обоих случаях? Что нужно подготовить и какие должны быть внутренние ресурсы? Эти вопросы мы обсудим со стороны вендора, интегратора и компаний, которые прошли этот путь по-разному.
15 сентября мы вместе с DATAREON проведем онлайн-конференцию «Как выбрать ESB под вашу ИТ-архитектуру».
Расскажу, почему к выбору ESB стоит подходить как к долгосрочному архитектурному решению. Покажу, как выглядит российский рынок шин данных, чем отличается DATAREON Platform и зачем проводить пилот до полноценного внедрения — чтобы проверить реальные сценарии, нагрузку, совместимость с ИТ-ландшафтом и готовность команды.
Отдельную часть встречи посвятим практическому опыту заказчиков. Своими кейсами поделятся две компании.
Иван Макушов
Ikon Tyres
Иван Макушов расскажет:
как компания подошла к выбору новой интеграционной шины;
какие требования предъявляли к платформе;
какие сценарии включили в пилот;
что оказалось важным при работе с подрядчиком;
какие выводы сделали по итогам пилота.
Дмитрий Сидоренко
«Уральская Агропромышленная Группа»
Дмитрий Сидоренко поделится опытом проведения пилота внутренней командой:
как организовали работу;
какие задачи проверяли;
какие ресурсы потребовались;
какие выводы сделали.
Будет полезно ИТ-директорам, архитекторам, руководителям интеграционных проектов, аналитикам и компаниям, которые хотят внедрять DATAREON Platform.
Приходите! Можно будет задать вопросы мне и спикерам.
15 сентября, 11:00, онлайн
