Автор: Richard Skriletz
Дата публикации оригинала: 2007-05-15
Перевод: Олег Кузьменко
Источник: Сайт BeyeNETWORK

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

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

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

Есть несколько причин, по которым не следует привязывать решение по основным данным к какому-нибудь приложению или платформе:

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

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

Модификация приложения может привести к тому, что его трудно будет поддерживать в актуальном состоянии в плане апгрейдов и улучшений, особенно это верно для покупного ПО (мне несколько раз приходилось работать с клиентами, которые не могли перейти на новую версию, потому что тогда бы потребовалось много времени и денег для того, чтобы накатить на новую версию те специфичные «улучшения», которые были сделаны в текущей версии и которые уже используются бизнесом – ситуация, которая не разрешится до тех пор, пока само приложение, за немалую сумму, не будет заменено или модернизировано путем внесения большого количества изменений);

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

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

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

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

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

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

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

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

Платформа и логистика
 Где будет находиться репозиторий основных данных? Каким образом основные данные будут предоставляться приложениям, хранилищам данных, витринам, а также пользователям? Будут ли поддерживаться все технические платформы, используемые для всего вышеперечисленного; если нет, то как можно избежать появления несогласованности в основных данных?

Данные и их семантика
 Какие атрибуты будут включены в основные данные, а какие останутся в прикладных системах? Почему отобранные атрибуты считаются основными данными (централизация данных не является веской причиной)? Требуются ли неструктурированные данные?

Основные данные и интеграция приложений
 Если приложению нужно, чтобы основные данные находились у него под рукой, как добиться того, чтобы находящиеся под рукой основные данные не расходились с репозиторием? Когда приложения «разделяют» или передают основные данные одно другому, как добиться синхронизации основных данных по всему предприятию? Когда эти приложения используют идентификаторы и ключи, отличающиеся друг от друга, а также от тех, что используются в репозитории, то как сохранить правильность основных данных даже тогда, когда используются разные ключи?

Предоставление данных и безопасность
Основные данные будут одними из самых конфиденциальных на предприятии – как контролировать доступ к ним? Будут ли основные данные шифроваться? Будут ли они передаваться в приложение в зашифрованном виде? Какие протоколы будут использоваться для сервисов по предоставлению и авторизации доступа к основным данным?

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

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

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

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


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: