Структура Захмана

В этой статье есть несколько проблем. Помогите улучшить ее или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти сообщения ) A major contributor to this article appears to have a close connection with its subject. It may require cleanup to comply with Wikipedia's content policies, particularly neutral point of view. Please discuss further on the talk page. (March 2015) (Learn how and when to remove this message) This article may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (February 2012) (Learn how and when to remove this message) (Learn how and when to remove this message)

Zachman Framework — это онтология предприятия и фундаментальная структура для архитектуры предприятия , которая обеспечивает формальный и структурированный способ просмотра и определения предприятия. Онтология — это двухмерная схема классификации, которая отражает пересечение двух исторических классификаций. Первая — примитивные вопросительные вопросы: Что, Как, Когда, Кто, Где и Почему . Вторая выведена из философской концепции овеществления, преобразования абстрактной идеи в реализацию. Трансформации овеществления в Zachman Framework: идентификация, определение, представление, спецификация, конфигурация и реализация. ^[1]

Структура Захмана не является методологией, поскольку она не подразумевает какой-либо конкретный метод или процесс сбора, управления или использования информации, которую она описывает; ^[2] скорее, это онтология, в которой схема для организации архитектурных артефактов (другими словами, проектных документов, спецификаций и моделей) используется для учета того, на кого нацелен артефакт (например, владелец бизнеса и строитель), и какая конкретная проблема (например, данные и функциональность) решается. ^[3]

Фреймворк назван в честь его создателя Джона Захмана , который впервые разработал концепцию в 1980-х годах в IBM . С тех пор он несколько раз обновлялся. ^[4]

Название "Zachman Framework" относится к The Zachman Framework for Enterprise Architecture, последняя версия 3.0. За свою тридцатилетнюю историю Zachman Framework развивался и включает в себя:

• Первоначальная структура, названная «Структура архитектуры информационных систем» , была опубликована Джоном Захманом в статье 1987 года в журнале IBM Systems. ^[5]
• Структура Захмана для архитектуры предприятия , обновление оригинала 1987 года, в 1990-х годах расширенная и переименованная. ^[6]
• Одна из последних версий Zachman Framework, предлагаемая Zachman International в качестве отраслевого стандарта.

В других источниках Zachman Framework представлен как фреймворк, созданный и названный в честь Джона Захмана, представленный многочисленными способами, см. изображение. Этот фреймворк объясняется, например, так:

• структура для организации и анализа данных , ^[7]
• каркас для архитектуры предприятия. ^[8]
• система классификации или схема классификации ^[9]
• матрица, часто в формате 6x6
• двумерная модель ^[10] или аналитическая модель.
• двумерная схема, используемая для организации подробных представлений предприятия. ^[11]

Помимо фреймворков, разработанных Джоном Захманом, были разработаны многочисленные расширения и/или приложения, которые также иногда называют фреймворками Захмана, однако они, как правило, представляют собой графические надстройки над самим фреймворком.

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

Framework — это логическая структура для классификации и организации описательных представлений предприятия. Она важна как для руководства предприятия, так и для участников, участвующих в разработке корпоративных систем. ^[13] Хотя для столбцов Framework не существует порядка приоритета, нисходящий порядок строк важен для согласования бизнес-концепций и фактического физического предприятия. Уровень детализации Framework является функцией каждой ячейки (а не строк). Когда это делается ИТ, нижний уровень фокуса сосредоточен на информационных технологиях , однако он может применяться в равной степени к физическому материалу (например, шаровым кранам, трубопроводам, трансформаторам, коробкам предохранителей) и связанным с ними физическим процессам, ролям, местоположениям и т. д., связанным с этими элементами. ^{[ требуется ссылка ]}

В 1980-х годах Джон Захман был вовлечен в IBM в разработку планирования бизнес-систем (BSP), метода анализа, определения и проектирования информационной архитектуры организаций. В 1982 году Захман ^[14] уже пришел к выводу, что эти анализы могут выйти далеко за рамки проектирования автоматизированных систем и управления данными в сферы стратегического бизнес-планирования и науки управления в целом. Их можно использовать в (в то время считавшихся более эзотерическими) областях архитектуры предприятия, проектирования систем, управляемых данными, критериев классификации данных и т. д. ^[14]

