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

На этом уровне даются ответы на следующие вопросы:

•Какие приложения необходимы для поддержки бизнес-процессов?

•Кто является основными пользователями и заинтересованными сторонами в реализации данных прикладных систем?

•Как выглядят нормализованные модели данных для этих приложений?

•Какие прикладные системы нужны для управления данными: создания, чтения, внесения изменений и удаления данных?

•Какие нужны технологии для реализации этих прикладных систем?

•Как будет выглядеть распределенная архитектура прикладных систем?

•Какие стандарты должны быть приняты организацией?

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

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

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

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

Ключевыми вопросами, которые должны быть решены на данном уровне абстракции, являются следующие:

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

•Как логические компоненты будут распределены между различными системами (будут ли эти компоненты реализованы в виде web-сервисов)?

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

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

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

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

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

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

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

Если мы говорим о физическом уровне (архитектуре) прикладной системы, то каждый

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

Примеры вопросов, на которые отвечают на данном уровне абстракции, следующие:

•Каковы функциональные спецификации каждой прикладной системы?

•Будет ли организация разрабатывать специализированные приложения или покупать стандартные?

•Каковы критерии выбора и как будут оцениваться различные инициативы по реализации систем?

•Как данные будут представлены на физическом уровне?

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

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

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

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

На уровнях физической архитектуры и уровне реализации для ускорения цикла разработки, повышения качества разрабатываемых систем (за счет использования проверенных решений) и уменьшения рисков проекта могут использоваться такие концепции и архитектурные модели, как, например, Microsoft Systems Architecture (MSA).

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

Архитектура и управление ИТ-портфелем

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

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

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

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

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

Всвязи с этим описание желаемого состояния архитектуры ИТ обеспечивает представление

онеобходимых инвестициях в технологии и навыки ИТ-персонала.

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

•стратегия и планирование на уровне предприятия.

•архитектура предприятия.

•управление ИТ-программами и проектами.

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

Процессы выработки стратегии и планирование обеспечивают основу для отбора, управления и оценки ИТ-ресурсов и проектов.

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

программами и проектами с управлением ИТ-активами и проектами – еще более существенное.

Рис. 4.6. Интеграция ключевых процессов управления информационными технологиями предприятия

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

Рис. 4.7. Архитектура, ИТ-активы и ИТ-проекты

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

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

Общие элементы определений "Архитектуры предприятия" и основные заблуждения

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

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

На одну и ту же архитектуру существуют различные взгляды (или представления).

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

Итак, перечислим общие элементы определений, связанных с архитектурой:

•архитектура определяет основные компоненты (бизнес-архитектура, архитектура приложений и т.д.);

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

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

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

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

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

•определения архитектуры не содержат описания самих компонент.

В связи с этим хотелось бы также отметить ряд достаточно распространенных неверных представлений об архитектуре. Из них назовем следующие:

•архитектура и проектировочные решения (дизайн систем) – это одно и то же;

•архитектура и инфраструктура – это одно и то же;

•архитектура – это только структура;

•архитектура – это "плоское" понятие, и одного представления схемы описания архитектуры будет достаточно;

•архитектуру нельзя оценить;

•архитектура – это искусство или наука.

Обсудим эти заблуждения чуть более подробно, следуя идеям Буча (Grady Booch), одного из создателей языка UML.

Архитектура включает анализ рисков и обоснования, объяснения причин. Сами архитектурные, проектировочные решения являются одним из проявлений архитектуры.

Архитектура является частью проектировочного решения, но это проектировочное

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

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

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

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

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

Еще одно из заблуждений состоит в том, что архитектуру, степень ее проработанности или зрелости нельзя оценить или измерить. Описаний самого процесса разработки архитектуры, рекомендаций по реализации этого процесса в реальности не так уж и много. Но интересный аспект заключается в том, что как только у вас есть или сформировалась некоторая архитектура, она может быть достаточно объективно оценена в соответствии с принципом: "Я не знаю точно, что я хочу, но я буду знать, как только я это увижу".

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

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

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

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