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

В этой статье используются пустые URL-адреса , которые неинформативны и уязвимы для ссылочной порчи . Пожалуйста, рассмотрите возможность преобразования их в полные цитаты, чтобы гарантировать, что статья останется проверяемой и сохранит единый стиль цитирования. Для форматирования доступно несколько шаблонов и инструментов, таких как reFill ( документация ) и Citation bot ( документация ) . ( Сентябрь 2022 г. ) ( Узнайте, как и когда удалять это сообщение )

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

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

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

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

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

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

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

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

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

В 1986 году в результате исследовательского проекта, спонсируемого группой компаний, включая IBM, была разработана структура архитектуры PRISM, которая, по-видимому, была первой опубликованной структурой 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 берет свое начало в планировании бизнес-систем (BSP) компании IBM. ^[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 году популярная книга Enterprise Architecture As Strategy ^[16] сообщила о результатах работы Центра исследований информационных систем Массачусетского технологического института. В этой книге подчеркивается необходимость для архитекторов предприятий сосредоточиться на основных бизнес-процессах («Компании преуспевают, потому что они [решили], какие процессы они должны выполнять хорошо, и внедрили ИТ-системы для оцифровки этих процессов») и вовлекать бизнес-менеджеров в преимущества, которые может предоставить стратегическая кросс-организационная интеграция процессов и/или стандартизация.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ARCON – эталонная архитектура для совместных сетей – ориентирована не на одно предприятие, а на сети предприятий ^{[23] [24]}
• Эталонная архитектура TCI Cloud Security Alliance ( Trusted Cloud Initiative). ^[25]
• Обобщенная корпоративная эталонная архитектура и методология (GERAM)
• RM-ODP — эталонная модель открытой распределенной обработки (ITU-T Rec. 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
• Treasury Enterprise Architecture Framework (TEAF) – структура для казначейства , опубликованная Министерством финансов США в июле 2000 года. ^[28]
• Колумбийская структура архитектуры предприятия - MRAE - Marco de Referencia de Arquitectura Empresarial Архивировано 10.05.2021 в Wayback Machine, структура для всех государственных учреждений Колумбии
• Структура архитектуры предприятия Индии (IndEA) — IndEA — это эталонная структура от правительства Индии.
• Архитектура информационных технологий Medicaid (MITA) — структура Центра США по услугам Medicare и Medicaid (CMS) для содействия комплексной трансформации бизнеса и информационных технологий для Medicaid

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

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

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

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

• Корпоративные архитектурные фреймворки: мода века (июль 2016 г.)
• Сравнение четырех лучших фреймворков корпоративной архитектуры (июль 2021 г.)