Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Структура «Федеральной структуры архитектуры предприятия» (FEAF), представленная в 2001 году, которая определила четыре архитектурных области. [1]

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

Обзор [ править ]

Слои советника

Начиная с книги Стивена Спевака под названием планирование архитектуры предприятия (EAP) в 1993 году [3] и, возможно, раньше, было нормальным распознавать четыре типа предметной области архитектуры. British Computer Society «s„Эталонная модель для предприятий и решений архитектуры“также следует этому подразделению , но дополнительно упоминает уровень архитектуры (одинарные) приложений чуть ниже приложение сек архитектуры, а также области информационной архитектуры, информационные системы архитектуры или безопасности архитектура (сквозная проблема): [4]

  • Бизнес-архитектура : структура и поведение бизнес-системы (не обязательно связанной с компьютерами). Охватывает бизнес-цели, бизнес-функции или возможности, бизнес-процессы и роли и т. Д. Бизнес-функции и бизнес-процессы часто сопоставляются с приложениями и данными, которые им нужны.
  • Архитектура данных : структуры данных, используемые бизнесом и / или его приложениями. Описания данных в хранилище и данных в движении. Описание хранилищ данных, групп данных и элементов данных. Сопоставление этих артефактов данных с качеством данных, приложениями, местоположениями и т. Д.
  • Архитектура приложений : структура и поведение приложений, используемых в бизнесе, с упором на то, как они взаимодействуют друг с другом и с пользователями. Ориентация на данные, потребляемые и производимые приложениями, а не на их внутреннюю структуру. При управлении портфелем приложений приложения обычно сопоставляются с бизнес-функциями и технологиями платформы приложений.
    Архитектура приложения (или компонента): внутренняя структура, модульность программного обеспечения внутри приложения. Это программная архитектура на самом низком уровне детализации. Обычно это ниже уровня модульности, определяемого архитекторами решений. Однако жесткой разделительной линии нет .
  • Технологическая архитектура / Техническая архитектура или архитектура инфраструктуры: структура и поведение ИТ-инфраструктуры . Охватывает клиентские и серверные узлы конфигурации оборудования, приложения инфраструктуры, которые работают на них, услуги инфраструктуры, которые они предлагают приложениям, протоколы и сети, которые соединяют приложения и узлы.

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

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

См. Также [ править ]

Ссылки [ править ]

  1. ^ Совет директоров по информационным технологиям (2001) Практическое руководство по архитектуре федерального предприятия . Февраль 2001 г.
  2. ^ Н. Дедич, «FEAMI: Методология для включения и интеграции процессов архитектуры предприятия в существующие организационные процессы», в IEEE Engineering Management Review, doi: 10.1109 / EMR.2020.3031968.
  3. ^ Стивен Спевак ; SC Hill (1992). Планирование архитектуры предприятия: разработка схемы данных, приложений и технологий . Бостон, паб QED. Группа. ISBN 978-0-471-59985-2.
  4. ^ «Эталонная модель для сертификатов ISEB в версии 3.0 архитектуры предприятия и решения» (PDF) . bcs. 2010 г.