Содержание


Сервис-ориентированная архитектура и архитектура предприятия

Часть 1. Взаимодействие SOA и EA

Comments

Серия контента:

Этот контент является частью # из серии # статей: Сервис-ориентированная архитектура и архитектура предприятия

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Сервис-ориентированная архитектура и архитектура предприятия

Следите за выходом новых статей этой серии.

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

Содержание статей этой серии основано на практическом опыте, который был получен в ходе работы над крупным проектом в одной из компаний сферы обслуживания, вошедшей в список Fortune 500. IBM®предоставила для этого проекта широкий диапазон услуг преобразования бизнеса и ИТ-услуг на основе аутсорсинга и управляла всеми клиентскими операциями, в том числе операциями мэйнфреймов, серверов средней мощности, настольных компьютеров, справочной службы, голосовых сетей и сетей данных, разработки приложений и обслуживания. Для этого проекта оказалась необходимой параллельная разработка SOA и EA. В данной серии, состоящей из трех статей, освещаются потенциальные проблемы, как, например, перекрытие областей применения SOA и EA, формулируются и предлагаются советы и рекомендации по их решению. В частности:

  • В части 1 даются определения и области применения SOA и EA, позволяющие создать инфраструктуру, в которой можно было бы выполнить корректное сравнение и сопоставление этих двух технологий;
  • В части 2 осуществляется собственно сравнение и сопоставление SOA и EA. Здесь также рассказывается о потенциальных проблемах, которые могут возникнуть в тех случаях, когда предприятие уже разработало (или продолжает разрабатывать) EA, и только после этого начинает внедрять SOA;
  • В части 3 приводятся рекомендации по решению этих проблем, разработанные на основе опыта, полученного при решении аналогичных проблем в проекте стоимостью 1.6 миллиардов долларов США, в рамках которого разработка SOA и EA велась параллельно.

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

  • Область применения EA и область применения SOA (например, как можно использовать сходные аспекты двух технологий);
  • Связь между Центром разработки и распространения передовых методов SOA (Center of Excellence, CoE) и советами управления EA (например, как избежать перекрытия областей применения);
  • Ответственности и владение инфраструктурой SOA (например, в каком месте следует встроить шину Enterprise Service Bus (ESB) в инфраструктуру, и следует ли использовать ее исключительно для SOA?).

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

В исследовании Технологической академии IBM архитектура EA определяется следующим образом:

«Дисциплина EA определяет и обслуживает архитектурные модели, механизм управление и инициативы по переходу, необходимые для эффективной координации частично автономных групп для решения бизнес-задач- и/или ИТ-задач»

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

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

В литературе нет недостатка в описании инфраструктур EA. Захман первым сформулировал концепцию и опубликовал описание инфраструктуры для EA, которая была названа в его честь. После этого было опубликовано немало других инфраструктур EA, которые использовались многими организациями, особенно в области федерального управления. На рисунке 1 изображены примеры таких инфраструктур.

Рисунок 1. Различные модели EA, описанные в литературе.
Sample EA frameworks
Sample EA frameworks
Sample EA frameworks
Sample EA frameworks

Ниже представлена расшифровка сокращений, используемых на рисунке 1:

  • FEAF — Federal Enterprise Architecture Framework (Инфраструктура архитектуры федеральной организации);
  • TEAF — Treasury Enterprise Architecture Framework (Инфраструктура архитектуры казначейства);
  • DoDAF — Department of Defense Architecture Framework (Инфраструктура архитектуры Министерства обороны);
  • NASCIO — National Association of State Chief Information Officers (Национальная ассоциация государственных менеджеров по информационным технологиям).

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

Рисунок 2. Инфраструктура EA, разработанная IBM
IBM EA framework
IBM EA framework

EA - не только архитектура

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

Рисунок 3. EA состоит из архитектуры, механизма управления и плана-графика
IBM EA framework
IBM EA framework

Инфраструктура EA

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

Рисунок 4. Позиционирование предметных областей EA и управления в процессе планирования
Positioning EA domains and governance
Positioning EA domains and governance

Предметные области, которые необходимо смоделировать в составе EA, это:

  • Бизнес-архитектура;
  • Архитектура приложений;
  • Архитектура информации;
  • Архитектура технологии.

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

SOA

Определения SOA

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

Определение W3C:

«Набор вызываемых компонентов, описания интерфейсов которых могут быть опубликованы и обнаружены.»

Определение CBDI:

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

Определение Gartner:

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

Определение IBM:

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

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

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

Определение с точки зрения бизнеса:

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

Определение с точки зрения архитектуры:

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

Определение с точки зрения реализации:

Модель программирования, совместимая со стандартами, инструментами и технологиями Web-сервисов.

SOA - это не только архитектура

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

Рисунок 5. SOA - это не только архитектура
SOA is more than architecture
SOA is more than architecture

Стек SOA-решения

SOA состоит из процессов, сервисов и компонентов. Ядром SOA является модель сервиса, которая определяет сервисы и компоненты, с помощью которых они реализуются. На рисунке 6 показан стек SOA-решения и взаимосвязи между элементами, из которых состоит SOA.

Рисунок 6. Стек SOA-решения
SOA solution stack
SOA solution stack

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

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

Заключение

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

Благодарности

Особая благодарность Йану Чартерсу (Ian Charters), руководителю исследования Технологической Академии IBM по EA за предоставленные им данные, на основе которых были разработаны многие из схем, представленных в данной статье. Кроме того, мы хотим поблагодарить следующих сотрудников за их работу в этой области и ценные комментарии к черновым версиям этой презентации: Пол Бейт (Paul Bate), Люба Чербаков (Luba Cherbakov), Клаудио Коззи (Claudio Cozzi), Петер Де Мео (Peter De Meo), Рей Харишанкар (Ray Harishankar), Керри Холли (Kerrie Holley), Дон Хатчсон (Don Hutcheson), Дэвид Дженсон (David Janson), Стивен Барнс (Steven Barnes), Сатиш Кальяни (Satish Kalyani) и Шарон Форчун (Sharon Fortune).


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=297198
ArticleTitle=Сервис-ориентированная архитектура и архитектура предприятия: Часть 1. Взаимодействие SOA и EA
publish-date=03252008