Долгое время в психологии существовал в качестве неоспоримой истины “постулат непосредственности”, который гласил, что “объективная действительность непосредственно и сразу влияет на психику и определяет ее деятельность” [1]. В 1941 году этот постулат был разрушен главой тбилисской школы психологии Д. Н. Узнадзе, который экспериментально установил наличие особого посредника между внешним миром и психикой человека. Роль этого посредника состояла в выработке “целостного отражения” реальности.

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

Путь к “целостному отражению” начался в ИТ-отрасли давно. Специалисты пытались создавать корпоративные словари-справочники задолго до появления в 1990 году идеи хранилищ данных. Результатами этих усилий были таблицы согласования и перекодировок, централизованные словари данных. Наконец умы специалистов захватила идея единого репозитория для описания метаданных — семантических структур, в контексте которых существуют данные.

Один из родоначальников теории хранилищ Билл Инмон в 1997 году писал, что “метаданные — это нервная система архитектурно выдержанной информационной инфраструктуры, без которых последняя является лишь набором независимых элементов, решающих не связанные между собой задачи” [2].

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

Метаданные включают не только описания бизнес-терминологии, но и информацию о способах физического хранения данных (схемах БД, индексах), технологиях подготовки выборок информации из различных источников, топологии программных компонентов и т. п.

Еще год назад существовало два центра создания метамоделей — ассоциации MDC (MetaData Coalition) и OMG (Object Management Group, http://www.omg.org). Первая занималась созданием открытой информационной модели (OIM, Open Information Model), вторая работала над общей моделью хранилища данных (CWM, Common Warehouse Model). К счастью, сегодня мы уже имеем единый процесс стандартизации метамодели информационной инфраструктуры: MDC и OMG объединили свои усилия в процессе создания CWM.

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

“Сегодня мы уже имеем инструменты и технологии, реализующие возможности оперативной обработки OLTP, оперативных хранилищ ODS и хранилищ данных в единой базе данных», — говорит Дуглас Хэкни, эксперт в области информационных хранилищ. По его мнению, эти технологии в ближайшие годы станут “мэйнстримом” в отрасли [3].

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

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

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

Проверенные методы инкрементального построения хранилищ данных позволяют в значительной степени снизить риски проекта. В частности, подход “снизу вверх” [4] и метод “федеративных архитектур” [5] помогают разбить процесс построения хранилища данных на несколько последовательных этапов, на каждом из которых строится элемент хранилища, описывающий состояние определенной предметной области.

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

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

Однако не стоит забывать, что фокусировка на идеальном (т. е. присутствующем в сознании как идея) “целостном отражении” может рассеиваться в сильном поле политических страстей: получив эффект от витрины данных, предприятие может оказаться перед соблазном остановиться на достигнутом. В результате вместо единой модели предприятия будет получен представленный “калейдоскопом” витрин набор не согласующихся между собой частных мнений о том, как живет бизнес. Такое “АРМированное” хранилище данных, скорее всего, не оправдает возлагаемых на него надежд. Ведь смысл создания хранилища заключается в появлении новой реальности — модели предприятия, воплощающей “целостное отражение”. Ранее такой реальности ни в одном элементе информационной инфраструктуры не существовало. В инфраструктуре не было механизма, который, вбирая потоки оперативной информации, обобщал бы ее и выкристаллизовывал суть деятельности компании в стратегической перспективе. Подсистемы, собираемые в информационную инфраструктуру корпорации, согласовывались на физическом уровне в целях соблюдения технических регламентов. При этом каждая подсистема имела свою задачу — эффективно поддержать отдельный процесс.

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

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

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

“Эксперименты” во всем мире подтверждают, что построенная нами фантасмагорическая картина в духе Филонова близка к реальности. Некоторые источники утверждают, что 88% проектов построения хранилищ данных выходят за временные или бюджетные рамки и терпят крушение. А в скольких из них был найден компромисс там, где нет места компромиссам? Ведь “целостное отражение” достигается там, где у истины нет версионности.

Евгений Аксенов — генеральный директор компании "Алеф Консалтинг & Софт" (http://www.alef.ru). С ним можно связаться по e-mail: evgeny@alef.ru.

Источники информации

1. Узнадзе Д. Н. Экспериментальные основы психологии установки. — В сб. Психологические исследования. — М., 1966.

2. W. H. Inmon. Metadata in the data warehouse: A statement of vision. http://www.inmon.com.

3. Douglas Hackney. Data Warehouse Delivery: The Future is Now. — DMReview. December 2001. http://www.dmreview.com.

4. Douglas Hackney. Data warehouse Delivery. Who are you? — DMReview. February, April 1998. http://www.dmreview.com.

5. Douglas Hackney. Data warehouse Delivery. Federation Variation. — DMReview. May 2001. http://www.dmreview.com.