Интеграционный проект, направленный на поддержку «сквозных» бизнес-процессов, по своей значимости оказывается одним из наиболее критичных для бизнеса компаний. В идеальном варианте интеграционный проект может обеспечить целый ряд преимуществ.
Требуется тщательная подготовка
Одно из таких преимуществ — синхронизация данных между системами для исключения их дублирования при вводе. Другое — обеспечение целостности процессов. Например, для автоматизации действий по приёму сотрудника на работу нужно объединить несколько приложений — внести информацию о нём в бухгалтерскую систему, создать пользовательский раздел на корпоративном портале и в почтовой системе и так далее. Если же бизнес построен на взаимодействии с партнёрами (например, логистическая компания), то интеграция внутренних систем с системами партнёров позволит максимально быстро обмениваться информацией. В худшем случае интеграция добавит проблем ИТ-департаменту при том, что задачи интеграции решены не будут или будут, но не в том объеме, как хотелось бы.
Оказаться как можно ближе к идеальному варианту помогает тщательное детальное планирование и анализ исходной ситуации. Прежде всего — определение потоков данных и бизнес-процессов, которые требуется поддержать. Какие данные, из каких систем и по каким событиям нужно синхронизировать, с какими правилами конвертации, если таковые есть? Для бизнес-процессов требуется определить последовательность операций и их составляющие, участвующие во взаимодействии системы и алгоритмы обработки данных.
Затем встанет вопрос извлечения данных из одних систем и размещения их в других. Обычно в компаниях есть самые разные системы — как от известных вендоров с хорошими возможностями интеграции, так и заказные программные разработки. Во втором случае интеграционных интерфейсов может и не быть. В самом пессимистичном варианте придётся провести «обратное проектирование» бизнес-логики приложения, чтобы, к примеру, по данным, имеющимся в базе, восстановить те, которые нужны для интеграции. Имея достаточные для этого возможности (к примеру, интеграционный интерфейс системы MS Dynamics AX 4.0), нужно только реализовать несколько стандартных интеграционных методов. В большинстве случаев объем работ лежит между этими крайностями.
Оценив потребность в получении и обработке данных, можно переходить к оценке трудозатрат. Если стоит задача синхронизации данных между однопользовательской бухгалтерской системой и написанной на заказ складской системой, реализованной на СУБД уровня MS Access, то этот объем работ вполне может выполнить один программист средней квалификации по принципу «точка — точка» путём выгрузки-загрузки файлов. Если же стоит задача интегрировать несколько промышленных и заказных программных систем с большими объемами данных и с синхронизацией десятков сложных бизнес-процессов, то здесь нужна команда высококвалифицированных специалистов.
Интеграционная шина или «точка — точка»
Зная набор интегрируемых систем, наборы данных, бизнес-процессы для интеграции, примерные объемы данных и учитывая перспективы развития ИТ-систем компании, можно обдумать, каким путём будет реализован интеграционный проект. В большинстве случаев выбор здесь делается между методами «точка — точка» и «интеграционная шина». Иногда применяется решение с выделенным интеграционным хранилищем данных, например БД с интеграционными таблицами. В этом случае с таблицами интегрируется каждая система, даже не подозревая о существовании других систем. Такое решение используется редко, в основном если компания сама развивает свои ИТ-системы и полностью может контролировать структуру интеграционных таблиц. Но с течением времени такое решение будет всё сложнее поддерживать.
Нередко бывает достаточно метода «точка — точка», даже при интеграции нескольких систем. Для примера возьмём управляющую компанию. У неё есть три системы — электронного документооборота (СЭД), трейдерская и финансовая система MS Dynamics AX. Бизнес-процессы таковы, что документ после согласования в СЭД попадает в трейдерскую систему, а из неё данные о торгах раз в сутки передаются в финансовую систему MS Dynamics AX. Новые договора также вводятся в MS Dynamics AX и после этого согласуются в СЭД. Бизнес-процессы устоялись, системы и связи между ними стабильны, внедрение новых систем в будущем не планируется. В таких условиях внедрение «интеграционной шины» будет избыточным и неоправданным. И интеграция по типу «точка — точка» здесь является наилучшим решением.
Как правило, интеграционная логика в таких решениях реализуется или программным кодом в одной из систем (в мастер-системе), или же на базе какого-либо готового инструмента (к примеру, с помощью компонента Integration Services СУБД SQL Server корпорации Microsoft).
Несколько примеров из собственной практики. В крупной международной логистической компании нужно было интегрировать наше решение для документооборота DocHouse и внутреннюю систему заказчика для управления заказами. Объем ежедневной синхронизации — примерно тысяча записей. Очевидно, что здесь решение с использованием «интеграционной шины» будет избыточным. Поэтому мы выбрали интеграцию по типу «точка — точка». Были согласованы форматы синхронизируемых данных, написана пара хранимых процедур для MS SQL Server, изменена логика процесса документооборота в DocHouse. Объем работ — примерно две человеко-недели. Другой пример. Крупная управляющая компания имеет большую базу данных Oracle, куда стекается информация из всех агентских пунктов. Внутренняя работа с клиентами ведется с помощью системы MS CRM. Задача — синхронизировать информацию по клиентам и продажам финансовых инструментов между этими системами. Первичный импорт информации — около миллиона записей. Последующая ежедневная синхронизация — примерно сотня тысяч записей. Здесь мы тоже выбрали интеграцию по принципу «точка — точка», ведь нам нужно было лишь забрать данные из одной системы, конвертировать их и положить в другую систему, ничего более. «Интеграционная шина» была бы здесь очень тяжеловесным и дорогим решением, в котором её потенциал не был бы полностью раскрыт.
Проект был выполнен с использованием компонента Integration Services СУБД MS SQL Server, хранимых процедур на T-SQL и программного кода на VB.NET. Согласование форматов данных, разработка бизнес-процесса, программирование и тестирование — всё было сделано за три месяца командой из трех человек.
К сожалению, подход «точка — точка» работает до определенного предела, за которым трудозатраты превышают преимущества. Чем больше систем, тем больше связей между ними, а значит, сложнее логика синхронизации. Системы часто общаются по разным протоколам и с разными форматами данных. Значит, интегрируемые системы должны знать обо всех возможных комбинациях протокол/формат данных. Программный код интеграционного процесса «размазывается» по системам, и его становится все сложнее исправлять и развивать, что увеличивает затраты на поддержку.
Как понять, что компании нужно переходить от интеграции «точка — точка» к интеграционной шине? Точный ответ на этот вопрос зависит от очень многих параметров — ресурсов, как финансовых, так и человеческих, динамики развития ИТ-инфраструктуры, развития самого бизнеса компании. В качестве отправной точки можно порекомендовать следующие признаки: большое количество ИТ-систем (больше четырёх), часто изменяющиеся связи между ними, разные протоколы и форматы данных; бизнес-процессы охватывают несколько систем (больше двух); большие объемы данных (больше тысячи записей в день по каждой из основных систем); высокие требования к надежности и масштабируемости; необходимость в интегрированной информации, то есть в представлении консолидированной отчетности по нескольким системам.
Практический пример. Банк, занимающийся ипотекой. Выданные кредиты учитываются и отслеживаются с помощью CRM-системы. Нужно было автоматизировать приём кредитных дел от информационных систем партнёров. Около двух десятков бизнес-процессов, сложные трансформации данных (XML различных содержательных нотаций), взаимодействие с несколькими внутренними системами (CRM, базой данных, корпоративным порталом) с использованием различных протоколов (HTTP, Web Services, SQL, файловый), надежность обработки данных — все эти требования предопределили использование интеграционного решения MS BizTalk Server. Такие возможности, как большой набор адаптеров для различных протоколов, выделенные компоненты для трансформации данных, позволяли нам быстро подключать к одному и тому же бизнес-процессу различные системы. Основная часть бизнес-процессов была разработана нами за пять месяцев.
Производители связующего ПО по-разному трактуют термин «интеграционная шина». В контексте обсуждаемых методов интеграции, на мой взгляд, наиболее удачным будет такое определение: программный сервер, который выполняет бизнес-процессы, имеет адаптеры ко всем интегрируемым системам, умеет конвертировать данные, обладает масшабируемостью и надежностью при обработке сообщений, предоставляет инструменты для мониторинга как системных параметров процессов, так и бизнес-показателей интеграционных процессов. Последняя особенность шины является прямым следствием её работы «поверх» остальных систем. Обрабатывая и консолидируя данные, шина позволяет в режиме реального времени строить отчеты в разрезе поставщиков, товаров, комплектов — то есть бизнес-показателей интеграционных процессов. Эта возможность особенно ценна для бизнес-пользователей.
Выделенная интеграционная шина имеет несколько преимуществ перед методом «точка — точка». Программный код бизнес-процессов выполняется одной системой, при этом интеграционная шина «понимает» каждую систему и говорит на её языке (комбинации протокол/формат данных). При необходимости шину можно масшатбировать для увеличения производительности, поддержка транзакционности бизнес-процессов у неё осуществляется «из коробки». Присутствие дополнительных инструментов по мониторингу бизнес-активности делает её привлекательной для бизнес-пользователей.
К сожалению, интеграционная шина имеет и недостатки, которые являются продолжением её преимуществ. Всю интеграционную логику она содержит в себе. Остановка шины по какой-либо причине ведет к полному параличу всей ИТ-инфраструктуры предприятия. К счастью, это решается кластеризацей входящих в неё серверов, такую возможность поддерживают все вендоры. При этом интеграционные проекты характеризуются большой сложностью, что зачастую требует привлечения грамотного партнёра по внедрению.
Выбор же способа реализации интеграционной шины зависит от многих факторов: бюджета проекта, квалификации проектной команды, систем и их интеграционных интерфейсов, объемов интеграции, перспектив развития ИТ-инфраструктуры, ориентации на того или иного вендора.
Как и в любом другом проекте внедрения информационной системы, правильно составленное техническое задание, грамотная архитектура, тестирование решения бизнес-пользователями, разграничение ответственности между командами сопровождения — всё это необходимые условия успешного проекта по интеграции систем предприятия. Не стоит забывать и об итерационности подключения систем к общей шине. Не менее важна согласованность действий между бизнес-пользователями, ведь интеграционная шина связывает несколько приложений, которые эксплуатируются разными департаментами. Встают вопросы прав доступа к данным, обеспечения безопасности. Иногда некоторые пользователи по каким-либо причинам не хотят делиться информацией с другими системами.
Некоторые выводы
Таким образом, для успеха интеграционного проекта важны многие факторы: наличие интеграционных интерфейсов в интегрируемых системах, выбор метода интеграции и интеграционной шины, сильное руководство проекта, как техническое, так и на уровне менеджмента компании.
Успешный интеграционный проект может поднять обработку информации на новую высоту, стать важным конкурентным преимуществом. Провал же такого проекта может откатить ИТ-инфраструктуру компании на несколько шагов назад и отбить у менеджмента всякое желание экспериментировать с интеграцией в будущем.
