Читаем Ценность ваших данных полностью

Самая известная рамочная структура архитектуры предприятия была разработана Джоном Захманом[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.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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