В статье 1987 года «Структура архитектуры информационных систем» ^[15] Захман отметил, что термин «архитектура» использовался свободно специалистами по информационным системам и означал разные вещи для планировщиков, дизайнеров, программистов, специалистов по коммуникациям и других. ^[16] В поисках объективной, независимой основы, на которой можно было бы разработать структуру архитектуры информационных систем, Захман рассмотрел область классической архитектуры и множество сложных инженерных проектов в промышленности. Он увидел похожий подход и пришел к выводу, что архитектуры существуют на многих уровнях и включают в себя по крайней мере три перспективы: сырье или данные , функцию процессов и местоположение или сети. ^[16]

Архитектура информационных систем разработана как схема классификации для организации архитектурных моделей. Она обеспечивает синоптическое представление моделей, необходимых для архитектуры предприятия. Архитектура информационных систем не определяет подробно, что должны содержать модели, не навязывает язык моделирования, используемый для каждой модели, и не предлагает метод создания этих моделей. ^[17]

В статье 1992 года «Расширение и формализация структуры архитектуры информационных систем» Джон Ф. Сова и Джон Захман представляют структуру и ее недавние расширения, а также показывают, как ее можно формализовать в нотации концептуальных графов. ^[18] Также в 1992 году:

Соавтор Джона Захмана Джон Сова предложил дополнения к перспективе Scope «планировщика» (ограничивающие списки, общие для предприятия и его среды) и перспективе Detailed Representation «субподрядчика» (являющегося компонентами решения поставщика вне контекста). Столбцы Who, When и Why были представлены общественности, понятие четырех уровней метафреймворков и описание интеграционных ассоциаций по перспективам были изложены в статье. Кери Андерсон Хили помогла, создав модель моделей (метамодель фреймворка), которая также была включена в статью.

—  Стэн Локк, «Конвергенция предприятий в нашей жизни», из информационного бюллетеня «The Enterprise Newsletter» ^[19]

Позже, в 1990-х годах ^[19]

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

В статье 1997 года «Концепции фреймворка для архитектуры предприятия» Захман сказал, что фреймворк следует называть «фреймворком для архитектуры предприятия», и так должно было быть с самого начала. Однако в начале 1980-х годов, по словам Захмана, «было мало интереса к идее реинжиниринга предприятия или моделирования предприятия , а использование формализмов и моделей, как правило, ограничивалось некоторыми аспектами разработки приложений в сообществе информационных систем». ^[20]

В 2008 году компания Zachman Enterprise представила « Фреймворк Захмана: официальное краткое определение» в качестве нового стандарта фреймворка Захмана.

С 1990-х годов было предложено несколько расширенных рамок, таких как:

• Мэтью и Макги (1990) ^[21] расширили три первоначальные перспективы «что», «как» и «где» до события («когда»), причины («почему») и организации («кто»). ^[16]
• Шох и Лапланте (1995) опубликовали в журнале IBM Systems Journal (т. 34, № 1, январь 1995 г., стр. 22–38) статью «Структура архитектуры систем реального времени», представляющую собой расширение исходной структуры Захмана, применимой к системам реального времени.
• Эвернден (1996) представил альтернативную информационную структуру .
• Интегрированная архитектура, разработанная Capgemini с 1996 года. ^[22]
• Владан Йованович и др. (2006) представляют куб Захмана, расширенную версию структуры Захмана в многомерный куб Захмана. ^[23]

Основная идея, лежащая в основе концепции Захмана, заключается в том, что одна и та же сложная вещь или предмет может быть описана для разных целей разными способами с использованием разных типов описаний (например, текстовых, графических). Концепция Захмана предоставляет тридцать шесть необходимых категорий для полного описания чего-либо; особенно сложных вещей, таких как промышленные товары (например, бытовая техника), построенные конструкции (например, здания) и предприятия (т. е. организация и все ее цели, люди и технологии). Концепция предоставляет шесть различных преобразований абстрактной идеи (не увеличивая детализацию, а преобразуя) с шести различных точек зрения. ^[24]

