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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

 

 

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

 

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

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

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

 

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

 

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

● что (столбец объектов): сущности (объекты), используемые для построения архитектуры;

● как (столбец процессов): проводимые работы;

● где (столбец местоположений): местоположения бизнес-структур и технологических структур;

● кто (столбец обязанностей): роли и организационные системы;

● когда (столбец привязки по времени): сроки, интервалы, события, циклы, расписания;

● зачем (столбец мотивации): цели, стратегии и средства.

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

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

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

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

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

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

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

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