Модель архитектуры предприятия NIST

Референтная модель для архитектуры предприятия

Модель архитектуры предприятия NIST.

Модель архитектуры предприятия NIST ( модель EA NIST ) — это эталонная модель архитектуры предприятия конца 1980-х годов . Она определяет архитектуру предприятия [1] через взаимосвязь между бизнес-средой предприятия, его информационной и технологической средой. [2]

Разработанная в конце 1980-х годов Национальным институтом стандартов и технологий (NIST) и другими, федеральное правительство Соединенных Штатов продвигало эту эталонную модель в 1990-х годах в качестве основы для корпоративных архитектур отдельных правительственных агентств США и в общей федеральной корпоративной архитектуре . [2]

Вступление

Модель архитектуры предприятия NIST представляет собой пятиуровневую модель архитектуры предприятия , разработанную для организации, планирования и построения интегрированного набора информации и архитектур информационных технологий. Пять уровней определяются отдельно, но взаимосвязаны и переплетены. [2] Модель определяет взаимосвязь следующим образом: [3]

  • Архитектура бизнеса определяет информационную архитектуру
  • Информационная архитектура предписывает архитектуру информационных систем.
  • Архитектура информационных систем определяет архитектуру данных.
  • Архитектура данных предполагает определенные системы доставки данных, и
  • Системы доставки данных (программное обеспечение, оборудование, коммуникации) поддерживают архитектуру данных.

Иерархия в модели основана на представлении о том, что организация выполняет ряд бизнес-функций, каждая функция требует информации из ряда источников, и каждый из этих источников может использовать одну или несколько операционных систем, которые, в свою очередь, содержат данные, организованные и хранящиеся в любом количестве систем данных. [4]

История

Модель архитектуры предприятия NIST была инициирована в 1988 году на пятом семинаре по направлениям управления информацией, спонсируемом NIST в сотрудничестве с Ассоциацией вычислительной техники (ACM), IEEE Computer Society и Федеральной группой пользователей управления данными (FEDMUG). Результаты этого исследовательского проекта были опубликованы в виде специальной публикации NIST 500-167, Направления управления информацией: вызов интеграции . [3]

Новая область управления информацией

С распространением информационных технологий, начавшимся в 1970-х годах, работа по управлению информацией приобрела новый вид и также начала включать в себя область обслуживания данных . Управление информацией больше не было простой работой, которую мог выполнять практически каждый. Понимание задействованной технологии и теории, лежащей в ее основе, стало необходимым. По мере того, как хранение информации переходило на электронные средства, это становилось все более и более трудным. [3]

Понятие модели с тремя схемами было впервые введено в 1975 году трехуровневой архитектурой ANSI/X3/SPARC , которая определила три уровня для моделирования данных. [5]

Одним из первых общих подходов к построению информационных систем и управлению системной информацией с 1970-х годов был трехсхемный подход . Он предлагает использовать три различных представления при разработке систем, в которых концептуальное моделирование рассматривается как ключ к достижению интеграции данных : [6]

  • Внешняя схема для пользовательских представлений
  • Концептуальная схема интегрирует внешние схемы
  • Внутренняя схема, определяющая физические структуры хранения

В центре концептуальная схема определяет онтологию концепций , как пользователи думают о них и говорят о них. Физическая схема согласно Сова (2004) «описывает внутренние форматы данных, хранящихся в базе данных , а внешняя схема определяет вид данных, представленных прикладным программам ». [7]

С 1970-х годов NIST провел серию из четырех семинаров по направлениям управления базами данных и информацией. Каждый из семинаров посвящен определенной теме: [8]

  • «Какая информация о технологии баз данных необходима менеджеру для принятия разумных решений об использовании новой технологии», 1975 год.
  • «Какая информация может помочь менеджеру оценить воздействие на систему базы данных?» в 1977 году.
  • « Инструменты управления информацией с точки зрения: использования; политик и контроля; логического и физического проектирования базы данных» в 1980 году; и
  • «Характер практики и проблемы управления информационными ресурсами » в 1985 году.

Пятый семинар в 1989 году проводила Национальная лаборатория компьютерных систем (NCSL) NIST. К тому времени это был один из четырех институтов, выполнявших техническую работу NIST. Конкретной целью NCSL было проведение исследований и предоставление научных и технических услуг для помощи федеральным агентствам в выборе, приобретении, применении и использовании компьютерных технологий. [9]

Семинар NIST по направлениям управления информацией

Пятый семинар Information Management Directions в 1989 году был сосредоточен на интеграции и производительности в управлении информацией . Пять рабочих групп рассматривали конкретные аспекты интеграции знаний, управления данными , планирования систем, разработки и обслуживания, вычислительных сред, архитектур и стандартов. Участники представляли академические круги, промышленность, правительство и консалтинговые фирмы. Среди 72 участников были Том ДеМарко , Ахмед К. Элмагармид , Элизабет Н. Фонг, Эндрю У. Франк , [10] Роберт Э. Фултон, [11] Алан Х. Голдфайн, [12] Дейл Л. Гудхью , [13] Ричард Дж. Майер , Шамкант Навате , Т. Уильям Олле , В. Брэдфорд Ригдон , Джудит А. Куиллард, Стэнли YW Су, [14] и Джон Захман .

Том ДеМарко выступил с программной речью, заявив, что стандарты приносят больше вреда, чем пользы, когда они работают против преобладающей культуры, и что суть стандартизации — это открытие, а не инновация. [15] Пять рабочих групп встретились, чтобы обсудить различные аспекты интеграции:

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

Третья рабочая группа по системному планированию работала под председательством Джона Захмана и приняла концепцию Захмана в качестве основы для обсуждения.

Модель архитектуры предприятия, 1989 г.

Пятая рабочая группа по архитектурам и стандартам была под председательством У. Брэдфорда Ригдона из McDonnell Douglas Information Systems Company (MDISC), подразделения McDonnell Douglas . Ригдон и др. (1989) [16] объяснили, что обсуждения архитектуры в то время в основном фокусировались на технологических проблемах. Их цель состояла в том, чтобы «взять более широкий взгляд и описать потребность в корпоративной архитектуре , которая включает акцент на бизнес- и информационные требования. Эти вопросы более высокого уровня влияют на архитектуру данных и технологий и решения». [17] Для этого рабочая группа рассмотрела три вопроса: [18]

  • Уровни архитектуры на предприятии
  • Проблемы, решаемые архитектурой
  • Преимущества и риски наличия архитектуры

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

Применение в 1990-х годах

В некотором смысле модель архитектуры предприятия NIST опередила свое время. Согласно Захману (1993), в 1980-х годах «архитектура» была признана интересной темой, но все еще было мало консолидированной теории относительно этой концепции. [19] Архитектура программного обеспечения , например, стала важной темой только во второй половине девяностых. [20]

Для поддержки модели архитектуры предприятия NIST в 1990-х годах она широко пропагандировалась в федеральном правительстве США как инструмент управления архитектурой предприятия. [2] Модель архитектуры предприятия NIST применяется в качестве основы в нескольких структурах архитектуры предприятия федеральных правительственных агентств США и в общей структуре архитектуры федерального предприятия . [2] При координации этих усилий модель NIST была дополнительно разъяснена и расширена в «Меморандумах 97-16 (Архитектуры информационных технологий)» 1997 года, выпущенных Управлением по управлению и бюджету США. [21] см. далее Архитектура информационных технологий.

Темы модели архитектуры предприятия NIST

Фонды

Согласно Ригдону и др. (1989), архитектура — это «четкое представление концептуальной структуры компонентов и их взаимосвязи в определенный момент времени». [22] Например, она может представлять «взгляд на текущую ситуацию с островками автоматизации, избыточными процессами и несоответствиями данных» [23] или «будущую интегрированную автоматизированную информационную структуру, к которой предприятие будет двигаться через предписанное количество лет». [24] Роль стандартов в архитектуре заключается в том, чтобы «обеспечивать или ограничивать архитектуру и служить ее основой». [23]

Для разработки архитектуры предприятия Ригдон признает: [17]

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

Различные уровни архитектуры предприятия можно визуализировать в виде пирамиды: наверху — бизнес-единица предприятия, а внизу — система доставки внутри предприятия. Предприятие может состоять из одной или нескольких бизнес-единиц, работающих в определенной области бизнеса. Пять уровней архитектуры определяются как: бизнес-единица, информация, информационная система, данные и система доставки. [23]

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

Примеры элементов архитектуры предприятия (1989).

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

Каждый уровень архитектуры в модели имеет определенное назначение: [25]

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

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

Архитектура информационных технологий

В «Меморандуме 97-16 (Архитектура информационных технологий)» дано следующее определение архитектуры предприятия: [21]

Архитектура предприятия — это явное описание текущих и желаемых взаимосвязей между бизнес-процессами и процессами управления и информационными технологиями. Она описывает «целевую» ситуацию, которую агентство хочет создать и поддерживать, управляя своим ИТ-портфелем.
Документация Enterprise Architecture должна включать обсуждение принципов и целей. [Примечание 1] Например, общая среда управления агентства, включая баланс между централизацией и децентрализацией и темпы изменений в агентстве, должна быть четко понята при разработке Enterprise Architecture. В этой среде принципы и цели задают направление по таким вопросам, как содействие взаимодействию, открытые системы, публичный доступ, удовлетворенность конечного пользователя и безопасность.