Это позволяет разным людям смотреть на одно и то же с разных точек зрения. Это создает целостный взгляд на окружающую среду, важную возможность, проиллюстрированную на рисунке. ^[25]

Каждая строка представляет собой общее представление решения с определенной точки зрения. Верхняя строка или перспектива не обязательно имеет более полное понимание целого, чем нижняя перспектива. Каждая строка представляет собой отдельную, уникальную перспективу; однако результаты с каждой перспективы должны предоставлять достаточно подробностей для определения решения на уровне перспективы и должны явно переводиться в следующую нижнюю строку. ^[26]

Каждая перспектива должна учитывать требования других перспектив и ограничения, которые эти перспективы накладывают. Ограничения каждой перспективы являются аддитивными. Например, ограничения более высоких рядов влияют на ряды ниже. Ограничения более низких рядов могут, но не обязательно влияют на более высокие ряды. Понимание требований и ограничений требует передачи знаний и понимания от перспективы к перспективе. Структура указывает вертикальное направление для этой коммуникации между перспективами. ^[26]

Текущая версия (3) фреймворка Захмана классифицирует строки следующим образом:

• Перспектива руководителя (содержание области действия) – Первый архитектурный эскиз представляет собой « пузырьковую диаграмму » или диаграмму Венна , которая в общих чертах отображает размер, форму, частичные взаимосвязи и основную цель окончательной структуры. Она соответствует резюме руководителя для планировщика или инвестора, который хочет получить обзор или оценку области действия системы, ее стоимости и того, как она будет соотноситься с общей средой, в которой она будет работать.
• Перспектива управления бизнесом (бизнес-концепции) – Далее следуют чертежи архитектора, которые изображают окончательное здание с точки зрения владельца, которому придется жить с ним в повседневной рутине бизнеса. Они соответствуют моделям предприятия (бизнеса), которые составляют проекты бизнеса и показывают бизнес-единицы и процессы и то, как они связаны.
• Перспектива архитектора (системная логика) – Планы архитектора являются переводом чертежей в подробные представления требований с точки зрения проектировщика. Они соответствуют модели системы, разработанной системным аналитиком, который должен определить элементы данных, логические потоки процессов и функции, которые представляют бизнес-сущности и процессы.
• Перспектива инженера (технологическая физика) – Подрядчик должен перерисовать планы архитектора, чтобы представить перспективу строителя, с достаточной детализацией, чтобы понять ограничения инструментов, технологий и материалов. Планы строителя соответствуют технологическим моделям, которые должны адаптировать модель информационных систем к деталям языков программирования, устройств ввода/вывода (I/O) или других требуемых вспомогательных технологий.
• Перспектива технического специалиста (компоненты инструмента) – Субподрядчики работают по планам цеха, в которых указаны детали деталей или подразделов. Они соответствуют подробным спецификациям, которые предоставляются программистам, которые кодируют отдельные модули, не заботясь об общем контексте или структуре системы. В качестве альтернативы они могут представлять собой подробные требования к различным коммерческим готовым продуктам (COTS) , государственным готовым продуктам (GOTS) или компонентам модульного системного программного обеспечения, которые закупаются и внедряются, а не создаются.
• Перспектива предприятия или (экземпляры операций)

Подводя итог, можно сказать, что каждая перспектива фокусирует внимание на одних и тех же фундаментальных вопросах, а затем отвечает на эти вопросы с этой точки зрения, создавая различные описательные представления (т. е. модели), которые переходят от более высоких к более низким перспективам. Базовая модель для фокуса (или абстракция продукта) остается постоянной. Базовая модель каждого столбца однозначно определена, но связана по всей матрице и вниз по ней. ^[26] Кроме того, шесть категорий компонентов архитектуры предприятия и базовые вопросительные вопросы, на которые они отвечают, образуют столбцы структуры Захмана, и они следующие: ^[24]

1. Наборы инвентаря – Что
2. Потоки процессов – как
3. Распределительные сети – где
4. Распределение ответственности – Кто
5. Временные циклы – когда
6. Мотивация Намерения – Почему

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

