Пошаговое внедрение средств управления метаданными IBM Information Server

Сабир Асадуллаев, исполнительный архитектор SWG IBM EE/A

21.09.2009

http://www. ibm. com/developerworks/ru/library/sabir/Information_Server/index. html

Резюме

Всего 10 лет назад рынок предлагал для создания хранилищ данных (ХД) только серверы, СУБД и ограниченный набор инструментов. Разработчикам ХД приходилось самостоятельно разрабатывать средства извлечения и загрузки данных (ETL), средства управления метаданными и нормативно-справочной информацией (НСИ) и многое другое.

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

Описание сценария

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

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

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

В соответствии с выявленными проблемами были сформулированы следующие бизнес –

цели:

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

Повысить эффективность интеграционных бизнес — процессов и минимизировать время и усилия их внедрения.

Устранить препятствия для создания корпоративного хранилища данных.

Текущая логическая топология

Существующая ИТ среда включает в себя информационные системы дочерних организаций, Отраслевые информационные системы, отраслевые хранилища данных,

информационные системы центрального офиса, витрины данных и перспективное корпоративное хранилище данных.

Информационные системы дочерних организаций реализованы на различных платформах и находятся вне рассмотрения данной работы. Отраслевые информационные системы основаны, в основном, на SAP R/3. Отраслевые хранилища данных разработаны на платформе SAP BW. Информационные системы центрального офиса (ЦО) разработаны с применением технологий Oracle. Витрины данных в настоящее время работают поверх информационных систем центрального офиса и используют SAP BW. В качестве платформы для корпоративного хранилища данных принята DB2.

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

В центре Рис. 1 расположена централизованная часть ИТ инфраструктуры Компании. Она включает в себя несколько отраслевых хранилищ данных на платформе SAP/BW и информационные системы центрального офиса на базе СУБД Oracle. Исторически сложилось так, эти две группы используют различные средства и методы сбора данных, поэтому данные, хранимые в этих системах, несогласованны друг с другом. В результате отчеты, создаваемые OLAP-системами не обеспечивают единого понимания атрибутов (показателей) отчетов.

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

Архитектура системы управления метаданными

Существуют три основных архитектурных шаблона для системы управления метаданными: двухточечный шаблон, двухточечный с единой метамоделью и «звезда» [1].

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

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

Архитектурный шаблон «звезда» представляет собой репозиторий, к которому могут обращаться все системы и инструменты. Репозиторий метаданных содержит как единую метамодель, так и метаданные, устанавливающие единый бизнес – язык для всех интегрируемых систем.

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

Источники метаданных – это все информационные системы – источники данных, которые включены в корпоративную систему управления метаданными.

Средства интеграции метаданных предназначены для извлечения метаданных из источников, их интеграции и размещения в репозитории метаданных

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

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

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

Архитектура репозитория метаданных

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

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

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

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

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

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

Таблица 1. Сравнение архитектур репозиториев метаданных

Архитектура

Централизованная

Распределенная

Децентрализованная

Метамодель

Единственная,

единая и единообразная

Единственная, единая и

единообразная

Множественные,

разнообразные,

несовместимые модели

Глобальный

репозиторий

Полный набор

метаданных

Подмножество

глобальных метаданных

Ссылки на метаданные в

локальных репозиториях

Локальный

репозиторий

Нет локальных

репозиторив

Метаданные локальных

систем

Собственные

метамодели, метаданные и их организация

Управление

метаданными

разнообразные,

несовместимые модели

Глобальный

репозиторий

Полный набор

метаданных

Подмножество

глобальных метаданных

Ссылки на метаданные в

локальных репозиториях

Локальный

репозиторий

Нет локальных

репозиторив

Метаданные локальных

систем

Собственные

метамодели, метаданные и их организация

Управление

метаданными

2. Второе, наиболее важное изменение – это централизованное управление метаданными, которое позволить установить в Компании единый бизнес-язык для всех систем, эксплуатируемых в центральном офисе. Поэтому на клиентской стороне требуется только программа-клиент метаданных.

Две фазы расширенного жизненного цикла метаданных Расширенный жизненный цикл ведения метаданных (Рис. 3), предложенный в работе [3], состоит из следующих этапов: анализ и понимание, разработка, преобразование,

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

отчетность и аудит.

