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

Эта статья поднимает множество проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалить эти сообщения-шаблоны ) Похоже, что один из основных авторов этой статьи тесно связан с ее предметом. Может потребоваться очистка для соответствия политике содержания Википедии, особенно с нейтральной точкой зрения . Пожалуйста, обсудите дальше на странице обсуждения . ( Март 2015 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) Эта статья может быть слишком технической для понимания большинством читателей . Пожалуйста, помогите улучшить его, чтобы он был понятен неспециалистам , не удаляя технических деталей. ( Февраль 2012 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) ( Узнайте, как и когда удалить этот шаблон сообщения )

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

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

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

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

Обзор [ править ]

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

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

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

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

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

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

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

История [ править ]

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

Фреймворк "Архитектура информационных систем" [ править ]

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

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

Расширение и формализация [ править ]

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

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

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

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

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

Платформа для архитектуры предприятия [ править ]

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

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

Расширенные и модифицированные рамки [ править ]

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

• Мэтью и МакГи (1990) ^[21] расширили три исходных точки зрения «что», «как» и «где» на событие («когда»), причину («почему») и организацию («кто»). . ^[16]
• Evernden (1996) представил альтернативную информационную фреймворк .
• Integrated Architecture Framework , разработанный Capgemini с 1996 года ^[22]
• Владан Йованович и др. (2006) представляют куб Захмана, расширение структуры Захмана в многомерный куб Захмана. ^[23]

Темы Zachman Framework [ править ]

Концепция [ править ]

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

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

Просмотры строк [ править ]

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

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

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

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

Фокус столбцов [ править ]

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

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

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

Модели ячеек [ править ]

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

Описания ячеек взяты непосредственно из Zachman Framework версии 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 Объединение или интеграция всех моделей ячеек в одну строку составляет полную модель с точки зрения этой строки  : по той же причине, что и при отсутствии добавления строк и столбцов, изменение имен может изменить фундаментальную логическую структуру структуры.
• Правило 7 Логика рекурсивна  : логика взаимосвязана между двумя экземплярами одной и той же сущности.

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

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

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

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

Приложения и влияния [ править ]

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

Настройка [ править ]

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

• Матрица взглядов и перспектив TEAF .

• Рамки для руководства, описания и обзора выполнения EA.

• Продукция TEAF.

• Рабочие продукты TEAF для руководства, описания и выполнения EA.

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

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

Стандарты, основанные на Zachman Framework [ править ]

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

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

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

• EAP сопоставлен с Zachman Framework, 1999

• Отображение C4ISR , 1999 г.

• Карта продуктов Министерства обороны и ячеек Zachman Framework, 2003.

• Картирование части DoDAF , 2007.

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

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

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

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

• Модель архитектуры предприятия NIST. ^[26]

• C4ISR AE, 1997.

• ДОЭ АЭ, 1998.

• ДОДАФ , 2003.

• Федеральное Enterprise Architecture Framework (FEAF) основан на Захмане но рассматривается только первые три колонок Zachman, используя несколько различных имена, и фокусируется на верхнем из трех рядов. ^[37] (см. Здесь )

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

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

• Интегрированный поток процессов для ИТ-проектов VA (2001)

• Фреймворк В.А. Захмана

• Введение в репозиторий VA EA (2008)

• Учебное пособие по архитектуре Zachman Architecture Framework

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

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

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

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

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

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

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

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

Критика [ править ]

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

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

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

См. Также [ править ]

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

Ссылки [ править ]

Внешние ссылки [ править ]

Викискладе есть медиафайлы по теме Zachman Framework .

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