Развитие представлений об архитектуре предприятия

Термин "архитектура" означает множество близких по смыслу понятий, но применяющихся в различных приложениях. Известных формальных определений архитектуры существует несколько сотен ^[1].

В англоязычных источниках – в методиках, статьях, стандартах – термину "архитектура предприятия" соответствует термин enterprise architecture.

Дж. А. Захман в 1987 г. в статье "Структура архитектуры информационных систем" вначале называл свою концепцию архитектурной структурой информационных систем, а впоследствии – структурой архитектуры предприятия.

В публикациях, в основном в Интернете, содержится большое количество рекомендаций, материалы аналитических компаний, теоретические и практические наработки в области архитектуры ИТ таких организаций, как Совет директоров по информационным технологиям госорганизаций США (CIO Council) и ряда других ^[2].

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

Таблица 8.1

Краткая характеристика концепций архитектуры предприятия

Годы создания		Наименование, фирма (ведомство), автор		Основная идея концепции (модели)
1987		Модель Дж. А. Захмана.		Модель предприятия представляется в виде набора согласованных описаний, которые соотносятся с ячейками формализованной матрицы. По столбцам матрицы разнесены основные аспекты деятельности (объекты – "что", действия – "как", местоположения – "где", люди – "кто", время – "когда" и мотивы – "почему"). По строкам – различные описания системы с точки зрения бизнес-руководителей, менеджеров и разработчиков. В матрице учтены существенные для архитектуры аспекты предприятия. Заполнение матрицы происходит сверху вниз
1994		Модель Министерства обороны США ТАИМ (Technical Architecture Framework for Information Management – Базовая архитектура технического обеспечения для управления информацией)

1992		Модель ЕАР (Enterprise Architecture Planning – Планирование архитектуры предприятия) [7, 18], Стивен Спивак		Методика ЕАР обеспечивает взгляд на предприятие с точки зрения его бизнес-функций и требований к информационному обеспечению. Применен сегментный подход – 4 уровня, 7 блоков, определяющих архитектуру, и соответствующий план ее реализации. Модель основана на упрощенной матрице Захмана 1987 г. Суть процесса ЕАР состоит в определении верхних строк этой матрицы (при этом включена концепция технических средств). Методика ЕАР – это инструмент планирования, но не детального проектирования архитектуры. Результаты планирования используются в качестве основы для интегрированной разработки прикладных систем и технологий, которые обеспечивают потребности бизнеса. Отличительными характеристиками этого подхода к планированию архитектуры являются следующие: • в основу заложены потребности бизнеса, а не технологические факторы: • основное внимание в большей степени сосредоточено на данных и потребностях в информации, чем на процессах; • ответственность за процесс в бо́льшей степени несут представители бизнес-подразделений, чем специалисты по ИТ. Подходом Спивака пользовались такие организации, как: Министерство энергетики США, Штаб Военно-воздушных сил США





1995		Модель "4 + 1" (точнее 2The 4 + + 1) View Model of Architecture, Филипп Кручтен		Предлагается использовать пять представлений. Четырьмя основными представлениями в этой методике являются следующие. Логическое представление. Отвечает на вопрос: что система должна выполнять в терминах конечных пользователей? Для иллюстрирования могут применяться диаграммы классов (в нотации языка UML). Процессное представление. Учитывает нефункциональные требования к системе, включая производительность и доступность. Описывает вопросы параллельного исполнения и синхронизации процессов. Физическое представление. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы. Представление уровня разработки. Описывает фактическую организацию модулей системы, разделение ее на подсистемы, которые могут разрабатываться независимо. Архитектура системы во многом определяется сценариями, которые объединяют все представления вместе. Сценарии использования описываются как последовательность взаимодействия объектов и процессов. Они отражают наиболее важные требования, которые должна удовлетворять система. Это представление в каком-то смысле является избыточным и пересекается с четырьмя предыдущими, но оно важно по следующим причинам: сценарии использования позволяют идентифицировать элементы архитектуры, которые требуются для эффективно работающей системы; с помощью сценариев можно выполнять проверку и иллюстрацию того, что архитектура является работоспособной и полной