Структура Захмана обычно изображается как ограниченная 6 x 6 "матрица" с коммуникационными вопросительными как столбцами и трансформациями реификации как строками. Классификации структуры подавляются ячейками, то есть пересечением между вопросительными и трансформациями. ^[29]

Описания ячеек взяты непосредственно из версии 3.0 фреймворка Захмана.

Перспектива руководства

1. (Что) Идентификация инвентаря
2. (Как) Идентификация процесса
3. (Где) Распределение Идентификация
4. (Кто) Ответственность Идентификация
5. (Когда) Определение времени
6. (Почему) Определение мотивации

Перспектива управления бизнесом

1. (Что) Определение инвентаря
2. (Как) Определение процесса
3. (Где) Распределение Определение
4. (Кто) Ответственность Определение
5. (Когда) Определение времени
6. (Почему) Мотивация Определение

Перспектива архитектора

1. (Что) Представление инвентаря
2. (Как) Процесс Представления
3. (Где) Распределение Представление
4. (Кто) Ответственность Представительство
5. (Когда) Временное представление
6. (Почему) Мотивация Представление

Перспектива инженера

1. (Что) Спецификация инвентаря
2. (Как) Спецификация процесса
3. (Где) Спецификация распределения
4. (Кто) Ответственность Спецификация
5. (Когда) Сроки Спецификация
6. (Почему) Мотивация Спецификация

Точка зрения технического специалиста

1. (Что) Конфигурация инвентаря
2. (Как) Конфигурация процесса
3. (Где) Конфигурация распределения
4. (Кто) Ответственность Конфигурация
5. (Когда) Конфигурация времени
6. (Почему) Конфигурация мотивации

Перспектива предприятия

1. (Что) Инвентарные экземпляры
2. (Как) Процесс Инстантации
3. (Где) Распространение экземпляров
4. (Кто) Ответственность Инстантации
5. (Когда) Временные реализации
6. (Почему) Мотивация Инстантации

Поскольку разработка продукта (т. е. архитектурный артефакт) в каждой ячейке или решение проблемы, воплощенное ячейкой, является ответом на вопрос с точки зрения, обычно модели или описания являются изображениями более высокого уровня или поверхностными ответами ячейки. Уточненные модели или проекты, поддерживающие этот ответ, являются подробными описаниями внутри ячейки. Разложение (т. е. детализация до более высоких уровней детализации) происходит внутри каждой ячейки. Если ячейка не сделана явной (определенной), она неявная (неопределенная). Если она неявная, существует риск принятия предположений относительно этих ячеек. Если предположения верны, то экономятся время и деньги. Однако если предположения неверны, это, вероятно, увеличит затраты и превысит график внедрения. ^[26]

В состав фреймворка входит набор правил: ^[30]

• Правило 1. Столбцы не имеют порядка  : столбцы взаимозаменяемы, но не могут быть сокращены или созданы.
• Правило 2. Каждый столбец имеет простую общую модель  : каждый столбец может иметь свою собственную метамодель.
• Правило 3. Базовая модель каждого столбца должна быть уникальной  : Базовая модель каждого столбца, объекты отношений и их структура уникальны. Каждый объект отношений взаимозависим, но цель представления уникальна.
• Правило 4 Каждая строка описывает отдельную, уникальную перспективу  : Каждая строка описывает точку зрения определенной бизнес-группы и является уникальной для нее. Все строки обычно присутствуют в большинстве иерархических организаций.
• Правило 5 Каждая ячейка уникальна  : комбинация 2, 3 и 4 должна создавать уникальные ячейки, где каждая ячейка представляет собой конкретный случай. Пример: A2 представляет собой бизнес-выходы, поскольку они представляют то, что должно быть в конечном итоге построено.
• Правило 6. Объединение или интеграция всех моделей ячеек в одной строке представляет собой полную модель с точки зрения этой строки  : по той же причине, что и при отказе от добавления строк и столбцов, изменение имен может изменить фундаментальную логическую структуру Framework.
• Правило 7. Логика рекурсивна  : логика является реляционной между двумя экземплярами одной и той же сущности.

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

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