Жизненный цикл с точки зрения пошагового внедрения удобно разделить на две фазы:

1. Фаза «Проектирование метаданных»: анализ и понимание, разработка,

преобразование, публикация.

2. Фаза «Производство метаданных»: потребление, владение, управление качеством,

управление метаданными, отчетность и аудит.

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

«Проектирование метаданных» сгруппированы в левой части Рис. 3, тогда как этапы фазы

«Производство метаданных» размещены справа.

Фаза «Проектирование метаданных»

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

Бизнес-аналитик осуществляет картирование потоков данных и готовит исходную классификацию.

Эксперт предметной области должен разработать бизнес классификацию.

Аналитик данных выполняет анализ систем.

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

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

Коллективное создание и управление бизнес – словарем, поддержку бизнес контекста для ИТ активов, разработка потоков извлечения, трансформации и доставки данных обеспечивается на этапе Разработка.

ИТ разработчик создает логику обработки, преобразования и перемещения.

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

ИТ разработчик готовит задания на преобразования и перемещение данных,

которые исполняются системой.

Унифицированный механизм размещения метаданных и оповещения об обновлениях вступает в работу на этапе Публикация.

ИТ разработчик обеспечивает размещение сервисов, с помощью которых

Стюард метаданных осуществляет публикацию метаданных

Анализ и понимание

Бизнес-аналитик

Картирование потоков данных Исходная классификация Эксперт предметной области Бизнес классификация Аналитик данных

Анализ систем

Отчетность и аудит

Стюард метаданных

Проведение аудита

Подготовка отчетов

Управление

Руководитель проекта

Назначение стюардов Определение ответственности и управляемости

Моделирование

Аналитик данных

Логическая и физическая модели

Синхронизация моделей

Разработка

ИТ разработчик

Логика обработки,

преобразования и перемещения

Преобразование

ИТ разработчик

Задания на преобразования и перемещение данных

Управление качеством

Руководитель проекта

Анализ воздействия изменений

Бизнес-аналитик

Выявление противоречий в метаданных Эксперт предметной области Обновление бизнес классификации Аналитик данных

Устранение противоречий

ИТ разработчик

Управление ресурсами данных Стюард метаданных Поддержка единого понимания Бизнес — пользователи

Выявление рассогласований

Владение

Стюард метаданных

Права использования метаданных

Публикация

ИТ разработчик

Размещение сервисов

Стюард метаданных

Публикация метаданных

Потребление

Бизнес — пользователи

Использование метаданных

Рис. 3. Расширенный жизненный цикл ведения метаданных

Фаза «Производство метаданных»

Визуальная навигация и отображение метаданных и их взаимосвязей; доступ к метаданным, их интеграция, импорт и экспорт; анализ влияния изменений; поиск и запросы осуществляются на этапе Потребление (Рис.3).

Бизнес – пользователи получают возможность использования метаданных

Права доступа к метаданным определяются на этапе Владение.

Стюард метаданных определяет права использования метаданных

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

Руководитель проекта проводит анализ воздействия изменений

Бизнес-аналитик выявляет противоречия в метаданных

Эксперт предметной области обновляет бизнес классификацию

Аналитик данных устраняет противоречия между метаданными и классификацией

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

Стюард метаданных поддерживает единое понимания смысла метаданных

Бизнес – пользователи в свое работе неизбежно выявляют рассогласование метаданных

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

Руководитель проекта должен назначить стюардов и распределить ответственность между членами команды.

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

Стюард метаданных осуществляет проведение аудита и подготовку отчетов

Результаты аудита могут быть использованы для анализа и понимания на следующем витке жизненного цикла.

Роли и взаимодействия на фазе проектирования метаданных

С помощью редактора картирования, входящего в состав FastTrack, бизнес-аналитик создает спецификации картирования (сопоставления, отображения) потоков от источников к потребителям информации (Рис.4). Каждое картирование может содержать несколько источников и несколько потребителей. Спецификации картирования используются для документирования бизнес — требований.

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

Бизнес-аналитик использует Information Analyzer для принятия решений по проектированию интеграции на основе изучения таблиц, столбцов, ключей, и их

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

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

Аналитик данных получает в качестве Information Analyzer инструмент для полного анализа систем-источников информации и целевых систем, оценки структуры, содержимого и качества данных на уровне отдельных столбцов, на уровне нескольких столбцов, на уровне таблиц, на уровне файлов, на межтабличном уровне и на уровне нескольких источников.

Аналитики данных и архитекторы могут вызывать Rational Data Architect для проектированы баз данных, в том числе, федеративных, которые могут взаимодействовать с DataStage и другими компонентами Information Server. Rational Data Architect анализ данных на основе исследования и анализа метаданных. Аналитики данных могут выявлять, моделировать, визуализировать и связывать разнородные активы данных, и могут создавать физические модели с нуля, из логических моделей с помощью преобразования, или с помощью обратного проектирования эксплуатируемых баз данных.

ИТ — разработчик использует FastTrack в процессе разработки логики заданий сквозной обработки информации. FastTrack преобразует артефакты, полученные из различных источников, в понятные описания. Эта информация имеет внутренние связи, что позволяет разработчику получать описания из репозитория метаданных и сосредоточиться на разработке сложной логики, не теряя времени на поиск среди множества документов и файлов.

FastTrack интегрирован в IBM Information Server так, что спецификации, метаданные и задания становятся доступны всем участникам проекта, которые используют Information Server, Information Analyzer, DataStage Server и Business Glossary.

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

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

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

ИТ — разработчик привлекает Information Services Director как основу для размещения интеграционных задач в качестве согласованных и многократно используемых сервисов. Затем ИТ — разработчик может использовать сервис — ориентированные задания управления метаданными для интеграции корпоративных приложений, для управления бизнес – процессами, вместе с корпоративной интеграционной шиной и серверами приложений.

Бизнес-пользователи нуждаются в доступе к метаданным «только на чтение», и их потребности покрываются двумя инструментами: Business Glossary Browser и Business Glossary Anywhere.

Роли и взаимодействия на фазе производства метаданных

ИТ — специалисты, ответственные за управление изменениями, например, руководитель проекта, с помощью Metadata Workbench может анализировать воздействие изменений на информационную среду (Рис.5).

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

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

Стадия исследования выполняется бизнес — аналитиком с тем, чтобы достичь полной видимости действительного состояния данных и в этом ему могут помочь инструменты анализа, встроенные в QualityStage.

Аналитик данных устраняет противоречия между глоссарием и таблицами и столбцами баз данных с помощью Business Glossary и Rational Data Architect

Metadata Workbench предоставляет ИТ – разработчикам средства просмотра, анализа и обогащения метаданных. Таким образом, ИТ – разработчики могут использовать средства проектирования, встроенные в Metadata Workbench для управления и понимания информационных активов, созданных и доступных посредством IBM Information Server

Бизнес — пользователи, ответственные за соблюдение законодательных требований (таких, как акт Сарбейн-Оксли или Базель-II), имеют возможность отслеживать происхождение данных с помощью соответствующих инструментов Metadata Workbench.

Стюарды могут использовать Information Analyzer для поддержки единого понимания смысла данных всеми пользователями и участниками проекта.

Стюарды могут привлекать Metadata Workbench для управления метаданными,

хранящимися в IBM Information Server.

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

Путь внедрения – 1. Проектирование.

Итак, мы имеем два пути внедрения метаданных: Первый путь: Проектирование метаданных, Второй путь: Производство.

Эти два маршрута начинаются в одной исходной точке. На Рис. 6 представлен путь внедрения метаданных, который связан, в основном, с первой частью жизненного цикла метаданных – «Проектирование». Имеются в виду этапы Анализ и проектирования, Моделирование, Разработка, Преобразование, Публикация и Потребление.

Прежде всего, необходимо установить Metadata Server, который поддерживает репозиторий метаданных, и обслуживает сервисы метаданных.

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

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

В качестве четвертого шага мы можем добавить Business Glossary для создания бизнес — классификации.

С тем, чтобы разработать логические и физические модели на пятом шаге может быть добавлен Rational Data Architect.

Шестой шаг – это расширенное использование установленного ранее Information Analyzer

для создания правил выверки данных.

На седьмом шаге мы планируем расширенное использование FastTrack для программирования сквозной обработки информации от источников до систем назначения.

На седьмом шаге можно установить QualityStage и DataStage для разработки и выполнения процедур преобразования данных.

Для размещения интеграционных заданий как сервисов на девятом шаге следует добавить

