Zachman Framework

редактировать
Zachman Framework корпоративной архитектуры

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

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

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

Содержание
  • 1 Обзор
  • 2 История
    • 2.1 Структура «Архитектура информационных систем»
    • 2.2 Расширение и формализация
    • 2.3 Структура для архитектуры предприятия
    • 2.4 Расширенные и модифицированные платформы
  • 3 темы Zachman Framework
    • 3.1 Концепция
    • 3.2 Представления строк
    • 3.3 Фокус столбцов
    • 3.4 Модели ячеек
    • 3.5 Набор правил структуры
    • 3.6 Гибкость на уровне детализации
  • 4 Приложения и факторы влияния
    • 4.1 Настройка
    • 4.2 Стандарты на основе Zachman Framework
    • 4.3 Сопоставление других структур
    • 4.4 База для других структур архитектуры предприятия
      • 4.4.1 Пример: Архитектура предприятия с одним виртуальным устройством
  • 5 Критика
  • 6 См. Также
  • 7 Ссылки
  • 8 Внешние ссылки
Обзор

Название «Zachman Framework» относится к Zachman Framework для архитектуры предприятия с версией 3.0, которая является самой последней. За свою тридцатилетнюю историю Zachman Framework эволюционировала и включает:

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

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

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

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

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

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

История

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

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

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

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

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

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

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

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

— Стэн Локк, Конвергенция предприятий в нашей жизни, из ИНФОРМАЦИОННОГО БЮЛЛЕТЕНЯ ПРЕДПРИЯТИЙ

Позже, в 1990-е годы

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

Структура для архитектуры предприятия

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

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

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

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

  • Мэтью и МакГи (1990) расширили три исходных точки зрения «что» и «как» и «где» - к событию («когда»), причине («почему») и организации («кто»).
  • Эвернден (1996) представил альтернативу Information FrameWork.
  • Интегрированная архитектура архитектуры, разработанная Capgemini с 1996 года.
  • Владан Йованович и др. (2006) представляет куб Захмана, расширенный вариант структуры Захмана в многомерный Куб Захмана.
Темы Zachman Framework

Концепция

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

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

Виды строк

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

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

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

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

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

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

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

  1. Inventory Sets - What
  2. Process Flows - How
  3. Распределительные сети - Где
  4. Распределение ответственности - Кто
  5. Временные циклы - Когда
  6. Намерения мотивации - Почему

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

Модели ячеек

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

Описания ячеек взяты непосредственно из версии 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. (почему) экземпляры мотивации

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

Набор правил структуры

Пример правил Zachman Framework.

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

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

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

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

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

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

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

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

Настройка

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

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

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

Стандарты на основе Zachman Framework

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

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

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

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

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

База для других структур архитектуры предприятия

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

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

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

Департамент по делам ветеранов в начале 21 века планировал полностью реализовать архитектуру предприятия. на основе Zachman Framework.

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

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

Подробная информация о ячейке метамодели EA EA увеличена.

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

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

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

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

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

Критика

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

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

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

См. Также
Ссылки
Внешние ссылки
Викискладе есть средства массовой информации, связанные с Структурой Захмана.
Последняя правка сделана 2021-06-23 05:44:36
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте