Применение архитектурных подходов в сфере информационных технологий

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

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

Хотя концепция SOA была сформулирована специалистами в области ИТ, но в действительности это был прямой ответ на потребности сегодняшнего дня, когда становится уже не совсем понятно, где заканчиваются бизнес-функции организации и начинаются информационные технологии, их обеспечивающие, и наоборот. Ведущие поставщики информационных технологий, такие как Microsoft и IВМ, развивают эту концепцию в рекомендациях по проектированию информационных систем на своих программных платформах. А такие компании, как Gartner, считают, что сервис-ориентированная архитектура будет ведущим принципом проектирования новых критически важных прикладных систем и бизнес-процессов в ближайшем будущем.

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

Резюмируя все вышесказанное можно сказать, что под сервис-ориентированной архитектурой следует понимать подход к проектированию прикладных информационных систем, который руководствуется следующими принципами [(Introduction to Service-Oriented Architecture, 2003)]:

· явное отделение бизнес-логики прикладной системы от логики презентации информации;

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

· при этом «потребитель услуги», который может быть прикладной системой или другим сервисом, имеет возможность вызвать сервис через интерфейсы, используя соответствующие коммуникационные механизмы;

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

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

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

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

Ориентация на сервисную архитектуру позволяет построить комплексную ссылочную модель архитектуры предприятия, которая в единой манере описывает как бизнес, так и ИТ. Эта модель состоит из следующих основных компонент (рис 1.1):

• презентационный уровень описывает интерфейсные сервисы для взаимодействия пользователей с ИС, включая корпоративные и публичные порталы, доступ с мобильных устройств, а также различные преобразования информации при взаимодействии с внешними системами и устройствами;
• на уровне бизнес-сервисов формируются модели и осуществляется управление выполнением бизнес-процессов предприятия с использованием специализированных средств, а также координация автоматизированных и "ручных" операций;
• интеграционные сервисы обеспечивают взаимодействие между приложениями, которое может быть реализовано, в частности, с использованием средств обмена сообщениями или в рамках единой среды исполнения, такой как сервер приложений J2EE;

· сервисы уровня данных реализуют средства извлечения и повторного использования данных из СУБД и приложений. Явное выделение такого уровня позволяет изолировать вышестоящие компоненты архитектуры от изменений в технологиях, а также обеспечить единый унифицированный подход к выполнению операций с данными;

· уровень инфраструктуры, приложений и СУБД является основой для всей структуры, и именно здесь концентрируются основные инвестиции в ИТ.

Рис. 1.1. Сервис-ориентированная архитектура (SOA)

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

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

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

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

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

Объектом изучения в рамках настоящей дисциплины является отдельная организация, и особый интерес будет представлять трактовка самого понятия «архитектуры предприятия». С одной стороны, представление о нем имеет свои корни в дисциплине, которая получила название «системное мышление». Ос-новным объектом изучения этой дисциплины является система, когда «целое со-ставляет нечто большее, чем механическая сумма составляющих, т.е. cucme-ма обладает свойствами, которые omcymcmвyem у составляющих ее злемен-тов» [(Rechtin, 1991)]. Эберхард Речтин (Eberhardt Rechtin), автор этого высказывания, является одним из основателей этого направления мышления.

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

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

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

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

Архитектура предприятия частично затрагивает и процессы управления ИТ в организации. В процессе проведения аудита информационных технологий, построение EA может дополнить достаточно эффективные методики организации и реорганизации процессов внутри ИТ-службы, такие как ITIL, COBIT и другие.

1.2. Архитектура предприятия: основные определения

Многие организации испытывают постоянные труд-ности и находятся в постоянном поиске синхронизации целей и задач бизнеса и процессов развития своих информационных систем. По мнению аналитической компании Butler Group, которая специализируется на исследованиях в сфере ИТ (см. www.butlergroup.com): можно даже говорить о так называемом «облаке неопределенности» между определенными организацией целями и обеспечивающей их ИТ-инфраструктурой (рис. 1.2).

Рис. 1.2. Облако неопределенности ИТ-инфраструктуры и целей организации

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

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

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

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

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

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

Широко распространенный термин, связанный с применением архитектурных методик именно в сфере информационных технологий, «ИТ-архитектура» имеет такое большое количество трактовок и может означать множество близких по смыслу, но, тем не менее, различающихся понятий. Для различных людей смысл – этого термина может быть разным. С одной стороны, можно достаточ-но быстро сформулировать интуитивное определение, которое после анализа ока-жется вполне применимым. С другой стороны, при формальном подходе известных определений архитектуры су-ществует несколько сотен. Для этого достаточно зайти на сайт Института Проекти-рования Программного Обеспечения Карнеги-Меллона (SEI - Carnegie Mellon Software Епgineering Institute) http://www.sei.cmu.edu/architecture/ и просмотреть представленные там трактовки. Из самых простых (словарь Уэбстера) заключается в том, что ИТ-архитектура - это «способ, который используется для организации и uнmeгpaцuu компонент ком-пьютерной системы».

