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

Сервис-ориентированная архитектура и архитектура предприятия: Часть 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
Proposed EA governance           organizational model
Задачи AMC:
  • AMC принимает решения по поводу общей стратегии функционирования архитектуры клиента с учетом бизнес-стратегии клиента, технологических срезов (специально профинансированных исследований, описывающих доступные технологии) и отраслевых знаний.
  • Работает с поставленными задачами и решает их.
  • Финансирует и реализует EA.
Задачи DARB можно разбить на две категории:
  1. Последовательная разработка EA и ее обслуживание:
    • DARB собирает имеющиеся архитектурные политики и проверяет их, чтобы решить, какие из них можно применить в процессе внедрения EA у клиента.
    • Оценивает и объединяет отдельные архитектурные решения по проекту, способствующие тому, чтобы организационная структурая стала неотъемлемой частью EA.
  2. Механизм управления архитектурой
    • Направляет разработку архитектуры проекта.
    • Наблюдает за соответствием архитектуры проекта архитектуре предприятия на стороне клиента.
    • Утверждает архитектуру проекта, что является необходимым условием для проведения закупок аппаратного и программного обеспечения и инициализации проектирования и разработки в деталях.
    • Рассматривает возможность исключений.
В ходе создания и разработки модели механизма управления EA рабочая группа по SOA предложила структурную модель механизма управления SOA, изображенную на рисунке 2.

Рисунок 2. Проект структурной модели механизма управления SOA
The proposed SOA           governance organizational model
В этой модели управление 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 и архитектуры
Mapping the architecture and SOA governance organizational models


Уроки, которые мы извлекли
Решая проблемы, возникавшие в процессе работы над проектом заказчика, мы извлекли ценные уроки по поводу внедрения 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 должны соответствовать политикам обеспечения безопасности организации.

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