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

редактировать

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

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

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

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

Содержание
  • 1 Введение
  • 2 История
    • 2.1 Возникающая область управления информацией
    • 2.2 Семинар NIST по направлениям управления информацией
    • 2.3 Применение в 1990-е годы
  • 3 Темы модели архитектуры предприятия NIST
    • 3.1 Основы
    • 3.2 Уровни архитектуры
    • 3.3 Архитектура информационных технологий
  • 4 Приложения
  • 5 См. Также
  • 6 Примечания
  • 7 Ссылки
  • 8 Внешние ссылки
Введение

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

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

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

История

Модель архитектуры предприятия NIST была инициирована в 1988 году на пятом семинаре по направлениям управления информацией, спонсируемом NIST в сотрудничестве с Association for Computing Machinery (ACM), IEE E Computer Society и Федеральная группа пользователей управления данными (FEDMUG). Результаты этого исследовательского проекта были опубликованы в специальной публикации NIST 500-167, «Направления управления информацией: проблема интеграции».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложения
FDIC EA Framework.

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

См. Также
Примечания
Ссылки

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

Внешние ссылки
На Викискладе есть материалы, связанные с моделью архитектуры предприятия NIST.
Последняя правка сделана 2021-05-31 07:02:34
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте