Эта область архитектуры предприятия рассматривает "традиционные" аспекты построения информационных систем, которые необходимы для поддержки прикладных систем и информационных ресурсов организации. Для технологической архитектуры иногда используются такие термины, как "платформы", "инфраструктура", "системная архитектура" или просто "ИТ-архитектура".
Технологическая архитектура является как бы фундаментом, основой всего портфеля информационных технологий предприятия. Вторую существенную часть этого портфеля составляют прикладные системы, обеспечивающие выполнение бизнес-процессов (мы обсуждали это в предыдущем разделе, посвященном архитектуре приложений).
Основное назначение технологической архитектуры – это обеспечение надежных ИТ-сервисов, предоставляемых в рамках всего предприятия в целом и координируемых централизованно, как правило, департаментами информационных технологий. Технологическая архитектура определяет набор принципов и стандартов (индустриальных стандартов; стандартов, связанных с продуктами; конфигураций), которые обеспечивают руководства в отношении выбора и использования таких технологий как аппаратные платформы, операционные системы, системы управления базами данных, средства разработки, языки программирования, ПО промежуточного слоя, сервисы электронной почты, каталоги, системы безопасности, сетевая инфраструктура и т.д. Мы уже отмечали раньше, что отдельные аспекты (безопасность, интеграция, иногда разработка) могут быть выделены в отдельные области (домены) архитектуры предприятия в зависимости от особенностей организации.
Инфраструктурные сервисы, в основном, стандартизированы в рамках предприятия и используются сразу несколькими прикладными системами, расположенными над уровнем инфраструктурных сервисов и непосредственно обеспечивающих выполнение бизнес-процессов. При наличии необходимой инфраструктуры новые прикладные системы, которые потребуются предприятию для выполнения новых бизнес-процессов или реализации новых стратегий, могут быть созданы достаточно быстро и эффективно. Это является предпосылкой для повышения того, что называется динамичностью и гибкостью предприятия. Одной из частных задач, решаемых в рамках технологической архитектуры, является формирование "списка закупаемых технологий".
По самой своей природе, инвестиции в инфраструктуру ИТ являются крупными и долговременными, при этом они не имеют определенной ценности для бизнеса с точки зрения получения конечных результатов. Но ценность инфраструктуры заключается в ее способности быстро и экономически эффективно обеспечить реализацию новых прикладных систем в интересах различных подразделений предприятия, которые и приносят бизнес-пользу. В конечном итоге, именно инфраструктура определяет тот спектр прикладных систем, которые могут быть развернуты на предприятии для обеспечения его бизнес-процессов.
Проблема построения технологической инфраструктуры и инвестиций в инфраструктуру аналогична построению общественной инфраструктуры: дорог, мостов, больниц и школ. Оба типа обеспечиваются централизованно и финансируются, в конечном итоге, за счет косвенных отчислений средств конечных потребителей (налоги и пр.). Для обеспечения совместимости необходимо следовать определенным стандартам (например, правила размещения зданий вдоль улиц или правила использования прикладными системами инфраструктурных технологий). Одна из самых главных трудностей состоит в том, что размеры и масштабы использования инфраструктуры должны быть оценены еще до того как с большой определенностью станут известны все потребности со стороны бизнеса.
Развитие практически всех компонент инфраструктуры (будь то серверы, средства хранения данных или системы передачи данных) за прошедшие полвека сопровождалось фантастическими успехами в плане увеличения мощности, производительности, миниатюризации, надежности и других параметров. Существует большое количество технологических стандартов, как де-факто, так и де-юре, которые в той или иной комбинации выбираются для включения в архитектуру организации. В целом, проектирование данной компоненты архитектуры является, пожалуй, самой традиционной и достаточно хорошо проработанной практикой – как у системных интеграторов, так и в большинстве крупных организаций, поэтому мы не будем рассматривать особенности тех или иных компонент (да это и невозможно в рамках одного курса), а ограничимся упоминанием нескольких важных подходов.
Существует два принципиально отличных подхода формирования технологической архитектуры. Первый условно можно назвать "открытым". Он заключается в перечислении используемых на предприятии стандартов (индустриальных и пр.) и теоретически позволяет уменьшить зависимость предприятия от конкретных поставщиков. Однако уменьшение этой зависимости имеет ограниченный успех, поскольку замена одного продукта другим, поддерживающим один и тот же набор стандартов, как правило, оказывается невозможным или затруднительным. Поэтому с середины 1990-х годов большинство предприятий стали использовать второй подход, который связан, в конечном итоге, с перечислением конкретных продуктов и технологий.
Реальные преимущества от наличия упорядоченного в рамках технологической архитектуры списка используемых технологий таковы:
В то же время разнообразие технологий на предприятии – это неизбежная ситуация в силу многих причин, начиная с технологических и заканчивая организационными и политическими. Не останавливаясь на этом подробно, отметим, что обсуждавшаяся нами выше концепция
Рисунок 7.1 иллюстрирует то, что технологическая инфраструктура предприятия располагается на нескольких "уровнях" и принятие решения о размещении той или иной части инфраструктуры в масштабе предприятия или отдельных бизнес-подразделений является стратегическим решением, которое должно основываться на принятых в организации принципах построения архитектуры. Аналогично, если речь идет об инфраструктуре "
(рис 7.1) Различные уровни размещения инфраструктурыНа данном рисунке условно изображено предприятие с несколькими бизнес-подразделениями и разнообразным портфелем технологий: некоторые из этих технологий координируются и эксплуатируются централизованно, другие – на уровне отдельных подразделений. ИТ-сервисы, которые требуются для предприятия в целом, обеспечиваются комбинацией общекорпоративной и публичной инфраструктуры. Инфраструктура уровня подразделения ориентирована на более специфические потребности соответствующих подразделений.
Например, в крупной компании обработка больших массивов производственных данных может производиться в едином корпоративном центре обработки данных. Все подразделения используют эту централизованную инфраструктуру, но имеют некоторые дополнительные локальные потребности, которые обеспечиваются локальной инфраструктурой. Одно из бизнес-подразделений, крупнейшее на предприятии, может и не иметь своей собственной локальной инфраструктуры, а использовать исключительно централизованные сервисы.
Существуют различные способы категоризации технологий и сервисов, которые относятся к технологической архитектуре. Например, META Group выделяет два различных типа областей (доменов) технологической архитектуры (более подробно см. лекции 8): базовые (технологии, которые используются практически каждой информационной системой) и прикладные (более специфические с точки зрения использования бизнесом).
Примерами базовых доменов технологической архитектуры являются сети, аппаратное обеспечение, операционные системы, системы хранения,
Примерами прикладных доменов технологической архитектуры являются системы коллективной работы, электронной почты и управления потоками работ (workflow), Интранет, Интернет-приложения, системы электронной коммерции,
Gartner называет в технологической архитектуре шесть архитектурных компонент (сервисов), в каждом из которых выделяется определенное количество технологических "строительных блоков" (bricks) [4.24]:
На самом деле, возможных способов классификации элементов, составляющих основу технологической архитектуры, может быть множество. В качестве еще одного примера можно привести техническую справочную модель (
Эта справочная модель содержит четыре области технологических сервисов: доступ и доставка; платформы и инфраструктура; компонентная модель; сервис интерфейсов и интеграции. Каждая область технологических сервисов делится на категории, категории содержат стандарты, а стандарты содержат спецификации.
На рисунке 7.2 приведен пример областей, категорий, стандартов и спецификаций
(рис 7.2) Пример областей, категорий, стандартов и спецификаций технической справочной модели TRM FEAFОтдельный интерес представляют взаимосвязи между функциональными и операционными требованиями к системам и различными областями архитектуры, такими как прикладные системы и технологическая архитектура [4.25].
Функциональные требования к прикладной системе описывают ту ценность, которую представляет система с точки зрения реализации функций организации (бизнес-ценность). Архитектура приложений, по сути дела, является архитектурой всех автоматизированных сервисов, которые обеспечивают и реализуют такие функциональные требования, включая интерфейсы к бизнес-приложениям и другим прикладным системам. Она описывает структуру приложений и то, как эта структура реализует функциональные требования организации.
Операционные (или эксплуатационные) требования к программной системе специфицируют такие аспекты, как надежность, управляемость, производительность, безопасность, совместимость. И это далеко не полный список. Примерами операционных требований являются возможность доступа к системе только авторизованных пользователей, уровень доступности прикладной системы 99,99% времени и т.д.
Технологическая архитектура является архитектурой инфраструктуры аппаратного и программного обеспечения, которая обеспечивает работу прикладных систем и выполнение операционных (нефункциональных) требований, предъявляемых к архитектуре прикладных систем и информации. Она описывает структуру и взаимосвязи между используемыми технологиями и то, как эти технологии обеспечивают выполнение операционных требований организации.
(рис 7.3) Взаимосвязи функциональных и операционных требований с архитектурой приложений и технологической архитектуройПоэтому ассоциации, о которых мы должны всегда помнить, следующие: "Функциональные требования обеспечиваются архитектурой приложений,
Хотя, конечно, следует сделать одно замечание. Хорошая технологическая архитектура может обеспечивать безопасность, доступность, надежность и целый список других операционных требований, но если приложение спроектировано так, что оно не использует преимуществ технологической архитектуры, оно все равно будет функционировать плохо, и его будет сложно внедрять и сопровождать. Аналогичным образом, хорошо спроектированная структура прикладной системы, которая точно соответствует требованиям бизнес-процессов и собрана из многократно используемых компонент с применением современнейших технологий, может не соответствовать реальной конфигурации используемого аппаратного и системного программного обеспечения. Например, имеющиеся серверы могут не поддерживать работу компонент системы, конфигурация и топология сети – не обеспечивать потребности в потоках информации. Это показывает, что все-таки есть существенная взаимосвязь между архитектурой приложений и технологической архитектурой: хорошая технологическая архитектура должна быть построена с учетом поддержки прикладных систем, играющих важную роль в работе организации. Хорошая архитектура приложений должна эффективно использовать технологическую архитектуру, чтобы обеспечить должный уровень соответствия всем операционным требованиям.
Для оценки состояния технологической инфраструктуры предприятия в терминах, понятных бизнес-руководству, и с точки зрения потенциальных возможностей реализации различных бизнес-стратегий, можно использовать подход, предложенный Питером Кином (Peter Keen) [4.26]. Он основан на использовании двух критериев:
На рисунке 7.4 приведен вариант матрицы, которая использует эти два критерия. Чем шире функциональные возможности и охват инфраструктуры, тем более сложные, одновременно совершаемые в разных системах транзакции, может выполнять организация в различных местах расположения бизнеса. Например, точка "A" на рисунке означает возможность обеспечить, например, прием заказа и его обработку, включая информацию о складе, планах производства, выставление счетов во всех соответствующих системах и подразделениях независимо от местоположения. В то же время точка "B" соответствует ограниченным функциональным возможностям и широте охвата инфраструктуры, которая обеспечивает возможности по пересылке электронных сообщений в рамках отдельных подразделений.
(рис 7.4) Охват и функциональные возможности инфраструктурыЗаметим, что количество градаций в параметре охвата можно детализировать и варьировать, добавив сюда, например, возможности по выполнению операций в рамках страны, за рубежом и т.д., в зависимости от характера деятельности предприятия.
Эту модель оценки инфраструктуры можно использовать для идентификации типичных действий, которые требуются для выполнения бизнес-процессов в рамках каждой области функциональных возможностей. Затем можно сравнить эти возможности с потребностями, которые исходят от бизнеса, включая планируемые потребности. Как правило, обнаруживается достаточно заметный разрыв между потребностями и возможностями. В результате руководство департамента ИТ может спланировать реализацию необходимых проектов для перевода текущей технологической архитектуры в желаемое состояние, оценить затраты, необходимое время и возможные трудности.
Требования к технологической инфраструктуре можно также оценивать, используя необходимость в реализации различных стилей бизнес-процессов и прикладных систем, которые мы обсуждали в лекции 6 (приложения, обслуживающие большое количество транзакций, операции в реальном времени, аналитические приложения, приложения поддержки совместной работы или утилиты).
Уделим особое внимание одному, но достаточно важному аспекту, который сейчас активно позиционируется в качестве перспективного направления развития. Речь идет о создании адаптивной технологической инфраструктуры, которая способна в определенных пределах, автоматически или полуавтоматически, "подстраиваться под требования" со стороны бизнес-приложений для обеспечения оптимальной работы.
Основными характеристиками адаптивной системы (см. также [4.27]) являются:
Другая важная проблема – необходимость повышения эффективности использования существующих вычислительных ресурсов. Действительно, типовая загрузка
Для решения этой задачи предложили свои решения практически все ведущие производители, включая HP (концепция Adaptive Enterprise, архитектура Darwin), IBM (On Demand), Sun (N1), Microsoft (Dynamic
Существует несколько концептуальных обоснований для таких решений ([4.28]-[4.30]). Одним из них является так называемая концепция "Organic IT", предложенная компанией Forrester. В соответствии с определением, "...это инфраструктура, построенная из относительно дешевых компонентов с такой избыточностью, которая обеспечивает автоматическое разделение между всеми приложениями и администрирование корпоративных информационных ресурсов, в том числе программного обеспечения, процессоров, систем хранения данных и сетей". Такая инфраструктура позволяет повысить "коэффициент полезного использования" ресурсов, упростить интеграцию различных технологических компонент между собой и облегчить управляемость системы в целом.
Аналогичная концепция под названием "Инфраструктура реального времени" (Real-Time Infrastructure,
Таким образом, основные идеи адаптивной инфраструктуры таковы:
Возможная реализация такой адаптивной инфраструктуры на практике может осуществляться так, как показано на рис. 7.5.
Приведем несколько комментариев к данному рисунку:
(рис 7.5) Инфраструктура реального времениПредполагается, что этот подход позволит, за счет эффективного усреднения потребностей приложений, обеспечить повышение загрузки ресурсов примерно вдвое. Заметим, что практическая реализация такой архитектуры потребует и соответствующего изменения модели сервисов. Для этого компанией Gartner предложена специальная концепция IT
Применение стандартов играет важную роль в архитектуре информационных систем – прежде всего потому, что стандарты обеспечивают возможность взаимодействия различных компонент между собой. Чем более сложной, распределенной и тиражируемой является система, тем эта определяющая и консолидирующая роль стандартов становится все более актуальной. Стандарты есть общепринятые документы, формализующие лучшие практики. Строго говоря, принято различать стандарты де-юре, т.е. разработанные и поддерживаемые официальными органами по стандартизации, такими как Международная организация по стандартизации – ISO, и стандарты де-факто, основанные на существующем широком распространении технологии, методологии или продукта (например, использование MS Windows в качестве операционной системы для персональных компьютеров).
С другой стороны, можно выделять два класса – "технологические" и "рамочные" стандарты. Технологические стандарты определяют особенности реализации тех или иных протоколов, интерфейсов, языков программирования и т.п. Типичным примером являются спецификации WWW консорциума W3C. В составе описания ИТ-архитектуры предприятия обычно приводятся ссылки на используемые стандарты такого типа.
Для наших задач, связанных с разработкой архитектуры предприятия, наибольший интерес будут представлять такие "рамочные" стандарты, как уже упоминавшийся ISO 15704, а также ISO 15288 и, частично, ISO 12207. Помимо указанных, при разработке архитектуры предприятия достаточно широко используется порядка 30-ти дополнительных "поддерживающих" стандартов системной и программной инженерии. Например, стандарт ISO 14258 определяет концепции и правила для моделирования Предприятия и т.п. Эти стандарты являются рамочными (Framework) в том плане, что они задают общие требования к реализации процессов, связанных с разработкой и поддержкой жизненного цикла систем. Они обычно используются как методологическая основа для организации этих процессов с необходимой конкретизацией для каждого данного предприятия или области деятельности.
Если стандарт ISO 12207 был разработан для определения жизненного цикла только программного обеспечения, то ISO/IEC 15288 определяет жизненный цикл "более общей" системы. В применении к нашему контексту такой системой может являться совокупность информационных систем предприятия в целом.
В соответствии со стандартом ISO/IEC 15288 жизненный цикл систем охватывает "дерево" процессов, показанное на рис. 7.6.
(рис 7.6) Структура активностей стандарта ISO 15288Реально для использования на практике при формировании архитектуры информационной системы в целом или проведения разработок программных комплексов на уровне отраслей и отдельных компаний формируются так называемые профили стандартов. Каждый такой профиль является специально сформированной совокупностью – выборкой из нескольких базовых стандартов и, может быть, других нормативных документов с четко зафиксированными подмножествами определений, обязательных к реализации. Помимо таких обязательных элементов, профиль может определять некоторые требования как факультативные. Профиль, однако, не может расширять состав требований так, чтобы он противоречил использованным в нем базовым (исходным) стандартам.
Как уже отмечалось, профили могут создаваться как для отдельной системы, так и для класса систем, предназначенных для использования в определенных рамках. Хорошим примером такого профиля является SAGA, описывающая требования к системам для реализации "
Использование профилей направлено прежде всего на снижение трудоемкости и стоимости разработки проектов информационных систем и повышение качества их реализации за счет использования уже апробированных решений. При этом сами профили можно условно разделить на два класса – профили, описывающие собственно программные или архитектурные решения на основе ISO 15288, и профили, регламентирующие процессы жизненного цикла программных систем, такие как разработка, тестирование, сопровождение и т.п. Обычно для этого класса за основу берется стандарт ISO 12207.
Важным преимуществом использования архитектурных профилей является ориентация на использование модели открытых систем. Основные рекомендации по разработке таких профилей окружения открытых систем приведены в документе IEEE 1003.23, доступном по адресу http://www.enterprise-architecture.info. Создаваемые профили могут быть использованы как для детализации собственно ИТ-архитектуры, так и для формализации процесса ее разработки. Обычно в состав такого профиля включаются следующие разделы:
В соответствии с принципами построения открытых систем, профили строятся с учетом разделения системы на отдельные уровни (программное обеспечение, аппаратные платформы, внешнее окружение), взаимодействие между которыми происходит по четко определенным интерфейсам. Собственно, открытая система предполагает использование открытых, т.е. опубликованных стандартных интерфейсов, процессов и форматов данных для обеспечения портируемости (переносимости) на другие аппаратные платформы и операционные системы, а также обеспечивает взаимодействие с другими приложениями – как локальными, так и удаленными.
В составе интерфейсов выделяются отдельные сервисы информационных систем (ИС-сервисы). ИС-сервисы представляют собой сервисы достаточно высокого уровня (например, управление информацией или статистический анализ данных), которые могут быть объединены в группы – системные, коммуникационные, информационные и взаимодействия с пользователями. ИС-сервисы формулируются в бизнес-терминах, например, "статистическая обработка данных". Реализация этих сервисов осуществляется на основе взаимодействия "более элементарных" ИТ-сервисов, описываемых в терминах протоколов, программных интерфейсов и компонент. Примерами таких сервисов могут являться печать или управление транзакциями.
Формирование профиля, в соответствии с данными рекомендациями, производится на основании последовательного логического процесса, включающего такие этапы, как определение бизнес-требований, формирование общего списка ИТ-сервисов, заполнение матрицы корреляции бизнес-требований и ИТ-сервисов, формирование списка ИС-сервисов и матрицы корреляции ИТ/ИС-сервисов. Для необходимых ИС-сервисов выбираются существующие де-юре или де-факто стандарты, коммерчески доступные приложения или определяются требования по заказной разработке. Данное руководство содержит
также некоторые примеры
Более подробная информация по стандартам для открытых систем приведена, например, в [4.31],[4.32]. Важно отметить, что такой подход может быть полезным даже в том случае, когда конкретная информационная система не полностью удовлетворяет принципу открытости.
Детальное обсуждение многих вопросов, связанных со стандартами, включая аспекты применения международных стандартов в России, их сравнение с существующими стандартами серий ГОСТ 34, ГОСТ Р и других, можно найти в материалах конференций по стандартам [4.33] и на сайте http://www.fostas.ru.
Мы уже отмечали выше актуальность интеграции приложений и использования общих компонент информационных систем (сервисов). Отражением этого факта является существующая тенденция выделения данных аспектов в отдельные области архитектуры предприятия. Существенную роль при реализации этих областей играют стандартизованные элементы.
Подобно тому, как проект здания может включать в себя элементы ранее созданных конструкций, так и реализация поддержки бизнес-процесса в информационной системе может использовать уже известные фрагменты программного кода и/или типовые конфигурации оборудования. Это позволяет, с одной стороны, значительно сократить сроки выполнения решения, с другой – уменьшить риски за счет использования фрагментов, проверенных на практике. Фактически речь идет о выборе и использовании подходящих шаблонов (patterns). Английский термин "pattern" имеет различные варианты перевода, в том числе "образец", "шаблон" и т.п. В данном случае мы будем использовать русский термин "шаблон", оставляя кальку "паттерн" для обозначения аналогичных объектов в области программной архитектуры. Шаблоны являются как бы проверенными способами построения какой-то части системы.
Одним из удачных определений шаблонов является следующее: "Шаблон – это общее решение некоторой повторяющейся проблемы в определенном контексте" [4.34].
(рис 7.7) Шаблон – решение проблемы в контекстеТо есть важным аспектом, связанным с шаблонами, является то, что они сопровождаются определенными обоснованиями того, почему данное решение является хорошим в условиях заданного контекста. Шаблоны являются следующим шагом в понимании и применении моделей. Шаблон показывает, что делает некоторую модель хорошим решением и как создать некоторое решение для определенной проблемы.
Осознание важности шаблонов привело к тому, что, например, методика описания архитектуры Gartner выделяет шаблоны в качестве отдельного "слоя" архитектуры.
Использование шаблонов имеет явные корни в строительной архитектуре. Определяющий вклад в формирование исходного понятия "pattern" принадлежит известному архитектору Кристоферу Александеру. В своей фундаментальной работе 1987 года [4.35] он выделил более 250 типовых архитектурных решений, таких как лестницы, альковы, связи между офисами и др. Согласно Александеру, каждый такой прототип фактически определяет рекомендуемое решение отдельной проблемы в фиксированном контексте. В оригинале Александер выделяет контекст, воздействующие силы и особенности применения данного шаблона. В соответствии с аллегорическим комментарием Коупа, описание шаблона – это пьеса. Контекст задает место действия и определяет актеров, силы плетут заговор, найденное решение обеспечивает Катарсис.
Исходной целью этих работ Александера была не разработка каких-то новых идей, а, напротив, анализ накопленного опыта строительства – как отдельных зданий, так и целых городов – с целью выявления удачных архитектурных решений и способствовавших этому факторов. Конечно, критерии определения удачности в данной области во многом субъективны, так как зависят от общества, использующего данные постройки. В области информационных технологий такими критериями могут быть полнота выполнения требований, долговечность, эффективность реализации, а также, в соответствии с [4.36], ориентация, прежде всего, на расширение, а не на ограничение возможностей организации. Еще одним важным понятием из строительной архитектуры, которое нашло свое отражение в сфере информационных технологий, стал язык шаблонов (
В приведенном выше определении шаблона имеется три ключевых словосочетания:
В области информационных технологий первоначально шаблоны получили признание в области программной архитектуры. В широко известной работе группы авторов [4.37] (которых в англоязычной литературе по числу авторов книги часто называют "бандой четырех") описаны типовые конструкции для объектно-ориентированных языков программирования, таких как C++. Большое количество ссылок по данной тематике и примеров приведены на http://www.patterns.com. Но оказывается, что понятие шаблона оказывается весьма эффективно и в области архитектуры предприятия в целом!
В отношении информационных технологий можно сказать, что шаблоны являются логическими моделями технологий: это проектировочные идеи, которые могут быть многократно использованы в рамках предприятия в целом [4.38]. Как правило, эти решения служат, в каком-то смысле, индустриальными стандартами и обычно существуют продолжительное время. Их можно рассматривать как некоторые схемы, которые определяют компоненты решения, т.е.
Когда мы говорим о шаблонах, то речь не идет о конкретных моделях аппаратного или программного обеспечения. Как проиллюстрировано рисунком 7.8, интерес представляет другое: как серверы взаимодействуют между собой и как они совместно обеспечивают работу с системой клиента, использующего персональный компьютер? Какие роли играет каждый компонент? Какие типы коммуникаций необходимы между ними?
(рис 7.8) Шаблон показывает взаимодействие компонент системы между собойВажность шаблонов для архитектуры предприятия в целом обусловлена следующими причинами:
Можно сказать, что архитектурные концепции (методики) и шаблоны являются двумя инструментами для успешного, быстрого, эффективного с точки зрения затрат создания моделей и реализации систем с минимальными рисками. Принято идентифицировать шаблоны, которые относятся к различным доменам архитектуры (бизнес-шаблоны, шаблоны инфраструктуры и т.д.) и различным уровням абстракции архитектуры.
(рис 7.9) Архитектура, шаблоны и модели В рамках предприятия целесообразно создать репозиторий шаблонов. Характерное для предприятия число различных шаблонов составляет порядка 30. Это включает шаблоны использования унаследованных и старых клиент/серверных систем, модели для будущей архитектуры (например, сервис-ориентированной) и т.д.
Описание шаблонов может выполняться с различной степенью детализации и соответствия реальным условиям. В зависимости от этого уровня можно рассматривать элементы языка шаблонов различной степени абстракции – идиомы, шаблоны дизайна (design patterns) и рамочные модели (frameworks). При этом идиомы представляют собой шаблоны самого "низкого уровня", которые зависят от конкретной технологии. Шаблоны дизайна обладают определенной независимостью, но в то же время не могут рассматриваться как система в целом. Хорошим примером являются шаблоны стандартных классов. Например, понятие "Фабрики Объектов" в объектно-ориентированных приложениях, вообще говоря, не зависит от выбора конкретного языка программирования и может быть реализовано схожим образом и на С++, и на Java. Наконец, рамочные модели представляют собой "частично законченные" системы, которые либо демонстрируют наиболее принципиальные элементы реализации, либо являются полностью работоспособными системами для определенных упрощенных, ограниченных или идеализированных внешних условий. Эти модели могут быть использованы как основа для специализированных доработок, а также для быстрого создания модели системы в целом на основе таких отдельных компонент.
Далее концепция шаблонов была расширена и в область инфраструктуры, так что теперь можно вести речь о соответствующих комплексных программно-аппаратных решениях. Для нашего рассмотрения наибольший интерес представляют шаблоны достаточно высокого уровня. Применение таких решений значительно облегчает задачу реализации новых элементов информационных систем. Каждый такой шаблон может объединять конкретное прикладное ПО, операционную систему, сервер СУБД, аппаратную платформу или несколько распределенных платформ, интерфейсы, метаданные и т.п. Типичными примерами являются шаблон
Инфраструктурные шаблоны можно определить как стандартизированный набор требований, компонент и сервисов, которые в совокупности формируют необходимую адекватную инфраструктуру для данной прикладной системы и реализации логики бизнес-процессов [4.39]. Рисунок 7.10 иллюстрирует общее определение инфраструктурного шаблона в форме многоуровневой классификации функций и примерного списка технологических компонент на каждом уровне.
(рис 7.10) Пример инфраструктурного шаблонаОрганизация инфраструктуры с помощью набора шаблонов позволяет единообразно определять компоненты и функциональные возможности, в результате чего эта часть ИТ-инфраструктуры может многократно использоваться для различных типов прикладных систем, имеющих общие требования к инфраструктуре. Это соответствует тому принципу, который мы сформулировали в лекции 6, когда говорили о том, что различные стили и типы прикладных систем и бизнес-процессов предъявляют различные требования к инфраструктуре. Таким образом, вместо того, чтобы строить инфраструктуру для каждого приложения, ее разрабатывают как набор нескольких шаблонов, каждый из которых оптимально предназначен для определенной группы прикладных систем так, как показано на рис. 7.11.
(рис 7.11) От традиционной архитектуры – к архитектуре, использующей инфраструктурные шаблоныБольшой интерес при создании бизнес-архитектуры предприятия представляют бизнес-шаблоны. В соответствии с [4.34] описание бизнес-шаблона включает:
Заинтересованным в этом вопросе читателям мы рекомендуем статью [4.34], которая опубликована в журнале Microsoft, посвященном вопросам архитектуры; в электронном виде публикацию можно найти по адресу http://msdn.microsoft.com/architecture/journ/.
В качестве другого примера рассмотрим возможности предложенных компанией IBM "шаблонов для электронного бизнеса" [4.40].
Так как практически все приложения для электронного бизнеса сталкиваются с необходимостью решения таких вопросов, как масштабируемость, надежность, доступность, безопасность, то представляется, что использование относительно небольшого числа стандартизованных решений может оказаться полезным. Эти решения можно, в свою очередь, подразделить в зависимости от уровня абстракции – соответственно на бизнес-шаблоны, архитектурные шаблоны, шаблоны уровня приложений и т.п. При этом:
В соответствии с предлагаемой схемой выделяются 4 основных бизнес-шаблона (см. табл. 7.1).
| Интегрированный доступ | Cамообслуживание (U2B- User-to-Business) | Интеграция приложений |
| Cотрудничество (U2U – User-to-User) | ||
| Агрегированная информация (U2D – User-to-Data) | ||
| Расширенное предприятие ( |
Кроме этого, выделяют также два служебных шаблона: соответственно интеграции доступа и интеграции приложений.
Эти шаблоны предназначены для описания таких типовых областей, как:
Шаблоны могут быть использованы по отдельности или в комбинации при реализации более сложных комплексных решений. Для идентификации классов этих решений общеупотребительным стали аббревиатуры, использующие сходное звучание в английском языке цифры 2 и отношения между двумя сторонами – системы типа
Для реализации на практике единой архитектуры предприятия особое значение приобретают шаблоны интеграции приложений. Прежде всего, стоит выделить две категории, связанные с уровнем реализации взаимодействия, – интеграция на уровне процессов и интеграция на уровне данных. Первая категория используется, если данные из одного процесса непосредственно используются в другом процессе, связанном с первым. Примером может служить использование средств обмена сообщениями для гарантированной доставки данных из филиала банка в центральное отделение. Другая категория связана с синхронизацией данных между несвязанными непосредственно между собой процессами (например, загрузка агрегированных данных из системы биллинга клиентов в систему управления маркетингом).
Собственно шаблоны строятся на основе набора предварительно определяемых общих служб, которые могут входить в шаблон в необходимой комбинации. Примерами таких общих служб могут являться:
Аналогичные архитектурные шаблоны в терминологии Microsoft представляют собой Решения уровня предприятия [4.41]. Они группируются в виде специальной модели в соответствии с уровнем абстракции и архитектурным доменом (см. рис. 7.12).
(рис 7.12) Категоризация архитектурных шаблонов MicrosoftПри этом область шаблонов как бы "ограничена сверху" за счет включения в рассмотрение только реляционных баз данных, многоуровневой (layered) архитектуры объектно-ориентированных приложений и N-звенных систем. За счет такого ограничения (в частности, из рассмотрения исключены OLAP-системы и монолитные или исполняемые на одной платформе приложения) удается достичь существенной глубины проработки. В состав набора входят шаблоны для представления информации через Web, поддержки распределенных систем, предоставления сервисов, обеспечения производительности и надежности систем.
В последнее время необходимость интеграции и взаимодействия приложений в рамках совокупности большого количества информационных систем предприятия или нескольких предприятий, объединенных в целую партнерскую цепочку, оказывают существенное влияние на используемые программные архитектуры. Детальное рассмотрение этих аспектов выходит за рамки данного курса, но мы посчитали целесообразным привести краткую информацию о новых подходах к проектированию архитектуры информационных систем, так как они имеют непосредственное влияние на принципы формирования архитектуры предприятия в целом.
Речь идет, прежде всего, о сервисной модели взаимодействия между приложениями общей системы в рамках так называемой сервис-ориентированной архитектуры (Service-oriented architecture SOA) и о реализации архитектуры, "управляемой моделями" (модельная архитектура. Model-driven architecture MDA).
Что такое сервис-ориентированная архитектура и как она связана с вопросами бизнес-архитектуры и архитектуры информационных технологий предприятия?
Хотя концепция сервис-ориентированной архитектуры была сформулирована специалистами в области ИТ, но в действительности это был прямой ответ на потребности сегодняшнего дня, когда становится уже не совсем понятно, где заканчиваются бизнес-функции организации и начинаются информационные технологии, их обеспечивающие, и наоборот. Ведущие поставщики информационных технологий, такие как Microsoft [4.42] и IBM [4.43], развивают эту концепцию в рекомендациях по проектированию информационных систем на своих программных платформах. А такие компании, как Gartner, считают, что сервис-ориентированная архитектура будет ведущим принципом проектирования новых критически-важных прикладных систем и бизнес-процессов в ближайшем будущем.
Мы уже говорили о том, что в основе бизнес-архитектуры должна быть процессно-ориентированная модель функций предприятия. Комбинация этого подхода с концепцией сервис-ориентированной архитектуры информационных технологий позволяет лучше увязать процесс разработки компонент информационных систем с миссией, основными задачами и функциями организаций.
С помощью SOA организации имеют потенциальную возможность разрабатывать набор реализаций различных бизнес-процессов, которые могут быть многократно использованы предприятием как готовые сервисы.
Под сервис-ориентированной архитектурой понимается подход к проектированию прикладных информационных систем, который руководствуется следующими принципами [4.44]:
В целом, SOA представляет собой модель взаимодействия компонент, которая связывает различные функциональные модули приложений (сервисы) между собой с помощью четко определяемых интерфейсов. Заметим, что одним из известных интеграционных шаблонов как раз и является "Сервис". Интерфейсы сами по себе не зависят от используемых аппаратных платформ, операционных систем или языков программирования, используемых для разработки этих приложений. Это позволяет отдельным сервисам взаимодействовать между собой одним и тем же стандартным, но в то же время универсальным способом. Такая особенность использования интерфейса, независимого от окружения и платформы, получила название модели "слабой связи". Ее очевидным преимуществом является повышенная гибкость и адаптируемость, поскольку замена или модернизация одной из компонент системы не сказывается на остальных. Достаточно интересное введение в эту проблематику и обсуждение связи терминов SOА и web-cервисов можно найти, например, в [4.45].
Само понятие SOA не является чем-то принципиально новым, так как сходные возможности реализовывались и ранее, например, с помощью технологий обмена сообщениями. Принципиальным фактором является то, что современные подходы к реализации SOA охватывают не только технологический уровень обмена данными, но и уровень бизнес-операций. В частности, одним из важных результатов стала разработка специализированного языка BPEL (Business Process Executable Language for Web Services) для описания аспектов взаимодействия различных сервисов с точки зрения реализации бизнес-правил. Вообще говоря, принятие SOA как целевой архитектуры будет подразумевать и соответствующий подход к разработке приложений (SODA – service-oriented development architecture).
Для задач электронного бизнеса соответствующая функциональность SOA реализуется на уровне web-сервисов (служб). Под web-сервисами понимаются программные системы, которые используют XML в качестве формата данных, стандарты Web Services Description Language (WSDL) для описания своих интерфейсов, Simple Object Access Protocol (SOAP) для описания формата принимаемых и посылаемых сообщений и стандарт Universal Description, Discovery and Integration (UDDI) для создания каталогов доступных сервисов. И хотя принципы сервис-ориентированной архитектуры создания информационных систем не обязательно предполагают использование технологий web-сервисов, связь между этими двумя направлениями в развитии информационных технологий является достаточно тесной. При этом web-сервисы являются технологическими спецификациями, в то время как сервис-ориентированная архитектура (SOA) является принципом проектирования архитектуры программных систем.
С учетом отмеченных выше существующих тенденций перехода к бизнесу "реального времени" и создания систем так называемого "расширенного предприятия", объединяющих само предприятие, его поставщиков, партнеров и клиентов в единую систему, становится очевидно, что технологии web-cервисов найдут свое применение на всех уровнях корпоративных информационных систем. Предполагается, что в будущем практически все взаимодействие приложений как в рамках одной информационной системы, так и между системами отдельных участников бизнес-процесса, будет осуществляться с использованием такого механизма, так что достаточно критическими становятся вопросы согласованной работы этих сервисов. Для описания такой работы были предложены даже специальные термины – "хореография" и "оркестровка" (очевидно, по аналогии с управлением оркестром из различных инструментов или ансамблем разных исполнителей). При этом, если хореография определяет взаимодействие различных участников с использованием сервисов, то оркестровка описывает взаимодействие сервисов в рамках одного бизнес-процесса, в частности, с использованием языка типа BPEL.
Более того, даже интеграцию унаследованных приложений целесообразно проводить с применением данной технологии, когда определенная, наиболее важная часть существующей функциональности как бы "инкапсулируется" и представляется стандартизированным интерфейсом. При наличии существующей инфраструктуры web-сервисов на предприятии можно ожидать существенного сокращения сроков и затрат на интеграцию.
Таким образом, влияние сервис-ориентированных подходов на изменения в архитектуре можно охарактеризовать как сбалансированный переход от централизованной инфраструктуры информационных технологий и замкнутого на себе функционала прикладных систем в сторону архитектуры, обеспечивающей возможности быстрого создания новых систем из набора доступных сервисов, т.е. более гибкой, динамичной и способной к взаимодействию.
Ориентация на сервисную архитектуру позволяет построить комплексную ссылочную модель архитектуры предприятия, которая в единой манере описывает как бизнес, так и ИТ [4.46]:
Эта модель состоит из следующих основных компонент:
(рис 7.13) Ссылочная модель сервис-ориентированной Архитектуры предприятияВзаимодействие между этими уровнями, однако, осуществляется не напрямую, а через сервисы, выделенные на уровень обработки событий. Сервисы этой компоненты архитектуры обеспечивают сбор данных о событиях в масштабе всего предприятия, необходимое преобразование и маршрутизацию этих данных между разными уровнями, а также "обратную связь" между сервисами каждого отдельного уровня.
В предложенной модели, наряду с рассмотренными уровнями, отвечающими за взаимодействие различных групп сервисов "как бы в процессе деятельности предприятия", выделяется отдельная компонента архитектуры, которая описывает аспекты, связанные с жизненным циклом сервисов – то есть их созданием, эксплуатацией и оптимизацией.
MDA является еще одной важной архитектурной концепцией создания информационных систем. Концепция MDA была предложена консорциумом OMG (Object Management Group, http://www.omg.org/), в который сегодня входит более 800 известных производителей программного и аппаратного обеспечения. MDA является определенным обобщением идей SOA, с одной стороны, и повторно используемых программных компонент (шаблонов, паттернов) с другой, предназначенным прежде всего для повышения гибкости разрабатываемых приложений масштаба предприятия, чтобы обеспечить простоту обеспечения соответствия требованиям бизнеса в условиях изменения используемых инфраструктурных платформ.
MDA по определению является открытой и "нейтральной" по отношению к используемым технологиям интеграции. Она основана на следующих принципах [3.18]:
В рамках такого подхода сначала создается архитектура, которая описывает модель бизнес-функциональности и поведения прикладной системы независимо от технических деталей реализации. Эта разработка должна вестись в контексте всей корпоративной архитектуры организации. На основе этой модели, не зависящей от платформы реализации, может быть разработана одна или несколько специфических для конкретной платформы моделей, в зависимости от того, какая платформа используется и поддерживается организацией. Уже на основе этих специфических для конкретной платформы моделей разрабатывается код конкретной прикладной системы, как показано на рис. 7.14.
(рис 7.14) Создание прикладных систем в соответствии с подходом MDAЭтот подход не определяет, какие языки разработки, операционные системы или
Более подробная информация по MDA доступна на сайте http://www.omg.org/mda, а также на сайтах практически всех ведущих производителей систем моделирования и разработки приложений.
Эта область архитектуры предприятия рассматривает "традиционные" аспекты построения информационных систем, которые необходимы для поддержки прикладных систем и информационных ресурсов организации. Для технологической архитектуры иногда используются такие термины, как "платформы", "инфраструктура", "системная архитектура" или просто "ИТ-архитектура".
Технологическая архитектура является как бы фундаментом, основой всего портфеля информационных технологий предприятия. Вторую существенную часть этого портфеля составляют прикладные системы, обеспечивающие выполнение бизнес-процессов (мы обсуждали это в предыдущем разделе, посвященном архитектуре приложений).
Основное назначение технологической архитектуры – это обеспечение надежных ИТ-сервисов, предоставляемых в рамках всего предприятия в целом и координируемых централизованно, как правило, департаментами информационных технологий. Технологическая архитектура определяет набор принципов и стандартов (индустриальных стандартов; стандартов, связанных с продуктами; конфигураций), которые обеспечивают руководства в отношении выбора и использования таких технологий как аппаратные платформы, операционные системы, системы управления базами данных, средства разработки, языки программирования, ПО промежуточного слоя, сервисы электронной почты, каталоги, системы безопасности, сетевая инфраструктура и т.д. Мы уже отмечали раньше, что отдельные аспекты (безопасность, интеграция, иногда разработка) могут быть выделены в отдельные области (домены) архитектуры предприятия в зависимости от особенностей организации.
Инфраструктурные сервисы, в основном, стандартизированы в рамках предприятия и используются сразу несколькими прикладными системами, расположенными над уровнем инфраструктурных сервисов и непосредственно обеспечивающих выполнение бизнес-процессов. При наличии необходимой инфраструктуры новые прикладные системы, которые потребуются предприятию для выполнения новых бизнес-процессов или реализации новых стратегий, могут быть созданы достаточно быстро и эффективно. Это является предпосылкой для повышения того, что называется динамичностью и гибкостью предприятия. Одной из частных задач, решаемых в рамках технологической архитектуры, является формирование "списка закупаемых технологий".
По самой своей природе, инвестиции в инфраструктуру ИТ являются крупными и долговременными, при этом они не имеют определенной ценности для бизнеса с точки зрения получения конечных результатов. Но ценность инфраструктуры заключается в ее способности быстро и экономически эффективно обеспечить реализацию новых прикладных систем в интересах различных подразделений предприятия, которые и приносят бизнес-пользу. В конечном итоге, именно инфраструктура определяет тот спектр прикладных систем, которые могут быть развернуты на предприятии для обеспечения его бизнес-процессов.
Проблема построения технологической инфраструктуры и инвестиций в инфраструктуру аналогична построению общественной инфраструктуры: дорог, мостов, больниц и школ. Оба типа обеспечиваются централизованно и финансируются, в конечном итоге, за счет косвенных отчислений средств конечных потребителей (налоги и пр.). Для обеспечения совместимости необходимо следовать определенным стандартам (например, правила размещения зданий вдоль улиц или правила использования прикладными системами инфраструктурных технологий). Одна из самых главных трудностей состоит в том, что размеры и масштабы использования инфраструктуры должны быть оценены еще до того как с большой определенностью станут известны все потребности со стороны бизнеса.
Развитие практически всех компонент инфраструктуры (будь то серверы, средства хранения данных или системы передачи данных) за прошедшие полвека сопровождалось фантастическими успехами в плане увеличения мощности, производительности, миниатюризации, надежности и других параметров. Существует большое количество технологических стандартов, как де-факто, так и де-юре, которые в той или иной комбинации выбираются для включения в архитектуру организации. В целом, проектирование данной компоненты архитектуры является, пожалуй, самой традиционной и достаточно хорошо проработанной практикой – как у системных интеграторов, так и в большинстве крупных организаций, поэтому мы не будем рассматривать особенности тех или иных компонент (да это и невозможно в рамках одного курса), а ограничимся упоминанием нескольких важных подходов.
Существует два принципиально отличных подхода формирования технологической архитектуры. Первый условно можно назвать "открытым". Он заключается в перечислении используемых на предприятии стандартов (индустриальных и пр.) и теоретически позволяет уменьшить зависимость предприятия от конкретных поставщиков. Однако уменьшение этой зависимости имеет ограниченный успех, поскольку замена одного продукта другим, поддерживающим один и тот же набор стандартов, как правило, оказывается невозможным или затруднительным. Поэтому с середины 1990-х годов большинство предприятий стали использовать второй подход, который связан, в конечном итоге, с перечислением конкретных продуктов и технологий.
Реальные преимущества от наличия упорядоченного в рамках технологической архитектуры списка используемых технологий таковы:
В то же время разнообразие технологий на предприятии – это неизбежная ситуация в силу многих причин, начиная с технологических и заканчивая организационными и политическими. Не останавливаясь на этом подробно, отметим, что обсуждавшаяся нами выше концепция
Рисунок 7.1 иллюстрирует то, что технологическая инфраструктура предприятия располагается на нескольких "уровнях" и принятие решения о размещении той или иной части инфраструктуры в масштабе предприятия или отдельных бизнес-подразделений является стратегическим решением, которое должно основываться на принятых в организации принципах построения архитектуры. Аналогично, если речь идет об инфраструктуре "
(рис 7.1) Различные уровни размещения инфраструктурыНа данном рисунке условно изображено предприятие с несколькими бизнес-подразделениями и разнообразным портфелем технологий: некоторые из этих технологий координируются и эксплуатируются централизованно, другие – на уровне отдельных подразделений. ИТ-сервисы, которые требуются для предприятия в целом, обеспечиваются комбинацией общекорпоративной и публичной инфраструктуры. Инфраструктура уровня подразделения ориентирована на более специфические потребности соответствующих подразделений.
Например, в крупной компании обработка больших массивов производственных данных может производиться в едином корпоративном центре обработки данных. Все подразделения используют эту централизованную инфраструктуру, но имеют некоторые дополнительные локальные потребности, которые обеспечиваются локальной инфраструктурой. Одно из бизнес-подразделений, крупнейшее на предприятии, может и не иметь своей собственной локальной инфраструктуры, а использовать исключительно централизованные сервисы.
Существуют различные способы категоризации технологий и сервисов, которые относятся к технологической архитектуре. Например, META Group выделяет два различных типа областей (доменов) технологической архитектуры (более подробно см. лекции 8): базовые (технологии, которые используются практически каждой информационной системой) и прикладные (более специфические с точки зрения использования бизнесом).
Примерами базовых доменов технологической архитектуры являются сети, аппаратное обеспечение, операционные системы, системы хранения,
Примерами прикладных доменов технологической архитектуры являются системы коллективной работы, электронной почты и управления потоками работ (workflow), Интранет, Интернет-приложения, системы электронной коммерции,
Gartner называет в технологической архитектуре шесть архитектурных компонент (сервисов), в каждом из которых выделяется определенное количество технологических "строительных блоков" (bricks) [4.24]:
На самом деле, возможных способов классификации элементов, составляющих основу технологической архитектуры, может быть множество. В качестве еще одного примера можно привести техническую справочную модель (
Эта справочная модель содержит четыре области технологических сервисов: доступ и доставка; платформы и инфраструктура; компонентная модель; сервис интерфейсов и интеграции. Каждая область технологических сервисов делится на категории, категории содержат стандарты, а стандарты содержат спецификации.
На рисунке 7.2 приведен пример областей, категорий, стандартов и спецификаций
(рис 7.2) Пример областей, категорий, стандартов и спецификаций технической справочной модели TRM FEAFОтдельный интерес представляют взаимосвязи между функциональными и операционными требованиями к системам и различными областями архитектуры, такими как прикладные системы и технологическая архитектура [4.25].
Функциональные требования к прикладной системе описывают ту ценность, которую представляет система с точки зрения реализации функций организации (бизнес-ценность). Архитектура приложений, по сути дела, является архитектурой всех автоматизированных сервисов, которые обеспечивают и реализуют такие функциональные требования, включая интерфейсы к бизнес-приложениям и другим прикладным системам. Она описывает структуру приложений и то, как эта структура реализует функциональные требования организации.
Операционные (или эксплуатационные) требования к программной системе специфицируют такие аспекты, как надежность, управляемость, производительность, безопасность, совместимость. И это далеко не полный список. Примерами операционных требований являются возможность доступа к системе только авторизованных пользователей, уровень доступности прикладной системы 99,99% времени и т.д.
Технологическая архитектура является архитектурой инфраструктуры аппаратного и программного обеспечения, которая обеспечивает работу прикладных систем и выполнение операционных (нефункциональных) требований, предъявляемых к архитектуре прикладных систем и информации. Она описывает структуру и взаимосвязи между используемыми технологиями и то, как эти технологии обеспечивают выполнение операционных требований организации.
(рис 7.3) Взаимосвязи функциональных и операционных требований с архитектурой приложений и технологической архитектуройПоэтому ассоциации, о которых мы должны всегда помнить, следующие: "Функциональные требования обеспечиваются архитектурой приложений,
Хотя, конечно, следует сделать одно замечание. Хорошая технологическая архитектура может обеспечивать безопасность, доступность, надежность и целый список других операционных требований, но если приложение спроектировано так, что оно не использует преимуществ технологической архитектуры, оно все равно будет функционировать плохо, и его будет сложно внедрять и сопровождать. Аналогичным образом, хорошо спроектированная структура прикладной системы, которая точно соответствует требованиям бизнес-процессов и собрана из многократно используемых компонент с применением современнейших технологий, может не соответствовать реальной конфигурации используемого аппаратного и системного программного обеспечения. Например, имеющиеся серверы могут не поддерживать работу компонент системы, конфигурация и топология сети – не обеспечивать потребности в потоках информации. Это показывает, что все-таки есть существенная взаимосвязь между архитектурой приложений и технологической архитектурой: хорошая технологическая архитектура должна быть построена с учетом поддержки прикладных систем, играющих важную роль в работе организации. Хорошая архитектура приложений должна эффективно использовать технологическую архитектуру, чтобы обеспечить должный уровень соответствия всем операционным требованиям.
Для оценки состояния технологической инфраструктуры предприятия в терминах, понятных бизнес-руководству, и с точки зрения потенциальных возможностей реализации различных бизнес-стратегий, можно использовать подход, предложенный Питером Кином (Peter Keen) [4.26]. Он основан на использовании двух критериев:
На рисунке 7.4 приведен вариант матрицы, которая использует эти два критерия. Чем шире функциональные возможности и охват инфраструктуры, тем более сложные, одновременно совершаемые в разных системах транзакции, может выполнять организация в различных местах расположения бизнеса. Например, точка "A" на рисунке означает возможность обеспечить, например, прием заказа и его обработку, включая информацию о складе, планах производства, выставление счетов во всех соответствующих системах и подразделениях независимо от местоположения. В то же время точка "B" соответствует ограниченным функциональным возможностям и широте охвата инфраструктуры, которая обеспечивает возможности по пересылке электронных сообщений в рамках отдельных подразделений.
(рис 7.4) Охват и функциональные возможности инфраструктурыЗаметим, что количество градаций в параметре охвата можно детализировать и варьировать, добавив сюда, например, возможности по выполнению операций в рамках страны, за рубежом и т.д., в зависимости от характера деятельности предприятия.
Эту модель оценки инфраструктуры можно использовать для идентификации типичных действий, которые требуются для выполнения бизнес-процессов в рамках каждой области функциональных возможностей. Затем можно сравнить эти возможности с потребностями, которые исходят от бизнеса, включая планируемые потребности. Как правило, обнаруживается достаточно заметный разрыв между потребностями и возможностями. В результате руководство департамента ИТ может спланировать реализацию необходимых проектов для перевода текущей технологической архитектуры в желаемое состояние, оценить затраты, необходимое время и возможные трудности.
Требования к технологической инфраструктуре можно также оценивать, используя необходимость в реализации различных стилей бизнес-процессов и прикладных систем, которые мы обсуждали в лекции 6 (приложения, обслуживающие большое количество транзакций, операции в реальном времени, аналитические приложения, приложения поддержки совместной работы или утилиты).
Уделим особое внимание одному, но достаточно важному аспекту, который сейчас активно позиционируется в качестве перспективного направления развития. Речь идет о создании адаптивной технологической инфраструктуры, которая способна в определенных пределах, автоматически или полуавтоматически, "подстраиваться под требования" со стороны бизнес-приложений для обеспечения оптимальной работы.
Основными характеристиками адаптивной системы (см. также [4.27]) являются:
Другая важная проблема – необходимость повышения эффективности использования существующих вычислительных ресурсов. Действительно, типовая загрузка
Для решения этой задачи предложили свои решения практически все ведущие производители, включая HP (концепция Adaptive Enterprise, архитектура Darwin), IBM (On Demand), Sun (N1), Microsoft (Dynamic
Существует несколько концептуальных обоснований для таких решений ([4.28]-[4.30]). Одним из них является так называемая концепция "Organic IT", предложенная компанией Forrester. В соответствии с определением, "...это инфраструктура, построенная из относительно дешевых компонентов с такой избыточностью, которая обеспечивает автоматическое разделение между всеми приложениями и администрирование корпоративных информационных ресурсов, в том числе программного обеспечения, процессоров, систем хранения данных и сетей". Такая инфраструктура позволяет повысить "коэффициент полезного использования" ресурсов, упростить интеграцию различных технологических компонент между собой и облегчить управляемость системы в целом.
Аналогичная концепция под названием "Инфраструктура реального времени" (Real-Time Infrastructure,
Таким образом, основные идеи адаптивной инфраструктуры таковы:
Возможная реализация такой адаптивной инфраструктуры на практике может осуществляться так, как показано на рис. 7.5.
Приведем несколько комментариев к данному рисунку:
(рис 7.5) Инфраструктура реального времениПредполагается, что этот подход позволит, за счет эффективного усреднения потребностей приложений, обеспечить повышение загрузки ресурсов примерно вдвое. Заметим, что практическая реализация такой архитектуры потребует и соответствующего изменения модели сервисов. Для этого компанией Gartner предложена специальная концепция IT
Применение стандартов играет важную роль в архитектуре информационных систем – прежде всего потому, что стандарты обеспечивают возможность взаимодействия различных компонент между собой. Чем более сложной, распределенной и тиражируемой является система, тем эта определяющая и консолидирующая роль стандартов становится все более актуальной. Стандарты есть общепринятые документы, формализующие лучшие практики. Строго говоря, принято различать стандарты де-юре, т.е. разработанные и поддерживаемые официальными органами по стандартизации, такими как Международная организация по стандартизации – ISO, и стандарты де-факто, основанные на существующем широком распространении технологии, методологии или продукта (например, использование MS Windows в качестве операционной системы для персональных компьютеров).
С другой стороны, можно выделять два класса – "технологические" и "рамочные" стандарты. Технологические стандарты определяют особенности реализации тех или иных протоколов, интерфейсов, языков программирования и т.п. Типичным примером являются спецификации WWW консорциума W3C. В составе описания ИТ-архитектуры предприятия обычно приводятся ссылки на используемые стандарты такого типа.
Для наших задач, связанных с разработкой архитектуры предприятия, наибольший интерес будут представлять такие "рамочные" стандарты, как уже упоминавшийся ISO 15704, а также ISO 15288 и, частично, ISO 12207. Помимо указанных, при разработке архитектуры предприятия достаточно широко используется порядка 30-ти дополнительных "поддерживающих" стандартов системной и программной инженерии. Например, стандарт ISO 14258 определяет концепции и правила для моделирования Предприятия и т.п. Эти стандарты являются рамочными (Framework) в том плане, что они задают общие требования к реализации процессов, связанных с разработкой и поддержкой жизненного цикла систем. Они обычно используются как методологическая основа для организации этих процессов с необходимой конкретизацией для каждого данного предприятия или области деятельности.
Если стандарт ISO 12207 был разработан для определения жизненного цикла только программного обеспечения, то ISO/IEC 15288 определяет жизненный цикл "более общей" системы. В применении к нашему контексту такой системой может являться совокупность информационных систем предприятия в целом.
В соответствии со стандартом ISO/IEC 15288 жизненный цикл систем охватывает "дерево" процессов, показанное на рис. 7.6.
(рис 7.6) Структура активностей стандарта ISO 15288Реально для использования на практике при формировании архитектуры информационной системы в целом или проведения разработок программных комплексов на уровне отраслей и отдельных компаний формируются так называемые профили стандартов. Каждый такой профиль является специально сформированной совокупностью – выборкой из нескольких базовых стандартов и, может быть, других нормативных документов с четко зафиксированными подмножествами определений, обязательных к реализации. Помимо таких обязательных элементов, профиль может определять некоторые требования как факультативные. Профиль, однако, не может расширять состав требований так, чтобы он противоречил использованным в нем базовым (исходным) стандартам.
Как уже отмечалось, профили могут создаваться как для отдельной системы, так и для класса систем, предназначенных для использования в определенных рамках. Хорошим примером такого профиля является SAGA, описывающая требования к системам для реализации "
Использование профилей направлено прежде всего на снижение трудоемкости и стоимости разработки проектов информационных систем и повышение качества их реализации за счет использования уже апробированных решений. При этом сами профили можно условно разделить на два класса – профили, описывающие собственно программные или архитектурные решения на основе ISO 15288, и профили, регламентирующие процессы жизненного цикла программных систем, такие как разработка, тестирование, сопровождение и т.п. Обычно для этого класса за основу берется стандарт ISO 12207.
Важным преимуществом использования архитектурных профилей является ориентация на использование модели открытых систем. Основные рекомендации по разработке таких профилей окружения открытых систем приведены в документе IEEE 1003.23, доступном по адресу http://www.enterprise-architecture.info. Создаваемые профили могут быть использованы как для детализации собственно ИТ-архитектуры, так и для формализации процесса ее разработки. Обычно в состав такого профиля включаются следующие разделы:
В соответствии с принципами построения открытых систем, профили строятся с учетом разделения системы на отдельные уровни (программное обеспечение, аппаратные платформы, внешнее окружение), взаимодействие между которыми происходит по четко определенным интерфейсам. Собственно, открытая система предполагает использование открытых, т.е. опубликованных стандартных интерфейсов, процессов и форматов данных для обеспечения портируемости (переносимости) на другие аппаратные платформы и операционные системы, а также обеспечивает взаимодействие с другими приложениями – как локальными, так и удаленными.
В составе интерфейсов выделяются отдельные сервисы информационных систем (ИС-сервисы). ИС-сервисы представляют собой сервисы достаточно высокого уровня (например, управление информацией или статистический анализ данных), которые могут быть объединены в группы – системные, коммуникационные, информационные и взаимодействия с пользователями. ИС-сервисы формулируются в бизнес-терминах, например, "статистическая обработка данных". Реализация этих сервисов осуществляется на основе взаимодействия "более элементарных" ИТ-сервисов, описываемых в терминах протоколов, программных интерфейсов и компонент. Примерами таких сервисов могут являться печать или управление транзакциями.
Формирование профиля, в соответствии с данными рекомендациями, производится на основании последовательного логического процесса, включающего такие этапы, как определение бизнес-требований, формирование общего списка ИТ-сервисов, заполнение матрицы корреляции бизнес-требований и ИТ-сервисов, формирование списка ИС-сервисов и матрицы корреляции ИТ/ИС-сервисов. Для необходимых ИС-сервисов выбираются существующие де-юре или де-факто стандарты, коммерчески доступные приложения или определяются требования по заказной разработке. Данное руководство содержит
также некоторые примеры
Более подробная информация по стандартам для открытых систем приведена, например, в [4.31],[4.32]. Важно отметить, что такой подход может быть полезным даже в том случае, когда конкретная информационная система не полностью удовлетворяет принципу открытости.
Детальное обсуждение многих вопросов, связанных со стандартами, включая аспекты применения международных стандартов в России, их сравнение с существующими стандартами серий ГОСТ 34, ГОСТ Р и других, можно найти в материалах конференций по стандартам [4.33] и на сайте http://www.fostas.ru.
Мы уже отмечали выше актуальность интеграции приложений и использования общих компонент информационных систем (сервисов). Отражением этого факта является существующая тенденция выделения данных аспектов в отдельные области архитектуры предприятия. Существенную роль при реализации этих областей играют стандартизованные элементы.
Подобно тому, как проект здания может включать в себя элементы ранее созданных конструкций, так и реализация поддержки бизнес-процесса в информационной системе может использовать уже известные фрагменты программного кода и/или типовые конфигурации оборудования. Это позволяет, с одной стороны, значительно сократить сроки выполнения решения, с другой – уменьшить риски за счет использования фрагментов, проверенных на практике. Фактически речь идет о выборе и использовании подходящих шаблонов (patterns). Английский термин "pattern" имеет различные варианты перевода, в том числе "образец", "шаблон" и т.п. В данном случае мы будем использовать русский термин "шаблон", оставляя кальку "паттерн" для обозначения аналогичных объектов в области программной архитектуры. Шаблоны являются как бы проверенными способами построения какой-то части системы.
Одним из удачных определений шаблонов является следующее: "Шаблон – это общее решение некоторой повторяющейся проблемы в определенном контексте" [4.34].
(рис 7.7) Шаблон – решение проблемы в контекстеТо есть важным аспектом, связанным с шаблонами, является то, что они сопровождаются определенными обоснованиями того, почему данное решение является хорошим в условиях заданного контекста. Шаблоны являются следующим шагом в понимании и применении моделей. Шаблон показывает, что делает некоторую модель хорошим решением и как создать некоторое решение для определенной проблемы.
Осознание важности шаблонов привело к тому, что, например, методика описания архитектуры Gartner выделяет шаблоны в качестве отдельного "слоя" архитектуры.
Использование шаблонов имеет явные корни в строительной архитектуре. Определяющий вклад в формирование исходного понятия "pattern" принадлежит известному архитектору Кристоферу Александеру. В своей фундаментальной работе 1987 года [4.35] он выделил более 250 типовых архитектурных решений, таких как лестницы, альковы, связи между офисами и др. Согласно Александеру, каждый такой прототип фактически определяет рекомендуемое решение отдельной проблемы в фиксированном контексте. В оригинале Александер выделяет контекст, воздействующие силы и особенности применения данного шаблона. В соответствии с аллегорическим комментарием Коупа, описание шаблона – это пьеса. Контекст задает место действия и определяет актеров, силы плетут заговор, найденное решение обеспечивает Катарсис.
Исходной целью этих работ Александера была не разработка каких-то новых идей, а, напротив, анализ накопленного опыта строительства – как отдельных зданий, так и целых городов – с целью выявления удачных архитектурных решений и способствовавших этому факторов. Конечно, критерии определения удачности в данной области во многом субъективны, так как зависят от общества, использующего данные постройки. В области информационных технологий такими критериями могут быть полнота выполнения требований, долговечность, эффективность реализации, а также, в соответствии с [4.36], ориентация, прежде всего, на расширение, а не на ограничение возможностей организации. Еще одним важным понятием из строительной архитектуры, которое нашло свое отражение в сфере информационных технологий, стал язык шаблонов (
В приведенном выше определении шаблона имеется три ключевых словосочетания:
В области информационных технологий первоначально шаблоны получили признание в области программной архитектуры. В широко известной работе группы авторов [4.37] (которых в англоязычной литературе по числу авторов книги часто называют "бандой четырех") описаны типовые конструкции для объектно-ориентированных языков программирования, таких как C++. Большое количество ссылок по данной тематике и примеров приведены на http://www.patterns.com. Но оказывается, что понятие шаблона оказывается весьма эффективно и в области архитектуры предприятия в целом!
В отношении информационных технологий можно сказать, что шаблоны являются логическими моделями технологий: это проектировочные идеи, которые могут быть многократно использованы в рамках предприятия в целом [4.38]. Как правило, эти решения служат, в каком-то смысле, индустриальными стандартами и обычно существуют продолжительное время. Их можно рассматривать как некоторые схемы, которые определяют компоненты решения, т.е.
Когда мы говорим о шаблонах, то речь не идет о конкретных моделях аппаратного или программного обеспечения. Как проиллюстрировано рисунком 7.8, интерес представляет другое: как серверы взаимодействуют между собой и как они совместно обеспечивают работу с системой клиента, использующего персональный компьютер? Какие роли играет каждый компонент? Какие типы коммуникаций необходимы между ними?
(рис 7.8) Шаблон показывает взаимодействие компонент системы между собойВажность шаблонов для архитектуры предприятия в целом обусловлена следующими причинами:
Можно сказать, что архитектурные концепции (методики) и шаблоны являются двумя инструментами для успешного, быстрого, эффективного с точки зрения затрат создания моделей и реализации систем с минимальными рисками. Принято идентифицировать шаблоны, которые относятся к различным доменам архитектуры (бизнес-шаблоны, шаблоны инфраструктуры и т.д.) и различным уровням абстракции архитектуры.
(рис 7.9) Архитектура, шаблоны и моделиВ рамках предприятия целесообразно создать репозиторий шаблонов. Характерное для предприятия число различных шаблонов составляет порядка 30. Это включает шаблоны использования унаследованных и старых клиент/серверных систем, модели для будущей архитектуры (например, сервис-ориентированной) и т.д.
Описание шаблонов может выполняться с различной степенью детализации и соответствия реальным условиям. В зависимости от этого уровня можно рассматривать элементы языка шаблонов различной степени абстракции – идиомы, шаблоны дизайна (design patterns) и рамочные модели (frameworks). При этом идиомы представляют собой шаблоны самого "низкого уровня", которые зависят от конкретной технологии. Шаблоны дизайна обладают определенной независимостью, но в то же время не могут рассматриваться как система в целом. Хорошим примером являются шаблоны стандартных классов. Например, понятие "Фабрики Объектов" в объектно-ориентированных приложениях, вообще говоря, не зависит от выбора конкретного языка программирования и может быть реализовано схожим образом и на С++, и на Java. Наконец, рамочные модели представляют собой "частично законченные" системы, которые либо демонстрируют наиболее принципиальные элементы реализации, либо являются полностью работоспособными системами для определенных упрощенных, ограниченных или идеализированных внешних условий. Эти модели могут быть использованы как основа для специализированных доработок, а также для быстрого создания модели системы в целом на основе таких отдельных компонент.
Далее концепция шаблонов была расширена и в область инфраструктуры, так что теперь можно вести речь о соответствующих комплексных программно-аппаратных решениях. Для нашего рассмотрения наибольший интерес представляют шаблоны достаточно высокого уровня. Применение таких решений значительно облегчает задачу реализации новых элементов информационных систем. Каждый такой шаблон может объединять конкретное прикладное ПО, операционную систему, сервер СУБД, аппаратную платформу или несколько распределенных платформ, интерфейсы, метаданные и т.п. Типичными примерами являются шаблон
Инфраструктурные шаблоны можно определить как стандартизированный набор требований, компонент и сервисов, которые в совокупности формируют необходимую адекватную инфраструктуру для данной прикладной системы и реализации логики бизнес-процессов [4.39]. Рисунок 7.10 иллюстрирует общее определение инфраструктурного шаблона в форме многоуровневой классификации функций и примерного списка технологических компонент на каждом уровне.
(рис 7.10) Пример инфраструктурного шаблонаОрганизация инфраструктуры с помощью набора шаблонов позволяет единообразно определять компоненты и функциональные возможности, в результате чего эта часть ИТ-инфраструктуры может многократно использоваться для различных типов прикладных систем, имеющих общие требования к инфраструктуре. Это соответствует тому принципу, который мы сформулировали в лекции 6, когда говорили о том, что различные стили и типы прикладных систем и бизнес-процессов предъявляют различные требования к инфраструктуре. Таким образом, вместо того, чтобы строить инфраструктуру для каждого приложения, ее разрабатывают как набор нескольких шаблонов, каждый из которых оптимально предназначен для определенной группы прикладных систем так, как показано на рис. 7.11.
(рис 7.11) От традиционной архитектуры – к архитектуре, использующей инфраструктурные шаблоныБольшой интерес при создании бизнес-архитектуры предприятия представляют бизнес-шаблоны. В соответствии с [4.34] описание бизнес-шаблона включает:
Заинтересованным в этом вопросе читателям мы рекомендуем статью [4.34], которая опубликована в журнале Microsoft, посвященном вопросам архитектуры; в электронном виде публикацию можно найти по адресу http://msdn.microsoft.com/architecture/journ/.
В качестве другого примера рассмотрим возможности предложенных компанией IBM "шаблонов для электронного бизнеса" [4.40].
Так как практически все приложения для электронного бизнеса сталкиваются с необходимостью решения таких вопросов, как масштабируемость, надежность, доступность, безопасность, то представляется, что использование относительно небольшого числа стандартизованных решений может оказаться полезным. Эти решения можно, в свою очередь, подразделить в зависимости от уровня абстракции – соответственно на бизнес-шаблоны, архитектурные шаблоны, шаблоны уровня приложений и т.п. При этом:
В соответствии с предлагаемой схемой выделяются 4 основных бизнес-шаблона (см. табл. 7.1).
| Интегрированный доступ | Cамообслуживание (U2B- User-to-Business) | Интеграция приложений |
| Cотрудничество (U2U – User-to-User) | ||
| Агрегированная информация (U2D – User-to-Data) | ||
| Расширенное предприятие ( |
Кроме этого, выделяют также два служебных шаблона: соответственно интеграции доступа и интеграции приложений.
Эти шаблоны предназначены для описания таких типовых областей, как:
Шаблоны могут быть использованы по отдельности или в комбинации при реализации более сложных комплексных решений. Для идентификации классов этих решений общеупотребительным стали аббревиатуры, использующие сходное звучание в английском языке цифры 2 и отношения между двумя сторонами – системы типа
Для реализации на практике единой архитектуры предприятия особое значение приобретают шаблоны интеграции приложений. Прежде всего, стоит выделить две категории, связанные с уровнем реализации взаимодействия, – интеграция на уровне процессов и интеграция на уровне данных. Первая категория используется, если данные из одного процесса непосредственно используются в другом процессе, связанном с первым. Примером может служить использование средств обмена сообщениями для гарантированной доставки данных из филиала банка в центральное отделение. Другая категория связана с синхронизацией данных между несвязанными непосредственно между собой процессами (например, загрузка агрегированных данных из системы биллинга клиентов в систему управления маркетингом).
Собственно шаблоны строятся на основе набора предварительно определяемых общих служб, которые могут входить в шаблон в необходимой комбинации. Примерами таких общих служб могут являться:
Аналогичные архитектурные шаблоны в терминологии Microsoft представляют собой Решения уровня предприятия [4.41]. Они группируются в виде специальной модели в соответствии с уровнем абстракции и архитектурным доменом (см. рис. 7.12).
(рис 7.12) Категоризация архитектурных шаблонов MicrosoftПри этом область шаблонов как бы "ограничена сверху" за счет включения в рассмотрение только реляционных баз данных, многоуровневой (layered) архитектуры объектно-ориентированных приложений и N-звенных систем. За счет такого ограничения (в частности, из рассмотрения исключены OLAP-системы и монолитные или исполняемые на одной платформе приложения) удается достичь существенной глубины проработки. В состав набора входят шаблоны для представления информации через Web, поддержки распределенных систем, предоставления сервисов, обеспечения производительности и надежности систем.
В последнее время необходимость интеграции и взаимодействия приложений в рамках совокупности большого количества информационных систем предприятия или нескольких предприятий, объединенных в целую партнерскую цепочку, оказывают существенное влияние на используемые программные архитектуры. Детальное рассмотрение этих аспектов выходит за рамки данного курса, но мы посчитали целесообразным привести краткую информацию о новых подходах к проектированию архитектуры информационных систем, так как они имеют непосредственное влияние на принципы формирования архитектуры предприятия в целом.
Речь идет, прежде всего, о сервисной модели взаимодействия между приложениями общей системы в рамках так называемой сервис-ориентированной архитектуры (Service-oriented architecture SOA) и о реализации архитектуры, "управляемой моделями" (модельная архитектура. Model-driven architecture MDA).
Что такое сервис-ориентированная архитектура и как она связана с вопросами бизнес-архитектуры и архитектуры информационных технологий предприятия?
Хотя концепция сервис-ориентированной архитектуры была сформулирована специалистами в области ИТ, но в действительности это был прямой ответ на потребности сегодняшнего дня, когда становится уже не совсем понятно, где заканчиваются бизнес-функции организации и начинаются информационные технологии, их обеспечивающие, и наоборот. Ведущие поставщики информационных технологий, такие как Microsoft [4.42] и IBM [4.43], развивают эту концепцию в рекомендациях по проектированию информационных систем на своих программных платформах. А такие компании, как Gartner, считают, что сервис-ориентированная архитектура будет ведущим принципом проектирования новых критически-важных прикладных систем и бизнес-процессов в ближайшем будущем.
Мы уже говорили о том, что в основе бизнес-архитектуры должна быть процессно-ориентированная модель функций предприятия. Комбинация этого подхода с концепцией сервис-ориентированной архитектуры информационных технологий позволяет лучше увязать процесс разработки компонент информационных систем с миссией, основными задачами и функциями организаций.
С помощью SOA организации имеют потенциальную возможность разрабатывать набор реализаций различных бизнес-процессов, которые могут быть многократно использованы предприятием как готовые сервисы.
Под сервис-ориентированной архитектурой понимается подход к проектированию прикладных информационных систем, который руководствуется следующими принципами [4.44]:
В целом, SOA представляет собой модель взаимодействия компонент, которая связывает различные функциональные модули приложений (сервисы) между собой с помощью четко определяемых интерфейсов. Заметим, что одним из известных интеграционных шаблонов как раз и является "Сервис". Интерфейсы сами по себе не зависят от используемых аппаратных платформ, операционных систем или языков программирования, используемых для разработки этих приложений. Это позволяет отдельным сервисам взаимодействовать между собой одним и тем же стандартным, но в то же время универсальным способом. Такая особенность использования интерфейса, независимого от окружения и платформы, получила название модели "слабой связи". Ее очевидным преимуществом является повышенная гибкость и адаптируемость, поскольку замена или модернизация одной из компонент системы не сказывается на остальных. Достаточно интересное введение в эту проблематику и обсуждение связи терминов SOА и web-cервисов можно найти, например, в [4.45].
Само понятие SOA не является чем-то принципиально новым, так как сходные возможности реализовывались и ранее, например, с помощью технологий обмена сообщениями. Принципиальным фактором является то, что современные подходы к реализации SOA охватывают не только технологический уровень обмена данными, но и уровень бизнес-операций. В частности, одним из важных результатов стала разработка специализированного языка BPEL (Business Process Executable Language for Web Services) для описания аспектов взаимодействия различных сервисов с точки зрения реализации бизнес-правил. Вообще говоря, принятие SOA как целевой архитектуры будет подразумевать и соответствующий подход к разработке приложений (SODA – service-oriented development architecture).
Для задач электронного бизнеса соответствующая функциональность SOA реализуется на уровне web-сервисов (служб). Под web-сервисами понимаются программные системы, которые используют XML в качестве формата данных, стандарты Web Services Description Language (WSDL) для описания своих интерфейсов, Simple Object Access Protocol (SOAP) для описания формата принимаемых и посылаемых сообщений и стандарт Universal Description, Discovery and Integration (UDDI) для создания каталогов доступных сервисов. И хотя принципы сервис-ориентированной архитектуры создания информационных систем не обязательно предполагают использование технологий web-сервисов, связь между этими двумя направлениями в развитии информационных технологий является достаточно тесной. При этом web-сервисы являются технологическими спецификациями, в то время как сервис-ориентированная архитектура (SOA) является принципом проектирования архитектуры программных систем.
С учетом отмеченных выше существующих тенденций перехода к бизнесу "реального времени" и создания систем так называемого "расширенного предприятия", объединяющих само предприятие, его поставщиков, партнеров и клиентов в единую систему, становится очевидно, что технологии web-cервисов найдут свое применение на всех уровнях корпоративных информационных систем. Предполагается, что в будущем практически все взаимодействие приложений как в рамках одной информационной системы, так и между системами отдельных участников бизнес-процесса, будет осуществляться с использованием такого механизма, так что достаточно критическими становятся вопросы согласованной работы этих сервисов. Для описания такой работы были предложены даже специальные термины – "хореография" и "оркестровка" (очевидно, по аналогии с управлением оркестром из различных инструментов или ансамблем разных исполнителей). При этом, если хореография определяет взаимодействие различных участников с использованием сервисов, то оркестровка описывает взаимодействие сервисов в рамках одного бизнес-процесса, в частности, с использованием языка типа BPEL.
Более того, даже интеграцию унаследованных приложений целесообразно проводить с применением данной технологии, когда определенная, наиболее важная часть существующей функциональности как бы "инкапсулируется" и представляется стандартизированным интерфейсом. При наличии существующей инфраструктуры web-сервисов на предприятии можно ожидать существенного сокращения сроков и затрат на интеграцию.
Таким образом, влияние сервис-ориентированных подходов на изменения в архитектуре можно охарактеризовать как сбалансированный переход от централизованной инфраструктуры информационных технологий и замкнутого на себе функционала прикладных систем в сторону архитектуры, обеспечивающей возможности быстрого создания новых систем из набора доступных сервисов, т.е. более гибкой, динамичной и способной к взаимодействию.
Ориентация на сервисную архитектуру позволяет построить комплексную ссылочную модель архитектуры предприятия, которая в единой манере описывает как бизнес, так и ИТ [4.46]:
Эта модель состоит из следующих основных компонент:
(рис 7.13) Ссылочная модель сервис-ориентированной Архитектуры предприятияВзаимодействие между этими уровнями, однако, осуществляется не напрямую, а через сервисы, выделенные на уровень обработки событий. Сервисы этой компоненты архитектуры обеспечивают сбор данных о событиях в масштабе всего предприятия, необходимое преобразование и маршрутизацию этих данных между разными уровнями, а также "обратную связь" между сервисами каждого отдельного уровня.
В предложенной модели, наряду с рассмотренными уровнями, отвечающими за взаимодействие различных групп сервисов "как бы в процессе деятельности предприятия", выделяется отдельная компонента архитектуры, которая описывает аспекты, связанные с жизненным циклом сервисов – то есть их созданием, эксплуатацией и оптимизацией.
MDA является еще одной важной архитектурной концепцией создания информационных систем. Концепция MDA была предложена консорциумом OMG (Object Management Group, http://www.omg.org/), в который сегодня входит более 800 известных производителей программного и аппаратного обеспечения. MDA является определенным обобщением идей SOA, с одной стороны, и повторно используемых программных компонент (шаблонов, паттернов) с другой, предназначенным прежде всего для повышения гибкости разрабатываемых приложений масштаба предприятия, чтобы обеспечить простоту обеспечения соответствия требованиям бизнеса в условиях изменения используемых инфраструктурных платформ.
MDA по определению является открытой и "нейтральной" по отношению к используемым технологиям интеграции. Она основана на следующих принципах [3.18]:
В рамках такого подхода сначала создается архитектура, которая описывает модель бизнес-функциональности и поведения прикладной системы независимо от технических деталей реализации. Эта разработка должна вестись в контексте всей корпоративной архитектуры организации. На основе этой модели, не зависящей от платформы реализации, может быть разработана одна или несколько специфических для конкретной платформы моделей, в зависимости от того, какая платформа используется и поддерживается организацией. Уже на основе этих специфических для конкретной платформы моделей разрабатывается код конкретной прикладной системы, как показано на рис. 7.14.
(рис 7.14) Создание прикладных систем в соответствии с подходом MDAЭтот подход не определяет, какие языки разработки, операционные системы или
Более подробная информация по MDA доступна на сайте http://www.omg.org/mda, а также на сайтах практически всех ведущих производителей систем моделирования и разработки приложений.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.