1996		Стратегическая модель архитектуры SAM (Strategic Architecture Model), английская консалтинговая компания Systems Advisers Ltd		SAM – это надстройка над моделью архитектуры предприятия Захмана. Она предоставляет общие структуры для определения архитектуры и механизмы, позволяющие организовать и анализировать информацию об архитектуре. SAM использует нотацию "сфер интересов*• для представления целостного набора фактов о предприятии и "отношений", которые связывают эти факты в "полезные" группы. В модели SAM выделены следующие категории сфер. • Стабильные – фундаментальные структуры, включающие бизнес-функции, исходные данные, бизнес-компоненты и инфраструктуру. • Подвижные – области моделирования, которые организация может изменить достаточно быстро. • Динамичные – основные области моделирования, в которых работает предприятие, а также действия, которые требуются для движения в сторону достижения целей и задач посредством связанных между собой проектов. "Сферы интересов" SAM позволяют систематизировать всю информацию, имеющую отношение к определенному предмету





1996–1997		"ЗD-модель" предприятия, Евгений Зиндер		Введена ось времени, где располагаются интервалы осуществления различных проектов и стадий развития ИС и всего предприятия. В качестве других осей выступает матрица Захмана: 1) ось уровня проектирования и использования ИС; 2) ось раздела обеспечения и аспекта работы И С; 3) ось времени, в котором развивается предприятие и его ИС. Стратегический и детальный анализ могут рассматриваться и как разные стадии, что демонстрирует принцип адаптации схемы к жизненным циклам разных типов. Характер расположения архитектурных компонентов ИС в этом третьем измерении отличается большим разнообразием, поскольку в реальной жизни многие процессы трансформации предприятия идут параллельно и итерационно. Применение схемы можно разбить на следующие шаги: Первым шагом является общее обсуждение 3D-схемы руководителями предприятияи его подразделений. Оно имеет своей целью достижение общего понимания всех типов сущностей этой схемы как компонентов и представлений системы в процессах их жизни – процессах создания и последующих трансформаций. Вторым шагом является разделение работ по построению самой общей модели 3D-предприятия между руководителями. Координатором всех работ может быть заместитель генерального директора или директор по развитию. Третьим шагом является привлечение специалистов и руководителей среднего звена с закреплением за ними конкретных "участков", то есть областей моделирования, на уровнях 3D-модели, начиная со второго и ниже. Четвертым шагом является первоначальное и неформальное описание тех частных моделей, которые актуальны для погружения в общую модель "как есть". Пятым шагом является рассмотрение совокупности частных моделей с их взаимосвязями

1999	Обобщенная рсференсная архитектура и методология предприятия GERAM, Ассоциация CIMOSA, рабочая группа 1FIP-IFAC		Методология GERAM (Generalised Enterprise Reference Architecture and Methodology) включена в качестве приложения в действующий базовый стандарт но архитектуре предприятия – ISO 15704 : 2000 "Requirements for enterprise-reference archite-ctures and methodologies" и до сих нор учитывается в новых стандартах (например, ISO 19439: 2006 "Enterprise integration Framework for enterprise modelling"). Схема GERAM предусматривала [7]: • четыре группы аспектов архитектуры предприятия, названных представлениями (Views) – типы моделей ("функции", "данные", "ресурсы", "организация"), назначения (может быть ассоциировано со столбцом "ЗАЧЕМ" Захмана), реализации и "физические представления" (аппаратура, НО) и возможность определять дополнительные аспекты; • описание всех аспектов или какой-то их части на каждой из семи или восьми фаз формирования архитектуры и функционирования предприятия; • конкретизацию модели архитектуры на трех уровнях – обобщенном, уровне частичных моделей и конкретных моделей

2002-2006	Архитектура федеральной организации FEA – Federal Enterprise Arhitecture, Административно-бюджетное управление США		В 1999 г. Совет директоров но информационным технологиям основных правительственных органов (CIO Council) предложил структуру архитектуры федеральной организации (FEAF). Версия 1.1 ISO 15704. В 2002 г. методология FEAF была переработана в FEA. FEA можно рассматривать и как методологию создания архитектуры предприятия, и как результат применения этой методологии к конкретной организационной структуре – Правительству США. Идея FEA в основном направлена на создание архитектуры сегмента для подмножества общей архитектуры предприятия (в случае с FEA предприятием является федеральное правительство, а подмножеством – правительственное агентство). Схема сегментов федерального правительства приведена на рисунке. Из рисунка видно, что многие сегменты используются во многих агентствах и все или почти все эти сегменты можно использовать повторно. FEA является наиболее полной методологией: она включает и всеобъемлющую таксономию, как в методологии Захмана, и архитектурный процесс, как в модели TOGAF

Декабрь 2003		Рамочная архитектура Министерства Обороны или DoDAF – Department of Defence Architecture Framework, Министерство обороны США		DoDAF содержит правила, руководства и документы, которые должны использоваться при разработке и описании архитектуры различных систем, используемых военным ведомством США. Архитектуру описывают три представления: • операционное; • системное; • представление технических параметров. Каждое из них используется для отражения различных архитектурных характеристик и атрибутов. Имеются пересечения – некоторые из атрибутов как бы объединяют два различных представления, что обеспечивает целостность, единство и единообразие в описании архитектуры. Важнейшим элементом и сильной стороной методики являются так называемые архитектурные продукты. Это графические, текстовые, табличные описания, которые создаются в процессе описания архитектуры и которые фиксируют характеристики, имеющие отношение к процессу







2003	TOGAF – The Open Group Architectural Framework (Структура архитектуры The Open Group), Консорциум The Open Group		Модель TOGAF применяется для описания интеграционных компонент, использующихся дчя поддержки широкого спектра корпоративных приложений. Как архитектурный процесс модель TOGAF дополняет модель Захман а. Захман показывает, как следует классифицировать артефакты. Модель TOGAF описывает процесс создания артефактов. В модели TOGAF архитектура предприятия подразделяется на четыре категории. 1. Архитектура бизнеса – описывает процессы, используемые для достижения бизнес-целей. 2. Архитектура приложений – описывает структуру конкретных приложений и их взаимодействие друг с другом. 3. Архитектура данных – описывает структуру корпоративных хранилищ данных и процедуры доступа к ним. 4. Технологическая архитектура – описывает инфраструктуру оборудования и программного обеспечения, в которой запускаются и взаимодействуют приложения

2005		Модель Gartner, Компания Gartner		Методология Gartner не является ни таксономией (как модель Захмана), ни процессом (как TOGAF), ни полной методологией (как FEA). Эта методология представляет собой набор практических рекомендаций по построению архитектуры предприятия, разработанных одной из наиболее известных в мире исследовательских и консалтинговых ИТ-организаций – компанией Gartner. Компания Gartner считает, что архитектура предприятия должна начинаться с того, чего организация собирается достичь, а не с текущего положения дел. После того как в организации будет сформировано единое представление о ее развитии, можно рассматривать влияние этого представления на архитектуру бизнеса, технологическую архитектуру, информационную архитектуру и архитектуру решений. В данном подходе сформулированы рекомендации, касающиеся разработки архитектуры в виде последовательности шагов и задач участников, которые, однако, не детализированы до уровня моделей процесса разработки архитектуры. Методика описания архитектуры Gartner представляет собой как бы трехмерный куб, состоящий из следующих элементов: • горизонтальные слои – бизнес-архитектура. Это четыре связанных, взаимозависимых и усложняющихся уровня; • вертикальные домены – информационная архитектура, включающая Приложения, Данные, Интеграцию, Доступ; • вертикальные элементы технической архитектуры, включающие Инфраструктуру, Системное управление, Безопасность. При этом описанные выше слои бизнес-архитектуры пересекаются со всеми элементами информационной и технической архитектур


2005	Методика Meta Group. Компания Meta Group		Отличительной особенностью методики МЕТА является более детальное и формализованное описание именно процесса разработки архитектуры и всех его составляющих. Архитектура реализуется на практике через процесс управления ИТ-программами и проектами. Предусматривает совместное участие представителей безнес-подразделений и ИТ в выработке общего понимания набора требований. Организация процесса разработки архитектуры и создание начальной версии архитектуры предприятия, согласно Meta Group, состоит в прохождении следующих этапов. 1. Видение общих требований в архитектуре. 2. Разработка концепции архитектуры. 3. Архитектурное моделирование. Методика предлагает формализованные шаблоны, обеспечивающие разработку основных документов: "Видение общих требовании" и "Принципы концептуальной архитектуры"

Однако вскоре Е. Зингер предложил более широкое определение: "Архитектура предприятия – это вовсе не архитектура информационных систем или технологий; данное понятие охватывает и устройство бизнеса (деятельности по государственному управлению, если это министерство), и базовые технологии (например, станки, банкоматы, технологические процессы и т.д.), и работников всех видов и рангов, и информационные технологии" ^[3].

"Архитектурный взгляд" на системы (как IТ-системы, так и бизнес-системы) определен в стандарте ANSI/IEEE 1471–2000 как фундаментальная организация системы, состоящая из совокупности компонент, их связей между собой и с внешней средой, а также принципов, которыми руководствуются при их создании и развитии".

