 | Уровень сложности: средний Мамду Ибрахим, старший сертифицированный специалист в области архитектуры информационных систем, IBM
Гил Лонг, заслуженный инженер, IBM
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 можно разбить на две категории:
-
Последовательная разработка EA и ее обслуживание:
- DARB собирает имеющиеся архитектурные политики и проверяет их, чтобы решить, какие из
них можно применить в процессе внедрения EA у клиента.
- Оценивает и объединяет отдельные архитектурные решения по проекту,
способствующие тому, чтобы организационная структурая стала неотъемлемой частью EA.
-
Механизм управления архитектурой
- Направляет разработку архитектуры проекта.
- Наблюдает за соответствием архитектуры проекта архитектуре предприятия на стороне клиента.
- Утверждает архитектуру проекта, что является необходимым условием для проведения
закупок аппаратного и программного обеспечения и инициализации проектирования и
разработки в деталях.
- Рассматривает возможность исключений.
Структурная модель
механизма управления 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 должны соответствовать
политикам обеспечения безопасности организации.
Заключение
Реализация SOA в организации, уже внедрившей EA, или параллельная реализация обеих систем
вызывает определенные сложности. Потенциальные проблемы, имеющие отношение к архитектуре и механизму руководства,
появившиеся в результате пересечения их областей влияния, структур
руководства, процессов и архитектур. Чтобы облегчить этот процесс,
необходимо иметь хорошо спланированную модель механизма руководства архитектуры и управления SOA,
а также четкое понимание принципов их совместной работы. Кроме того, необходимо использовать уроки, полученные вашими предшественниками. Например те, которые мы приводим в этой статье. И тогда вы сможете сэкономить значительные средства в ходе реализации вашего проекта.
Благодарности
Мы хотим поблагодарить следующих специалистов за их работу в данной
области и ценные комментарии к черновым версиям этой презентации: Пол Бейт (Paul Bate), Люба Чербаков (Luba Cherbakov), Клаудио Коззи (Claudio Cozzi), Петер Де Мео (Peter De Meo), Рей Харишанкар (Ray Harishankar), Керри Холли (Kerrie Holley), Дон Хатчсон (Don Hutcheson), Дэвид Дженсон (David Janson), Стивен Барнс (Steven Barnes), Сатиш Кальяни (Satish Kalyani) и Шарон Фочун (Sharon Fortune).
Ресурсы Научиться
Получить продукты и технологии
Обсудить
- Примите участие в обсуждении материала на форуме.
- Присоединяйтесь к сообществу developerWorks
, участвуя в блогах developerWorks, в том числе, в следующих блогах, посвященных SOA
и Web-сервисам: (EN)
-
Service Oriented Architecture -- Off the Record (Сервис-ориентированная архитектура - не для протокола) Сенди Картер (Sandy Carter);
-
Best Practices in
Service-Oriented Architecture (Передовые методы сервис-ориентированной архитектуры) Али Арсанджани (Ali Arsanjani);
-
WebSphere SOA and J2EE in Practice (WebSphere SOA и J2EE на практике) Бобби Вулфа (Bobby
Woolf);
-
Building SOA applications with patterns (Создание SOA-приложений при помощи шаблонов) доктора Эойна Лейна (Eoin Lane);
-
Client Insights, Concerns and Perspectives on SOA (Понимание заказчика, вопросы и перспективы SOA) Керри Холли (Kerrie Holley);
-
Collaboration apps, SOA, open source, Apache Tuscany, and world
travel (Совместная работа приложений, SOA, разработок с открытым исходным кодом, Apache Tuscany и путешествие вокруг света) Лусиано Ресенде (Luciano Resende);
-
Isn't it SOAnderful?: SOA, architecture, and developer issues (SOA: проблемы архитектуры и разработки)
Пэт Фландерс (Pat Flanders);
-
Service-Oriented Architecture and Business-Level
Tooling (Сервис-ориентированная архитектура и инструменты бизнес-уровня) Саймона Джонстона (Simon Johnston);
-
SOA Innovations (Новинки SOA) доктора Лианг Джи Жанг (Liang-Jie Zhang);
-
SOA, ESB and
Beyond (SOA, ESB и далее) Санджая Босе (Sanjay Bose);
-
Web Services Interoperability (Функциональная совместимость Web-сервисов) Тома Гловера (Tom Glover).
Об авторах | | | Доктор Мамду Ибрахим (Mamdouh Ibrahim) является старшим сертифицированным специалистом в области архитектуры информационных систем и старшим
техническим специалистом (STSM) в Центре изучения и распространения передовых методов архитектуры предприятия и технологий (Enterprise Architecture and
Technology Center of Excellence). Кроме того, он является членом коллектива центра изучения и распространения передовых методов Web-сервисов SOA (SOA Web Services
Center of Excellence). Доктор Ибрахим имеет более чем 30-летний
производственный и академический опыт в сфере таких технологий, как EA (архитектура предприятия), SOA,
распределенные вычислительные сети и беспроводные технологии. Он также работает в комитете по сертификации в области архитектуры информационных систем (IBM IT
Architect Certification Board), является автором и инструктором курсов по развитию архитектурного мышления IBM
(Architectural Thinking). Доктор Ибрахим имеет ученую степень доктора в области вычислительной техники;
магистра в области вычислительной техники и математики и
бакалавра в области электротехники и математики. Он является внештатным
преподавателем в Центральном Мичиганском университете (Central Michigan University). Он был генеральным председателем на конференции OOPSLA 2002, а в настоящее время
является председателем оргкомитета OOPSLA (до 2008 г). Доктор Мамду Ибрахим участвует в деятельности таких организаций, как
ACM, Компьютерное сообщество IEEE и AAAI. |
| | | Гил Лонг - заслуженный инженер IBM. Он работает руководителем отдела международных учебных программ в области архитектуры предприятий
и руководителем подразделения интеграции систем управления SOA
и специализируется на проектировании архитектуры уровня предприятия, планировании перехода и
планировании инфраструктуры SOA. Господин Лонг имеет обширный опыт работы в качестве руководителя высшего звена
во всех сферах информационных технологий, включая стратегическое планирование информационных систем, проектирование архитектуры,
проектирование и реализацию бизнес-систем, проектирование и
развертывание систем и сетей, а также операции с данными. В его должностные обязанности входило управление
крупными ИТ-организациями, подбор персонала и отчетность по бюджету. Кроме того, он
работал в нескольких отраслях, таких как здравоохранение, финансовые операции, образование,
розничная торговля, страхование, коммунальное обслуживание, производство и управление. |
Выскажите мнение об этой странице
| |