Information Services Director.

На последнем, десятом шаге, необходимо дать пользователям права доступа к метаданным, и для этого следует добавить Business Glossary Browser and Business Glossary Anywhere.

Путь внедрения – 2. Производство.

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

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

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

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

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

В качестве четвертого шага мы можем добавить Business Glossary для создания бизнес — классификации.

С тем, чтобы разработать логические и физические модели на пятом шаге может быть добавлен Rational Data Architect.

Шестой шаг – это расширенное использование установленного ранее Information Analyzer

для создания правил выверки данных.

На седьмом шаге мы планируем расширенное использование FastTrack для программирования сквозной обработки информации от источников до систем назначения.

На седьмом шаге можно установить QualityStage и DataStage для разработки и выполнения процедур преобразования данных.

Для размещения интеграционных заданий как сервисов на девятом шаге следует добавить

Information Services Director.

На последнем, десятом шаге, необходимо дать пользователям права доступа к метаданным, и для этого следует добавить Business Glossary Browser and Business Glossary Anywhere.

Путь внедрения – 2. Производство.

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

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

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

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

Для выполнения анализа воздействия изменений необходимо добавить Metadata

Workbench.

Расширенное использование продуктов FastTrack и QualityStage позволяет выявить противоречия между словарем и столбцами баз данных.

Расширенное использование Rational Data Architect поможет устранить выявленные противоречия между глоссарием и столбцами баз данных.

Применение программного пакета Metadata Workbench способствует пониманию и управлению информационными активами.

С помощью Business Glossary пользователи могут обновлять бизнес – классификацию в соответствии с новыми требованиями.

Для подготовки отчетов о выявленных рассогласованиях метаданных и других недостатков, желательно использовать Metadata Workbench.

Information Analyzer следует использовать для поддержки единого понимания смысла метаданных.

Для поддержки метаданных и подготовки отчетов о состоянии метаданных могут быть использованы и Metadata Workbench и Web Console.

66

Рис. 7. Путь внедрения метаданных на этапах жизненного цикла «Производство метаданных»

67

Заключение

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

Пошаговое внедрение средств управления метаданными IBM Information Server снижает сроки и трудоемкость реализации проекта, позволяет бизнес – пользователем раньше воспользоваться преимущества управления метаданными, и повышает вероятность успешного внедрения среды управления метаданными.

Эта работа выполнена в рамках инициативы plusOne. Автор выражает благодарность

Anshu Kak за приглашение в проект plusOne и поддержку.

Литература

1. Poole J., Chang D., Tolbert D, Mellor D. Common Warehouse Metamodel: An Introduction to the Standard for Data Warehouse Integration, Wiley, 2003.

2. Marco D., Jennings M. Universal Meta Data Models, Wiley, 2004.

своей природе.

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

В работе [1] было показано, что нормативно-справочная информация включает в себя словари, справочники, классификаторы, кодификаторы, нормативы и идентификаторы.

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

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

Справочник (например, телефонный) ведется сторонней организацией. Нумерация кодов

(номеров телефонов) не подчиняется каким-либо правилам.

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

Норматив может представлять собой просто некоторое числовое значение (например, ставка налогообложения), который получен из неструктурированного документа (приказа, закона, акта). Примером норматива может служить значение ставки налогообложения

13%.

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

Реконсиляция – ручная сверка нескольких версий документа, или записи с целью их согласования.

НСИ и мастер – данные

В отечественной литературе давно устоялось понятие «нормативно-справочная информация», которое появилось в дисциплинах, касающихся управления народным хозяйством еще в докомпьютерные времена [2]. Термин «мастер-данные» пришел к нам из англоязычной документации и, к сожалению, стал использоваться как синоним НСИ. На самом деле между НСИ и мастер-данными есть значительные различия.

Рис. 8. Пример данных, мастер-данных и НСИ

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

Данные пассажира являются не столь стабильными, как коды аэропорта. В тоже время,

будучи один раз введенные в систему, данные пассажира могут быть в дальнейшем

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

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

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

При этом НСИ и МД имеют много общего, поэтому в тех случаях, когда рассматриваемые факторы касаются и НСИ, и МД, мы будем упоминать их как «НСИ и МД», например,

«система ведения НСИ и МД».

Общие недостатки традиционного ведения НСИ и МД

