Jump to content

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

Модель архитектуры предприятия NIST , созданная в 1989 году, является одной из первых структур архитектуры предприятия . [1]

Структура архитектуры предприятия ( EA framework ) определяет, как создавать и использовать архитектуру предприятия . Структура архитектуры предоставляет принципы и методы создания и использования описания архитектуры системы. Он структурирует мышление архитекторов, разделяя описание архитектуры на области, слои или представления, и предлагает модели – обычно матрицы и диаграммы – для документирования каждого представления. Это позволяет принимать системные проектные решения по всем компонентам системы и принимать долгосрочные решения относительно новых требований к проектированию, устойчивости и поддержке. [2]

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

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

Компоненты структуры архитектуры предоставляют структурированное руководство, которое разделено на три основные области: [4]

  • Описания архитектуры: как документировать предприятие как систему с нескольких точек зрения. Каждое представление описывает один фрагмент архитектуры; оно включает в себя те организации и отношения, которые решают конкретные проблемы, представляющие интерес для конкретных заинтересованных сторон; он может принимать форму списка, таблицы, диаграммы или более высокого уровня их совокупности.
  • Методы проектирования архитектуры: процессы, которым следуют архитекторы. Обычно всеобъемлющий процесс архитектуры предприятия, состоящий из этапов, разбит на процессы более низкого уровня, состоящие из более мелких действий. Процесс определяется его целями, входами, фазами (шагами или действиями) и выходами. Это может быть подкреплено подходами, методами, инструментами, принципами, правилами и практиками.
  • Организация архитекторов: руководство по структуре команды и управлению командой, включая необходимые навыки, опыт и обучение.

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

Обзор эволюции структур архитектуры предприятия (1987–2003 гг.). [4] [5] Слева: The Zachman Framework 1987, NIST Enterprise Architecture 1989, EAP 1992, TISAF 1997, FEAF 1999 и TEAF 2000. Справа: TAFIM под влиянием POSIX , JTA, JTAA, TOGAF 1995, DoD TRM. [6] и C4ISR 1996 г. и DoDAF 2003 г.

Самые ранние зачатки методологии поэтапного планирования, которую в настоящее время поддерживает The Open Group Architecture Framework (TOGAF) и другие структуры EA, можно проследить до статьи Маршалла К. Эванса и Лу Р. Хейга под названием «Генеральный план для информационных систем». [7] опубликовано в 1962 году в Harvard Business Review. [8]

С 1970-х годов люди, работающие в сфере ИС/ИТ, искали способы привлечения деловых людей – для реализации бизнес-ролей и процессов – и влияния на инвестиции в информационные системы и технологии для бизнеса – с целью получения широких и долгосрочных выгод предприятия. Многие из целей, принципов, концепций и методов, используемых в настоящее время в структурах EA, были установлены в 1980-х годах и могут быть найдены в структурах архитектуры ИС и ИТ, опубликованных в этом десятилетии и в следующем. [9]

К 1980 году IBM Business Systems Planning (BSP) продвигалась как метод анализа и проектирования информационной архитектуры организации со следующими целями:

  1. понимать проблемы и возможности текущих приложений и технической архитектуры;
  2. разработать будущее состояние и путь миграции для технологии, поддерживающей предприятие;
  3. предоставить руководителям предприятий структуру направления и принятия решений по капитальным затратам на ИТ;
  4. предоставить информационной системе (ИС) план развития.

В 1982 году, работая в IBM и BSP, Джон Захман изложил свою структуру «Архитектуры информационных систем» уровня предприятия. Тогда и в последующих работах Захман использовал слово «предпринимательство» как синоним бизнеса. «Хотя многие популярные методологии планирования информационных систем, подходы к проектированию, а также различные инструменты и методы не исключают или не противоречат анализу на уровне предприятия, лишь немногие из них явно обращаются к корпоративной архитектуре или пытаются ее определить». [10] Однако в этой статье термин «Архитектура предприятия» был упомянут только один раз без какого-либо конкретного определения, и во всех последующих работах Захмана использовался термин «Архитектура информационных систем». [11] [12]

В 1986 году архитектура архитектуры PRISM , которая, по-видимому, была первой опубликованной структурой EA. в результате исследовательского проекта, спонсируемого группой компаний, включая IBM, была разработана [13]

