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

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

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

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

Государственные структуры

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

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

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

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

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

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

  1. ^ Совет директоров по информационным технологиям (1999 г.). Федеральная структура архитектуры предприятия версии 1.1 В архиве 2012-02-13 в Wayback Machine. Сентябрь 1999 г.
  2. ^ «Техническая цель». SearchCIO.
  3. ^ Открытая группа (2008) TOGAF Версия 9. Van Haren Publishing, 1 нояб. 2008. с. 73
  4. ^ а б Стивен Марли (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. ^ а б c d е Грэм Беррисфорд (2008-13) "Краткая история советника: что в нем есть, а чего нет В архиве 2013-09-18 в Wayback Machine " на grahamberrisford.com, последнее обновление 16.07.2013. Доступ 16.07.2003.
  10. ^ Джон Захман (1982) Исследование по планированию бизнес-систем и контролю бизнес-информации: сравнение в IBM Systems Journal 21 (1). стр.32.
  11. ^ а б Джон А. Захман (1987). Основа для архитектуры информационных систем. В: IBM Systems Journal, том 26, № 3. Публикация IBM G321-5298.
  12. ^ а б Захман и Сова (1992) Расширение и формализация структуры архитектуры информационных систем Журнал IBM Systems, Том 31, № 3
  13. ^ а б c d Святослав Котусев (2016). История архитектуры предприятия: обзор, основанный на фактах. В: Journal of Enterprise Architecture, vol. 12, вып. 1. С. 29-37.
  14. ^ W.B. Ригдон (1989). Архитектура и стандарты. В разделе «Направления управления информацией: проблема интеграции» (Специальная публикация NIST 500-167), E.N. Фонг, А.Х. Голдфайн (ред.), Гейтерсбург, доктор медицины: Национальный институт стандартов и технологий (NIST), стр. 135-150.
  15. ^ Richardson, G.L .; Jackson, B.M .; Диксон, Г. (1990). «Архитектура предприятия, основанная на принципах: уроки Texaco и Star Enterprise». MIS Quarterly. 14 (4): 385–403. Дои:10.2307/249787. JSTOR  249787.
  16. ^ Жанна В. Росс, Питер Вайль, и Дэвид С. Робертсон ( (2006) Архитектура предприятия как стратегия: создание основы для ведения бизнеса. Пресса Harvard Business Review
  17. ^ Открытая группа (2011) TOGAF® 9.1> Часть II: Метод разработки архитектуры (ADM)> Предварительный этап. Доступ 16 июля 2013 г.
  18. ^ Открытая группа (2011) TOGAF® 9.1> Часть II: Метод разработки архитектуры (ADM)> Введение в ADM. Доступ 16 июля 2013 г.
  19. ^ Официальный документ TOGAF 9.1 Знакомство с TOGAF версии 9.1 http://www.opengroup.org/togaf/
  20. ^ Найлз Э. Хьюлетт (2006), Программа архитектуры предприятия Министерства сельского хозяйства США В архиве 2007-05-08 на Wayback Machine. PMP CEA, группа по архитектуре предприятия, USDA-OCIO. 25 января 2006 г.
  21. ^ Сводный эталонный образец документа FEA В архиве 2010-07-05 в Wayback Machine. whitehouse.gov, май 2005 г.
  22. ^ Деннис Э. Висноски (2011) Разработка архитектуры предприятия: призыв к действию. в: Common Defense Quarterly. Январь 2011 г., стр. 9
  23. ^ Камаринья-Матос Л.М., Афсарманеш Х., Совместные сети: эталонное моделирование, Springer, 2008.
  24. ^ Camarinha-Matos, L.M .; Афсарманеш, Х. (2008). «Об эталонных моделях для совместных сетевых организаций». Исследование производства международных журналов. 46 (9): 2453–2469. Дои:10.1080/00207540701737666. S2CID  51802872.
  25. ^ "Эталонная архитектура CSA TCI" (PDF). Альянс облачной безопасности. Архивировано из оригинал 11 июня 2016 г.. Получено 7 июля 2020.
  26. ^ DNDAF В архиве 2011-04-24 на Wayback Machine
  27. ^ Джанни, Даниэле; Линдман, Никлас; Фукс, Иоахим; Сузич, Роберт (2012). «Представление Архитектурных рамок Европейского космического агентства для космических систем системного проектирования». Проектирование сложных систем и управление ими. Труды Второй Международной конференции по проектированию сложных систем и управлению CSDM 2011. Springer. С. 335–346. CiteSeerX  10.1.1.214.9671. Дои:10.1007/978-3-642-25203-7_24. ISBN  978-3-642-25202-0.
  28. ^ Совет директоров по информационным технологиям Министерства финансов США (2000 г.). Структура архитектуры предприятия казначейства В архиве 2009-03-18 на Wayback Machine. Версия 1, июль 2000 г.
  29. ^ МЕГАФ
  30. ^ САБСА
  31. ^ Авансовые методы (AM)
  32. ^ Лабнаф [1]
  33. ^ Прагматичный советник [2]
  34. ^ Механизм проектирования решений (SAM)
  35. ^ Тони Шан и Винни Хуа (2006). Механизм построения решения. Материалы 10-й Международной конференции по корпоративным вычислениям IEEE EDOC (EDOC 2006), октябрь 2006 г., стр. 23-32.

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