Захман Фреймворк

Структура архитектуры предприятия Захмана

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

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

Платформа названа в честь ее создателя Джона Захмана , который впервые разработал эту концепцию в 1980-х годах в IBM . С тех пор он обновлялся несколько раз.

Обзор

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

• Первоначальная структура под названием A Framework for Information Systems Architecture была опубликована Джоном Захманом в статье 1987 года в журнале IBM Systems.
• Zachman Framework for Enterprise Architecture , обновление оригинала 1987 года, в 1990-е годы расширено и переименовано.
• Одна из последних версий Zachman Framework, предлагаемая Zachman International в качестве отраслевого стандарта.

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

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

• структура для организации и анализа данных ,
• основа для архитектуры предприятия.
• система классификации или схема классификации
• матрица, часто в формате матрицы 6x6
• двумерная модель или аналитическая модель.
• двумерная схема, используемая для организации детального представления предприятия.

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

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

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

История

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

Структура «Архитектура информационных систем»

Оригинальная «Структура архитектуры информационных систем» 1987 года.

Простой пример Рамочной программы 1992 года.

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

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

Расширение и формализация

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

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

— Стэн Локк, Конвергенция предприятий в нашей жизни, из информационного бюллетеня Enterprise.

Позже, в 1990-е гг.

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

Фреймворк для архитектуры предприятия

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

В 2008 году Zachman Enterprise представила Zachman Framework: официальное краткое определение в качестве нового стандарта Zachman Framework.

Расширенные и модифицированные фреймворки

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

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

Темы Zachman Framework

Концепция

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

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

Виды строк

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

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

Структура Захмана по делам ветеранов с объяснением ее строк.

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

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

Фокус столбцов

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

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

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

Модели клеток

Структура Захмана обычно изображается как ограниченная «матрица» размером 6 x 6 с коммуникативными вопросительными предложениями в виде столбцов и трансформационными преобразованиями в виде строк. Каркасные классификации подавляются Ячейками, то есть пересечением Вопросительных вопросов и Преобразований.

Описания ячеек взяты непосредственно из версии 3.0 Zachman Framework.

Исполнительная перспектива

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. (Почему) Реализация мотивации

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

Рамочный набор правил

Пример правил структуры Захмана.

Фреймворк поставляется с набором правил:

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

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

Гибкость в уровне детализации

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

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

Приложения и влияния

С 1990-х годов Zachman Framework широко используется как средство обеспечения структуры для информационных технологий в стиле моделирования предприятия . Модель Захмана может применяться как в коммерческих компаниях, так и в государственных учреждениях. Внутри правительственной организации эта концепция может применяться ко всему агентству на абстрактном уровне или к различным департаментам, управлениям, программам, подразделениям и даже к основным оперативным подразделениям.

Кастомизация

Zachman Framework применяется в специализированных средах, таких как TEAF , построенных на основе аналогичных структур, матрицы TEAF .

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

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

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

Стандарты, основанные на платформе Захмана

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

Сопоставление других фреймворков

Еще одно применение Zachman Framework — эталонная модель для других корпоративных архитектур, см., например, эти четыре:

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

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

• Анализ Rational Unified Process как процесса,
• Как модели архитектуры, управляемой моделями (MDA), используемые при разработке программного обеспечения, соотносятся с Zachman Framework.
• Сопоставление моделей IEC 62264 со структурой Захмана для анализа отслеживаемости информации о продуктах.
• Сопоставление метода разработки архитектуры TOGAF (например, методологии) со структурой Захмана.

База для других платформ корпоративной архитектуры.

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

• 
  Модель архитектуры предприятия NIST.
• 
  C4ISR АЕ, 1997.
• 
  ДОУ А.Е., 1998.
• 
  ДОДАФ , 2003.

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

Пример: корпоративная архитектура с одним виртуальным устройством

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

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

Управление по делам ветеранов в начале XXI века планировал реализовать корпоративную архитектуру, полностью основанную на Zachman Framework.

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

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

Увеличенные сведения о ячейке метамодели VA EA.

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

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

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

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

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

Критика

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

• Эта концепция является чисто спекулятивной, неэмпирической и основана только на концептуальном аргументе о том, что «эквивалентность [между архитектурными представлениями обрабатывающей и строительной отраслей] усилит аргумент о том, что аналогичный набор архитектурных представлений, вероятно, будет создан в течение процесс построения любого сложного инженерного изделия, в том числе информационной системы»
• Практические отзывы показывают, что общая идея создания всеобъемлющих описаний предприятий, предложенная структурой Захмана, нереалистична.
• В 2004 году Джон Захман признал, что эта структура является теоретической и никогда не была полностью реализована: «Если вы спросите, кто успешно реализует всю структуру, ответ — никто, о ком мы пока не знаем».
• Подробных примеров, демонстрирующих успешное практическое применение фреймворка, нет.
• Практик EA Стэнли Гэвер утверждает, что «аналогия с классической архитектурой, впервые проведенная Джоном Захманом, ошибочна и неполна».
• Джейсон Блумберг утверждает, что «предприятие — это не обычная система, такая как машина или здание, и его нельзя спроектировать или спроектировать как таковую».
• Детальное рассмотрение показывает, что концепция Захмана на самом деле основана только на чисто спекулятивных аргументах, подкреплена вымышленными обещаниями, не имеет практических вариантов использования и с исторической точки зрения не привносит никаких инновационных идей, отсутствующих раньше.

Эта критика предполагает, что Zachman Framework вряд ли может отражать реальную лучшую практику в EA.

См. также

• Концептуальная схема
• Модель данных
• Структура архитектуры предприятия
• Планирование архитектуры предприятия
• Структура архитектуры предприятия Федеральной корпорации по страхованию вкладов (FDIC)
• Пять Вт
• Посмотреть модель

Внешние ссылки

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