В 1987 году Джон Захман, специалист по маркетингу в IBM, опубликовал статью « Структура архитектуры информационных систем» . [11] В документе представлена ​​схема классификации артефактов , которые описывают (на нескольких уровнях абстракции) что, как, где, кто, когда и почему в информационных системах. Поскольку IBM уже использовала BSP, Захману не нужно было обеспечивать процесс планирования. В документе не упоминается архитектура предприятия.

В 1989 году Национальный институт стандартов и технологий (NIST) опубликовал Модель архитектуры предприятия NIST . [14] Это была пятиуровневая эталонная модель, которая иллюстрирует взаимосвязь бизнеса, информационных систем и технологических областей. Его продвигало федеральное правительство США. Это не была структура EA в том виде, в котором мы ее видим сейчас, но она помогла сформировать идею разделения EA на домены или уровни архитектуры. Модель архитектуры предприятия NIST, по-видимому, была первой публикацией, в которой постоянно использовался термин «архитектура предприятия». [13]

В 1990 году термин «архитектура предприятия» был впервые официально определен как архитектура, которая «определяет и связывает между собой данные, аппаратное обеспечение, программное обеспечение и коммуникационные ресурсы, а также поддерживающую организацию, необходимую для поддержания общей физической структуры, необходимой для архитектура". [13] [15]

В 1992 году статья Захмана и Совы [12] началось так: «Джон Захман представил структуру архитектуры информационных систем (ISA), которая получила широкое распространение среди системных аналитиков и разработчиков баз данных». Термин «архитектура предприятия» не появился. В статье речь шла об использовании структуры ISA для описания «...общей информационной системы и того, как она связана с предприятием и окружающей его средой». Слово «предприятие» использовалось как синоним бизнеса.

В 1993 году в книге Стивена Спевака «Планирование архитектуры предприятия» (EAP) был определен процесс определения архитектур использования информации для поддержки бизнеса и план реализации этих архитектур. Бизнес-миссия является основной движущей силой. Затем данные, необходимые для выполнения миссии. Затем создаются приложения для хранения и предоставления этих данных. Наконец, технология реализации приложений. Планирование архитектуры предприятия — это ориентированный на данные подход к планированию архитектуры. Цель состоит в том, чтобы улучшить качество данных, доступ к данным, адаптируемость к меняющимся требованиям, совместимость и совместное использование данных, а также сдерживание затрат. (BSP) IBM EAP берет свое начало в системе планирования бизнес-систем . [13]

В 1994 году Open Group выбрала TAFIM Министерства обороны США в качестве основы для разработки TOGAF, где архитектура означала ИТ-архитектуру. TOGAF начал с стратегического и общекорпоративного, но ориентированного на технологии подхода. Оно возникло из-за желания рационализировать беспорядочное ИТ-состояние. Вплоть до версии 7 TOGAF по-прежнему был сосредоточен на определении и использовании технической эталонной модели (или базовой архитектуры) для определения сервисов платформы, требуемых от технологий, которые все предприятие использует для поддержки бизнес-приложений. [9]

В 1996 году Закон США о реформе управления ИТ , более известный как Закон Клингера-Коэна , неоднократно предписывал, что инвестиции федерального правительства США в ИТ должны быть сопоставлены с идентифицируемыми выгодами для бизнеса. Кроме того, он возложил на ИТ-директора агентства ответственность за «...разработку, поддержание и содействие внедрению надежной и интегрированной ИТ-архитектуры для исполнительного агентства».

К 1997 году Захман переименовал и переориентировал свою структуру ISA на структуру EA; она оставалась схемой классификации описательных артефактов, а не процессом планирования систем или изменений в системах.

В 1998 году Федеральный совет ИТ-директоров начал разработку Федеральной структуры архитектуры предприятия (FEAF) в соответствии с приоритетами, изложенными в документе Клингера-Коэна, и опубликовал ее в 1999 году. FEAF представлял собой процесс, очень похожий на ADM TOGAF, в котором «команда архитекторов создает план последовательности перехода систем, приложений и связанных с ними бизнес-практик, основанный на подробном анализе пробелов [между базовой и целевой архитектурами]».

