Войти
Модель архитектуры предприятия NIST, инициированная в 1989 году, одна из самых ранних структур для архитектуры предприятия.Структура архитектуры предприятия (Структура архитектуры предприятия ) определяет, как создавать и использовать архитектуру предприятия. Структура архитектуры предоставляет принципы и методы для создания и использования описания архитектуры системы. Он структурирует мышление архитекторов, разделяя описание архитектуры на области, уровни или представления, и предлагает модели - обычно матрицы и диаграммы - для документирования каждого представления. Это позволяет принимать системные проектные решения по всем компонентам системы и принимать долгосрочные решения в отношении новых требований к дизайну, устойчивости и поддержки.
Архитектура предприятия рассматривает предприятие как большую и сложную систему или систему систем. Чтобы управлять масштабом и сложностью этой системы, архитектурная структура предоставляет инструменты и подходы, которые помогают архитекторам абстрагироваться от уровня детализации, на котором работают строители, чтобы сосредоточить внимание на задачах корпоративного проектирования и создать ценную документацию по описанию архитектуры.
Компоненты структуры архитектуры обеспечивают структурированное руководство, которое разделено на три основные области:
Обзор эволюции структур архитектуры предприятия (1987–2003 гг.). Слева: Zachman Framework 1987, Архитектура предприятия NIST 1989, EAP 1992, TISAF 1997, FEAF 1999 и TEAF 2000. Справа: TAFIM под влиянием POSIX, JTA, JTAA, TOGAF 1995, DoD TRM и C4ISR 1996 и DoDAF 2003. Самые ранние рудименты методологии поэтапного планирования, которую в настоящее время поддерживает TOGAF и другие структуры EA, можно проследить до статьи Маршалла К. Эванса и Лу Р. Хейга под названием «Генеральный план информации. Systems », опубликованной в 1962 году в Harvard Business Review.
С 1970-х годов люди, работающие в сфере информационных технологий и информационных технологий, искали способы привлечь деловых людей - чтобы задействовать бизнес-роли и процессы - и повлиять на инвестиции в информационные системы для бизнеса технологий - с учетом широкой и долгосрочной выгоды предприятия. Многие цели, принципы, концепции и методы, используемые в настоящее время в структурах EA, были определены в 1980-х годах, и их можно найти в структурах архитектуры IS и ИТ, опубликованных в то и следующее десятилетие.
К 1980 году Планирование бизнес-систем (BSP) продвигалось как метод анализа и проектирования информационной архитектуры организации со следующими целями:
В 1982 году, работая в IBM и с BSP, Джон Захман изложил свою структуру для «Архитектуры информационных систем» корпоративного уровня. Тогда и в более поздних статьях Захман использовал слово «предприятие» как синоним слова «бизнес». «Хотя многие популярные методологии планирования информационных систем, подходы к проектированию, а также различные инструменты и методы не исключают и не противоречат анализу на уровне предприятия, лишь немногие из них явно обращаются или пытаются определить архитектуры предприятия». Однако в этой статье термин «Архитектура предприятия» упоминался только один раз без какого-либо конкретного определения, и во всех последующих работах Захмана использовался термин «Архитектура информационных систем».
В 1986 году был разработан в результате исследовательский проект, спонсируемый группой компаний, включая IBM, который, казалось бы, был первой опубликованной структурой EA.
В 1987 году Джон Захман, специалист по маркетингу в IBM, опубликовал статью A Framework for Information Системная архитектура. В документе представлена схема классификации артефактов, которые описывают (на нескольких уровнях абстракции), что, как, где, кто, когда и почему в информационных системах. Поскольку IBM уже использовала BSP, Захману не нужно было предоставлять процесс планирования. В документе не упоминается архитектура предприятия.
В 1989 году Национальный институт стандартов и технологий (NIST) опубликовал Модель архитектуры предприятия NIST. Это была пятиуровневая эталонная модель, которая иллюстрирует взаимосвязь бизнеса, информационных систем и технологических областей. Его продвигало федеральное правительство США. Это не была структура EA, как мы ее видим сейчас, но она помогла установить понятие разделения EA на домены или уровни архитектуры. Модель архитектуры предприятия NIST, по-видимому, была первой публикацией, в которой последовательно использовался термин «Архитектура предприятия».
В 1990 году термин «Архитектура предприятия» впервые был официально определен как архитектура, которая «определяет и связывает данные, аппаратные средства, программное обеспечение и коммуникационные ресурсы, а также вспомогательная организация, необходимая для поддержания общей физической структуры, требуемой архитектурой ".
В 1992 году началась статья Захмана и Совы:" Джон Захман представил структура для архитектуры информационных систем (ISA), которая широко применяется системными аналитиками и разработчиками баз данных ». Термин "архитектура предприятия" не появился. Документ был посвящен использованию структуры ISA для описания «... общей информационной системы и того, как она связана с предприятием и окружающей средой». Слово «предприятие» использовалось как синоним слова «бизнес».
В 1993 году в книге Стивена Спевака Планирование архитектуры предприятия (EAP) был определен процесс определения архитектур для использования информации в поддержку бизнеса и план реализации этих архитектур. Бизнес-миссия - это главный драйвер. Затем данные необходимы для выполнения миссии. Затем приложения созданы для хранения и предоставления этих данных. Наконец, технология для реализации приложений. Планирование архитектуры предприятия - это подход к планированию архитектуры, ориентированный на данные. Цель состоит в том, чтобы улучшить качество данных, доступ к данным, адаптивность к меняющимся требованиям, совместимость и совместное использование данных, а также сдерживание затрат. EAP берет свое начало в IBM Business Systems Planning (BSP).
В 1994 году Open Group выбрала TAFIM из Министерства обороны США в качестве основы для разработки The Open Group Architecture Framework (TOGAF), где под архитектурой понималась ИТ-архитектура. TOGAF исходила из стратегического и общекорпоративного, но ориентированного на технологии взгляда. Это возникло из-за желания рационализировать грязную ИТ-среду. Вплоть до версии 7 TOGAF все еще был сосредоточен на определении и использовании технической эталонной модели (или базовой архитектуры) для определения сервисов платформы, необходимых для технологий, которые все предприятие использует для поддержки бизнес-приложений.
В 1996 году, Закон США о реформе управления ИТ, более известный как Закон Клингера-Коэна, неоднократно предписывал, что инвестиции федерального правительственного агентства США в ИТ должны быть сопоставлены с очевидными выгодами для бизнеса. Кроме того, он возложил на ИТ-директора агентства ответственность за «… разработку, поддержку и содействие внедрению надежной и интегрированной ИТ-архитектуры для исполнительного агентства».
К 1997 году Захман переименовал и переориентировал свою структуру ISA на структуру EA; он оставался схемой классификации описательных артефактов, а не процессом планирования систем или изменений в системах.
В 1998 году Федеральный совет директоров по информационным технологиям начал разработку Федеральной структуры архитектуры предприятия (FEAF) в соответствии с приоритетами, сформулированными в Клинджер-Коэн, и опубликовал ее в 1999 году. «Команда разработчиков архитектуры создает план последовательного перехода систем, приложений и связанных бизнес-практик, основанный на подробном анализе пробелов [между базовой и целевой архитектурами]».
В 2001 году Совет директоров по информационным технологиям США опубликовал Практическое руководство по архитектуре федерального предприятия, которое начинается со слов: «Архитектура предприятия (EA) устанавливает общесистемную дорожную карту для достижения цели агентства за счет оптимальной производительности его ядра. бизнес-процессы в рамках эффективной среды информационных технологий (ИТ) ». В этот момент процессы в TOGAF, FEAF, EAP и BSP были четко связаны.
В 2002/3 в Enterprise Edition TOGAF 8 сместился сфокусироваться с уровня технологической архитектуры на более высокие уровни бизнеса, данных и приложений. После инженерии информационных технологий был введен структурированный анализ, который включает, например, сопоставление организационных единиц с бизнес-функциями и объектов данных с бизнесом. Функции. Сегодня бизнес-функции часто называют бизнес-возможностями. И многие корпоративные архитекторы рассматривают свои бизнес-функции / иерархию / карту возможностей как фундаментальный артефакт архитектуры предприятия. y связывать объекты данных, варианты использования, приложения и технологии с функциями / возможностями.
В 2006 году популярная книга «Архитектура предприятия как стратегия» сообщила о результатах работы Центра исследований информационных систем Массачусетского технологического института. В этой книге подчеркивается, что архитекторам предприятий необходимо сосредоточиться на основных бизнес-процессах («Компании преуспевают, потому что они [решили], какие процессы они должны выполнять хорошо, и внедрили ИТ-системы для оцифровки этих процессов») и привлекать бизнес-менеджеров. с преимуществами, которые может дать стратегическая межорганизационная интеграция и / или стандартизация.
Исследовательский проект Британского компьютерного общества (BCS) по разработке профессиональных сертификатов в области архитектуры предприятий и решений в 2008 году показал, что архитектура предприятия всегда была неотделима от архитектуры информационных систем, которая является естественно, поскольку деловым людям информация необходима для принятия решений и выполнения бизнес-процессов.
В 2011 году ТОГАФ 9.1. В спецификации говорится: «Бизнес-планирование на уровне стратегии дает начальное направление для архитектуры предприятия». Обычно бизнес-принципы, бизнес-цели и стратегические движущие силы организации определяются в другом месте. Другими словами, архитектура предприятия - это не бизнес-стратегия, методология планирования или управления. Архитектура предприятия стремится согласовать технологии информационных систем бизнеса с заданной бизнес-стратегией, целями и драйверами. В спецификации TOGAF 9.1 уточняется, что «полное описание архитектуры предприятия должно содержать все четыре области архитектуры (бизнес, данные, приложение, технология), но реалии ресурсных и временных ограничений часто означают, что не хватает времени, финансирования или ресурсов. для построения нисходящего, всеобъемлющего описания архитектуры, охватывающего все четыре области архитектуры, даже если объем предприятия [...] меньше, чем полный объем всего предприятия ».
В 2013 году TOGAF - самая популярная архитектура архитектуры (судя по опубликованным номерам сертификатов), которая, по некоторым предположениям, определяет EA. Однако некоторые по-прежнему используют термин «Архитектура предприятия» как синоним «Архитектура бизнеса», а не охватывают все четыре области архитектуры - бизнес, данные, приложения и технологии.
Уровни корпоративной архитектуры. Со времен Стивена Спевака Планирование архитектуры предприятия (EAP) в 1993 году и, возможно, раньше тогда было нормальным делить архитектуру предприятия на четыре области архитектуры.
Обратите внимание, что архитектура приложений касается выбора и взаимосвязей между приложениями в портфель корпоративных приложений, а не внутренняя архитектура отдельного приложения (которую часто называют архитектурой приложения).
Многие структуры EA объединяют домены данных и приложений в единый (оцифрованный) уровень информационной системы, расположенный ниже бизнеса (обычно это система человеческой деятельности) и выше технологии (платформа ИТ-инфраструктура ).
Пример архитектуры федерального предприятия, в которой определены пять архитектурных уровней. В течение многих лет было принято рассматривать домены архитектуры как слои, с идеей, что каждый уровень содержит компоненты, которые выполняют процессы и предлагают услуги для уровня выше. Такой взгляд на домены архитектуры был очевиден в TOGAF v1 (1996), который инкапсулировал уровень технологических компонентов за сервисами платформы, определенными в «Технической эталонной модели» - во многом в соответствии с философией TAFIM и POSIX.
Представление архитектурных доменов как слоев можно представить следующим образом:
Каждый уровень делегирует работу нижнему уровню. На каждом уровне компоненты, процессы и службы могут быть определены на крупномасштабном уровне и разложены на более мелкие компоненты, процессы и услуги. На графике показана вариация на эту тему.
В дополнение к трем основным компонентам структуры, описанным выше.
Идеальная структура EA должна включать:
Большинство современных структур EA (например, TOGAF, ASSIMPLER, EAF) включают большую часть вышеперечисленного. Захман всегда уделял внимание советам по описанию архитектуры.
Эталонная архитектура архитектуры предприятия с субдоменами Домены приложений и технологий (не путать с доменами бизнеса) характеризуются возможностями домена и службами домена. Возможности поддерживаются сервисами. Службы приложений также упоминаются в ориентированной на службы архитектуре (SOA). Технические услуги обычно поддерживаются программными продуктами.
Просмотр данных начинается с классов данных, которые могут быть разложены на субъекты данных, которые могут быть далее разложены на объекты данных. Наиболее часто используемый базовый тип модели данных называется мерда (оценка диаграмм взаимосвязей основных сущностей, см. модель взаимосвязей сущностей ). Класс, субъект и сущность образуют иерархическое представление данных. У предприятий могут быть миллионы экземпляров объектов данных.
Эталонная традиционная модель архитектуры предприятия предлагает четкое различие между областями архитектуры (бизнес, информация / данные, приложение / интеграция и техническая / инфраструктура). Эти домены можно разделить на дисциплины субдоменов. Пример домена и поддоменов EA находится на изображении справа.
Многие группы по архитектуре предприятия состоят из специалистов с навыками, соответствующими доменам архитектуры предприятия и дисциплинам поддоменов. Вот несколько примеров: корпоративный бизнес-архитектор, корпоративный документальный архитектор, корпоративный архитектор приложений, корпоративный архитектор инфраструктуры, корпоративный информационный архитектор и т. Д.
Примером списка эталонных шаблонов архитектуры в областях прикладной и информационной архитектуры являются доступно по адресу Архитектурный образец (информатика).
Иллюстрация модели представления 4 + 1 архитектуры.A Модель представления - это структура, которая определяет набор представлений или подходы, используемые в системном анализе, проектировании систем или построении архитектуры предприятия.
С начала 1990-х годов был предпринят ряд попыток определить стандартные подходы для описания и анализа системных архитектур. Многие из последних фреймворков архитектуры предприятия имеют определенный набор представлений, но эти наборы не всегда называются моделями представлений.
Возможно, самый известный стандарт в области архитектуры программного обеспечения и системной архитектуры начал свою жизнь как IEEE 1471, Стандарт IEEE для описания архитектуры программно-интенсивной системы, утвержденный в 2000 году.
В своей последней версии стандарт опубликован как ISO / IEC / IEEE 42010 : 2011. Стандарт определяет структуру архитектуры как соглашения, принципы и практики для описания архитектур, установленных в конкретной области приложения и / или сообществе заинтересованных сторон, и предлагает структуру архитектуры, определяемую:
Структуры архитектуры, соответствующие стандарту могут включать дополнительные методы, инструменты, определения и практики помимо указанных.
Всего несколько структур архитектуры предприятия, используемых сегодня, 2011 г. В настоящее время существует бесчисленное множество структур EA, гораздо больше, чем в следующем списке.
Структуры архитектуры предприятия, выпущенные как с открытым исходным кодом :
 | На Викискладе есть материалы, относящиеся к архитектуре предприятия. |
