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

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

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

Введение

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

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

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

История

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

Развивающаяся область управления информацией

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

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

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

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

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

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

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

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

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

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

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

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

Пятую рабочую группу по архитектуре и стандартам возглавил У. Брэдфорд Ригдон из компании McDonnell Douglas Information Systems (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]

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

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

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

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

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

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

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

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

Документация по архитектуре предприятия должна включать обсуждение принципов и целей. ^{[Примечание 1]} Например, при разработке архитектуры предприятия следует четко понимать общую среду управления агентством, включая баланс между централизацией и децентрализацией, а также темпы изменений внутри агентства. В этой среде принципы и цели задают направление по таким вопросам, как содействие функциональной совместимости, открытые системы, публичный доступ, удовлетворенность конечных пользователей и безопасность.

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

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

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

Приложения

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

Информационная архитектура Министерства энергетики (DOE) ^[28]
Структура архитектуры предприятия FDIC — это структура архитектуры предприятия Федеральной корпорации по страхованию депозитов (FDIC).
Структура федеральной архитектуры предприятия (FEAF): в документации Федеральной структуры архитектуры предприятия версии 1.1 1999 года объясняется, как платформа NIST используется в качестве основы структуры FEA . ^[2]
Архитектура предприятия NWS: Архитектура предприятия Национальной метеорологической службы ^[29]

См. также

Примечания

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

Ссылки

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

^ Совет директоров по информационным технологиям (2001). Практическое руководство по архитектуре федерального предприятия, версия 1.0. Предисловие. Февраль 2001 года.
^ Перейти обратно: ^а ^б ^с ^д ^и ^ж Совет директоров по информационным технологиям (1999 г.). Структура федеральной архитектуры предприятия, версия 1.1 . Сентябрь 1999 года.
^ Перейти обратно: ^а ^б ^с Фонг и Голдфайн, 1989 г.
^ Джон О'Луни (2002). Подключение правительств: проблемы и возможности для государственных менеджеров . Издательская группа Гринвуд. стр.67.
^ Мэтью Уэст и Джулиан Фаулер (1999). Модели данных высокого качества . Руководитель технического взаимодействия STEP в европейских перерабатывающих отраслях (EPISTLE).
^ ПОДХОД К РАЗДЕЛУ 2 РЕМЕНЬЯ . Проверено 30 сентября 2008 г.
^ Джон Ф. Сова (2004). «Проблема знаний», в: Тенденции исследований в области науки, технологий и математического образования . Под редакцией Дж. Рамадаса и С. Чунавалы, Центр Хоми Бхабха, Мумбаи, 2006 г.
^ Фонг и Голдфайн 1989 , с. 5
^ Фонг и Голдфайн 1989 , с. я
^ Франк, Эндрю У. Исследовательская группа геоинформации, Вена. По состоянию на 15 июля 2013 г.
^ Дэвид Террасо (2004) « Роберт Фултон, 72 года, умирает: профессор инженерного дела и комиссар округа ». на сайтеWhistle.gatech.edu
^ Алан Х. Голдфайн на DBLP библиографическом сервере
^ Дейл Л. Гудхью на DBLP библиографическом сервере
^ Стэнли Ю.В. Су на DBLP библиографическом сервере
^ Фонг и Голдфайн 1989 , с. ix
^ Ригдон 1989
^ Перейти обратно: ^а ^б Ригдон 1989 , с. 136
^ Фонг и Голдфайн 1989 , с. 136
^ Дж. А. Захман (1993) Концепции структуры для EA - Ресурсы архитектуры предприятия . Бумага Zachman International, Inc. п. 1
^ Леонор Баррока, Джон Холл и Патрик Холл (200) « Введение и история архитектур программного обеспечения, компонентов и повторного использования » в: Архитектуры программного обеспечения , 2000 стр. 1
^ Перейти обратно: ^а ^б ^с ^д Франклин Д. Рейнс, OBM США (1997 г.) Меморандум 97-16 (Архитектура информационных технологий) M-97-16, выпущенный 18 июня 1997 г.
^ Ригдон 1989 , с. 136
^ Перейти обратно: ^а ^б ^с Ригдон 1989 , с. 137
^ Ригдон 1989 , стр. 137–138.
^ Ригдон 1989 , стр. 139–140.
^ OIG (2005). Реализация принципов электронного правительства. Архивировано 14 января 2009 г. в Wayback Machine . май 2005 г.
^ «Эксклюзивное интервью с Джоном Захманом» Роджера Сешнса. В: Перспективы Международной ассоциации архитекторов программного обеспечения . Апрель 2006 г.
^ Федеральное управление гражданской авиации (1998) Инициативы федеральной информационной архитектуры . февраль 1998 г.
^ Бобби Джонс (2003) Архитектура предприятия NWS . В: 20-я Международная конференция по интерактивным системам информации и обработки. 2004 .

Источники

Фонг, Элизабет Н.; Голдфайн, Алан Х., ред. (сентябрь 1989 г.). Направления управления информацией: задачи интеграции (PDF) . Специальное издание NIST. Том. 500–167. Национальный институт стандартов и технологий (NIST).
- Ригдон, У. Брэдфорд (сентябрь 1989 г.). «Архитектура и стандарты». Ин Фонг, Элизабет Н.; Голдфайн, Алан Х. (ред.). Направления управления информацией: задачи интеграции (PDF) . НИСТ. стр. 135–150.

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