В 2001 году Совет главных ИТ-директоров США опубликовал «Практическое руководство по архитектуре федерального предприятия », которое начинается так: «Архитектура предприятия (EA) устанавливает дорожную карту для всего агентства для достижения миссии агентства посредством оптимального выполнения его основных бизнес-процессов в рамках эффективной информационной системы. технологической (ИТ) среды».На тот момент процессы в TOGAF, FEAF, EAP и BSP были явно связаны.

В 2002/3 году в версии Enterprise Edition TOGAF 8 сместил акцент с уровня технологической архитектуры на более высокие уровни бизнеса, данных и приложений. он представил структурированный анализ После разработки информационных технологий , который включает, например, сопоставление организационных единиц с бизнес-функциями и объектов данных с бизнес-функциями. Сегодня бизнес-функции часто называют бизнес-возможностями. И многие архитекторы предприятий рассматривают свои бизнес-функции/иерархию/карту возможностей как фундаментальный артефакт архитектуры предприятия. Они связывают объекты данных, варианты использования, приложения и технологии с функциями/возможностями.

В 2006 году вышла популярная книга «Архитектура предприятия как стратегия». [16] сообщила о результатах работы Центра исследований информационных систем Массачусетского технологического института. В этой книге подчеркивается необходимость для корпоративных архитекторов сосредоточиться на основных бизнес-процессах («Компании преуспевают, потому что они [решили], какие процессы они должны выполнять хорошо, и внедрили ИТ-системы для оцифровки этих процессов») и привлечь бизнес-менеджеров. с преимуществами, которые может обеспечить стратегическая межорганизационная интеграция и/или стандартизация процессов.

(BCS) по разработке профессиональных сертификатов в области архитектуры предприятий и решений в 2008 году Исследовательский проект Британского компьютерного общества показал, что архитектура предприятия всегда была неотделима от архитектуры информационных систем, что естественно, поскольку деловым людям нужна информация для принятия решений и реализации. наши бизнес-процессы. [9]

В 2011 году TOGAF 9.1. В спецификации говорится: «Бизнес-планирование на уровне стратегии обеспечивает начальное направление архитектуры предприятия». [17] Обычно бизнес-принципы, бизнес-цели и стратегические движущие силы организации определяются в другом месте. [9] Другими словами, архитектура предприятия — это не бизнес-стратегия, методология планирования или управления. Архитектура предприятия стремится согласовать технологию бизнес-информационных систем с заданной бизнес-стратегией, целями и движущими силами. В спецификации TOGAF 9.1 поясняется, что «полное описание архитектуры предприятия должно содержать все четыре домена архитектуры (бизнес, данные, приложения, технологии), но реалии ограниченности ресурсов и времени часто означают, что не хватает времени, финансирования или ресурсов». построить нисходящее, всеобъемлющее описание архитектуры, охватывающее все четыре домена архитектуры, даже если объем предприятия [...] меньше, чем полный объем всего предприятия». [18]

В 2013 году ТОГАФ [19] — это самая популярная архитектурная среда (судя по опубликованным номерам сертификатов), которая, по мнению некоторых, определяет EA. [9] Однако некоторые до сих пор используют термин «Архитектура предприятия» как синоним бизнес-архитектуры, а не охватывают все четыре области архитектуры — бизнес, данные, приложения и технологии.

Темы фреймворка EA [ править ]

Область архитектуры [ править ]

Уровни архитектуры предприятия. [20]

Со времени выхода книги Стивена Спевака «Планирование архитектуры предприятия » (EAP) в 1993 году – а возможно, и раньше – стало нормальным делить архитектуру предприятия на четыре архитектурные области .

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

Многие платформы EA объединяют домены данных и приложений в единый (цифровой) уровень информационной системы, расположенный ниже бизнеса (обычно системы человеческой деятельности) и выше технологий ( ИТ-инфраструктура платформы ).

Уровни архитектуры предприятия [ править ]

Пример архитектуры федерального предприятия , в которой определены пять архитектурных уровней. [21]

В течение многих лет было принято рассматривать домены архитектуры как уровни, полагая, что каждый уровень содержит компоненты, которые выполняют процессы и предлагают услуги вышестоящему уровню. Такой взгляд на домены архитектуры был очевиден в TOGAF v1 (1996), который инкапсулировал уровень технологических компонентов позади сервисов платформы, определенных в «Технической эталонной модели» - во многом в соответствии с философией TAFIM и POSIX.

