Мамду Ибрахим, старший сертифицированный специалист в области архитектуры информационных систем, 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 
Рисунок 2. Стек SOA-решения
В следующей таблице приводятся результаты сопоставления предметных областей архитектуры 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 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 
Механизмы управления 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 вполне вероятно, что некоторые из принятых руководителями разных проектов решений могут вызывать явиться причиной возникновения конфликтных ситуаций, в которые будут вовлекаться те, кто в своей работе ориентируется на эти решения.
