Сервис-ориентированная архитектура и архитектура предприятия: Часть 3. Как они работают вместе?

Мамду Ибрахим, старший сертифицированный специалист в области архитектуры информационных систем, IBM
Гил Лонг, заслуженный инженер, IBM
http://www.ibm.com/developerworks/ru/library/ws-soa-enterprise3/index.html
16.04.2008
Если вы внедряете сервис-ориентированную архитектуру (Service-Oriented Architecture, SOA) и одновременно с этим разрабатываете или планируете архитектуру предприятия (Enterprise Architecture, EA), то эта статья, безусловно, будет вам полезна. В первых двух частях этой серии мы сравнили и сопоставили SOA и EA, а также осветили проблемы, которые могут стать результатом нескоординированного развертывания EA и SOA в организации. Авторы столкнулись с этими проблемами в процессе работы над клиентским проектом стоимостью 1, 6 миллиардов долларов США, в котором разработка SOA и EA осуществлялась одновременно. В заключительном выпуске серии мы извлечем уроки из этого опыта и предоставим рекомендации, которые помогут вам справиться с описанными проблемами и избежать убытков.

Введение и повторение пройденного

Концепции, деятельности, процессы и результаты SOA, EA и соответствующие им механизмы руководства во многом пересекаются. Например, и SOA, и EA требуют наличия входной информации, основанной на бизнес-задачах, и генерируют результаты, которые привязаны к этим задачам и оцениваются в соответствии с ними. И SOA, и EA предназначены для решения задач на корпоративном уровне (стратегия и планирование, ссылочная архитектура и т.д.). Поэтому их модели механизма управления схожи. Если ваша организация внедряет SOA и одновременно с этим разрабатывает EA (и соответствующие механизмы управления), вы можете столкнуться с проблемами, если вовремя не распознаете и не примете во внимание сходства и различия между SOA и EA.
В части 1 этой серии даются определения и рассказывается об областях применения SOA и EA для создания инфраструктуры, в которой можно было бы выполнить корректное сравнение и сопоставление этих двух технологий. В ней также рассказывалось о том, что SOA и EA – это больше, чем архитектура. В частности, и SOA, и EA содержат в себе архитектуру, механизм руководства и план-график. Мы рассмотрели схему разных предметных областей и инфраструктуру руководства обеими технологиями.
В части 2 мы сосредоточились на идентификации сходств и различий между SOA и EA, рассматривая архитектурную составляющую обеих технологий и выявляя пересечения между соответствующими им предметными областями. Кроме того, в этой части рассказывалось о потенциальных проблемах, которые могут возникнуть в ситуациях, когда предприятие начинает внедрять SOA уже после того, как была разработана (или продолжает разрабатываться) EA. Затем мы остановились на аспектах механизма руководства EA и SOA и выполнили анализ, аналогичный тому, что проводился нами для архитектуры в процессе работы над крупным проектом с компанией из сферы обслуживания, входящей в список Fortune 500.
Перед вами часть 3, заключительная статья серии, в которой мы представляем учебный пример, основанный на опыте сотрудничества с крупным клиентом, для которого мы параллельно разрабатывали EA и SOA. Мы приводим рекомендации, основанные на том, как мы сами решали потенциальные проблемы и подводим итог извлеченным из этого опыта урокам.
Проект
Клиент, компания из списка Fortune 500, заключил с IBM® контракт на аутсорсинговые услуги в сфере бизнеса и информационных технологий (сроком на 10 лет). По этому проекту IBM предоставляет широкий спектр услуг преобразования бизнеса и ИТ-сервисов на основе аутсорсинга и управляет всеми ИТ-операциями клиента, в том числе, операциями мэйнфреймов, серверов средней мощности, настольных компьютеров, справочной службы, сетей передачи голоса и данных, разработки приложений и обслуживания.
Среди основных действий преобразования ИТ-систем можно выделить следующие:

• Создание инфраструктуры и центра разработки и распространения передовых методов (CoE) для построения SOA;
• 3 уровня зрелости процесса по стандарту Института программной инженерии (Software Engineering Institute, SEI) в области разработки и обслуживания приложений;
• Управление портфелем приложений;
• Разработка нескольких новых проектов преобразования, а также центра обработки данных и нескольких проектов консолидации.

Важные факты и проблемы
Во-первых, давайте разберем некоторые из специфических проблем SOA-EA, с которыми мы сталкивались; это поможет представить характер среды, в которой имели место описываемые события:
Архитектура предприятия (EA)

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

SOA

• Специалисты IBM создали проект SOA и продемонстрировали высочайшую компетенцию в области разработки, это позволило им обойти конкурентов и получить данный контракт.
• Контракт включал финансирование и планирование деятельности по внедрению SOA. ; Это обеспечило компании прекрасные стартовые позиции.
• Лишь один из проектов преобразования был явно привязан к SOA, тогда как остальные проекты преобразования были структурированы и профинансированы без явного упоминания SOA. В результате реализация SOA в рамках таких проектов после подписания контракта стало проблематичным.

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

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

Для механизма управления архитектурой мы предложили модель двухуровневой структуры (см. рисунок 1), которая представляла собой адаптированную модель механизма руководства, описанную в методе IBM Enterprise Architecture Consulting Method. В этой модели имеется два руководящих органа: Совет управления архитектурой (Architecture Management Council, AMC) и Координационный совет по разработке архитектуры (Delivery Architecture Review Board, DARB).

Рисунок 1. Проект структурной модели механизма управления EA

Задачи AMC:

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

Задачи DARB можно разбить на две категории:

1. Последовательная разработка EA и ее обслуживание:
• DARB собирает имеющиеся архитектурные политики и проверяет их, чтобы решить, какие из них можно применить в процессе внедрения EA у клиента.
• Оценивает и объединяет отдельные архитектурные решения по проекту, способствующие тому, чтобы организационная структурая стала неотъемлемой частью EA.
2. Механизм управления архитектурой
• Направляет разработку архитектуры проекта.
• Наблюдает за соответствием архитектуры проекта архитектуре предприятия на стороне клиента.
• Утверждает архитектуру проекта, что является необходимым условием для проведения закупок аппаратного и программного обеспечения и инициализации проектирования и разработки в деталях.
• Рассматривает возможность исключений.

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

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

Рисунок 2. Проект структурной модели механизма управления SOA

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

Проблемы, имеющие отношение к архитектуре

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

Проблемы, имеющие отношение к механизму руководства

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

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

Рисунок 3. Сопоставление структурных моделей механизмов руководства SOA и архитектуры


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

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

Урок 2: Механизм руководства SOA должен использовать структуру механизмов руководства EA и ИТ

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

Урок 3: Модель финансирования SOA не входит в область применения EA

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

Урок 4: Инфраструктура SOA (ESB) должна быть ресурсом уровня организации

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