Джон Захман ясно заявляет в своей документации, презентациях и семинарах, что в качестве структуры существует гибкость в том, какая глубина и широта детализации требуется для каждой ячейки матрицы в зависимости от важности для данной организации. Автопроизводитель, чьи бизнес-цели могут потребовать сосредоточения на инвентаризации и процессах, может посчитать полезным сосредоточить свои усилия по документированию на столбцах «Что» и « Как» . Напротив, туристическая компания, чей бизнес больше связан с людьми и временем проведения мероприятий, может посчитать полезным сосредоточить свои усилия по документированию на столбцах «Кто» , «Когда » и «Где» . Однако невозможно избежать важности столбца «Почему» , поскольку он обеспечивает бизнес-драйверы для всех остальных столбцов.

Начиная с 1990-х годов структура Захмана широко использовалась в качестве средства предоставления структуры для моделирования предприятий в стиле инжиниринга информационных технологий . ^[31] Структура Захмана может применяться как в коммерческих компаниях, так и в государственных учреждениях. В рамках государственной организации структура может применяться ко всему агентству на абстрактном уровне или к различным департаментам, офисам, программам, подразделениям и даже к основным операционным подразделениям. ^[32]

Структура Захмана применяется в специализированных фреймворках, таких как TEAF , построенных вокруг схожих фреймворков — матрицы TEAF .

• 
  Матрица взглядов и перспектив TEAF .
• 
  Структура направления, описания и обзора достижений EA.
• 
  Продукция TEAF.
• 
  Рабочие продукты TEAF для направления, описания и выполнения EA.

Другие источники:

• Матрица TEAF называется образцом настройки, см. здесь, стр. 22.

Zachman Framework также используется как основа для описания стандартов, например, стандартов для здравоохранения и информационной системы здравоохранения. Каждая ячейка основы содержит такую ​​серию стандартов для здравоохранения и информационной системы здравоохранения. ^[33]

Другим применением Zachman Framework является использование его в качестве эталонной модели для других корпоративных архитектур, например, следующих четырех:

• 
  EAP сопоставлен с фреймворком Захмана, 1999 г.
• 
  Картографирование C4ISR , 1999 г.
• 
  Продукция Министерства обороны США соответствует ячейкам структуры Захмана, 2003 г.
• 
  Картографирование части DoDAF , 2007.

Другие примеры:

• Анализ рационального унифицированного процесса как процесса, ^[34]
• Как модели архитектуры на основе моделей (MDA), используемые при разработке программного обеспечения, соотносятся с фреймворком Захмана. ^[35]
• Сопоставление моделей IEC 62264 с фреймворком Захмана для анализа прослеживаемости информации о продуктах. ^[36]
• Сопоставление метода разработки архитектуры TOGAF (например, методологии) с фреймворком Захмана. ^[6]

Менее очевидны способы, которыми исходная структура Захмана стимулировала разработку других структур корпоративной архитектуры , таких как NIST Enterprise Architecture Model , C4ISR AE, DOE AE и DoDAF :

• 
  Модель архитектуры предприятия NIST. ^[26]
• 
  C4ISR АЕ, 1997.
• 
  Министерство энергетики США, 1998.
• 
  ДОДАФ , 2003.

• Структура архитектуры федерального предприятия (FEAF) основана на структуре Захмана, но затрагивает только первые три столбца Захмана, используя немного другие названия, и фокусируется на верхней части трех строк. ^[37] (см. здесь)

Методология Zachman Framework, например, использовалась Министерством по делам ветеранов США (VA) для разработки и поддержки архитектуры One-VA Enterprise в 2001 году. Эта методология требовала определения всех аспектов предприятия VA с точки зрения бизнес-процессов, данных, технических аспектов, местоположения, персонала и требований. Следующим шагом в реализации методологии было определение всех функций, связанных с каждым бизнес-процессом, и выявление связанных элементов данных. После выявления дублирования функций и несоответствия в определении данных могут быть выявлены и устранены, . ^[38]