Формальное определение в стандарте IEEE 1471 ^[4] Института инженеров-электриков и электронщиков для определения архитектуры предлагает метамодель. Этот стандарт определяет такие абстрактные элементы архитектуры, как представления, системы, среды, обоснования, заинтересованные стороны и т.д. В соответствии с этим представлением "система обладает некоторой архитектурой, которая может быть определенным образом описана с различных точек зрения в зависимости от интереса тех людей (участников), которые рассматривают архитектуру системы. Каждой точке зрения на архитектуру системы соответствует определенное представление, основу которого составляет некоторый набор моделей".

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

Применительно к архитектуре предприятия формальное описание впервые было сформулировано в стандарте ISO 15704, который был предложен рабочей группой IFAC/IFIP (International Federation of Automatic Control/International Federation for Information Processing). Идея состояла в том, чтобы разработать максимально общую, так называемую эталонную (reference) модель архитектуры предприятия, которая охватывала бы дополнительно процесс развития предприятия во времени как проект, а также учитывала бы роль человеческого фактора. Тогда архитектуры отдельных подсистем, в том числе ИТ-системы предприятия, могут быть разработаны как специфические уточнения такой общей модели.

Разработанная как приложение к данному стандарту, такая общая эталонная модель архитектуры получила название GERAM (Generalized Enterprise Reference Architecture and Methodology – Обобщенная референсная архитектура и методология предприятия). Фактически GERAM представляет собой абстрактное описание архитектуры общего уровня, которая может быть использована для "привязки" и сравнения между собой различных практических моделей архитектур. В частности, в ее рамках определяются такие понятия, как "продукт", "жизненный цикл", "роль персонала в системе", "моделирование процессов" применительно к задачам описания функционирования предприятия ^[5].

В Национальном стандарте Российской Федерации ^[6] архитектура определяется как "описание (модель) основного устройства (структуры) и связей, частей системы (физического или концептуального объекта или сущности)".

При этом предлагается различать два типа архитектур, имеющих отношение к интеграции предприятия, а именно:

а) системные архитектуры (называемые иногда архитектурами "типа 1"), действие которых распространяется на проектирование системы, например, на компьютеризированную систему, являющуюся частью системы интеграции предприятия;

б) стандартные проекты предприятия (называемые иногда архитектурами "типа 2"), действие которых распространяется на организацию разработки и выполнения проекта, например, на интеграцию предприятия или другую программу развития предприятия.

В некоторых работах выделяют такие виды, как системная архитектура (архитектура систем – System Architecture) и программная архитектура (архитектура программного обеспечения – Software Architecture).

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

Под "программной архитектурой" в зависимости от контекста может пониматься как архитектура взаимодействия приложений в рамках информационной системы предприятия (т.е. архитектура приложений), так и архитектура программных модулей или архитектура взаимодействия различных классов в рамках одного приложения.

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

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

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

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

Интересный пример анализа различных аспектов деятельности программного архитектора предлагается в стандарте IEEE 1471–2000 ^[7].

В соответствии с определениями компании Gartner ^[8] архитектура – это:

• общий план или концепция, используемая для создания системы, такой как здание или информационная система, или "абстрактное описание системы, ее структуры, компонентов и их взаимосвязей";

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

Первое определение ориентировано на описание существующих и будущих систем, второе – на процесс их построения.

Галактионов В. И. ^[9] предлагает рассматривать архитектуру предприятия в двух аспектах:

• статическом – в некоторый фиксированный момент времени;

• динамическом – как процесс перехода (миграции) от текущего состояния к некоторому желаемому состоянию в будущем.

Рассматриваемая в статике архитектура предприятия состоит из следующих элементов:

• миссия и стратегия, стратегические цели и задачи;

• бизнес-архитектура;

• системная архитектура.

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

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

Проектирование системной архитектуры предполагает разделение системы на наиболее крупные составные части и принятие конструктивных решений, которые после их принятия с трудом поддаются изменению. Если впоследствии оказывается, что нечто изменить легче, чем казалось вначале, это "нечто" легко исключается из "архитектурной" категории.

Статический срез системной архитектуры на определенный момент времени включает:

• архитектуру приложений – функциональный и компонентный состав информационной системы;

• архитектуру данных – способы взаимодействия систем и хранения данных;

• архитектуру оборудования – используемые технические средства/решения.