В этом руководстве была принята и дополнительно объяснена пятикомпонентная модель NIST. Агентствам было разрешено идентифицировать различные компоненты по мере необходимости и указывать организационный уровень, на котором будут реализованы конкретные аспекты компонентов. Хотя сущность этих компонентов, иногда называемых «архитектурами» или «субархитектурами», должна быть рассмотрена в полной архитектуре предприятия каждого агентства, агентства имеют большую гибкость в описании, комбинировании и переименовании компонентов, которые состоят из: [21]

  • Бизнес-процессы : этот компонент архитектуры предприятия описывает основные бизнес-процессы, которые поддерживают миссии организации. Компонент бизнес-процессов представляет собой высокоуровневый анализ работы, которую агентство выполняет для поддержки миссии, видения и целей организации, и является основой ITA. Анализ бизнес-процессов определяет информацию, необходимую и обрабатываемую агентством. Этот аспект ITA должен разрабатываться старшими менеджерами программ совместно с ИТ-менеджерами. Без глубокого понимания своих бизнес-процессов и их связи с миссиями агентства агентство не сможет эффективно использовать свой ITA.
    Бизнес-процессы можно описать, разложив процессы на производные бизнес-действия. Существует ряд методологий и связанных с ними инструментов, которые помогают агентствам разлагать процессы. Независимо от используемого инструмента, модель должна оставаться на достаточно высоком уровне, чтобы обеспечить широкую фокусировку агентства, но при этом достаточно подробной, чтобы быть полезной для принятия решений, поскольку агентство определяет свои информационные потребности. Агентства должны избегать чрезмерного акцента на моделировании бизнес-процессов, что может привести к пустой трате ресурсов агентства. [Примечание 2]
  • Информационные потоки и связи : этот компонент анализирует информацию, используемую организацией в ее бизнес-процессах, идентифицируя используемую информацию и движение информации внутри агентства. В этом компоненте описываются связи между различными потоками информации. Эти информационные потоки указывают, где необходима информация и как она распределяется для поддержки функций миссии. [Примечание 3]
  • Приложения  : компонент приложений идентифицирует, определяет и организует действия, которые собирают, манипулируют и управляют бизнес-информацией для поддержки операций миссии. Он также описывает логические зависимости и отношения между бизнес-действиями. [Примечание 4]
  • Описания данных : этот компонент архитектуры предприятия определяет, как данные поддерживаются, доступны и используются. На высоком уровне агентства определяют данные и описывают отношения между элементами данных, используемыми в информационных системах агентства. Компонент описания и отношений данных может включать модели данных, которые описывают данные, лежащие в основе деловых и информационных потребностей агентства. Четкое представление данных и отношений данных важно для определения данных, которые могут совместно использоваться корпоративно, для минимизации избыточности и для поддержки новых приложений [Примечание 5]
  • Технологическая инфраструктура  : компонент технологической инфраструктуры описывает и идентифицирует физический уровень, включая функциональные характеристики, возможности и взаимосвязи оборудования, программного обеспечения и коммуникаций, включая сети, протоколы и узлы. Это «схема электропроводки» физической ИТ-инфраструктуры . [Примечание 6]

За исключением компонента «Бизнес-процессы», взаимосвязи между этими компонентами и их приоритеты не предписываются данным руководством; не подразумевается никакой иерархии взаимоотношений. Кроме того, агентства должны документировать не только свою текущую среду для каждого из этих компонентов, но и целевую среду, которая является желаемой. [21]

Приложения

Структура FDIC EA. [26]

Структура NIST была принята несколькими федеральными агентствами США и использована в качестве основы для их информационной стратегии. [27] Эталонная модель применяется в следующих структурах:

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

Примечания

  1. ^ Примерами опубликованных архитектурных «фреймворков» являются « Структура архитектуры информационной системы казначейства» (TISAF), «Структура технической архитектуры для управления информацией» Министерства обороны США (TAFIM) и «Информационная архитектура, том 1» Министерства энергетики.
  2. ^ Министерство обороны США включает аспекты элемента «Бизнес-процессы» в свою операционную архитектуру; Министерство финансов США включает его в свое бизнес-представление.
  3. ^ Министерство сельского хозяйства США включило этот компонент в свою бизнес-архитектуру, а Министерство обороны и казначейство США встроили его в свои операционные архитектуры.
  4. ^ Министерство энергетики США включает бизнес-приложения в свою субархитектуру приложений, а Министерство финансов США включает их в свою функциональную архитектуру.
  5. ^ Министерство сельского хозяйства США включило этот элемент в свою архитектуру бизнеса/данных, а Министерство финансов США включило его в свою информационную архитектуру.
  6. ^ Министерство сельского хозяйства США включило эту архитектуру в свои Технические стандарты и Архитектуры телекоммуникаций. Министерство обороны США использует свою Системную архитектуру, а Казначейство США — свою Инфраструктуру для описания физического уровня.

