четверг, 3 июля 2008 г.

Сервис-ориентированная архитектура и архитектура предприятия: Часть 2. Сходства и различия

Мамду Ибрахим, старший сертифицированный специалист в области архитектуры информационных систем, IBM
Гил Лонг, заслуженный инженер, IBM
http://www.ibm.com/developerworks/ru/library/ws-soa-enterprise2/index.html

16.04.2008

В этой, второй, статье данной серии мы изучим модели архитектуры и механизма руководства для сервис-ориентированной архитектуры (Service-Oriented Architecture, SOA) и архитектуры предприятия (Enterprise Architecture, EA), а также исследуем их сходства и различия. Затем вы узнаете о потенциальных проблемах, с которыми могут столкнуться организации, если они не позаботятся о координации деятельностей SOA на предприятии.

Введение

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

В части 1 этой серии даются определения и рассказывается об областях применения SOA и EA для создания инфраструктуры, в которой можно было бы выполнить корректное сравнение и сопоставление этих двух технологий. Кроме того, авторы статьи объясняют, что SOA и EA - это больше, чем архитектуры, — а именно: каждая из них состоит из архитектуры, механизма руководства и плана-графика. Мы рассмотрели схему разных предметных областей и инфраструктуру руководства обеими технологиями.

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

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

Буква A в аббревиатурах SOA и EA

Чтобы определить пересечения между разными предметными областями архитектуры SOA и EA, рассмотрим рисунки 1 и 2. На них изображены соответствующие предметные области EA и SOA. Мы воспользуемся этими рисунками как основой для сопоставления двух технологий.


Рисунок 1. Предметные области архитектуры EA
EA architecture domains


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

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


Таблица 1. Сопоставление предметных областей архитектуры SOA и EA
Предметные области архитектурыСтек SOA-решенияИнфраструктура EA
БизнесБизнес-процессАрхитектура бизнеса
ПриложенияСервисы и компонентыАрхитектура приложений
Миграция и связующее ПОАрхитектура интеграции / ESBАрхитектура технологии
ДанныеАрхитектура данныхАрхитектура информации
ОперацииКачество сервиса, безопасность, мониторинг и инфраструктураАрхитектура технологии

Однако нередко встречается и такая ситуация, при которой предметные области SOA являются подмножеством предметных областей EA. Например, SOA не имеет отношения к разработке архитектуры бизнеса. Зато она использует результаты бизнес-процессов и другие артефакты архитектуры бизнеса, например, моделирования бизнес-компонентов (Component Business Modeling, CBM), в качестве входной информации для идентификации бизнес-сервисов. Напротив, EA имеет отношение к разработке архитектуры бизнеса, в том числе, бизнес-процессов и CBM. Аналогично, с точки зрения архитектуры приложений SOA имеет отношение к моделированию и разработке сервисов и реализующих их компонентов, тогда как архитектура EA имеет дело не только со специфическими артефактами SOA, но и с другими компонентами, пакетами и системами для предприятия в целом.

При анализе архитектуры технологии, ESB SOA представляется всего лишь как один из многих механизмов интеграции, которые, возможно, должна обеспечить EA. Обратите внимание на то, что SOA не обращается к архитектуре управления контентом, в отличие от EA.

Кроме того, в EA и SOA пересекаются такие предметные области, как обеспечение безопасности и управление сервисом. Фактически, безопасность SOA является частным случаем общей системы безопасности, которую должна определять EA, а управление сервисами SOA и мониторинг (SOA Service Management and Monitoring) являются одним из механизмов управления системами (Systems Management), который входит в инструментарий EA.


Предметные области архитектуры: сходства и различия

Ниже перечислены все сходства и различия, которые мы обнаружили, изучая концепции архитектуры в SOA и EA:

Сходства

Предметные области SOA и EA во многом сходны. Например:

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

Различия

Архитектурные предметные области EA относятся к макроуровню, тогда как архитектурные предметные области SOA работают на микроуровне. Точнее,

  • EA фокусируется на определении бизнес-компонентов, а SOA - на бизнес-сервисах;
  • EA работает с инфраструктурами приложений и корпоративными прикладными системами, а область применения SOA ограничивается моделированием сервисов;
  • EA взаимодействует с инфраструктурой уровня организации, в том числе, с серверами, базами данных и аналогичными структурами, тогда как SOA фокусируется на инфраструктурах, которые поддерживают сервисы, а именно на Enterprise Service Bus;
  • EA устанавливает, какие шаблоны корпоративной интеграции необходимо использовать и когда, включая интеграцию по схеме "точка-точка", передачу файлов и другие традиционные принципы интеграции прикладных систем. SOA реализует принципы интеграции, основанные на использовании сервисов. Хотя принцип интеграции SOA может показаться более гибким и чаще рекомендуемым, все же необходимо рассматривать его как один из принципов, который должен определяться и поддерживаться EA.

