Обзор архитектуры Microsoft

Архитектура предприятия

Центр архитектуры .NET

июль 2002 г.

Майкл Платт
Корпорация Microsoft

Содержание

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

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

Архитектура предприятия

В стандарте ANSI/IEEE 1471-2000is дается следующее определение архитектуры: «фундаментальная организация системы, реализованная в ее компонентах, связях этих компонентов друг с другом и внешней средой и принципах, определяющих структуру и развитие системы».

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

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

Отдельные модели в архитектуре предприятия упорядочены логически, что позволяет получить высокодетализированное описание предприятия, включая следующие элементы:

  • цели и задачи;
  • процессы и их организация;
  • системы и данные;
  • используемые технологии.

Точка зрения на архитектуру корпорации Microsoft

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

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

Бизнес-архитектура

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

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

Архитектура приложений

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

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

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

Информационная архитектура

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

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

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

Технологическая архитектура

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

  • настольные компьютеры и серверы;
  • операционные системы;
  • сетевые компоненты;
  • принтеры;
  • модемы.

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

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

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

Архитектура приложений и технологическая архитектура

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

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

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

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

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

Рис. 1. Связи между архитектурами

Концептуальное, логическое и физическое представления

Для каждой архитектуры можно выделить несколько представлений: концептуальное, логическое и физическое. Концептуальное представление наиболее абстрактно и обычно описывается в терминах, знакомых обычным пользователям (не ИТ-специалистам). Концептуальное представление используется для определения функциональных требований и представления приложения с точки зрения бизнес-пользователей в процессе создания бизнес-модели. Логическое представление отражает основные функциональные компоненты системы и связи между ними независимо от технических подробностей реализации соответствующих функций. Архитекторы создают модели приложений, которые фактически являются логическим представлением бизнес-модели, поскольку определяют соответствие приложений целям и требованиям бизнеса. Модель приложения отражает логическое представление архитектуры приложения. Физические представления наименее абстрактны и отражают компоненты конкретной реализации и связи между ними. Каждый из элементов в физическом представлении реализуется программно или аппаратно, как правило, в процессе проектирования или разработки. Подобное представление реализации обычно используется отделами разработки или эксплуатации; его рассмотрение выходит за рамки данного документа.

Рис. 2. Архитектурные представления

На каждом уровне архитектуры может использоваться несколько представлений (как правило, так и происходит); например, для каждого приложения используется свое логическое представление.

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

Рис. 3. Архитектурные представления и шаблоны

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

Архитектура приложений

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

Концептуальное представление

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

Логическое представление

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

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

Физическое представление

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

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

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

К первому типу относятся архитектурные концепции, которые предоставляют архитекторам следующие сведения:

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

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

Рис. 4. Представления архитектуры приложений

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

Архитектура приложений: концептуальное представление

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

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

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

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

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

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

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

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

Такое концептуальное представление приложений подробно рассматривается в статье Архитектура приложений: концептуальное представление.

Шаблоны приложений

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

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

Технологическая архитектура

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

Концептуальное представление

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

Логическое представление

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

Физическое представление

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

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

Технологическая архитектура: концептуальное представление

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

Рис. 5. Концептуальное представление технологической архитектуры

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

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

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

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

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

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

Технологические шаблоны

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

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

Показ: