Что такое архитектура? Каждый интуитивно понимает, что это такое, но для темы нашего номера этого мало. Как правило, понятие архитектуры связывается с проектированием и строительством зданий. При этом основная задача архитектора — определение взаимосвязей между различными функциями, которые выполняет здание, такими как технические, эстетические и утилитарно-функциональные, одновременно на нескольких уровнях проектирования. Здесь важно отметить две вещи. Во-первых — наличие нескольких различных взглядов на одно здание (технический взгляд не есть эстетический, более того, как правило, один противоречит другому). И во-вторых — признание необходимости внутренней структуры каждой из функций.

Постепенно понятие архитектуры обобщалось. Так, в одном из отчетов (еще за 1998 год) исследовательской лаборатории IBM я наткнулся на следующее определение: «Архитектура — это унифицированная или логически связанная форма структур». Еще одно похожее определение: «Архитектура — это способ структурирования представлений». Другими словами, архитектура — это способ представления различных структур, то есть метаязык описания структур. Такое понимание архитектуры как способа представления логики и взаимосвязей внутри структур конкретного предмета и закрепилось сейчас.

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

Кристаллизация понятия «архитектура предприятия» послужила толчком для теоретических исследований. Очень интересны рассуждения некоторых аналитиков об архитектурном стиле, о том, как проектировать архитектуру. Ведь действительно, архитектура, скажем, сервисно-ориентированного предприятия должна отличаться от архитектуры производственного. Кроме того, активно обсуждается, в какой степени архитектура предприятия должна ориентироваться на ключевые бизнес-процессы, которые определяют суть жизнедеятельности компании. Понятно, что это необходимо, но не приведет ли к абсолютной невозможности обобщения архитектур предприятий?

Из всего спектра идей отметим здесь одну интересную идею, которая придает архитектуре прикладное значение. В одной из моделей архитектур вводится понятие continuum (континуум). Под «континуумом» понимается некая философия построения архитектуры через повторное использование различных блоков. Причем выделяются два уровня — архитектурный континуум, или архитектурная непрерывность, и континуум решений. Архитектура требует выделения архитектурных блоков как на уровне предприятия, так и на уровне решений. Главная идея — повторное использование этих блоков по определенным правилам и с определенными взаимодейст­виями между ними.

Несмотря на то, что архитектура предприятия — понятие далеко не новое (оно появилось где-то в начале 90-х годов), серьезных находок в этом направлении не так много. Сегодня существует несколько проработанных архитектур предприятий, с которыми стоит познакомиться. Наиболее популярная — архитектура Захмана.

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

С целью систематизировать подходы к созданию корпоративных информационных систем Захман предложил подход к моделированию архитектуры, таблицу, получившую название Zachman Framework. (Впервые таблица была предложена в 1987 году, во второй же своей редакции она появилась в 1992 году, более подробно о ней читайте в статье Евгения Зиндера, стр. 46.) Причем, представляя свои идеи, Захман делал акцент на интеграции. Есть одно примечательное высказывание Захмана: интеграция не должна быть случайной. Она действительно должна быть прогнозируемой, прозрачной. И цель архитектуры Захмана — показать эту интеграцию, когда данные и системы интегрируются с целями и задачами на различных уровнях рассмотрения и анализа. В этом — суть понятия архитектуры. Ее основная задача — именно структуризация и понимание взаимодействия и взаимовлияния различных сущностей, участвующих в образовании системы, как информационной, так и предприятия в целом.

Наконец, важно отметить один примечательный факт. Несмотря на различия в понятиях «архитектура предприятия» и «архитектура ИТ» все существенные достижения в области архитектуры предприятия так или иначе ориентированы в сторону ИТ. Они все очень близки к ИТ-сфере. Создается впечатление, что их создатели старались думать об архитектуре абстрактно, но у них получалось мыслить только ИТ-категориями. Почему получилось именно так? Возможно, дело в том, что те самые взаимоотношения и взаимосвязи, о которых говорилось в определении, могут быть хорошо смоделированы именно в ИТ-среде. А возможно, причина лежит еще глубже: не только и не столько взаимосвязи, но и сами структурные элементы бизнеса или сущности бизнеса в формализованном и унифицированном виде (это требуется для существования архитектуры) могут быть выделены только в ИТ-среде. Существуют они, конечно, и без ИТ, но вот описать их на основе единой метаструктуры — не получается. Мне думается, что более верно именно это, последнее, объяснение. И это выводит значение архитектуры ИТ на совершенно другой уровень. Таким образом, значение правильно построенной архитектуры ИТ выходит за рамки собственно информационной системы предприятия.