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

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

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

Обзор

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

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

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

История

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Темы фреймворка EA

Область архитектуры

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

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

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

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

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

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

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

В течение многих лет было принято рассматривать домены архитектуры как уровни, полагая, что каждый уровень содержит компоненты, которые выполняют процессы и предлагают услуги вышестоящему уровню. Такой взгляд на домены архитектуры был очевиден в 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 г.

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

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

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

промышленности

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

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

• Архитектурная основа Европейского космического агентства (ESAAF) - основа европейских космических систем систем.
• Структура архитектуры предприятия Федеральной корпорации по страхованию вкладов (FDIC)
• Структура федеральной архитектуры предприятия (FEAF) – структура, разработанная в 1999 году Федеральным советом ИТ-директоров США для использования в правительстве США (не путать с руководством Федеральной архитектуры предприятия (FEA) 2002 года по категоризации и группировке инвестиций в ИТ, выпущенным США Федеральное управление управления и бюджета )
• Архитектура государственного предприятия (GEA) - общая структура, законодательно установленная для использования департаментами правительства Квинсленда.
• Эталонная архитектура правительства Нидерландов (NORA) - эталонная структура электронного правительства Нидерландов NORA.
• Модель архитектуры предприятия NIST
• Treasury Enterprise Architecture Framework (TEAF) — структура казначейства , опубликованная Министерством финансов США в июле 2000 года.
• Структура архитектуры предприятия Колумбии - MRAE - Marco de Referencia de Arquitectura Empresarial. Архивировано 10 мая 2021 г. в Wayback Machine. Структура для всех государственных учреждений Колумбии.
• Структура архитектуры предприятия Индии (IndEA) — IndEA является эталонной структурой правительства Индии.

Фреймворки с открытым исходным кодом

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

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

Собственные фреймворки

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

См. также

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

Внешние ссылки

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