Более полное и объемное определение [(Monin)] заключается в том, что «Архитектура системы состоит из нескольких компонент, внешних свойств и интерфейсов, связей и накладываемых ограни-чений, а также архитектуры этих внутренних компонент». Такая широкая трактовка удобна тем, что является достаточно общей, применимой практически к любой системе, а не обязательно только к системе, использующей ин-формационные технологии, и при этом позволяет ограничить степень детализа-ции на нужном уровне. Упоминание внутренних компонент специ-ально перенесено в конец определения - для отражения того факта, что «хоро-шая», четко построенная архитектура позволяет обеспечить повторное использование или модер-низацию/замену таких внутренних компонент без изменения внешней охваты-вающей системы. Итеративное, иерархическое построение архитектуры позво-ляет решить и еще одну важную задачу - облегчить ее восприятие человеком.

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

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

Прежде чем привести полное определение Архитектуры ИТ, обратим внимание на еще одну немаловажную деталь. В соответствии с тезисом, сформули-рованным Giga Group [(The Pillars of Enterprise Architecture Terminology, 2002)] «в индустрии ИТ нет одного, единственно правиль-ного стандарта на определение Архитектуры ИТ, поэтому общие соглашения внутри организации важнее теоретической точности». Итак, важна не столь-ко академическая точность определения того, что такое Архитектура ИТ, сколь-ко то, насколько на практике в реальности будут воплощены архитектурные принципы. Организация может и сама сформулировать и принять для себя определение данного понятия, лишь бы оно было полным, целостным и понятным всем участникам проекта по разработке архитектуры.

Проанализировав большое количество -рекомендаций, материалов аналитических компаний, таких как Gartner и Giga Group, теоретических и практических наработок в области архитектурных подходов в сфере ИТ можно сделать следующий вывод: -их трактовки -имеют больше общего, чем отличий, и значит есть возможность сформулировать некоторый общий подход.

В самом общем виде, в соответствии с определениями Gartner [(Defining Architecture for IT: А Framework of Frameworks, 2002)], архитектура это общий план или концепция, используемая для создания системы, такой как здание или информационная система, или «абстрактное описание cucme-мы, ее структуры, компонентов и их взаимосвязей»; «семейство руководящих принципов, концепций, правил, шаблонов, интерфейсов и стандартов, используемых при построении совокупности информационных технологий предприятия».

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

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

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

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

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

Согласно ISO 15704 («Industrial Automation Systems - Requirements for Enterprise-Reference Architectures and Methodologies. 1999») архитектура предприятия должна включать роль людей, описание процессов (функции и поведение) и представление всех вспомогательных технологий на протяжении всего жизненного цикла предприятия. В соответствии с документом «Federal Enterprise Architecture Framework. Dev. by: The Chief Information Officers Council (USA)» архитектура является стратегической информационной основой, которая определяет:

· структуру бизнеса;

· информацию, необходимую для ведения бизнеса;

· технологии, применяемые для поддержания бизнес-операций;

· процессы преобразования, развития и перехода, необходимые для реализации новых технологий в ответ на изменение/появление новых бизнес-потребностей.

Надо отметить, что кроме вышеперечисленных общих трактовок данного понятия, в данной области существуют и разработки крупных компаний. Например, в исследовании Технологической академии IBM архитектура EA определяется следующим образом: «Дисциплина EA определяет и обслуживает архитектурные модели, механизм управление и инициативы по переходу, необходимые для эффективной координации частично автономных групп для решения бизнес-задач- и/или ИТ-задач (М. Ибрагим, 2008)».

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

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

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

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

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

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

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

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

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

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

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

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

· собственно архитектура информационной системы- как объективная ре-альность, включающая существующие компоненты и их связи;

· описание архитектуры (architecture description)- отражение объективной или планируемой реальности в какой-либо документированной форме.

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

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

В дальнейшем термин «архитектура» будет использоваться в зависимости от контекста, обозначая как существующую реальность, так и соответствующее ей описание.

Еще одна формальное определение приведено в стандарте IEEE 1471 Инсти-тута инженеров-электриков и электронщиков, который предоставляет метамодель для определения архитектуры. Этот стандарт определяет такие абстрактные эле-менты архитектуры, как представления, системы, среды, обоснования, заинтересо-ванные стороны и т.д. В соответствии с этим представлением система обладает некоторой архи-тектурой, которая мажет быть определенным образом описана с различных то-чек зрения в зависимости от интереса тех людей (участников), которые рассма-тривают архитектуру системы. Каждой точке зрения на архитектуру системы со-ответствует определенное представление, основу которого составляет некото-рый набор моделей. Все вышеперечисленные элементы увязаны между собой в соответствии со схемой (рис. 1.3).

Рис. 1.3. Рамочная модель архитектуры по IEEE 1471

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

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

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

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

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

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

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

В частности, хорошее введение в предмет программной архитектуры и в специфику профессии программного архитектора представляет собой работа [(Monin, 2007)]. Другим интересным примером анализа различных аспектов деятельности Программного архитектора являются публикации Д. Бредемейера (http://www.bredemeyer.com/).