Самая известная рамочная структура архитектуры предприятия была разработана Джоном Захманом[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. Основные артефакты архитектуры данных
По мере поступления данных в организацию через каналы связи или интерфейсы обеспечивается их защита и интеграция; они сохраняются, регистрируются, каталогизируются, распространяются, включаются в отчеты, анализируются и предоставляются заинтересованным лицам. Попутно данные могут подвергаться верификации, улучшению, связыванию, сертификации, агрегированию, анонимизации и использованию в целях аналитики вплоть до момента их архивации или удаления. Следовательно, описания корпоративной архитектуры данных должны включать как корпоративные модели данных (с указанием структуры и спецификаций данных), так и описания потоков данных.
