Каркас архитектуры предприятия - Enterprise architecture framework

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

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

Обзор

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

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

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

История

Обзор эволюции структур архитектуры предприятия (1987–2003 гг.).^[4][5] Слева: Фреймворк Захмана 1987, Архитектура предприятия NIST 1989, EAP 1992, ТИСАФ 1997, FEAF 1999 и ЧАЙФ 2000. Справа: ТАФИМ под влиянием POSIX, JTA, JTAA, TOGAF 1995, МО ТРМ^[6] и C4ISR 1996 г. и DoDAF 2003.

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

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

К 1980 году IBM Планирование бизнес-систем (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 Планирование бизнес-систем (BSP).^[13]

В 1994 году Open Group выбрала ТАФИМ от Министерства обороны США в качестве основы для разработки Open Group Architecture Framework (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 EditionTOGAF 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

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

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

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

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

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

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

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

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

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

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

Посмотреть модель

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

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

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

Стандартизация

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

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

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

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

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

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

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

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

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

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

• АГАТ - Архитектурная структура France 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 это справочная система от правительства Индии.

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

Структуры архитектуры предприятия, выпущенные как Открытый исходный код:

• МЕГАФ^[29] это инфраструктура для реализации структур архитектуры, которые соответствуют определению структуры архитектуры, приведенному в ISO / IEC / IEEE 42010.
• Праксема, методология открытого предприятия, содержит структуру архитектуры предприятия, называемую топологией корпоративной системы (EST).
• TRAK - общая системно-ориентированная структура, основанная на MODAF 1.2 и выпущен под GPL /GFDL.
• Архитектура прикладной безопасности бизнеса Sherwood (САБСА)^[30] - это открытая структура и методология для архитектуры безопасности предприятия и управления услугами, основанная на рисках и ориентированная на интеграцию безопасности в управление бизнесом и ИТ.

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

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

Смотрите также

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

Рекомендации

внешняя ссылка

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