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

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

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

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

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

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

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

Обзор эволюции структур архитектуры предприятия (1987–2003 гг.). [4] [5] Слева: 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Темы EA framework [ править ]

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

Слои архитектуры предприятия. [20]

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

  • Бизнес-архитектура ,
  • Архитектура данных ,
  • Архитектура приложений ,
  • Технологическая архитектура .

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

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

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

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

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

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

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

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

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

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

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

Идеальный фреймворк советника должен включать:

  1. Метрики измерения стоимости бизнеса
  2. Модель инициативы EA
  3. Модель зрелости EA
  4. Модель корпоративной коммуникации

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

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

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

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

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

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

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

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

Посмотреть модель [ редактировать ]

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

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

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

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

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

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

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

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

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

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

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

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

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

Рамки оборонной промышленности [ править ]

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

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

  • Архитектурная структура Европейского космического агентства (ESAAF) - основа для европейских космических систем систем [27]
  • Структура корпоративной архитектуры FDIC
  • Федеральная структура архитектуры предприятия (FEAF) - структура, разработанная в 1999 году Федеральным советом директоров по информационным технологиям США для использования в правительстве США (не путать с руководством по федеральной архитектуре предприятия (FEA) 2002 года по классификации и группировке инвестиций в ИТ, выпущенным Федеральное управление управления и бюджета США )
  • Архитектура государственного предприятия (GEA) - общая структура, законодательно разрешенная для использования департаментами правительства Квинсленда.
  • Nederlandse Overheid Referentie Architectuur (NORA) - эталонная структура от правительства Нидерландов E-overheid NORA
  • Модель архитектуры предприятия NIST
  • Структура казначейской архитектуры предприятия (TEAF) - структура казначейства , опубликованная Министерством финансов США в июле 2000 года. [28]
  • Структура архитектуры предприятия Колумбии - MRAE - Marco de Referencia de Arquitectura Empresarial - структура для всех государственных учреждений Колумбии
  • Структура архитектуры предприятия Индии (IndEA) - IndEA является эталонной структурой от правительства Индии.

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

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

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

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

  • ASSIMPLER Framework - структура архитектуры, основанная на работе Мандара Ванарса из Wipro в 2002 году.
  • Avancier Methods (AM) [32] Консультации по процессам и документации для архитекторов предприятий и решений, поддерживаемые обучением и сертификацией.
  • BRM (Build-Run-Manage) Framework - структура архитектуры, созданная Сандживом "Санни" Мишра в первые годы его работы в IBM в 2000 году.
  • Capgemini Integrated Architecture Framework (IAF) - от компании Capgemini в 1993 г.
  • Dragon1 - открытый метод визуальной корпоративной архитектуры, недавно признанный Open Group в качестве архитектуры архитектуры.
  • Фреймворк DYA, разработанный Sogeti с 2004 года.
  • Концепция архитектуры Dynamic Enterprise Enterprise на основе технологии Web 2.0
  • Расширенная структура архитектуры предприятия - от Института разработок архитектуры предприятия в 2003 г.
  • EACOE Framework [3] - структура архитектуры предприятия, разработанная Джоном Захманом.
  • IBM Information FrameWork (IFW) - задумана Роджером Эвернденом в 1996 году.
  • Инфомет - изобретен Питером Вилджоэном в 1990 году.
  • Labnaf [33] - Единая структура для управления преобразованиями предприятий
  • Платформа Pragmatic Enterprise Architecture Framework (PEAF) [34] - часть семейства платформ Pragmatic, разработанная Кевином Ли Смитом, Pragmatic EA, с 2008 г.
  • Эталонная архитектура предприятия Purdue, разработанная Теодором Дж. Уильямсом в Университете Пердью в начале 1990-х годов.
  • Структура архитектуры предприятия SAP
  • Фреймворк сервис-ориентированного моделирования (SOMF) , основанный на работе Майкла Белла
  • Механизм создания решений (SAM) [35] - структура согласованной архитектуры, состоящая из набора интегральных модулей. [36]
  • Zachman Framework - архитектурный фреймворк, основанный на работе Джона Захмана из IBM в 1980-х годах.

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

  • Шаблоны архитектуры (эталонная архитектура EA)
  • EABOK (Руководство по своду знаний об архитектуре предприятия)
  • Архитектура предприятия
  • Артефакты архитектуры предприятия
  • Планирование архитектуры предприятия
  • Инжиниринг предприятия
  • ISO / IEC / IEEE 42010
  • Эталонная архитектура

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

  1. ^ Совет директоров по информационным технологиям (1999). Федеральная структура архитектуры предприятия версии 1.1. Заархивировано 13 февраля 2012 г. на Wayback Machine . Сентябрь 1999 г.
  2. ^ «Техническая цель» . SearchCIO.
  3. ↑ Открытая группа (2008), версия 9 TOGAF . Van Haren Publishing, 1 нояб. 2008. с. 73
  4. ^ a b Стивен Марли (2003). Архитектурная основа . НАСА / SCI. На Webarchive.org, дата обращения 3 апреля 2015 г.
  5. ^ Яап Шеккерман (2004) Как выжить в джунглях структур архитектуры предприятия . с.89 дает аналогичную схему.
  6. ^ Министерство обороны США (2001) Техническая справочная модель Министерства обороны . Версия 2.0. 9 апреля 2001 г. с. 11, упоминалось, что на DoD TRM также влияет POSIX.
  7. ^ Эванс, М.К. и Гаага, Л.Р. (1962) Генеральный план информационных систем , Harvard Business Review, Vol. 40, No. 1, pp. 92-103.
  8. ^ Котусев, Святослав (2018) Практика корпоративной архитектуры: современный подход к бизнесу и согласованию ИТ . Мельбурн, Австралия: SK Publishing.
  9. ^ a b c d e Грэм Беррисфорд (2008-13) « Краткая история EA: что в ней, а что нет. Архивировано 18 сентября 2013 г. в Wayback Machine » на grahamberrisford.com , последнее обновление 16/07/ 2013. Доступ 16.07.2003.
  10. ^ Джон Захман (1982) Исследование планирования бизнес-систем и управления бизнес-информацией: сравнение в IBM Systems Journal 21 (1). стр32.
  11. ^ a b Джон А. Захман (1987). Структура для архитектуры информационных систем . В: IBM Systems Journal, том 26, № 3. Публикация IBM G321-5298.
  12. ^ a b Захман и Сова (1992) Расширение и формализация структуры архитектуры информационных систем IBM Systems Journal, Том 31, № 3
  13. ^ а б в г Святослав Котусев (2016). История архитектуры предприятия: обзор, основанный на фактах . В: Journal of Enterprise Architecture, vol. 12, вып. 1. С. 29-37.
  14. ^ WB Rigdon (1989). Архитектура и стандарты . In Information Management Directions: The Integration Challenge (NIST Special Publication 500-167), EN Fong, AH Goldfine (Eds.), Gaithersburg, MD: Национальный институт стандартов и технологий (NIST), стр.135-150.
  15. ^ Ричардсон, GL; Джексон, BM; Диксон, GW (1990). «Архитектура предприятия, основанная на принципах: уроки Texaco и Star Enterprise». MIS Quarterly . 14 (4): 385–403. DOI : 10.2307 / 249787 . JSTOR 249787 . 
  16. ^ Джин В. Росс , Питер Вейл и Дэвид С. Робертсон ((2006) Архитектура предприятия как стратегия: создание основы для выполнения бизнеса . Harvard Business Review Press
  17. ^ The Open Group (2011) TOGAF® 9.1> Часть II: Метод разработки архитектуры (ADM)> Предварительный этап . Доступ 16 июля 2013 г.
  18. ^ The Open Group (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, заархивированный 05.07.2010 на Wayback Machine . whitehouse.gov, май 2005 г.
  22. ^ Деннис Э. Висноски (2011) Разработка архитектуры предприятия: призыв к действию . в: Common Defense Quarterly . Январь 2011 г., стр. 9
  23. ^ LM Camarinha-Матос, Х. Afsarmanesh, Совместные сети: Справочное моделирование, Springer, 2008.
  24. ^ Камаринья-Матос, LM; Афсарманеш, Х. (2008). «Об эталонных моделях для совместных сетевых организаций». Международный журнал исследований производства . 46 (9): 2453–2469. DOI : 10.1080 / 00207540701737666 . S2CID 51802872 . 
  25. ^ "Эталонная архитектура CSA TCI" (PDF) . Альянс облачной безопасности . Архивировано из оригинального 11 июня 2016 года . Дата обращения 7 июля 2020 .
  26. ^ DNDAF Архивировано 24 апреля 2011 г. в Wayback Machine
  27. ^ Джанни, Даниэле; Линдман, Никлас; Фукс, Иоахим; Сузич, Роберт (2012). «Представление Архитектурных рамок Европейского космического агентства для космических систем системного проектирования». Проектирование сложных систем и управление ими. Труды Второй Международной конференции по проектированию сложных систем и управлению CSDM 2011 . Springer. С. 335–346. CiteSeerX 10.1.1.214.9671 . DOI : 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. ^ Методы Avancier (AM)
  33. ^ Лабнаф [1]
  34. ^ Прагматический советник [2]
  35. ^ Механизм создания решений (SAM)
  36. ^ Тони Шан и Винни Хуа (2006). Механизм построения решения . Материалы 10-й Международной конференции по корпоративным вычислениям IEEE EDOC (EDOC 2006), октябрь 2006 г., стр. 23-32.

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

  • Структуры архитектуры предприятия: причуда века (июль 2016 г.)