Другими аспектами системной архитектуры являются:

• способы и планы миграции от текущего состояния архитектуры к целевому;

• способы передачи реализаций между средами;

• стоимость решения, включая капитальные и операционные расходы.

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

Данилин А. В. и Слюсаренко А. И. проводят анализ определений архитектуры и предлагают в зависимости от контекста определять архитектуру системы как [7]:

1) многоаспектное описание или план задуманной или развиваемой системы на уровне ее компонентов, детализированное в достаточной мере для руководства ее воплощением, а также принципы и руководящие материалы, определяющие руководство конструированием и развитием системы во времени;

2) структура существующей системы как совокупность се компонентов и их взаимосвязей.

В варианте второго пункта этого определения архитектура у предприятий была всегда.

Опираясь на методологию Gartner, в соответствии с которой подход к формулировке архитектуры должен основываться на анализе бизнес-процессов и поддерживающих их приложений, авторы [7] делают вывод о том, что "архитектура предприятия является одним из инструментов организационных изменений всего предприятия в целом с использованием ИТ, и особенно той части организации, которая отвечает за информационные технологии", и что "представление об архитектуре предприятия имеет свои корни в дисциплине, которая получила название “системное мышление”".

И дают более подробное разъяснение этой идеи следующим образом.

"Отличительной характеристикой решений, принимаемых в отношении архитектуры, является то, что эти решения должны приниматься с учетом широкой, или системной, перспективы. Любое решение, которое может быть принято локально (например, в рамках подсистемы), не является архитектурным для системы в целом. Это позволяет делать различие между детальным проектированием и принятием решений по поводу практической реализации системы, с одной стороны, и архитектурными решениями – с другой. Первые решения имеют локальное влияние, а вторые – систематическое. Поэтому для проектных решений нужна соответствующая более широкая перспектива, позволяющая учесть системное влияние решений более высокого уровня, что дает возможность достичь желаемого уровня компромиссов и соглашений между составными частями для обеспечения должного уровня качества системы в целом".

При этом в [7] отмечается, что организации испытывают постоянные трудности в синхронизации целей и задач бизнеса и процессов развития своих информационных систем. Существует как бы "облако неопределенности" между определением организацией и обеспечивающей ее ИТ-инфраструктурой своих целей и задач.

Архитектура информационных технологий и архитектура предприятия в целом по мнению авторов [7] является основным механизмом интерпретации и реализации целей организации. Это достигается через создание определенного количества взаимосвязанных архитектурных представлений, которые с использованием различных методик описания архитектуры разбивают архитектуру предприятия на различное количество моделей и определений, относящихся к таким областям, как бизнес, информация, прикладные системы, технологическая инфраструктура.

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

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

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

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

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

Иерархическое построение архитектуры позволяет облегчить ее восприятие человеком.

В определениях можно выделить, по крайней мере, три различных аспекта:

• иерархия архитектур различных организационных систем;

• соотношения между объективной реальностью и субъективным восприятием;

• соотношения между общесистемной архитектурой и частными архитектурами.

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

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

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

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

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

Следующей ступенью явилось понятие корпоративной информационно-технологической архитектуры масштаба предприятия (EWITA – Enterprise-wide information technology architecture). Это означало, что усилия но описанию архитектуры предприятия должны включать в себя описание архитектуры информации и архитектуры прикладных систем, а не только технологический уровень. Основное направление работ при этом состояло в совместном использовании общих данных, исключении дублирования бизнес-функций, координации управления пользователями, ресурсами, информационной безопасностью за счет улучшений в управлении портфелем прикладных систем. Корпоративная информационно-технологическая архитектура масштаба предприятия описывает то, как компоненты информационной системы связаны между собой; точно так же бизнес-архитектура описывает то, как связаны между собой элементы бизнеса.

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

Важным логическим шагом для эффективного описания существующих на предприятии процессов и планируемых изменений явилось введение понятия архитектуры предприятия (Enterprise Architecture), которая объединяет корпоративную ИТ-архитектуру масштаба предприятия с бизнес-архитектурой и позволяет обеспечить достижение его стратегических целей.

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

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

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

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

При этом понятия структуры и архитектуры используются неоднозначно:

• либо понятие "структура" характеризует строение, расположение, порядок, т.е. конфигурацию ИС – "структура архитектуры" у Захмана;

• либо существует точка зрения ^[10], в соответствии с которой под архитектурой понимается описание системы с точки зрения конечных пользователей и интерфейсов

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