 | Уровень сложности: средний Мамду Ибрахим, старший сертифицированный специалист в области архитектуры информационных систем, IBM
Гил Лонг, заслуженный инженер, IBM
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 вполне вероятно, что некоторые из принятых руководителями разных проектов решений могут вызывать явиться причиной возникновения конфликтных ситуаций, в которые будут вовлекаться те, кто в своей работе ориентируется на эти решения.
|
Заключение
В этой статье рассказывалось о сходствах и различиях
между SOA и EA с точки зрения архитектуры и управления. Кроме того,
мы рассмотрели потенциальные проблемы, с которыми может столкнуться организация, не
уделяющая внимание координированию деятельности по SOA и EA. В следующем выпуске
данной серии (Часть 3) будут даны рекомендации по поводу решения описанных проблем;
эти рекомендации основаны на опыте, полученном в результате участия в реальном проекте.
Благодарности
Особая благодарность Йану Чартерсу (Ian Charters), руководителю исследования
Технологической Академии IBM по EA за предоставленные им данные, на основе которых были разработаны многие из схем, представленных в данной статье. Кроме того
, мы хотим поблагодарить следующих сотрудников за их работу в этой области и
ценные комментарии к черновым версиям этой презентации: Пол Бейт (Paul Bate), Люба
Чербаков (Luba Cherbakov), Клаудио Коззи (Claudio Cozzi), Петер Де Мео (Peter De Meo), Рей Харишанкар (Ray Harishankar), Керри Холли (Kerrie Holley), Дон Хатчсон (Don Hutcheson), Дэвид
Дженсон (David Janson), Стивен Барнс (Steven Barnes), Сатиш Кальяни (Satish Kalyani) и Шарон Фочун (Sharon Fortune).
Ресурсы Научиться
Получить продукты и технологии
Обсудить
Об авторах | | | Доктор Мамду Ибрахим (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. Господин Лонг имеет обширный опыт работы в качестве руководителя высшего звена
во всех сферах информационных технологий, включая стратегическое планирование информационных систем, проектирование архитектуры,
проектирование и реализацию бизнес-систем, проектирование и
развертывание систем и сетей, а также операции с данными. В его должностные обязанности входило управление
крупными ИТ-организациями, подбор персонала и отчетность по бюджету. Кроме того, он
работал в нескольких отраслях, таких как здравоохранение, финансовые операции, образование,
розничная торговля, страхование, коммунальное обслуживание, производство и управление. |
Выскажите мнение об этой странице
| |