• 
  Интегрированный технологический процесс для ИТ-проектов VA (2001)
• 
  Портал VA Zachman Framework
• 
  Введение в репозиторий VA EA (2008)
• 
  Учебное пособие по архитектуре Zachman

Департамент по делам ветеранов в начале 21 века ^{[ когда? ]} планировал внедрить архитектуру предприятия, полностью основанную на структуре Захмана.

• В 2001 году в качестве эталонной модели для начала планирования архитектуры предприятия была использована модель Захмана.
• Где-то в это время был создан портал VA Zachman Framework.
• Этот портал VA Zachman Framework по-прежнему используется в качестве справочной модели, например, при определении информации об оценке эффективности, собранной из различных исходных деловых и проектных документов.

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

Эта диаграмма ^[a] была включена в VA-EA для предоставления символического представления метамодели, которую она использовала, для описания архитектуры One-VA Enterprise и для построения репозитория EA без использования коммерческого программного обеспечения репозитория EA. Она была разработана с использованием объектно-ориентированной базы данных в программном продукте Caliber-RM. Caliber-RM предназначен для использования в качестве инструмента управления конфигурацией программного обеспечения , а не в качестве репозитория EA.

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

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

1. Двигаясь по строкам сверху вниз, можно проследить жизненный цикл разработки систем (SDLC), который является фактическим стандартом в информационной индустрии;
2. Диаграмма подчеркивает важность часто игнорируемой строки Zachman Row-Six (интегрированное, операционное представление предприятия). Представления в интерпретации Zuech строки Zachman Row-Six состоят, в основном, из измеримых улучшений обслуживания и экономии/избежания затрат, которые являются результатом бизнес-процессов и технологических инноваций, которые были разработаны в строках со второй по пятую.

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

Хотя концепция Захмана широко обсуждается, ее практическая ценность подвергается сомнению:

• Эта структура является чисто спекулятивной, неэмпирической и основана только на концептуальном аргументе о том, что «эквивалентность [между архитектурными представлениями обрабатывающей и строительной отраслей] усилит аргумент о том, что аналогичный набор архитектурных представлений, вероятно, будет создан в процессе создания любого сложного инженерного продукта, включая информационную систему» ^​​[5].
• Практические отзывы показывают, что общая идея создания всеобъемлющих описаний предприятий, предлагаемая фреймворком Захмана, нереалистична ^[40]
• В 2004 году Джон Захман признал, что структура является теоретической и никогда не была полностью реализована: «Если вы спросите, кто успешно реализует всю структуру, ответ будет: никто, насколько нам известно, пока не существует» ^[41]
• Подробных примеров, демонстрирующих успешное практическое применение фреймворка, нет ^[42].
• Практикующий архитектор Стэнли Гейвер утверждает, что «аналогия с классической архитектурой, впервые предложенная Джоном Захманом, ошибочна и неполна» ^[43]
• Джейсон Блумберг утверждает, что «предприятие — это не обычная система, как машина или здание, и не может быть спроектировано или спроектировано как таковое» ^[44]
• Детальное изучение показывает, что структура Захмана на самом деле основана только на чисто спекулятивных аргументах, продвигается с помощью вымышленных обещаний, не имеет практических примеров использования и, с исторической точки зрения, не вносит никаких инновационных идей, отсутствовавших ранее ^{[45] [46]}

Эта критика предполагает, что структура Захмана вряд ли может отражать реальную передовую практику в области АП.

• Концептуальная схема
• Модель данных
• Структура архитектуры предприятия
• Планирование архитектуры предприятия
• Структура архитектуры предприятия FDIC
• Пять W
• Посмотреть модель

На Викискладе есть медиафайлы по теме «Фреймворк Захмана» .

• Структура Захмана: официальное краткое определение Джона А. Захмана на сайте Zachman International, 2009.
• Эволюция концепции Захмана: обзор эволюции концепции Захмана, представленный Джоном П. Захманом на конференции Zachman International, апрель 2009 г.
• UML, RUP и Zachman Framework: вместе лучше, Виталий Темненко, IBM, 15 ноября 2006 г.