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

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

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

Обзор

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

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

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

История

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Домен архитектуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типы фреймворка архитектуры предприятия

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

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

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

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

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

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

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

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

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

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

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

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

использованная литература

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