Наиболее распространенной и очевидной проблемой традиционного ведения НСИ и МД является отсутствие поддержки временных изменений. Адрес, как правило, является одной из важнейших компонент НСИ и МД. К сожалению, адреса меняются. Клиент может переехать, но может «переехать» целый дом и даже улица. Так, в 2009 году адрес комплекса зданий «Башня на набережной» изменился с «Краснопресненская набережная, дом 18» на «Пресненская набережная, дом 10». Таким образом, запрос “Какое количество корреспонденции было доставлено в офис компании, арендующей помещения в «Башне на набережной» в 2009 году?” должен корректно обрабатывать записи о доставках с двумя разными адресами.

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

Таким образом, корпоративное ведение НСИ и МД включает в себя три категории мероприятий:

1. Методологические мероприятия, определяющие методы, регламенты, стандарты,

процессы и роли, поддерживающие весь жизненный цикл ведения НСИ и МД

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

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

В данной статье мы рассмотрим, в первую очередь, технологические мероприятия, которые включают в себя создание единой модели данных НСИ и МД, ведение и архивацию исторической НСИ и МД, идентификацию объектов НСИ и МД, устранение дубликатов, выявление противоречий, обеспечение ссылочной целостности, поддержку жизненного цикла объекта НСИ и МД, выработку правил очистки, создание системы

ведения НСИ и МД и ее интеграцию с эксплуатируемыми информационными системами предприятия.

Технологические недостатки ведения НСИ и МД

Рассмотрим более детально технологическую область создания инфраструктуры НСИ и

МД и связанные с ней недостатки традиционного ведения НСИ и МД.

Нет единой модели данных НСИ и МД

Единая модель данных НСИ и МД отсутствует, или она не формализована, что не позволяет эффективно использовать объекты НСИ и МД и затрудняет любую автоматизацию работы с данными.

Модель данных является основной и самой важной частью ведения НСИ и МД, отвечая, к примеру, на следующие вопросы:

что включать в идентифицирующие атрибуты объекта НСИ и МД?

что из всех атрибутов объекта НСИ и МД хранить в модели данных и отнести к НСИ и МД, а что отнести к операционным данным и оставить в эксплуатируемой информационной системе?

как провести интеграцию по модели с внешними идентификаторами и классификаторами (ОКПО, ОКУД)?

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

Нет единого регламента ведения истории и архивации

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

Пример проблем, вызванных отсутствием ведения исторической нормативно-справочной информации приведен в разделе «Выполнение требований закона и снижение рисков»

Сложность отождествления объектов НСИ и МД

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

Возникновение дубликатов объектов НСИ и МД

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

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

Несогласованность метаданных НСИ и МД

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

Ссылочная целостность и синхронизация модели НСИ и МД

В реальной жизни все объекты НСИ и МД, находящиеся в пространстве своей IT системы, содержат в себе не только значения, но и ссылки на другие НСИ и МД, которые могут находиться (и вестись) в отдельных внешних системах. Здесь в полный рост встает проблема синхронизации и поддержки целостности всей модели НСИ и МД организации. Одним из общепринятых путей решения такого рода проблем является переход к использованию НСИ и МД которые ведутся и импортируются в организацию извне (к примеру, справочники КЛАДР, ОКВЭД, ТН ВЭД, ФСКП и ЕКПС).

Рассогласование жизненного цикла объекта НСИ и МД

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

«размазанные» во времени объекты сложно использовать как в транзакционных, так и в аналитических процессах.

Выработка правил очистки

Правила очистки НСИ и МД зачастую вполне справедливо относят к методологическим аспектам. Безусловно, ИТ специалисты нуждаются в постановке задачи от бизнес – пользователей, например, в каких случаях необходимо обновлять коды аэропортов, или какая из двух платежек имеет правильную кодировку реквизитов. Но бизнес — специалисты не знакомы с тонкостями реализации эксплуатируемых ИТ систем. Более того, документация на эти системы или неполна, или отсутствует. Поэтому необходим анализ информационных систем с целью уточнения правил очистки и выявления новых правил.

Неверный выбор мастер-системы ведения НСИ и МД

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

«мастер системы» для ведения НСИ и МД вместо создания специализированного

