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

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

Модель архитектуры предприятия NIST (Модель NIST EA) конец 80-х эталонная модель за архитектура предприятия. Он определяет архитектуру предприятия[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]

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

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

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

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

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

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

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

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

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

В третьей рабочей группе по системному планированию председательствовал Джон Захман, и принял Фреймворк Захмана как основу для обсуждения.

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

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

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

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

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

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

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

Темы, посвященные модели архитектуры предприятия NIST

Фонды

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

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

  • Есть несколько способов разработать архитектуру
  • Есть несколько способов внедрения стандартов
  • Разработка и внедрение должны быть адаптированы к среде
  • Тем не менее, каждую архитектуру можно разделить на разные уровни.

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложения

FDIC EA Framework.[27]

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

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

Примечания

  1. ^ Министерство обороны США включает аспекты бизнес-процессов в свою операционную архитектуру; Министерство финансов США учитывает это в своей деловой перспективе.
  2. ^ Министерство сельского хозяйства США включило этот компонент в свою бизнес-архитектуру, а Министерство обороны и казначейство США встроило его в свои операционные архитектуры.
  3. ^ Министерство энергетики США включает бизнес-приложения в свою субархитектуру приложений, а Министерство финансов США включает их в свою функциональную архитектуру.
  4. ^ Министерство сельского хозяйства США включило этот элемент в свою архитектуру бизнеса / данных, а Министерство финансов США включило его в свою информационную архитектуру.
  5. ^ Министерство сельского хозяйства США включило эту архитектуру в свои технические стандарты и архитектуру телекоммуникаций. Министерство обороны США использует свою системную архитектуру, а Министерство финансов США - свою инфраструктуру для описания физического уровня.

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

Эта статья включаетматериалы общественного достояния от Национальный институт стандартов и технологий интернет сайт https://www.nist.gov.

  1. ^ Совет директоров по информационным технологиям (2001 г.) Практическое руководство по архитектуре федерального предприятия версии 1.0 Предисловие. Февраль 2001 г.
  2. ^ а б c d е ж Совет директоров по информационным технологиям (1999 г.). Федеральная структура архитектуры предприятия версии 1.1. Сентябрь 1999 г.
  3. ^ а б c Элизабет Н. Фонг и Алан Х. Голдфайн (1989) Направления управления информацией: проблема интеграции. Специальная публикация 500-167 Национального института стандартов и технологий (NIST), сентябрь 1989 г.
  4. ^ Джон О'Луни (2002). Органы власти: вызовы и возможности для государственных менеджеров. Издательская группа «Гринвуд». стр.67.
  5. ^ Мэтью Уэст и Джулиан Фаулер (1999). Модели данных высокого качества. Технический представитель по связям с общественностью STEP в Европе, занимающийся перерабатывающей промышленностью (EPISTLE).
  6. ^ РЕМЕНЬ РАЗДЕЛ 2 ПОДХОД. Проверено 30 сентября 2008 года.
  7. ^ Джон Ф. Сова (2004). "The Challenge of Knowledge Soup" в: Тенденции исследований в области естественных наук, технологий и математического образования. Под редакцией Дж. Рамадаса и С. Чунавалы, Центр Хоми Бхабха, Мумбаи, 2006 г.
  8. ^ Фонг и Голдфайн (1989, с. 5)
  9. ^ Фонг и Голдфайн (1989, стр. I)
  10. ^ Франк, Эндрю У. Исследовательская группа по геоинформации, Вена. Проверено 15 июля 2013 г.
  11. ^ Дэвид Террасо (2004) "Умер 72-летний Роберт Фултон: профессор инженерных наук и уполномоченный округа ". на whistle.gatech.edu
  12. ^ Алан Х. Голдфайн в DBLP.
  13. ^ Дейл Гудхью в DBLP.
  14. ^ Стэнли Ю. В. Су в DBLP.
  15. ^ Фонг и Голдфайн (1989, стр. Ix)
  16. ^ В. Брэдфорд Ригдон (1989) «Архитектура и стандарты». В: Направления управления информацией: проблема интеграции. E.N. Фонг и А.Х. Голдфайн (ред.). NIST, сентябрь 1989 г., стр. 135–150
  17. ^ а б Ригдон (1989), стр. 136
  18. ^ Фонг и Голдфайн (1989, с. 136)
  19. ^ Дж. А. Захман (1993) Концепции Framework для EA - Ресурсы по архитектуре предприятия. Бумага Zachman International, Inc. п. 1
  20. ^ Леонор Баррока, Джон Холл и Патрик Холл (200) "Введение и история программных архитектур, компонентов и повторного использования " в: Программные архитектуры, 2000 с. 1
  21. ^ а б c d Франклин Д. Рейнс, РУО США (1997) Меморандум 97-16 (Архитектура информационных технологий) М-97-16, выпущен 18 июня 1997 г.
  22. ^ Ригдон и др. (1989, стр.136)
  23. ^ а б c Ригдон (1989), стр. 137
  24. ^ Ригдон и др. (1989, с. 137-38).
  25. ^ Ригдон и др. (1989, с. 139-140).
  26. ^ Примеры опубликованных архитектурных «каркасов» включают Структура архитектуры информационной системы казначейства (TISAF), Министерство обороны США Структура технической архитектуры для управления информацией (ТАФИМ), а Информационная архитектура Министерства энергетики Том 1.
  27. ^ OIG (2005). Реализация принципов электронного правительства В архиве 14 января 2009 г. Wayback Machine. Май 2005 г.
  28. ^ «Эксклюзивное интервью с Джоном Захманом» пользователя Roger Sessions. В: Перспективы Международной ассоциации архитекторов программного обеспечения. Апрель 2006 г.
  29. ^ Федеральное управление гражданской авиации (1998) Федеральные инициативы в области информационной архитектуры. Февраль 1998
  30. ^ Бобби Джонс (2003) Архитектура предприятия NWS. В: 20-я Международная конференция по интерактивным системам информации и обработки. 2004 г..

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