[26] Примеры опубликованных архитектурных «структур» включают « Структуру архитектуры информационной системы Казначейства Министерства обороны США » (TISAF), «Структуру технической архитектуры управления информацией» (TAFIM) и «Информационную архитектуру Министерства энергетики», том 1 .

[27] Министерство обороны США включает аспекты элемента бизнес-процессов в свою операционную архитектуру; Министерство финансов США включает его в свою бизнес-идею.

[28] Министерство сельского хозяйства США включило этот компонент в свою бизнес-архитектуру, а Министерство обороны и Казначейство США встроило его в свою операционную архитектуру.

[29] Министерство энергетики США включает бизнес-приложения в свою подархитектуру приложений, а Министерство финансов США включает их в свою функциональную архитектуру.

[30] Министерство сельского хозяйства США включило этот элемент в свою архитектуру бизнеса/данных, а Министерство финансов США включило его в свою информационную архитектуру.

[31] Министерство сельского хозяйства США включило эту архитектуру в свои технические стандарты и телекоммуникационные архитектуры. Министерство обороны США использует свою системную архитектуру, а Казначейство США — свою инфраструктуру для описания физического уровня.

[CIO_2001-1] Совет директоров по информационным технологиям (2001). Практическое руководство по архитектуре федерального предприятия, версия 1.0. Предисловие. Февраль 2001 года.

[CIOC99-2] Перейти обратно: ^а ^б ^с ^д ^и ^ж Совет директоров по информационным технологиям (1999 г.). Структура федеральной архитектуры предприятия, версия 1.1 . Сентябрь 1999 года.

[FG89-3] Перейти обратно: ^а ^б ^с Фонг и Голдфайн, 1989 г.

[4] Джон О'Луни (2002). Подключение правительств: проблемы и возможности для государственных менеджеров . Издательская группа Гринвуд. стр.67.

[MW99-5] Мэтью Уэст и Джулиан Фаулер (1999). Модели данных высокого качества . Руководитель технического взаимодействия STEP в европейских перерабатывающих отраслях (EPISTLE).

[STRAP08-6] ПОДХОД К РАЗДЕЛУ 2 РЕМЕНЬЯ . Проверено 30 сентября 2008 г.

[JFS04-7] Джон Ф. Сова (2004). «Проблема знаний», в: Тенденции исследований в области науки, технологий и математического образования . Под редакцией Дж. Рамадаса и С. Чунавалы, Центр Хоми Бхабха, Мумбаи, 2006 г.

[8] Фонг и Голдфайн 1989 , с. 5

[9] Фонг и Голдфайн 1989 , с. я

[10] Франк, Эндрю У. Исследовательская группа геоинформации, Вена. По состоянию на 15 июля 2013 г.

[11] Дэвид Террасо (2004) « Роберт Фултон, 72 года, умирает: профессор инженерного дела и комиссар округа ». на сайтеWhistle.gatech.edu

[12] Алан Х. Голдфайн на DBLP библиографическом сервере

[13] Дейл Л. Гудхью на DBLP библиографическом сервере

[14] Стэнли Ю.В. Су на DBLP библиографическом сервере

[15] Фонг и Голдфайн 1989 , с. ix

[WBR_1989-16] Ригдон 1989

[Rigdon-17] Перейти обратно: ^а ^б Ригдон 1989 , с. 136

[18] Фонг и Голдфайн 1989 , с. 136

[19] Дж. А. Захман (1993) Концепции структуры для EA - Ресурсы архитектуры предприятия . Бумага Zachman International, Inc. п. 1

[20] Леонор Баррока, Джон Холл и Патрик Холл (200) « Введение и история архитектур программного обеспечения, компонентов и повторного использования » в: Архитектуры программного обеспечения , 2000 стр. 1

[M-97-16-21] Перейти обратно: ^а ^б ^с ^д Франклин Д. Рейнс, OBM США (1997 г.) Меморандум 97-16 (Архитектура информационных технологий) M-97-16, выпущенный 18 июня 1997 г.

[22] Ригдон 1989 , с. 136

[Rig_1989,_137-23] Перейти обратно: ^а ^б ^с Ригдон 1989 , с. 137

[24] Ригдон 1989 , стр. 137–138.

[25] Ригдон 1989 , стр. 139–140.

[32] OIG (2005). Реализация принципов электронного правительства. Архивировано 14 января 2009 г. в Wayback Machine . май 2005 г.

[Zac06-33] «Эксклюзивное интервью с Джоном Захманом» Роджера Сешнса. В: Перспективы Международной ассоциации архитекторов программного обеспечения . Апрель 2006 г.

[FAA98-34] Федеральное управление гражданской авиации (1998) Инициативы федеральной информационной архитектуры . февраль 1998 г.

[35] Бобби Джонс (2003) Архитектура предприятия NWS . В: 20-я Международная конференция по интерактивным системам информации и обработки. 2004 .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[Примечание 1]

[Примечание 2]

[Примечание 3]

[Примечание 4]

[Примечание 5]

[Примечание 6]

[26]

[27]

[28]

[29]