На прошлой недели меня пригласили на встречу, организованную для ИТ директоров одним из известных поставщиков решений класса master data management. Значительная часть обсуждения была посвящена вопросу как «продать» бизнес-заказчику MDM решение. Безусловно, у такого рода проектов должен быть именно бизнес-заказчик. Однако, выгоды внедрения новой системы для ИТ тоже должны быть обозначены. Иначе ИТшники будут сидеть и ждать пока бизнес созреет и сам принесет им MDM-проект. Ниже я постарался набросать несколько собственных мыслей на тему зачем нужен MDM ИТ директору.
Через десять лет после публикации статьи о реляционной модели данных, в декабре 1979-го, Эдгар Ф. Кодд написал работу «Extending the Database Relational Model to Capture More Meaning» (см. Расширение реляционной модели для лучшего отражения семантики). Это работой он ответил на доброжелательные и, вероятно, не очень доброжелательные отзывы на свою первую статью, открывшую миру реляционную модель
Реляционная модель для форматированных баз данных была задумана уже десять лет назад, главным образом, как инструмент, призванный освободить пользователя от потребности иметь дело с нагромождением деталей представления данных в среде хранения… В течение нескольких последних лет работы многих исследователей были нацелены на сохранение (достаточно формальным образом) большего смысла данных при сохранении независимости от реализации. Эту деятельность иногда называют семантическим моделированием данных (semantic data modeling)
По сути, Кодд согласился с необходимостью внесения большей семантики в реляционную модель и даже сформулировал несколько предложений на этот счет. Первым делом, он выделил из всех сущностей вспомогательные. Не смотря на то, что любые сущности в реляционной модели представляются одинаково, некоторые из них несут иную смысловую нагрузку, чем стержневые (kernel) или основные сущности. Групп вспомогательных сущностей получилось две. Во-первых, это сущности, характеризующие какие-либо другие стержневые или вспомогательные сущности. Во-вторых, это ассоциации, т.е. сущности, призванные отобразить отношения между какими-либо иными сущностями. Точно так же свойства объектов были классифицированы Коддом на непосредственные, т.е. неразрывно связанные с сами объектом, и косвенные. Кроме того, в отдельную группу попали многозначные свойства, представляемые обычно свойствами не основной, а характеристической функции.
Упомянутая выше работа Кодда не приобрела такой же известности, как реляционная модель. Поэтому, значительная часть разработчиков, при написании баз данных не сильно задумывается, о классификации сущностей и их свойств и отображении в модели семантики предметной области. Традиционным запросом к разработчикам заказных приложений является просьба добавить пару полей в одну табличку, пару полей в другую и т.п. Такие изменения, естественно, осуществляются в ходе релизов, а потому происходят долго и стоят дорого. По мере развития организации, информационных систем в ней становится все больше, структуры данных все запутанней, интеграция все сложней, а функционал работы с основными данными все дальше и дальше от идеального. Ничто не мешает нам разрабатывать приложения с нормальной организацией данных. Ничто, кроме сроков запуска, ограниченного бюджета и, как следствие, необходимости довольствоваться услугами разработчиков не самой высокой квалификации. Особенно это становится заметным из-за ныне модной передачи заказной разработки на аутсорсинг и сокращения ИТ бюджетов, последовавших за приходом первой волны кризиса.
В связи с этим, у организаций на сегодняшний день есть три пути управления основными данными. Первый заключается в том, чтобы ничего не делать. Понемногу, по заявкам пользователей, дорабатывать структуру существующих баз данных, интегрировать их, по мере необходимости, ругать программистов, разработавших когда-то плохие модели данных. Это путь при котором мы будем тратить наш ИТ бюджет маленькими порциями на всякую ерунду. Второй – все переделать. Для этого придется обучить собственных разработчиков и аутсорсеров, переработать большинство существующих систем, оснастить их современными программными интерфейсами и наладить архитектурный надзор за внесение изменений в структуру баз данных. Миссия благородная, но невыполнимая. И наконец, можно навести порядок с основными данными в одной системе и не трогать другие. Третий путь предполагает отказ от сколь либо существенных доработок баз данных в унаследованных приложениях и развитие структур данных в рамках одного решения – MDM. Для этого придется проинтегрировать MDM с основными системами, однако, построение зависимостей, классификаторов и ассоциаций станет возможным посредством настроек или операций, совершаемых пользователем (см. Таксономия и фолксономия). Для других приложений, основные данные станут доступны через стандартизированные, повторно-используемые интерфейсы. Работа пользователей по вводу, а при необходимости согласованию основных данных будет сосредотачиваться в едином, предназначенном для этого инструменте.
Дальше надо считать что выгодней: понемножку «допиливать» множество систем, попутно интегрируя их друг с другом, или вложиться в одну систему, создать команду по её конфигурированию и выстроить соответствующий процесс управления изменениями.