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

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

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

Качество данных

Отсутствие качественных данных (приведенных к единому формату, недублирующихся, согласованных между собой, без “мусорных” записей) в информационных системах многих компаний является данностью, с которой приходится работать. Зачастую этот факт при внедрении новых ИС не учитывается, и в конце реализации проекта компания получает еще одну систему со своим набором данных, слабо согласующимися с данными других систем. В таких случаях при попытке настройки взаимодействия несогласованность данных приводит к тому, что интеграция систем есть, а интеграции данных нет. Может даже получиться несколько наборов данных в одной системе идентичных по сути, но разных по представлению (например, “юр. лицо” и “Юридические лица”).

Решать задачу согласованности данных призваны системы управления мастер-данными (Master Data Management, MDM). Но сегодня эти системы в российских компаниях являются больше экзотикой, чем нормой (об этом свидетельствует список референсов основных поставщиков MDM-решений). В отсутствии единой MDM-системы в компании задачи согласования данных и обеспечения их качества ложатся на процессы интеграции. Для этого разрабатываются бизнес-правила преобразования данных, создаются таблицы соответствия и т.п. решения, что по сути своей представляет систему MDM для одного или группы интеграционных процессов.

Конечно, не рекомендуется решать задачи интеграции, миграции данных и задачи улучшения качества данных, дедубликации в рамках одного проекта. Но если выхода нет, то прежде чем начинать разрабатывать бизнес-правила и таблицы соответствия, необходимо изучить данные, провести их предварительный анализа путем профилирования (Data Profiling). Проведение профилирования позволяет получить информацию о содержании, качестве и структуре данных. Этот важный этап, предшествующий этапу проектирования процессов интеграции, очень часто игнорируется, что приводит в итоге к несогласованности данных в интегрируемых системах. Еще одной важной задачей профилирования данных является сужение множества передаваемых данных, ведь в процессе анализа можно выявить “мусорные”, дублирующиеся или ненужные вообще для передачи данные.

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

1. несогласованность интегрируемых данных, в следствие отсутствия в компании единой системы управления мастер-данными;
2. непридание важности профилированию, анализу и очистки данных перед реализацией процессов интеграции.

Организационные трудности

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

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

Еще одной сложностью, с которой приходится сталкиваться - это закрытость служб сопровождения и разработчиков информационных систем компании Заказчика. Например, при построении хранилища данных необходимо проводить анализ данных и их структуры, хранящихся в системах-источниках. Но зачастую изучить их не получается по причине того, что не предоставляется документация, запрещается доступ к системе-источнику, отсутствуют примеры данных и т.д. В таком случае специалистами Заказчика применяется следующий подход при взаимодействии с Разработчиком: “Скажите, что Вам нужно, а мы дадим только то, что из этого есть в системе”. Это приводит к тому, что у бизнес-аналитиков и специалиста по модели данных складывается неполная картина о имеющихся данных в компании. Как результат, неполное хранилище данных. Избежать этого можно только путем правильной ориентацией специалистов Заказчика на взаимодействие с консультантами Разработчика.

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

Резюмируя перечень организационных трудностей, можно сказать, что к ним относятся:

1. отсутствие ответственных за интеграционные процессы;
2. недостаточный административный ресурс или несвоевременное его применение;
3. отсутствие ответственных за качество данных;
4. закрытость служб сопровождения и разработчиков информационных систем компании Заказчика;
5. непривлечение к анализу данных и последующей разработке бизнес-правил преобразования предметных экспертов Заказчика.

Технические трудности

Процесс организации интеграции сводится к следующим действиям:

1. определение источника/приемника данных;
2. анализ данных источника;
3. выбор инструмента интеграции;
4. согласование форматов, способа и периодичности обмена данными (согласование регламента интеграции);
5. проектирование и разработка процессов интеграции;
6. тестирование;
7. промышленная эксплуатация.

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

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

Еще одной ошибкой, связанной с интеграционной платформой, является её неправильное использование. Нет смысла покупать Informatica PowerCenter для того, чтобы всю логику преобразования данных реализовать на языке PL/SQL базы данных Oracle.

Стремление разработчиков к универсальности и применению передовых технологий, форматов, шаблонов и т.п. может излишне усложнить решение по интеграции. Организация обмена данными через web-сервисы порой приводит к задержкам передачи и обработки большого объема данных, усложнению выявления ошибок в данных в огромных xml-файлах и т.д. Все стремится к простоте. При организации процессов интеграции не следует их усложнять без необходимости протоколами с шифрованием, web-сервисами, гарантированной доставкой и т.п.

Подводя итог под техническими трудностями, можно сказать, что к ним относятся:

1. выбор неподходящей платформы интеграции;
2. неверное использование платформы интеграции;
3. излишнее усложнение решения.

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

Ковтун М.В. Февраль 2011