Самое простое из множества определений термина «архитектура предприятия» (Ап) можно получить, применяя термин «архитектура» к системе «предприятие»: «Архитектура предприятия — это способ понимания всех различных элементов, из которых состоит предприятие, и того, как эти элементы взаимосвязаны. Элементы включают в себя людей, процессы, бизнес и технологии» (The Open Group, www.opengroup.org/architecture). Существуют однако более развернутые определения, в которых содержится анализ АП, в частности, согласно FEAPMO (Federal Enterprise Architecture Program Management-Office-(US-government): «Архитектура предприятия — это стратегическая информационная основа, определяющая: структуру бизнеса (основной деятельности); информацию, которая необходима для ведения этого бизнеса; технологии, которые необходимы, чтобы поддерживать процессы этого бизнеса; переходные процессы, необходимые для реализации новых технологий в ответ на появление новых, изменяющихся бизнес-потребностей».

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

Наиболее часто АП представляют в виде «слоеного пирога», при этом кулинарные рецепты отличаются незначительно. Так, обычно верхний слой отводят бизнес-процессам, а ниже располагают сервисы, данные / информаци.ю, прикладные системы, инфраструктуру и связь (например, www.opengroup.org/architecture/togaf8-doc/arch). Иногда выделяют три слоя: миссия и стратегия организации, бизнес-архитектура (которая в свою очередь разделяется на бизнес-процессы, ресурсы и корпоративные стандарты) и ИТ–архитектура (которая строится из программных систем, данных и инфраструктуры) (например, Г. Калянов, www.enterprise.com.ua). В американской федеральной модели FEA (www.whitehouse.gov/omb/egov/a-2-EAModelsNEW2.html) выделяются пять моделей-уровней: справочная модель оценки результативности (Performance Reference Model, PRM), справочная модель бизнеса (Business Reference Model, BRM), справочная модель сервисных компонентов (Service Component Reference Model, SRM), справочная модель данных (Data Reference Model, DRM), техническая справочная модель (Technical Reference Model, TRM).

Однако довольно быстро стало понятно, что связь между слоями вовсе не иерархическая и картина должна быть более сложной. Так появились: матрица Захмана, пирамида CIO Council, параллелограмм GERAM (Generalized Enterprise Reference Architecture and Methodology) и девятицветник TOGAF (The Open Group Architecture Framework). Многие из этих моделей «выросли» из слоеных пирогов в попытке добиться большей полноты модели и ее соответствия оригиналу. За каждой из них стоит своя логическая структура для классификации и организации комплексной информации, предназначенная для описания архитектуры.

Наибольшей популярностью сегодня пользуется матрица Захмана, которая предлагает с одной стороны (по горизонтали) вспомнить детский стишок: «Есть у меня шестерка слуг, проворных, удалых … Они по знаку моему являются в нужде. Зовут их: Как и Почему, Кто, Что, Когда и Где», а с другой — посмотреть на АП с точки зрения самых разных потребителей: от владельца бизнеса до системного администратора и пользователя ИТ. Сейчас все чаще встречается гибрид традиционного «слоеного» представления архитектуры и модели Захмана.

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

 

Все предприятия, к несчастью,

Довольно сложные создания.

Мы разделяем их на части

Для упрощения описания.

Марина Аншина (anshina@sibur-rt.ru) — начальник управления ИТ ОАО «СИБУР — Русские шины», президент фонда ФОСТАС, автор книги «Технология создания распределенных систем» и статей по тематикам стратегии и архитектуры ИТ, оценки эффективности и рисков проектов ИТ, технологии CORBA и компонентного программного обеспечения.