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

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

6. РУКОВОДСТВО DII

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

Определение правил, на основании которых осуществляются моделирование и преобра зование данных, входит в сферу ответственности заинтересованных сторон, представляющих бизнес-подразделения (business stakeholders). Они же должны утверждать все вносимые в пра вила изменения. Правила должны фиксироваться в качестве метаданных и консолидироваться с целью проведения сквозного анализа в рамках организации. Создание и проверка достовер ности предиктивных моделей (вместе с определением действий, выполнение которых должно быть инициировано в ответ на те или иные события) также относятся к бизнес-функциям.

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

такое событие должно быть привязано к проверке, которую назначает тот или иной орган руко водства. Контроль событий может быть включен в жизненный цикл разработки систем (SDLC) как один из элементов принятия решения о переходе проекта на следующую стадию, в соответ ствии с моделью управления проектом «Стадия — Переход» (Stage-Gate), или учитываться в поль зовательских историях (User Stories). Например, чек-лист соответствия архитектуры решения предъявляемым требованиям может включать вопросы следующего рода: «Используется ли ESB или другие специальные инструменты (там, где это возможно)?», «Был ли проведен анализ воз можностей повторного использования имеющихся сервисов?» и т. п.

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

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

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

6.1 Соглашения о совместном доступе к данным

Прежде чем создавать интерфейсы или реализовывать предоставление данных в электрон ном виде, следует разработать соглашение о совместном использовании данных (data sharing agreement) или меморандум о взаимопонимании (Мemorandum Of Understanding, MOU). Доку мент должен включать основные требования в отношении ответственности и условий исполь зования данных, которыми предполагается обмениваться, согласованные с соответствующими распорядителями бизнес-данных.

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

чае использования персональных или других защищенных данных.

6.2 DII и происхождение данных

При разработке DLL-решений полезно учитывать сведения о происхождении данных. Эти сведе ния также часто требуются потребителям при использовании данных, но еще большую важность

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

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

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

6.3 Метрики для оценки эффективности интеграции данных

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

Доступность данных:

доступность запрошенных данных.

Объемы и скорости обработки данных:

объемы переданных и преобразованных данных;

объемы проанализированных данных;

скорость передачи данных;

задержка между временем завершения обновления данных и временем выдачи обновлен ных данных;

задержка между временем начала события и временем начала выполнения ответных дей ствий;

время, требуемое для предоставления доступа к новым источникам данных.

Стоимость и сложность решения:

стоимость разработки и эксплуатации решений;

простота получения новых данных;

сложность решений и операций;

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