Потенциальные проблемы

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

  • Если организация сосредоточится исключительно на SOA, то другие аспекты EA могут остаться без внимания. Например, могут быть проигнорированы и не решены на уровне организации традиционные потребности, учитываемые другими принципами интеграции, но не поддерживаемые SOA (например, интерфейс «точка-точка»). Кроме того, без EA организации могут попасть в ловушку антишаблона «Золотой молоток» (если молоток - единственный инструмент, который у вас есть, то любую задачу вы поневоле постараетесь представить как гвоздь, который можно забить этим молотком) и будут пытаться использовать SOA для всех решений, даже для тех, которые не получат преимуществ от использования такой архитектуры;
  • При параллельной разработке SOA и EA вы можете столкнуться с недостаточной эффективностью вследствие того, что работы по проекту проводятся в двойном объеме, а возможности использовать артефакты имеющейся архитектуры постоянно упускаются. Несложно представить себе, что два коллектива, работающих над SOA и EA, могут тратить лишнее время и ресурсы на создание дублирующих, а иногда и конфликтующих, информационных моделей, инфраструктур, политик управления системами, стратегий и инструментов;
  • Без тщательного анализа ситуации и разделения специфических для SOA и EA предметных областей организации могут совершить ошибку и отнести вопросы, являющиеся специфическими для SOA, к области применения EA (например, такие специфические стандарты SOA, как XML и BPEL).
Механизм руководства

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

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

Механизм управления ИТ

«Структура взаимосвязей и процессов, предназначенная для руководства и управления организацией для достижения ею целей путем создания стоимости и одновременного нахождения равновесия между риском и окупаемостью ИТ и порождаемых ими процессов» — (IT Governance Institute)

Механизм управления архитектурой

«Метод и направление для управления и контролирования архитектуры организации и других архитектур на корпоративном уровне. Как правило, функционирует не изолированно, а в составе иерархии управляющих структур, которые, особенно в крупной организации, могут включать механизм руководства организацией, механизм руководства технологией, механизм руководства информационными технологиями (ИТ) и механизм руководства архитектурой» — (Open Group)

Механизм управления SOA

«Механизм управления SOA дополняет механизм управления ИТ по мере увеличения степени их ориентации на сервисы. Кроме того, SOA представляет собой межфункциональную инициативу, которая включает бизнес-технологии и ИТ-технологии в общий процесс разработки стратегии и задач организации. Таким образом, механизм управления SOA должен стать связующим звеном между организацией и механизмом управления ИТ» — Керри Холли (Kerrie Holley), сотрудник IBM

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

Структурные модели управления

Для поддержки процессов руководства необходимо разработать и утвердить структуру механизма управления, которая будет использоваться для определения, применения и обслуживания этих процессов. В данном разделе приводится сравнительное описание структур механизма управления для SOA и EA.

Модель механизма управления архитектурой

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


Рисунок 3. Типичная структура механизма управления архитектурой
Architecture governance organization

В этой структуре механизма управления архитектурой руководящие органы нижнего слоя работают с отдельными проектами, а руководящие органы в среднем слое осуществляют управление на уровне программ (обычно они курируют несколько проектов). Коллективы верхнего слоя работают на уровень выше уровня программ и обеспечивают необходимую связь с внешними сущностями и заинтересованными лицами (при необходимости). В контексте этой статьи наиболее важны такие органы, как наблюдательный совет по архитектуре (Architecture Review Board, ARB) и координационный комитет по архитектуре (Architecture Steering Group, ASG) в среднем слое.

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

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

Модель механизма руководства SOA

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

  • Координационный комитет по работе с SOA, который отвечает за осуществление руководства SOA в организации;
  • Наблюдательный совет, который отвечает за обеспечение соответствия SOA стандартам и политикам и создается для всех проектов, связанных с SOA;
  • Бизнес-совет по SOA, представляющий собой связующее звено с организациями определенных бизнес-специализаций (LOB) для идентификации и расстановки приоритетов разрабатываемых сервисов, являющихся важными для бизнеса;
  • Центр разработки и распространения передовых методов SOA (Center of Excellence, CoE), отвечающий за непрерывное повышение квалификации сотрудников и предоставление рекомендаций по разработке SOA для всех проектов.

Рисунок 4. Упрощенная структура механизма управления SOA
Simplified SOA           governance organization


Механизмы управления EA и SOA: сходства и различия

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

Ниже перечислены возможные соответствия между структурами механизма управления SOA и EA с учетом круга их обязанностей:

  • Стратегический исполнительный комитет по SOA (Executive Strategy Committee) соответствует Координационному комитету (Architecture Steering Group);
  • Наблюдательный совет по SOA (Review Board) соответствует Наблюдательному совету по архитектуре (Architecture Review Board);
  • Центр разработки и распространения передовых методов SOA (CoE) может соответствовать руководящей группе проекта (Design Authority) (понятие, распространенное в Великобритании, странах Европы, Среднего Востока и Африки, но обычно редко используемое в США); однако даже при наличии руководящей группы организация может создать CoE, чтобы гарантировать реализацию всех преимуществ, которые обещает внедрение SOA;
  • Бизнес-совет по SOA обычно не присутствует в среде EA.

В общем, механизмы управления SOA и EA имеют множество сходств и различий:

Сходства

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

Различия

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

Потенциальные проблемы

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

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

Комментариев нет: