NIST Enterprise Architecture Model ( NIST EA Model ) является поздним 1980s Эталонная модель для архитектуры предприятия . Он определяет архитектуру предприятия [1] посредством взаимосвязи между деловой, информационной и технологической средами предприятия. [2]
Разработанная в конце 1980-х годов Национальным институтом стандартов и технологий (NIST) и другими, федеральное правительство США продвигало эту эталонную модель в 1990-х годах в качестве основы для корпоративных архитектур отдельных правительственных агентств США и в общей архитектуре федерального предприятия. . [2]
вступление
Модель архитектуры предприятия NIST - это пятиуровневая модель архитектуры предприятия , предназначенная для организации, планирования и построения интегрированного набора архитектур информационных и информационных технологий. Пять слоев определены отдельно, но взаимосвязаны и переплетены. [2] Модель определила взаимосвязь следующим образом: [3]
- Бизнес-архитектура управляет информационной архитектурой
- Информационная архитектура предписывает архитектуру информационных систем
- Архитектура информационных систем определяет архитектуру данных
- Архитектура данных предлагает определенные системы доставки данных, и
- Системы доставки данных (программное обеспечение, оборудование, связь) поддерживают архитектуру данных.
Иерархия в модели основана на представлении о том, что организация управляет рядом бизнес-функций, каждая функция требует информации из нескольких источников, и каждый из этих источников может управлять одной или несколькими операционными системами, которые, в свою очередь, содержат данные, организованные и хранится в любом количестве систем данных. [4]
История
Модель архитектуры предприятия NIST была инициирована в 1988 году на пятом семинаре по направлениям управления информацией, организованном NIST в сотрудничестве с Ассоциацией вычислительной техники (ACM), Компьютерным обществом IEEE и Федеральной группой пользователей управления данными (FEDMUG). Результаты этого исследовательского проекта были опубликованы в специальной публикации NIST 500-167 « Направления управления информацией: проблема интеграции» . [3]
Возникающая область управления информацией
С распространением информационных технологий, начавшимся в 1970-х годах, работа по управлению информацией приобрела новый свет и также стала включать в себя сферу обслуживания данных . Управление информацией больше не было простой задачей, которую мог выполнить почти любой. Стало необходимым понимание задействованной технологии и теории, лежащей в основе этого. По мере того как хранение информации переходило на электронные средства, это становилось все труднее и труднее. [3]
Одним из первых общих подходов к созданию информационных систем и системного управления информацией с 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] Пять рабочих групп встретились, чтобы обсудить различные аспекты интеграции:
- интеграция знаний и управления данными
- интеграция управления техническими и бизнес-данными
- интеграция инструментов и методов системного планирования, разработки и обслуживания
- интеграция распределенных гетерогенных вычислительных сред и
- архитектуры и стандарты.
В третьей рабочей группе по системному планированию под председательством Джона Захмана была принята концепция Захмана в качестве основы для обсуждения.
Пятую рабочую группу по архитектурам и стандартам возглавил У. Брэдфорд Ригдон из McDonnell Douglas Information Systems Company (MDISC), подразделения McDonnell Douglas . Ригдон и др. (1989) [16] объяснили, что дискуссии об архитектуре в то время в основном сосредоточены на проблемах технологий. Их цель заключалась в том, чтобы «расширить взгляд и описать потребность в корпоративной архитектуре, которая включает упор на бизнес-требования и требования к информации. Эти проблемы более высокого уровня влияют на архитектуру данных и технологий и решения». [17] Для этого рабочая группа рассмотрела три вопроса: [18]
- Уровни архитектуры на предприятии
- Проблемы, решаемые архитектурой
- Преимущества и риски наличия архитектуры
Чтобы проиллюстрировать уровни архитектуры, была представлена модель, известная как модель архитектуры предприятия NIST (см. Изображение). В этой концепции три уровня подхода с тремя схемами разделены на пять уровней.
Применение в 1990-е годы
В некотором смысле модель архитектуры предприятия NIST опередила свое время. Согласно Захману (1993), в 80-е годы «архитектура» была признана интересной темой, но единой теории относительно этой концепции еще не существовало. [19] Архитектура программного обеспечения , например. стали важной темой не раньше второй половины девяностых годов. [20]
Для поддержки модели архитектуры предприятия NIST в 1990-х годах она широко рекламировалась в федеральном правительстве США как инструмент управления архитектурой предприятия. [2] Модель архитектуры предприятия NIST применяется в качестве основы во многих структурах архитектуры предприятия федеральных правительственных агентств США и в общей структуре архитектуры предприятия . [2] Для координации этих усилий модель NIST была дополнительно объяснена и расширена в 1997 г. «Меморандумом 97-16 (Архитектура информационных технологий)», выпущенном Управлением управления и бюджета США. [21] см. Далее « Архитектура информационных технологий» .
Темы, посвященные модели архитектуры предприятия NIST
Фонды
По данным Rigdon et al. (1989) архитектура - это «четкое представление концептуальной основы компонентов и их взаимосвязи в определенный момент времени». [22] Это может, например, представлять «взгляд на текущую ситуацию с островками автоматизации, избыточными процессами и несогласованностями данных» [23] или «будущую интегрированную информационную структуру автоматизации, к которой предприятие будет двигаться в установленное количество лет. " [24] Роль стандартов в архитектуре состоит в том, чтобы «разрешать или ограничивать архитектуру и служить ее основой». [23]
Для разработки архитектуры предприятия Ригдон признает: [17]
- Есть несколько способов разработать архитектуру
- Есть несколько способов внедрения стандартов
- Разработка и внедрение должны быть адаптированы к среде.
- Тем не менее, каждую архитектуру можно разделить на разные уровни.
Различные уровни корпоративной архитектуры можно представить в виде пирамиды: наверху - бизнес-единица предприятия, а внизу - система доставки внутри предприятия. Предприятие может состоять из одного или нескольких бизнес-единиц, работающих в определенной сфере бизнеса. Пять уровней архитектуры определены как: бизнес-единица, информация, информационная система, данные и система доставки. [23]
Отдельные уровни архитектуры предприятия взаимосвязаны особым образом. На каждом уровне архитектуры предполагают или диктуют архитектуры на более высоком уровне. На иллюстрации справа показан пример того, какие элементы могут составлять архитектуру предприятия.
Уровни архитектуры
Каждый уровень архитектуры в модели имеет определенное намерение: [25]
- Уровень бизнес-архитектуры: этот уровень может отображать всю корпорацию или ее подразделение, которые находятся в контакте с внешними организациями.
- Уровень информационной архитектуры: этот уровень определяет типы контента, формы представления и формат необходимой информации.
- Уровень архитектуры информационных систем: Спецификации для автоматизированных и процедурно-ориентированных информационных систем.
- Уровень архитектуры данных: структура для обслуживания, доступа и использования данных со словарем данных и другими соглашениями об именах.
- Уровень систем доставки данных: уровень технической реализации программного обеспечения, оборудования и средств связи, поддерживающих архитектуру данных.
Некоторые примеры элементов более подробного описания архитектуры предприятия показаны на иллюстрации.
Архитектура информационных технологий
В «Меморандуме 97-16 (Архитектура информационных технологий)» дано следующее определение архитектуры предприятия: [21]
- Архитектура предприятия - это подробное описание текущих и желаемых отношений между бизнесом, процессами управления и информационными технологиями. Он описывает «целевую» ситуацию, которую агентство желает создать и поддерживать, управляя своим ИТ-портфелем.
- Документация по архитектуре предприятия должна включать обсуждение принципов и целей. [26] Например, при разработке архитектуры предприятия следует четко понимать общую среду управления агентства, включая баланс между централизацией и децентрализацией, а также скорость изменений внутри агентства. В этой среде принципы и цели задают направление по таким вопросам, как содействие взаимодействию, открытые системы, общий доступ, удовлетворенность конечных пользователей и безопасность.
В этом руководстве была принята и дополнительно разъяснена пятикомпонентная модель NIST. Агентствам было разрешено идентифицировать различные компоненты по мере необходимости и определять организационный уровень, на котором будут реализованы определенные аспекты компонентов. Хотя сущность этих компонентов, иногда называемых «архитектурами» или «подархитектурами», должна рассматриваться в полной архитектуре предприятия каждого агентства, агентства обладают большой гибкостью в описании, объединении и переименовании компонентов, которые состоят из: [21]
- Бизнес-процессы : этот компонент архитектуры предприятия описывает основные бизнес-процессы, которые поддерживают миссии организации. Компонент «Бизнес-процессы» - это высокоуровневый анализ работы, которую агентство выполняет для поддержки миссии, видения и целей организации, и является основой ITA. Анализ бизнес-процессов определяет, какая информация нужна и обрабатывается агентством. Этот аспект ITA должен разрабатываться старшими руководителями программ совместно с ИТ-менеджерами. Без глубокого понимания своих бизнес-процессов и их отношения к миссии агентства агентство не сможет эффективно использовать свою ITA.
Бизнес-процессы можно описать путем разложения процессов на производные бизнес-операции. Существует ряд методологий и связанных инструментов, помогающих агентствам разложить процессы. Независимо от используемого инструмента, модель должна оставаться на достаточно высоком уровне, чтобы позволить агентству сфокусироваться на широком спектре, но в то же время достаточно детализированной, чтобы быть полезной при принятии решений, когда агентство определяет свои информационные потребности. Агентства должны избегать чрезмерного акцента на моделирование бизнес-процессов, которое может привести к нерациональной трате ресурсов агентства. [Примечание 1] - Информационные потоки и отношения : этот компонент анализирует информацию, используемую организацией в ее бизнес-процессах, определяя используемую информацию и движение информации внутри агентства. В этом компоненте описываются отношения между различными потоками информации. Эти информационные потоки указывают, где требуется информация и как информация передается для поддержки функций миссии. [Заметка 2]
- Приложения : компонент «Приложения» идентифицирует, определяет и организует действия, которые собирают, обрабатывают и управляют бизнес-информацией для поддержки операций миссии. Он также описывает логические зависимости и отношения между бизнес-операциями. [Заметка 3]
- Описания данных : этот компонент архитектуры предприятия определяет, как данные поддерживаются, доступны и используются. На высоком уровне агентства определяют данные и описывают отношения между элементами данных, используемыми в информационных системах агентства. Компонент Data Descriptions and Relationships может включать модели данных, которые описывают данные, лежащие в основе бизнеса и информационных потребностей агентства. Четкое представление данных и взаимосвязей между данными важно для определения данных, которые могут использоваться совместно, для минимизации избыточности и для поддержки новых приложений [Примечание 4]
- Технологическая инфраструктура : компонент технологической инфраструктуры описывает и идентифицирует физический уровень, включая функциональные характеристики, возможности и взаимосвязи оборудования, программного обеспечения и средств связи, включая сети, протоколы и узлы. Это «электрическая схема» физической ИТ-инфраструктуры . [Примечание 5]
За исключением компонента «Бизнес-процессы», взаимосвязь между этими компонентами и их приоритеты в данном руководстве не предписываются; здесь не подразумевается иерархия отношений. Более того, агентства должны задокументировать не только свою текущую среду для каждого из этих компонентов, но и желаемую целевую среду. [21]
Приложения
Структура NIST была выбрана несколькими федеральными агентствами США и использовалась в качестве основы для своей информационной стратегии. [28] Эталонная модель применяется в следующих рамках:
- Информационная архитектура Министерства энергетики (DOE) [29]
- Структура архитектуры предприятия FDIC - это структура архитектуры предприятия Федеральной корпорации по страхованию депозитов (FDIC).
- Федеральная структура архитектуры предприятия (FEAF): документация 1999 года о структуре архитектуры федерального предприятия версии 1.1 объясняет, как структура NIST используется в качестве основы структуры FEA . [2]
- Архитектура предприятия NWS: Архитектура предприятия национальной метеорологической службы [30]
Смотрите также
- Профиль переносимости приложений (APP)
- История бизнес-архитектуры
- Эталонная модель среды открытой системы
- Структура технической архитектуры для управления информацией (TAFIM)
- Структура архитектуры информационной системы казначейства
Заметки
- ^ Министерство обороны США включает аспекты бизнес-процессов в свою операционную архитектуру; Министерство финансов США учитывает это в своей деловой перспективе.
- ^ Министерство сельского хозяйства США включило этот компонент в свою бизнес-архитектуру, а Министерство обороны и казначейство США встроило его в свою операционную архитектуру.
- ^ Министерство энергетики США включает бизнес-приложения в свою субархитектуру приложений, а Министерство финансов США включает их в свою функциональную архитектуру.
- ^ Министерство сельского хозяйства США включило этот элемент в свою архитектуру бизнеса / данных, а Министерство финансов США включило его в свою информационную архитектуру.
- ^ Министерство сельского хозяйства США включило эту архитектуру в свои технические стандарты и телекоммуникационные архитектуры. Министерство обороны США использует свою системную архитектуру, а Министерство финансов США - свою инфраструктуру для описания физического уровня.
Рекомендации
Эта статья включает материалы, являющиеся общественным достоянием, с веб-сайта Национального института стандартов и технологий https://www.nist.gov .
- ^ Совет директоров по информационным технологиям (2001) . Практическое руководство по архитектуре федерального предприятия, версия 1.0. Предисловие. Февраль 2001 г.
- ^ a b c d e f Совет директоров по информационным технологиям (1999). Федеральная структура архитектуры предприятия версии 1.1 . Сентябрь 1999 г.
- ^ a b c Элизабет Н. Фонг и Алан Х. Голдфайн (1989) Направления управления информацией: проблема интеграции . Специальная публикация 500-167 Национального института стандартов и технологий (NIST), сентябрь 1989 г.
- ^ Джон О'Луни (2002). Wiring правительства: проблемы и возможности для государственных менеджеров . Издательская группа "Гринвуд". стр.67.
- ^ Мэтью Уэст и Джулиан Фаулер (1999). Модели данных высокого качества . Исполнительный директор по техническим связям STEP в европейской обрабатывающей промышленности (EPISTLE).
- ^ ПОДХОД ЧЕРЕЗ РАЗДЕЛ 2 . Проверено 30 сентября 2008 года.
- ^ Джон Ф. Сова (2004). "Проблема знаний", в: Тенденции исследований в области естественных наук, технологий и математического образования . Под редакцией Дж. Рамадаса и С. Чунавела, Центр Хоми Бхабха, Мумбаи, 2006 г.
- ↑ Фонг и Голдфайн (1989, с. 5)
- ↑ Фонг и Голдфайн (1989, стр. I)
- ^ Франк, Andrew U. Research Group Geoinformation, Вена. По состоянию на 15 июля 2013 г.
- ^ Дэвид Террасо (2004) « Роберт Фултон, 72 года, умирает: профессор инженерного дела и комиссар графства ». на whistle.gatech.edu
- ^ Алан Х. Голдфайн в DBLP .
- ^ Дейл Гудхью в DBLP .
- ^ Стэнли YW Су в DBLP .
- ↑ Фонг и Голдфайн (1989, стр. Ix)
- ^ В. Брэдфорд Ригдон (1989) "Архитектура и стандарты". В кн .: Направления управления информацией: проблема интеграции . Е. Н. Фонг и А. Х. Голдфайн (ред.). NIST, сентябрь 1989 г., стр. 135–150
- ^ а б Ригдон (1989), стр. 136
- ↑ Фонг и Голдфайн (1989, стр.136)
- ^ JA Zachman (1993) Концепции структуры для EA - Ресурсы архитектуры предприятия . Бумага Zachman International, Inc. п. 1
- ^ Леонор Баррока, Джон Холл и Патрик Холл (200) « Введение и история программных архитектур, компонентов и повторного использования » в: Software Architectures , 2000 p. 1
- ^ a b c d Франклин Д. Рейнс, US OBM (1997) Memoranda 97-16 (Архитектура информационных технологий) M-97-16, выпущенный 18 июня 1997 г.
- ^ Ригдон и др. (1989, стр.136)
- ^ a b c Ригдон (1989), стр. 137
- ^ Ригдон и др. (1989, стр. 137-38).
- ^ Ригдон и др. (1989, с. 139-140).
- ^ Примеры опубликованных архитектурных «структур» включают структуру архитектуры информационной системы казначейства (TISAF), структуру технической архитектуры министерства обороны США для управления информацией (TAFIM) и том 1 информационной архитектуры министерства энергетики .
- ^ КГИ (2005). Реализация принципов электронного правительства. Архивировано 14 января 2009 г. на Wayback Machine . Май 2005 г.
- ^ "Эксклюзивное интервью с Джоном Захманом" Роджером Сешнсом. В: Перспективы Международной ассоциации архитекторов программного обеспечения . Апрель 2006 г.
- ^ Федеральное управление гражданской авиации (1998) Инициативы федеральной информационной архитектуры . Февраль 1998 г.
- ^ Бобби Джонс (2003) Архитектура предприятия NWS . В: 20-я Международная конференция по интерактивным системам информации и обработки. 2004 .