Глава 11. Планирование и проектирование данных

В главе 9 «Управление данными: принципы и структуры» говорилось о том, что деятельность по непосредственному управлению жизненным циклом данных сосредоточена на трех направлениях, соответствующих основным фазам жизненного цикла (см. рис. 9.4):

1.планировании и проектировании данных;

2.обеспечении доступности и обслуживании данных;

3.практическом использовании данных и расширении возможностей их применения для достижения целей организации.

Сравнивая цепи поставок продукции с цепочками поставок данных, мы уже отмечали, что управление и тем и другим начинается с процессов планирования и проектирования (см. главу 7). В текущей главе мы обсудим это важное направление и такие вопросы, как:

●роль концепции архитектуры предприятия в планировании и проектировании различных сторон деятельности организации;

●основополагающее место архитектуры данных в управлении данными;

●цели моделирования данных и связанные с ним артефакты.

11.1.Архитектура данных

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

1.В рамочной модели управления корпоративной информацией (рис. 7.7) частные политики, процессы, процедуры и стандарты, поддерживающие политику работы с информацией, опираются на информационную архитектуру, формируемую в соответствии с датацентричным подходом (рис. 6.2).

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

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

11.1.1. Определение области знаний «Архитектура данных»

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

Термин «архитектура» также применяется для описания отдельных аспектов проектирования информационных систем. Стандарт

ISO/IEC/IEEE 42010:2011 Systems and software engineering. Architecture description («Системная и программная инженерия. Описание архитектуры») определяет архитектуру как «основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития»[386].

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

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

Архитектуру данных можно рассматривать с нескольких точек зрения, которые позволяют определить ее важнейшие составляющие.

● Выходные результаты архитектуры данных, такие как модели, определения и описания потоков данных на различных уровнях, т. е.

все то, что принято называть артефактами архитектуры данных.

●Работы по формированию, развертыванию и внедрению целевых решений в области архитектуры данных.

●Организационное поведение в рамках работ в области архитектуры данных; формы сотрудничества, образы мышления и навыки, распределенные по различным ролям.

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

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

Архитектура данных наиболее полезна в тех случаях, когда она в полном объеме обеспечивает потребности на корпоративном уровне. Единая корпоративная архитектура данных позволяет последовательно

исогласованно осуществлять стандартизацию и интеграцию данных в

масштабах организации[387].

11.1.2. Цели и бизнес-драйверы

Основная цель архитектуры данных – служить мостом между бизнес-стратегией и ее технологической реализацией.

Будучи частью архитектуры предприятия (см. следующий раздел), архитектура данных должна:

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

●переводить бизнес-потребности на язык требований к данным и системам, чтобы бизнес-процессы не испытывали дефицита в необходимой информации;

●обеспечивать управление сложным процессом предоставления данных и информации в масштабах предприятия;

●способствовать повышению согласованности между бизнес– и ИТ-процессами;

●служить средством гибкого проведения изменений и преобразований.

Именно эти бизнес-драйверы определяют меру ценности

архитектуры данных[388].

11.1.3. Архитектура предприятия

Архитектура информационных систем обычно рассматривается в рамках более широкой дисциплины – архитектуры предприятия

(Enterprise Architecture, EA)[389],[390], которая охватывает архитектуры нескольких предметных областей (доменов), включая данные, бизнесприложения и технологии.

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

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

11.1.4. Модель Захмана

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

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

* DAMA. DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition. Technics Publications, 2017. (Русский перевод: DAMADMBOK: Свод знаний по управлению данными. Второе издание / Dama International. – М.: Олимп-Бизнес, 2020.)

Самая известная рамочная структура архитектуры предприятия была разработана Джоном Захманом[393] в 1980-х годах. Захман обратил внимание на то, что к созданию зданий, самолетов, предприятий, цепочек создания стоимости, проектов или систем имеют отношение различные группы людей, у каждой из которых есть собственная точка зрения на архитектуру создаваемого объекта. Эту концепцию он применил к требованиям для различных типов и уровней архитектуры предприятия.

Модель Захмана представляет собой матрицу 6×6, охватывающую полный набор моделей, требуемых для описания предприятия, и связей между ними. Архитектурная рамочная структура Захмана не описывает, как именно создавать входящие в нее модели. Она показывает, что эти модели должны быть созданы (табл. 11.2).

Столбцы матрицы отражают обсуждаемые вопросы (что, как, где, кто, когда и зачем), а строки – преобразования в процессе материализации (выявление – identification, определение – definition, представление, спецификация – specification, конфигурация – configuration, реализация – instantiation). В ячейках на пересечении строк и столбцов отражены уникальные типы артефактов архитектуры данных.

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

●Перспектива руководства (бизнес-контекст). Перечни составляющих бизнеса, определяющие содержание моделей идентификации.

●Перспектива бизнес-менеджмента (бизнес-концепции).

Уточнение бизнес-менеджерами (как владельцами) связей между бизнес-концепциями и отражение их в моделях определения.

●Перспектива архитектора (бизнес-логика). Логические системные модели, детализирующие системные требования, и проектные решения без учета ограничений, отраженные архитекторами (как проектировщиками) в моделях представления.

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

●Перспектива технического специалиста (сборка). Чисто технический, без учета контекста, взгляд на то, каким образом отдельные компоненты должны быть собраны и функционировать. Отражается техническими специалистами (как внедренцами) в конфигурационных моделях.

●Перспектива пользователя (реализация). Реальные функционирующие объекты, с которыми работают сотрудники (как пользователи). Эта перспектива моделей не предусматривает.

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

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

11.1.5. Основные артефакты архитектуры данных

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

Корпоративная модель данных и описание потоков данных должны быть хорошо согласованы. При этом и модель, и потоки данных отражаются в трех состояниях – текущем, целевом (архитектурная перспектива) и переходном (проектная перспектива)[394].

Корпоративная модель данных

Корпоративная модель данных (Enterprise Data Model, EDM) представляет собой целостную, не зависящую от технических средств реализации концептуальную или логическую модель данных, отражающую единый согласованный взгляд на данные в масштабах всей организации. Этот термин обычно используется для обозначения высокоуровневой упрощенной модели данных, но уровень абстракции может быть различным в зависимости от целей ее представления. EDM содержит данные о ключевых сущностях предприятия (на уровне бизнес-концепций) и связях между ними, критически важные руководящие бизнес-правила и некоторые ключевые атрибуты. EDM закладывает основу для всех проектов в области данных или связанных с данными. Модели данных уровня отдельных проектов должны создаваться на основе EDM (см. главу 6 – разделы 6.3 и 6.4 и главу 7 – раздел 7.3). Данная модель подлежит обязательной проверке всеми заинтересованными сторонами для обеспечения согласованного мнения