Представление об архитектурных областях как об уровнях можно представить следующим образом:

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

каждого уровня Делегаты работают на уровне ниже. На каждом уровне компоненты, процессы и услуги могут быть определены на грубом уровне и разложены на более мелкие компоненты, процессы и услуги. На рисунке показан вариант на эту тему.

Компоненты структуры архитектуры предприятия [ править ]

В дополнение к трем основным компонентам структуры, рассмотренным выше.

  1. Совет по описанию: какая-то карта архитектурных артефактов или библиотека точек обзора.
  2. Рекомендации по процессу: своего рода метод разработки архитектуры с вспомогательным руководством.
  3. Рекомендации по организации: включая модель управления EA

Идеальная структура EA должна включать в себя:

  1. Метрики измерения ценности бизнеса
  2. Модель инициативы ЭА
  3. Модель зрелости советника
  4. Модель корпоративного общения

Большинство современных платформ EA (например, TOGAF, ASSIMPLER, EAF) включают в себя большую часть вышеперечисленного. Захман всегда уделял особое внимание советам по описанию архитектуры.

Домены и поддомены архитектуры предприятия [ править ]

Эталонная архитектура архитектуры предприятия с поддоменами

Домены приложений и технологий (не путать с бизнес-доменами) характеризуются возможностями домена и сервисами домена. Возможности поддерживаются сервисами. Службы приложений также упоминаются в сервис-ориентированной архитектуре (SOA). Технические услуги обычно поддерживаются программными продуктами.

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

Эталонная традиционная модель архитектуры предприятия предлагает четкое разграничение между областями архитектуры (бизнес, информация/данные, приложение/интеграция и техника/инфраструктура). Эти домены можно дополнительно разделить на дисциплины поддоменов. Пример домена и поддоменов EA представлен на изображении справа.

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

Пример списка эталонных шаблонов архитектуры в областях прикладной и информационной архитектуры доступен на странице Архитектурные шаблоны (информатика) .

Посмотреть модель [ изменить ]

Иллюстрация архитектурной модели вида 4+1 .

Модель представления — это структура, определяющая набор представлений или подходов, используемых в системном анализе , проектировании систем или построении архитектуры предприятия .

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

Стандартизация [ править ]

Пожалуй, самый известный стандарт в области архитектуры программного обеспечения и системной архитектуры начал свою жизнь как IEEE 1471 , стандарт IEEE для описания архитектуры программно-интенсивных систем, утвержденный в 2000 году.

В своей последней версии стандарт опубликован как ISO/IEC/IEEE 42010:2011 . Стандарт определяет структуру архитектуры как соглашения, принципы и практики для описания архитектур, установленных в конкретной области применения и/или сообществе заинтересованных сторон , и предлагает структуру архитектуры, определяемую:

  1. соответствующие заинтересованные стороны в сфере,
  2. типы проблем, возникающих в этой области,
  3. точки зрения на архитектуру, обрамляющие эти проблемы и
  4. правила корреспонденции, интегрирующие упомянутые ранее точки зрения.

Архитектурные структуры, соответствующие стандарту, могут включать дополнительные методы, инструменты, определения и практики, помимо указанных.

Типы инфраструктур предприятия [ править ]

Лишь некоторые из инфраструктур архитектуры предприятия, используемых сегодня, 2011 г. [22]

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

Фреймворки, разработанные консорциумами [ править ]

  • ARCON – Эталонная архитектура для сетей совместной работы – ориентирована не на одно предприятие, а скорее на сети предприятий. [23] [24]
  • Эталонная архитектура TCI Cloud Security Alliance (Trusted Cloud Initiative). [25]
  • Универсальная эталонная архитектура и методология предприятия (GERAM)
  • RM-ODP – Эталонная модель открытой распределенной обработки (Рекомендация МСЭ-Т X.901-X.904 | ISO/IEC 10746) определяет структуру архитектуры предприятия для структурирования спецификаций открытых распределенных систем .
  • IDEAS Group — усилия четырех стран по разработке общей онтологии для совместимости архитектур.
  • ISO 19439 Структура моделирования предприятия
  • TOGAF – The Open Group Architecture Framework – широко используемая структура, включающая метод архитектурной разработки и стандарты для описания различных типов архитектуры.

