В конце июля – начале августа этого года 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 – тема не очень новая и не очень сложная. Введение в тему можно почитать в статье Задачи управления мастер-данными Некоторое замешательство могут вызвать русскоязычные аналоги этого понятия «управление основными данными» и «нормативно-справочная информация». Но, в общем и целом большинству людей понятно, что речь идет о синхронизации справочников из различных информационных систем предприятия. Есть транзакционные данные, т.е. записи о конкретных операциях и есть справочники, на которые ссылаются транзакционные данные. Под мастер-данными (основными данными) и понимают справочники в широком смысле, т.е. существительные, отвечающие на вопросы «кто?» (клиенты, сотрудники, партнеры), «что?» (продукты, услуги), «где?» (адреса) и т.д. Наведение порядка в справочниках – задача скорее организационная, чем техническая. Впрочем, технические проблемы, являющиеся в данном случае прямым следствием организационно-политических причин, присутствуют тоже
Есть и еще один термин: “интеграция данных”, при которой большую роль играют справочные данные (reference data, а не master data). В инженерии это крайне важная штука, ибо MDM решения по факту работают только в масштабе предприятия, а вот работа со справочными данными и интеграция данных предполагает в том числе и работу в составе расширенного предприятия (extended enterprise), то есть по факту “в масштабах отрасли” (ибо речь идет о предприятиях, выполняющих крупные инжиниринговые проекта — часто множество в разных вариантах кооперации с другими предприятиями). Для этого есть разные варианты стандартов интеграции данных — и они основываются на онтологиях, а не просто “словарях-справочниках”. Мы, например, используем ISO 15926.Это, кстати, полностью отражает подмеченный вами ход на неминуемую семантизацию/онтологизацию (только ISO 15926 будет много покруче semantic web. Хотя и он явно не последнее слово онтологической инженерии).
Reference data – крайне важная штука не только в инженерии. 🙂 Я думаю, что существенен следующий аспект. Нужно ли уделять внимание мастер данным и как их структурировать решает сама организация. А вот референсные данные, действительно, создаются “в масштабах отрасли” или даже домена.
Когда-то, список стран и курсы валют получали из ERP системы. Уже лет, наверное, десять никто и не подумает оформлять заявку на доступ к ERP, чтоб узнать курс.
Справочников адресов телеком-операторы когда-то вели самостоятельно. В какой-то момент появился КЛАДР ну и т.д. Может я излишне оптимистичен, но я думаю, что рано или поздно наступит момент, когда реквизиты контрагента, полученные из Интернет будут более актуальны, чем те же данные, полученные из внутренней финансовой системы компании, а данные абонента мы будем получать не из CRM, а из социальных сетей.
На что все это влияет? Сейчас организации сами решают нужен ли им MDM и как организовывать свои основные данные. При этом, от глупостей в построении справочников, классифицировании объектов, создании таксономий никто не застрахован. Для референсных же данных, скорее всего, будут выработаны более качественные и более легитимные подходы, т.к. делаться это будет не только в рамках одного предприятия.
Нашёл Ваш блог случайно — очень рад! И пост как раз “в жилу”, я сейчас как раз занимаюсь проектом, связанными с управлением справочными данными.
Для финансовых организаций управление справочными данными тоже одна из ключевых проблем, во всяком случае на западе. И без целостной технологической поддержки, одними административными методами, толком не решаемой. В компании, где сейчас работаю — средних размеров, занимающейся управлением инвестфондами — как раз много текущих проблем из-за этой однобокости в прошлом, которые сейчас преодолевать приходится.
И, кстати, мы тоже используем SMW для представления архитектуры предприятия. Пришлось правда пару расширений “на коленке” сделать, так как платформа ещё очень и очень далека от зрелости. Я посмотрел Вашу презентацию по ссылке, деталей не много, но выглядит очень похоже. Приходилось ли Вам дорабатывать движок напильником? Скажите, насколько далеко Вы продвинулись внедряя SMW в управление архитектурой?
Если говорить в двух словах, то я считаю, что мы “не выжали” из проекта c SMW всех возможностей. Архитекторы продолжают её использовать(конечно же без доработок не обошлось) для документирования архитектуры проектов, но другие подразделения компании остаются “читателями”. Идея семантических ссылок в масштабах компании, безусловно, осталась не понятой. До разработки систем на SMW, как это делает Ryan Lane http://ryandlane.com/wiki мы не дошли.
Более успешным явился опыт отображения на SMW не архитектуры предприятия, а системной архитектуры интеграционных сред. Наверное потому, что в системной архитектуре объекты и отношения между ними менее абстрактные. Реальные компоненты проще отобразить в категории, а используемые интерфейсы отиграть гиперссылками.
Может быть, кто-нибудь из нашей команды меня дополнит?
Любопытные вещи делает Ryan Lane. Спасибо, присмотрюсь.
Если под MDM понимать ту ее распространенную интерпретацию, которая требует создания централизованного репозитария мастер-данных, то такая парадигма, очевидно, будет понемногу (а может и быстро) загибаться – все это никак не пилится с концепцией облачных сервисов и распределенного хранения и обработки информации. Занимаюсь сейчас этим в практическом смысле – делаем софт, обслуживающий произвольные распределенные справочники
Вот простой пример от нашего клиента – большая компания, имеющая структурные подразделения в нескольких странах. Обычный справочник, отражающий структуру и штатное расписание такой компании, надо делать распределенным – если делать это хорошо, так как обособленные подразделения сами ведут свою структуру и свое штатное расписание, а интегрирующий софт должен представлять все это в одном иерархическом справочнике, доступном откуда угодно
MDM с централизованным репозитарием, где есть только одна главная копия всех справочных данных, такую естественную задачу не решает
Интересный у вас софт. Это заказная разработка или продукт?
Я думаю, что облачные вычисления, наоборот, приведут к уменьшению количества справочников и подходов к их составлению. Понятно, что часть справочников, та же организационная иерархия тяготею к распределенности. Но множество справочников, особенно в больших многофилиальных компаниях частично или полностью дублируют друг-друга. Здесь к технологиям информационным необходимо добавлять технологии управленческие. Пока такие справочники распределены по системам, дублирование данных не очевидно, а когда вытащишь их в единое хранилище картинка становится прозрачней.
Ну да, само понятие справочника в облаках меняется, по крайней мере, в русскоязычном толковании – мы считаем, что справочник, как правило, это такая таблица, а вот англоязычное понятие reference data вполне себе актуально смотрится и в облаках, где минимальная единица данных справочника представлена как элемент данных, доступный по ссылке, т.е. это фактически не таблица, а запись
Дублирование IMHO это то, что в облаках будет считаться естественным и нормальным и от чего избавиться будет нельзя в принципе. Необходимо будет только такие дублированные данные снабжать 1) уникальным идентификатором типа GUID и 2)адресом, т.е. ссылкой, чтобы маркировать множество копий одних и тех же данных.
Разумная (и даже) неразумная избыточность и дублирование информации присутствует всюду в живой природе и является конкурентным преимуществом 🙂
Это тиражируемый прикладной продукт, имеющий бесплатную версию (в данном блоге у меня нет цели про него рассказывать :), так что подробности опущу.
Многие из тех, кто понаделали за годы разных справочников, пришли к мысли о необходимости универсального инструмента, администрирующего управление распределенными структурированными данными, в частности, справочниками. Облака, в которых реляционные БД с взаимосвязанными “нормализованными” таблицами не работают, усилили проблему распределенной обработки данных в современных СУБД.
Та же СУБД MS SQL Server не приблизилась, а максимально отдалилась от файлов – файл с базой данных уже нельзя просто переписать на другой компьютер, работать не будет.А ведь в облаках уже и файл слишком большой объект для адресации, нужна возможность адресовать собственно элементы данных, разбросанные в произвольном порядке по HTML-страницам – появление всевозможных RSS и других XML-структур, виджетов с доступом к БД на HTML-страницах и т.п. это ответ на потребность интеграции структурированных данных и неструктурированной информации.
Уже ощущается потребность полностью компоновать новые web-приложения на распределенных иерархических адресуемых структурах данных, доступных друг из друга по ссылкам и хранящихся как в текстах документов, так и в файлах и в таблицах БД. В частном случае такие структуры данных будут представлять собой распределенные справочники. От вендоров ничего реально функционирующего пока не последовало на эту тему – провал MDM это подтверждает (я ваще не понимаю, как они собираются отделять “master” данные от всех остальных, критерий очевидно ущербный)
Ниже моя концепция на эту тему, которую мы, я надеюсь, в каком-то виде скоро реализуем в своей ACM – сама задача возникла потому, что в простой и эффективной ACM системе встала проблема как привязывать справочники и таблицы с данными к сообщениям, а делать это традиционными способами означает гробить на корню саму концепцию ACM как простой в разворачивании и использовании системы
Такие реально распределенные структуры данных будут базироваться на использовании тегов данных (datatags – это я их так называю), представляющих собой расширение понятия тегов для обеспечения возможности маркировки распределенных в облаке данных. Сами справочники данных могут представлять собой аналог обычных таблиц СУБД, а также XML-структур, представляющих такие таблицы, доступ к которым осуществляется через их URL-адрес. Сами данные могут содержать такие же datatags – в результате образуется адресуемое пространство тегов данных, аналогичное web-линкам. С той разницей, что пространство web-ссылок связывает неструктурированную информацию, а пространство тегов данных позволяет связать и обработать распределенные структурированные данные – ну, в частности, таким инструментарием легко и просто будет решаться вышеупомянутая задача ведения структуры и штатного расписания большой географически распределенной компании – каждое подразделение будет вести свой кусочек, а вся большая структура будет сама как мозаика собираться вместе из этих кусочков и видна откуда угодно по ссылкам, да еще и в любых разрезах – это ж данные, по ним любые фильтры можно будет делать
Интересный у вас продукт. Ссылочкой не поделитесь, а?
Про провал MDM это Вы зря. Объективная реальность против. Вон, хотя бы, гартреровская диаграмма в верху страницы говорит, что системы MDM, можно сказать, только-только взрослеть начинают. А “мастер” данные от “остальных” отделить легко: что не является транзацией, то является записью в справочнике.
– с некоторых пор я решил, что ссылки на свой продукт в чужом блоге не очень неуместны 🙂
– мне лично кажется, что диаграмм Гартнера с очередной 3-хбуквенной аббревиатурой с очередными “визионерами”, которые так и не успевают стать “лидерами”, потому, что аббревиатура перестает использоваться вместе с ее концепцией – как минимум много
– останусь при своем мнении, что «мастер» данные от «остальных» отделить, в общем случае 1) нелегко и 2) не нужно. Тот же пример с ведением распределенной структуры предприятия – те же справочники подразделений, должностей etc. вроде бы мастер данные, а не транзакции, ан нет – реструктуризация на предприятии превратилась в непрерывный процесс и требуется вести эту структуру с сохранением ее состояния за прошлые периоды – вот вам и транзакции.
Иванова вышла замуж, стала Петровой – в прошлогоднем приказе о начислении премии она Иванова, в нынешнем приказе о предоставления отпуска она уже Петрова, а ссылки в СЭД из обоих документов должны указывать на данные об одном человеке, и желательно, чтобы факт смены фамилии в этих данных был отражен – вот вам и необходимость интеграции справочных данных и транзакций и невозможность их разделить