Ссылки

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

  1. ^ Совет директоров по информации (2001) Практическое руководство по архитектуре федерального предприятия, версия 1.0. Предисловие. Февраль 2001 г.
  2. ^ abcdef Совет директоров по информации (1999). Структура архитектуры федерального предприятия, версия 1.1. Сентябрь 1999 г.
  3. ^ abc Фонг и Голдфайн 1989
  4. ^ Джон О'Луни (2002). Электрификация правительств: проблемы и возможности для государственных менеджеров . Greenwood Publishing Group. стр. 67.
  5. ^ Мэтью Уэст и Джулиан Фаулер (1999). Высококачественные модели данных. Технический координатор по связям с общественностью STEP в европейской обрабатывающей промышленности (EPISTLE).
  6. ^ ПОДХОД К РАЗДЕЛУ 2 STRAP. Получено 30 сентября 2008 г.
  7. ^ Джон Ф. Сова (2004). «Проблема супа знаний» в: Research Trends in Science, Technology and Mathematics Education . Под редакцией Дж. Рамадаса и С. Чунавалы, Центр Хоми Бхабха, Мумбаи, 2006.
  8. ^ Фонг и Голдфайн 1989, стр. 5
  9. ^ Фонг и Голдфайн 1989, стр. i
  10. ^ Франк, Эндрю У. Исследовательская группа геоинформации, Вена. Доступ 15 июля 2013 г.
  11. ^ Дэвид Террасо (2004) «Роберт Фултон, 72, умирает: профессор инженерии и окружной комиссар». на whistle.gatech.edu
  12. ^ Алан Х. Голдфайн на сервере библиографии DBLP
  13. ^ Дейл Л. Гудхью на библиографическом сервере DBLP
  14. ^ Стэнли YW Su на сервере библиографии DBLP
  15. ^ Фонг и Голдфайн 1989, стр. ix
  16. ^ Ригдон 1989
  17. ^ ab Rigdon 1989, стр. 136
  18. ^ Фонг и Голдфайн 1989, стр. 136
  19. ^ JA Zachman (1993) Концепции для Framework for EA - Enterprise Architecture Resources . Статья Zachman International, Inc., стр. 1
  20. ^ Леонор Баррока, Джон Холл и Патрик Холл (200) «Введение и история архитектур программного обеспечения, компонентов и повторного использования» в: Архитектуры программного обеспечения , 2000 г., стр. 1
  21. ^ abcd Франклин Д. Рейнс, US OBM (1997) Меморандумы 97-16 (Архитектура информационных технологий) M-97-16, выпущенные 18 июня 1997 г.
  22. ^ Ригдон 1989, стр. 136
  23. ^ abc Ригдон 1989, стр. 137
  24. ^ Ригдон 1989, стр. 137–138
  25. ^ Ригдон 1989, стр. 139–140
  26. ^ OIG (2005). Внедрение принципов электронного правительства Архивировано 14 января 2009 г. в Wayback Machine . Май 2005 г.
  27. ^ "Эксклюзивное интервью с Джоном Захманом" Роджера Сешнса. В: Перспективы Международной ассоциации архитекторов программного обеспечения . Апрель 2006 г.
  28. ^ Федеральное управление гражданской авиации (1998) Инициативы по федеральной информационной архитектуре . Февраль 1998 г.
  29. ^ Бобби Джонс (2003) Архитектура предприятия NWS. В: 20-я Международная конференция по интерактивным информационным и вычислительным системам. 2004 .

Источники

  • Фонг, Элизабет Н.; Голдфайн, Алан Х., ред. (сентябрь 1989 г.). Направления управления информацией: проблема интеграции (PDF) . Специальная публикация NIST. Том  500–167 . Национальный институт стандартов и технологий (NIST).
    • Ригдон, В. Брэдфорд (сентябрь 1989 г.). «Архитектуры и стандарты». В Фонг, Элизабет Н.; Голдфайн, Алан Х. (ред.). Направления управления информацией: проблема интеграции (PDF) . NIST. стр.  135–150 .
На Викискладе есть медиафайлы по теме « Модель архитектуры предприятия NIST» .
Retrieved from "https://en.wikipedia.org/w/index.php?title=NIST_Enterprise_Architecture_Model&oldid=1238118856"