промышленности Основы оборонной

  • AGATE – Архитектурная основа DGA Франции.
  • ДНДАФ [26] – Структура архитектуры DND/CF (CAN)
  • DoDAF – структура архитектуры Министерства обороны США.
  • MODAF – Архитектурная основа Министерства обороны Великобритании.
  • NAF – Архитектурная основа НАТО

Правительственные структуры [ править ]

Фреймворки с открытым исходным кодом [ править ]

Фреймворки корпоративной архитектуры, выпущенные с открытым исходным кодом :

  • АрхиМейт
  • Структура бережливой архитектуры (LAF) [29] — это набор передовых практик, благодаря которым ИТ-среда будет последовательно и быстро реагировать на меняющуюся бизнес-ситуацию, сохраняя при этом свою последовательную форму.
  • MEGAF (Архитектурная среда мегамоделирования) [30] — это инфраструктура для реализации архитектурных структур, которые соответствуют определению архитектурной структуры, приведенному в ISO/IEC/IEEE 42010 .
  • Praxeme , методология открытого предприятия, содержит структуру архитектуры предприятия, называемую топологией системы предприятия (EST).
  • TRAK — общий системно-ориентированный фреймворк, основанный на MODAF 1.2 и выпущенный под лицензией GPL / GFDL .
  • Прикладная архитектура безопасности бизнеса Шервуда (SABSA) [31] — это открытая структура и методология для архитектуры безопасности предприятия и управления услугами, основанная на рисках и ориентированная на интеграцию безопасности в управление бизнесом и ИТ.