репозитория НСИ и МД. При этом не принимается о внимание, что подобный функционал, как правило, является несвойственным этой ИТ системе. В результате любые доработки таких систем, связанные с НСИ и МД, выливаются в крупные и необоснованные траты. Ситуация усугубляется, когда по мере развития подсистемы ведения НСИ и МД необходимо ввести качественно новый функционал: пакетную обработку данных, форматирование и очистку, назначить стюардов данных.

Неготовность ИТ систем к интеграции НСИ и МД

Для того, чтобы полноценно внедрить ведение НСИ и МД в существующие ИТ системы предприятия, необходимо провести интеграцию этих систем и, чаще всего, эта интеграция необходима не как единовременный и локализованный акт, а как изменение процессов, живущих внутри ИТ систем. Помимо интеграции для работы в операционном режиме (online), необходимо провести интеграцию для проведения первоначальной пакетной загрузки данных (ETL), а также для проведения процедур ручной сверки (реконсиляции).

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

Примеры проблем традиционного ведения НСИ и МД

Таким образом, основные проблемы ведения НСИ проистекают из-за децентрализации и фрагментации НСИ на предприятии и проявляются на практике в конкретных примерах.

Паспортные данные как уникальный идентификатор

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

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

Адрес как уникальный идентификатор

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

Необходимость массового переоформления договоров

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

Расхождение согласованных данных

Четвертый пример описывает типичную ситуацию для многих организаций. В результате бурного развития бизнеса предприятия было решено открыть новое направление, поддерживающее работу с клиентами в стиле B2C / B2B через Интернет. Для этого была приобретена новая ИТ система, поддерживающая автоматизацию нового направления бизнеса компании. При развертывании возникла необходимость провести интеграцию с существующими НСИ и мастер-данными предприятия и расширить их специфичными атрибутами, что оказалось не так просто, в первую очередь из-за отсутствия выделенной системы НСИ и МД. В результате НСИ были однократно загружены в новую систему безо всякой обратной связи с существующим ИТ ландшафтом компании, что через некоторое привело к двум независимым версиям клиентских справочников. Поначалу проблема решалась путем ручной обработки клиентских данных в электронных таблицах, однако через некоторое время количество клиентов значительно возросло, справочники

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

Преимущества корпоративного ведения НСИ и МД

Корпоративное ведение НСИ и МД обеспечивает следующие преимущества:

Выполнение требований закона и снижение рисков

Рост прибылей и удержание клиентов

Снижение затрат

Повышение гибкости для поддержки новых бизнес стратегий.

Звучит слишком хорошо, чтобы быть правдой, поэтому рассмотрим каждое из преимуществ на практических примерах.

Выполнение требований закона и снижение рисков

Следственные органы потребовали от крупной компании предоставить данные за предыдущие 10 лет. Задача казалась несложной и выполнимой: компания задолго до этого ввела процедуры регулярного архивного и резервного сохранения данных и прикладных программ, носители данных хранились в защищенном помещении, аппаратура для чтения носителей еще не успела устареть. Однако после восстановления исторических данных из архива обнаружилось, что данные не имеют практического смысла – НСИ за это время неоднократно менялась, и теперь невозможно установить, к чему относились те или иные данные. Никто не предусмотрел архивирование НСИ – казалось, что это устойчивая ко времени информация. На компанию были наложены значительные штрафные санкции, в компании были сделаны серьезные организационные выводы в отношении руководителей. Кроме того, было создано подразделение, отвечающее за ведение НСИ, чтобы избежать повторения неприятной ситуации.

Рост прибылей и удержание клиентов

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

Снижение затрат

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

Повышение гибкости для поддержки новых бизнес стратегий

Устранение фрагментации и децентрализации ведения НСИ и МД позволяет предоставлять информацию как сервис. Это означает, что любая ИТ система, соблюдая установленные протоколы обмена и права доступа, может обращаться к системе корпоративного ведения НСИ и МД и получать необходимые данные. Сервис — ориентированный подход позволят гибко выстраивать информационные сервисы в соответствии с изменяющимися бизнес – процессами, обеспечивая таким образом своевременную реакцию ИТ служб и систем в условиях изменяющихся требований.

Архитектурные принципы системы ведения НСИ и МД

В работе [3] приведены основные архитектурные принципы построения системы управления мастер-данными. Кратко перечислим их:

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

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

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

