Метка: НСИ

Как внести больше смысла в структуры основных данных

На прошлой недели меня пригласили на встречу, организованную для ИТ директоров одним из известных поставщиков решений класса master data management. Значительная часть обсуждения была посвящена вопросу как «продать» бизнес-заказчику MDM решение. Безусловно, у такого рода проектов должен быть именно бизнес-заказчик. Однако, выгоды внедрения новой системы для ИТ тоже должны быть обозначены. Иначе ИТшники будут сидеть и ждать пока бизнес созреет и сам принесет им MDM-проект. Ниже я постарался набросать несколько собственных мыслей на тему зачем нужен MDM ИТ директору.

Continue reading «Как внести больше смысла в структуры основных данных»

Master Data Management, EDA, ESB, SOA: собираем все вместе

Реализация повторно используемых интерфейсов предполагает, что мы будем хотя бы чуть-чуть абстрагироваться от конкретных задач и требований сегодняшнего дня. Иначе интерфейсы нам придется переделывать постоянно. Повторю пример из комментариев к сообщению Как сделать хороший API? При разработке программного интерфейса к каталогу книг методы

 

getBookAuthor(…) и getBookPublisher(…)

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

getBookProperty(authorID,…)

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

getItemProperty(itemID, propertyID,…)

Преимущества такого подхода достаточно очевидны. Впрочем, в дополнение к преимуществам появляются и определенные сложности. Одна из них состоит в необходимости разработки дополнительных функций для получения списка item-ов и списка их свойств. Причем перечни свойств элементов различных типов может не совпадать. Описание структуры данных принято выносить в мета-данные (meta-data management). Т.е. у нас должен появиться справочник, в который мы будем вносить эти данные и программные интерфейсы для чтения этих справочников из приложений. Вот мы и добрались до управления основными данными (master data management, нормативно-справочная информация) о котором говорили в сообщении Интерес к управлению данными возвращается Это станет особенно актуальным если информацию получать мы будем из нескольких разнородных приложений с различными программными интерфейсами. Кстати именно в этом случае нам понадобится ESB и управляемая событиями архитектура (Even-driven architecture) Может показаться, что я противоречу своим более ранним сообщениям. Однако, если разобраться чуть глубже, то станет понятно почему это не так (см. рисунок)

В каждом из унаследованных приложений свои структуры данных и свои программные интерфейсы (в одном книжки, в другом компакт-диски ). В каждом, в лучшем случае, свои справочники свойств или же тривиальный хардкод, что встречается чаще. Первое что нужно сделать – научить приложения уведомлять MDM-систему обо всех изменениях в справочниках (Event Driven стиль). В крайнем случае, можно наладить ETL процесс, который будет регулярно сканировать базу данных на предмет выявления изменений и отражать их в MDM. Для того чтоб получить перечень свойств книг или перечень свойств компакт-дисков, очевидно, не следует вызывать API унаследованных приложений, а следует обратиться к MDM системе. (Подробнее см. Gregor Hohp Programming Without a Call Stack – Event-driven Architectures) И в завершении картинки у нас появляется сервисная шина предприятия (ESB), которая берет на себя функции преобразования запросов из getItemProperty() в реализованный унаследованным приложением getBookAuthor(), а так же маршрутизации запросов между приложениям. Кроме того, ESB окажется полезным и при чтении MDM, например, для сокрытия задержек обновления данных в MDM, кеширования запросов и т.д. Сам процесс обновления данных в MDM системе можно и даже нужно реализовать в ESB, т.к. это позволит нам реализовать достаточно эффективные стратегии управления данными. Не стану углубляться в подробности, т.к. описание данных стратегий потребует некоторого погружения в описание архитектуры Web. Интересующихся отсылаю к диссертации изобретателя стиля RESTful Роя Филдинга (краткое введение в тему RESTful и Enterprise 2.0)

Интерес к управлению данными возвращается

В конце июля – начале августа этого года Gartner выпустил целую серию исследований посвященных управлению данным:

  • Hype Cycle for Data Management, 2011
  • Hype Cycle for Master Data Management, 2011
  • CIO Alert: You Need Information Professionals
  • и еще несколько статей

Интерес к теме управления данными у Gartner присутствовал всегда, но если раньше в исследованиях преобладали рассуждения о роли управления основными данными (master data management) для успеха SOA или BPM проектов, то сейчас тема данных стала вполне самодостаточной. На вершине пика завышенных ожиданий информационной архитектуры предприятия находится Semantic Web. Правда в мэйнстрим корпоративных информационных систем попадет он еще не скоро. О возможностях использования Semantic Mediawiki для отображения архитектуры предприятия я рассказывал некоторое время тому назад на заседании Клуба архитекторов Microsoft и на SOA мероприятии AHConference Архитектура предприятия в формате Semantic Web Подходят к пику ожиданий: Complex-Event Processing, Enterprise Taxonomy and Ontology Management (Таксономия и фолксономия), Data Services, Enterprisewide Metadata Repositories.

А вот Master Data Management покинул пик ожиданий и начал сползать в котлован разочарований. Т.е. интерес к MDM будет угасать, а недовольство высокой стоимостью MDM решений – расти. На мой взгляд, это совершенно несправедливо, т.к. практической пользы от MDM можно получить существенно больше, чем например от сервисов. Master Data Management — тема не очень новая и не очень сложная. Введение в тему можно почитать в статье Задачи управления мастер-данными Некоторое замешательство могут вызвать русскоязычные аналоги этого понятия «управление основными данными» и «нормативно-справочная информация». Но, в общем и целом большинству людей понятно, что речь идет о синхронизации справочников из различных информационных систем предприятия. Есть транзакционные данные, т.е. записи о конкретных операциях и есть справочники, на которые ссылаются транзакционные данные. Под мастер-данными (основными данными) и понимают справочники в широком смысле, т.е. существительные, отвечающие на вопросы «кто?» (клиенты, сотрудники, партнеры), «что?» (продукты, услуги), «где?» (адреса) и т.д. Наведение порядка в справочниках – задача скорее организационная, чем техническая. Впрочем, технические проблемы, являющиеся в данном случае прямым следствием организационно-политических причин,  присутствуют тоже