Собственные фреймворки [ править ]

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

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

  1. ^ Совет директоров по информационным технологиям (1999). Федеральная структура архитектуры предприятия, версия 1.1. Архивировано 13 февраля 2012 г. на Wayback Machine . Сентябрь 1999 года.
  2. ^ «Техническая цель» . Найдите директора по информационным технологиям.
  3. ^ Открытая группа (2008) TOGAF, версия 9 . Издательство Ван Харен, 1 ноября. 2008.с. 73
  4. Перейти обратно: Перейти обратно: а б Стивен Марли (2003). Архитектурный каркас . НАСА / SCI. На Webarchive.org, получено 04.03.2015.
  5. ^ Яап Шеккерман (2004) Как выжить в джунглях архитектур архитектуры предприятия . на стр.89 дана аналогичная схема.
  6. ^ Министерство обороны США (2001) Техническая эталонная модель Министерства обороны . Версия 2.0. 9 апреля 2001 г. с. 11, упоминается, что POSIX также влияет на DoD TRM.
  7. ^ Эванс, М.К. и Хейг, Л.Р. (1962) Генеральный план информационных систем , Harvard Business Review, Vol. 40, № 1, стр. 92-103.
  8. ^ Котусев, Святослав (2021) Практика архитектуры предприятия: современный подход к согласованию бизнеса и ИТ (2-е издание) . Мельбурн, Австралия: SK Publishing.
  9. Перейти обратно: Перейти обратно: а б с д и Грэм Беррисфорд (2008-13) « Краткая история EA: что в ней есть, а чего нет. Архивировано 18 сентября 2013 г. на Wayback Machine » на grahamberrisford.com , последнее обновление 16.07.2013. По состоянию на 16 июля 2003 г.
  10. ^ Джон Захман (1982) Исследование планирования бизнес-систем и управления бизнес-информацией: сравнение в IBM Systems Journal 21 (1). стр32.
  11. Перейти обратно: Перейти обратно: а б Джон А. Захман (1987). Структура архитектуры информационных систем . В: IBM Systems Journal, том 26, № 3. Публикация IBM G321-5298.
  12. Перейти обратно: Перейти обратно: а б Захман и Сова (1992) Расширение и формализация структуры архитектуры информационных систем IBM Systems Journal, Том 31, № 3
  13. Перейти обратно: Перейти обратно: а б с д Святослав Котусев (2016). История архитектуры предприятия: обзор, основанный на фактических данных . В: Журнал архитектуры предприятия, том. 12, нет. 1, стр. 29-37.
  14. ^ ВБ Ригдон (1989). Архитектуры и стандарты . В «Направлениях управления информацией: задача интеграции» (специальная публикация NIST 500–167), Э. Н. Фонг, А. Х. Голдфайн (ред.), Гейтерсбург, Мэриленд: Национальный институт стандартов и технологий (NIST), стр. 135–150.
  15. ^ Ричардсон, Г.Л.; Джексон, Б.М.; Диксон, GW (1990). «Архитектура предприятия, основанная на принципах: уроки Texaco и Star Enterprise». МИС Ежеквартально . 14 (4): 385–403. дои : 10.2307/249787 . JSTOR   249787 .
  16. ^ Джинн В. Росс , Питер Вейл и Дэвид К. Робертсон (2006) Архитектура предприятия как стратегия: создание основы для ведения бизнеса . Harvard Business Review Press
  17. ^ Открытая группа (2011) TOGAF® 9.1 > Часть II: Метод разработки архитектуры (ADM) > Предварительный этап . По состоянию на 16 июля 2013 г.
  18. ^ Открытая группа (2011) TOGAF® 9.1 > Часть II: Метод разработки архитектуры (ADM) > Введение в ADM . По состоянию на 16 июля 2013 г.
  19. ^ Технический документ TOGAF 9.1. Введение в версию TOGAF 9.1 http://www.opengroup.org/togaf/
  20. ^ Найлз Э. Хьюлетт (2006), Программа архитектуры предприятия Министерства сельского хозяйства США. Архивировано 8 мая 2007 г. в Wayback Machine . PMP CEA, группа по архитектуре предприятия, USDA-OCIO. 25 января 2006 г.
  21. ^ Документ консолидированной эталонной модели FEA, заархивированный 5 июля 2010 г. в Wayback Machine . whitehouse.gov, май 2005 г.
  22. ^ Деннис Э. Висноски (2011) Архитектура инженерного предприятия: призыв к действию . в: Ежеквартальный журнал Common Defense . Январь 2011 г., с. 9
  23. ^ Л. М. Камаринья-Матос, Х. Афсарманеш, Сети для совместной работы: эталонное моделирование, Springer, 2008.
  24. ^ Камаринья-Матос, LM; Афсарманеш, Х. (2008). «Об эталонных моделях для совместных сетевых организаций». Международные журнальные исследования производства . 46 (9): 2453–2469. дои : 10.1080/00207540701737666 . S2CID   51802872 .
  25. ^ «Эталонная архитектура CSA TCI» (PDF) . Альянс облачной безопасности . Архивировано из оригинала 6 ноября 2016 года . Проверено 7 июля 2020 г.
  26. ^ DNDAF. Архивировано 24 апреля 2011 г. в Wayback Machine.
  27. ^ Джанни, Даниэле; Линдман, Никлас; Фукс, Иоахим; Сузик, Роберт (2012). «Представление архитектурной структуры Европейского космического агентства для космических систем системной инженерии». Проектирование и управление сложными системами. Материалы Второй международной конференции по проектированию и управлению сложными системами CSDM 2011 . Спрингер. стр. 335–346. CiteSeerX   10.1.1.214.9671 . дои : 10.1007/978-3-642-25203-7_24 . ISBN  978-3-642-25202-0 .
  28. ^ Совет директоров по информационным технологиям Министерства финансов США (2000). Структура архитектуры казначейского предприятия. Архивировано 18 марта 2009 г. на Wayback Machine . Версия 1, июль 2000 г.
  29. ^ https://lafinstitute.org/
  30. ^ МЕГАФ
  31. ^ САБСА
  32. ^ Методы Авансье (AM)
  33. ^ Лабнаф [1]
  34. ^ Прагматический советник [2]
  35. ^ Механизм проектирования решений (SAM)
  36. ^ Тони Шан и Винни Хуа (2006). Механизм проектирования решения . Материалы 10-й Международной конференции IEEE по корпоративным вычислениям EDOC (EDOC 2006), октябрь 2006 г., стр. 23-32.

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

Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: a8292534676588e9e43ec23b5ca1d5f8__1710069900
URL1:https://arc.ask3.ru/arc/aa/a8/f8/a8292534676588e9e43ec23b5ca1d5f8.html
Заголовок, (Title) документа по адресу, URL1:
Enterprise architecture framework - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)