Система ведения мастер-данных должна отвечать требованиям безопасности и защиты данных.

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

На основании рассмотренных практических примеров мы можем расширить список архитектурных принципов дополнительными требованиями к системе ведения НСИ и МД:

Система ведения мастер-данных должна строиться на основании единой модели НСИ и МД. Без единой модели данных невозможны создание и эксплуатация системы ведения мастер-данных в качестве единого корпоративного источника мастер-данных.

Необходим единый регламент ведения истории и архивации. Его назначение – обеспечение возможности работы с историческими данными для повышения точности аналитических работ, выполнения требований закона и снижения рисков.

Должна быть обеспечена возможность отождествления объектов НСИ и МД и устранение их дубликатов. Без отождествления невозможно построение единой модели НСИ и МД и затруднительно выявление дубликатов, которые ведут дублированию «точек входа», к росту расходов на обработку объектов и на поддержание жизненных циклов объектов.

Метаданные НСИ и МД должны быть согласованы. Рассогласование приводит к тому, что даже если удается создать единую модель НСИ и МД, на самом деле эта модель не является качественной из-за того, что разные объекты могут в действительности оказаться дубликатами из-за разных описаний и представлений.

Должна поддерживаться ссылочная целостность и синхронизация модели НСИ и МД. В зависимости от выбранной архитектуры модель НСИ и МД может содержать как объекты, так и ссылки на них. То есть, отсутствие синхронизации и поддержка целостности необходимы для создания единой модели НСИ и МД.

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

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

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

Система ведения НСИ и МД должна учитывать неготовность ИТ систем к интеграции НСИ и МД. Интеграция систем требует встречных действий: существующие системы должны быть доработаны с учетом требований централизованного ведения НСИ и МД.

Заключение

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

Как следует из приведенных практических примеров, основные технологические проблемы ведения НСИ и МД вызваны децентрализацией и фрагментацией НСИ и МД на предприятии, для устранения которых сформулированы и предложены требования к системе ведения НСИ и МД.

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

Литература

1. Асадуллаев С., «Данные, метаданные и НСИ: тройная стратегия создания хранилищ данных», 09.07.2009, http://www. ibm. com/developerworks/ru/library/r-nci/index. html

2. Колесов А., «Технология управления НСИ корпоративного уровня», PC Week/RE, №

18(480) 24 — 30 Мая 2005 г., http://www. pcweek. ru/themes/detail. php? ID=70392

3. Oberhofer M., Dreibelbis A., «An introduction to the Master Data Management Reference

Architecture», 24.04.2008, http://www. ibm. com/developerworks/data/library/techarticle/dm-

0804oberhofer/

Об авторах

Сабир Асадуллаев более 25 лет работает в информационных технологиях. Является специалистом в области проектирования хранилищ данных и ведения корпоративных метаданных. Руководил ИТ проектами в нефтегазовой отрасли, в банковской сфере, на транспорте, в науке и других областях в Европе и в Северной Америке. Обладает опытом организации коллективной разработки программного обеспечения и создания офиса управления проектами (PMO). Работая в IBM c 2006г, подготовил ряд ключевых архитектурных решений для крупнейших клиентов IBM. Окончил физический факультет МГУ (1979), кандидат физ-мат. наук (1986), сертифицированный руководитель проектов (2001), лучший архитектор CEMAAS IBM (2006), сертифицированный архитектор корпоративных решений IBM (2008), исполнительный архитектор (2010). Автор более 30 публикаций в ИТ, астрономии и биологии.

Александр Карпов является специалистом в области интеграционных решений для банковских систем, прежде всего в области консолидации платежей и интеграции с системой SWIFT, имеет 13 летний опыт работы в ИТ индустрии, в том числе более 3 лет работы с крупными клиентами IBM в России в финансовом секторе. Начинал карьеру программистом в проектах розничных услуг и создании систем безопасности. Имеет опыт руководства разработкой архитектур распределенных ИТ систем в банковской области и финансовых рынков. Участвовал во внедрении централизованного управления НСИ в крупном банке. 3 года работал в крупном российском банке. Имеет высшее техническое образование, сертифицирован по TOGAF 8 (2009), сертифицированный архитектор IBM (2009).

Материал взят из: Архитектуры хранилищ данных Стратегия создания хранилищ данных Управление метаданными и НСИ — Сборник статей