Управление SOA – путь к совершенству

Вячеслав Ерохин

В статье рассматривается сервис-ориентированная архитектура (SOA) как бизнес-концепция. Предлагается подход к управлению жизненным циклом SOA с помощью методики «Управление SOA» (SOA Governance), основанной на средствах управления архитектурой предприятия (Enterprise Architecture Management) и стратегического управления ИТ.

Для того чтобы предложить эффективный способ управления SOA, нужно понять что же это такое? В зависимости от ответа, может строиться своя система решений задачи управления жизненным циклом SOA.

SOA – это архитектура

SOA – Service Oriented Architecture – архитектура, ориентированная на сервисы. SOA – это прежде всего бизнес-концепция архитектурного подхода к построению предприятия. Более ранние концепции не ставили в центр внимания архитектуру предприятия

SOA – первая широко известная бизнес-концепция, концентрирующаяся на архитектуре. Таким, образом, SOA надо понимать и применять в контексте управления архитектурой предприятия (Enterprise Architecture Management). Архитектура предприятия включает разные слои: бизнес-архитектура, информационная архитектура, техническая архитектура и т.д. SOA начинается с уровня бизнес-архитектуры.

SOA – это сервисы

Концепция SOA концентрируется на архитектуре, но архитектуре ориентированной на сервисы. Что такое сервисы и в чем разница с более ранними концепциями?

SOA, прежде всего, говорит о бизнес-сервисах. Конечно реализация SOA позволяет перейти к техническим сервисам, но это именно реализация SOA, а не ее суть. Самодостаточность, заменяемость и многократная используемость технического сервиса, лишь вытекает бизнес-сервиса. С точки зрения построения архитектуры предптриятия на принципах SOA первичен именно бизнес-сервис.

Таким образом, в SOA стоит выделить первый уровень - бизнес-архитектуры. В свою очередь бизнес-сервисы не существуют в отрыве от миссии компании, ее стратегии и целей. Бизнес-сервисы вытекают из места компании во внешней конкурентной среде. Долгосрочное развитие бизнеса может быть основано только на конкурентных преимуществах и их сочетании, обеспечивающем синергетический эффект. Обычно таких преимуществ немного – два-три. Большая удача – если их пять-шесть. Главная задача выживания компании – это задача создания и сохранения ее конкурентных преимуществ. Но конкурентные преимущества – или по-другому бизнес-потенциалы (Business Capabilities) – не строятся на основе процессов. Это функции компании как целого организма во внешней среде.

Бизнес-потенциалы

Концепция бизнес-потенциалов (business capabilities) получила в последнее время мощное развитие. Бизнес-потенциалы определяются как система конкурентных преимуществ, необходимых для реализации бизнес-стратегии предприятия. Бизнес-потенциалы ранжируются для определения их влияния на бизнес предприятия. Критически важные для бизнеса бизнес-потециалы получают максимальный приоритет. Такие бизнес-потенциалы являются самым высокоуровневым элементом построения архитектуры предприятия.

Проведение приоритизации бизнес-потенциалов позволяет принять решения, определяющие области управления в масштабе всего предприятия. Бизнес-потенциалы не критически важные для обеспечения долгосрочной конкурентоспособности предприятия остаются в поле зрения соответствующих бизнес-подразделений, рабочих групп или сотрудников, с предоставлением им соответствующих прав для их свободного использования и изменения. Такое распределение бизнес-потенциалов по степени важности и правам по их управлению определяется требованиями разумной минимизации архитектурной сложности на каждом уровне управления – принципом архитектурного минимализма.

Концепция бизнес-потенциалов в сочетании с принципом архитектурного минимализма открывает возможность к интеграции лучших черт, свойственных централизованной и децентрализованной моделям управления предприятием. Централизованные решения обеспечивают управляемость и мощный эффект от взаимодействия нескольких бизнес-потенциалов критически важных для бизнес-стратегии предприятия. Создается также благоприятный контекст для децентрализации управления предприятием, способной обеспечить инновационный цикл через создание малых рабочих групп с высокой автономией в принятии решений, не обязательно согласуемых с общей стратегией предприятия.

Основные правила, заложенные в основу концепции бизнес-потенциалов:

• построение иерархии приоритетов предприятия и приоритизация соответствующих этим приоритетам бизнес-потенциалов
• разумное ограничение детализации области управления и архитектурной сложности объекта управления
• обеспечение свободы принятия решения по поддержке бизнес-потенциалов в рамках компетенции подразделения, находящегося на соответствующем уровне управления

• взаимодействие уровней управления для согласованной поддержки бизнес-потенциалов.

Цель предприятия в рамках концепции бизнес-потенциалов – построение эффективной архитектуры предприятия, позволяющей:

• обеспечить сохранение поддержки критически важных бизнес-потенциалов
• обеспечить достижение стратегических целей предприятия.

Управление бизнес-потенциалами в контексте архитектуры предприятия – в частности архитектуры приложений – позволяет поддерживать анализ текущих показателей эффективности деятельности компании в сравнении с желаемыми показателями эффективности с построением их иерархической взаимосвязи. Этот метод позволяет выделить ключевые бизнес-потенциалы компании и обеспечить их приоритетную поддержку со стороны ИТ. С другой стороны, выделение бизнес-потенциалов, не дающих компании конкурентных преимуществ, позволяет сократить их поддержку или передать ее сторонним провайдерам на аутсорсинг.

Сервис или процесс

Бизнес-потенциалы (Business Capabilities) легко декомпозировать в бизнес-сервисы, но трудно – в бизнес-процессы. Сервисный подход ориентирован на стратегические цели компании – создание и сохранение бизнес-потенциалов.

Сервисный подход организации бизнеса ориентирован на построение сетей создания стоимости, предполагающих функциональное разделение рыночных субъектов и создание возможностей установления связей между ними. Процессный подход организации бизнеса ориентирован на способы реализации цепочек создания стоимости, где субъекты рынка объединены для производства товаров и услуг.

В сервисном подходе –именно бизнес-сервис является основным объектом планирования и управления. Бизнес-процесс – это способ реализации бизнес-сервиса. В процессном подходе первичен бизнес-процесс, как уникальная цепочка создания стоимости. Бизнес-сервис в процессном подходе либо не актуализируется вовсе и заменяется на технический сервис, либо является подчиненным элементом бизнес-процесса, кирпичиком из которых строится бизнес-процесс.

SOA – это не технологическая платформа

Может сложиться мнение, что SOA – это концепция, ориентированная на использование единой технологической платформы на основе веб-сервисов. Это не совсем так.

В SOA первично использование концепции архитектуры предприятия и концепции бизнес-сервисов. Следовательно, предприятие внедрившее управление архитектурой предприятия и управление на основе бизнес-сервисов является предприятием использующим SOA. Однако, если предприятие использует единую технологическую платформу типа Middleware, технические сервисы в виде веб-сервисов, то оно не обязательно внедрило у себя SOA.

Однако, прелесть SOA в том, что предприятие, внедрившее SOA, может эффективно использовать единую технологическую платформу и реализацию бизнес-сервисов, в виде набора технических сервисов.

SOA – вместо реинжиниринга бизнес-процессов – реинжиниринг предприятия

Стив Джонс, автор книги «Enterprise SOA Adoption Strategies. Using SOA to deliver IT to the businesss» утверждает: «Большинство компаний совершают одну принципиальную ошибку в отношении технологий: они рассмативают их через призму существующих процессов. Компании спрашивают: "Как эти новые технологические возможности могут улучшить и оптимизировать текущую работу?" Но вместо этого они должны спрашивать: "Что новое могут позволить нам делать технологии?" В отличие от автоматизации суть реинжиниринга - в новаторстве, в использовании новейших технологических возможностей для достижения совершенно новых целей. Один из самых сложных элементов реинжиниринга - умение найти новые, незнакомые возможности технологии».

Приходится слышать, что SOA предполагает реинжиниринг бизнес-процессов. Нет – SOA предполагает отказ от бизнес-процессов как бизнес-концепции. SOA предполагает реинжиниринг предприятия, а не его бизнес-процессов. SOA предлагает концепцию бизнес-сервисов вместо бизнес-процессов.

Процессный подход оказался неприменим в большинстве компаний. И не потому, что в этих компаниях работали неквалифицированные менеджеры. Главные причины провала попыток внедрения процессного подхода:

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

Бизнес-процессы обращены внутрь компании и нацелены на оптимизацию исполнения корпоративной мелодии (бизнес-процесса) – раз и навсегда заданной. Поэтому так остро стоит проблема постоянного реинжиниринга бизнес-процессов. Бизнес-процесс-это мелодия. И до сегодняшнего дня большинство предприятий проектируют под эту мелодию свой оркестр. Для другой мелодии они проектирую другой оркестр. Получается множество оркестров, исполняющих множество мелодий. Есть оркестр, исполняющий вальс, есть оркестр исполняющий польку и т.п. Так получается, потому, что целью проектирования и управления является исполнение конкретной – часто уникальной - мелодии, а кто и как исполняет эту мелодию – неважно. Если нам надо будет исполнить другую мелодию, нам придется сделать или купить другой оркестр.

SOA ставит целью создание набора инструментов, с помощью которого можно будет исполнить любую мелодию – бизнес-процесс (не важно какую) - нужную предприятию. SOA – это набор инструментов, необходимый и достаточный для исполнения и польки, и вальса. SOA – это единая нотная грамота, позволяющая исполнить любую мелодию. SOA – это аранжировка мелодии, учитывающая доступный набор инструментов.

SOA требует не реинжиниринга бизнес-процессов на предприятии, а конструирование бизнес-процессов из набора бизнес-сервисов. SOA предполагает наличие бизнес-процесса по конструированию бизнес-процессов. Такой бизнес-процесс называется SOA Governance.

Что такое SOA Governance?

SOA Governance (управление SOA) позволяет компании, использующей SOA, реализовать весь потенциал этого архитектурного подхода. SOA Governance позволяет решить проблемы, которые в противном случае могут помешать добиться гибкости и обеспечить преимущества, доступные при использовании SOA.

SOA Governance – это процесс управления жизненным циклом предприятия, построенного на основе SOA. SOA Governance – это также инфраструктура управления жизненным циклом SOA. Эффективное управление SOA - это не просто технология. Это подход к жизненному циклу, в котором участвуют все ответственные сотрудники организации, и учитываются различные активы организации.

Создание инфраструктуры управления SOA, предполагает решение ряда типовых задач:

• определение полномочий для принятия решений в среде SOA;
• создание необходимых сервисов;
• управление жизненным циклом сервисов;
• оценка эффективности использования сервисов.

Реализация подхода SOA Governance позволяет ответить на следующие вопросы:

• Кто определяет, какое из существующих направлений деятельности позволяет получить наиболее полные данные о заказчиках?
• Кто будет управлять общими службами? Кто будет их финансировать? Кто будет отвечать за их модернизацию?
• Как убедить все направления бизнеса использовать именно эти службы, а не свои собственные, которые могут казаться им более подходящими?
• Кто будет определять права доступа и частоту обращения к этим службам?

Создание высокоэффективных бизнес-сервисов

Архитектура, ориентированная на сервисы, позволяет включать многократно используемые сервисы в состав типовых наборов или исключать их из состава этих наборов в зависимости от требований, предъявляемых в каждом бизнес-подразделении или регионе.

Реализация подхода SOA Governance позволяет ответить на следующие вопросы:

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

Управление жизненным циклом сервисов

Эффективное управление SOA предполагает отказ от увеличения количества ненужных сервисов и создание механизма управления изменениями в многократно используемых сервисах. Этого можно достичь через реализацию соответствующих механизмов управления:

• Управление сервис-ориентированной архитектурой (SOA)
• Управление изменениями
• Управление вводом в эксплуатацию, использованием и выводом сервисов из эксплуатации
• Выявление и учет существующих сервисов, а также управление доступом к ним

Разработка и внедрение механизмов управления изменениями и учета специфики пользователей, позволяет отвечать на следующие вопросы:

• Как организовать сервисы и активы с общим доступом, чтобы в дальнейшем их можно было многократно использовать?
• Кому разрешается вносить изменения в сервисы, внедренные повторно другими пользователями?
• Кто использует данный сервис и какие процессы будут затронуты при внесении в него изменений?
• Кто должен одобрить внесение изменений?
• Кто должен обеспечить финансирование изменений, вносимых в интересах конкретных пользователей?

Оценка эффективности

Для оценки эффективности инфраструктуры, построенной на основе SOA, требуется разработка соглашения об уровне обслуживания (Service Level Agreement - SLA). Необходимо также внедрение средств мониторинга, позволяющих, среди прочего, проводить биллинг за использование сервисов для оценки экономического эффекта. Такие средства мониторинга, должны обеспечивать доступ к информации о степени загрузки сервисов и стоимости их использования.

Процесс SOA Governance

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

Процесс SOA Governance состоит из четырех этапов:

• Планирование – анализ потребностей в элементах SOA
• Согласование (определение) – проработка подхода к управлению SOA, согласование отдельных элементов SOA между собой
• Разработка (реализация) – разработка и ввод управления SOA в действие
• Функционирование (оценка) – мониторинг и оценка внедренных решений и управление ими.

Планирование инфраструктуры SOA

На этапе планирования анализируются потребности организации и выявляются области, в которых требуется более эффективное управление.

Основная часть планирования проводится специалистами, отвечающими как за развитие направлений бизнеса, так и за ИТ-инфраструктуру, и предполагает организацию их совместной работы. На этом этапе определяются проблемы согласования бизнеса и ИТ, требующие решения.

На этом этапе реализуются следующие мероприятия:

• Выделение в ИТ-стратегии компании направления, ориентированного на использование SOA.
• Определение необходимого уровня возможностей ИТ и SOA
• Формулирование и уточнение видения и стратегии развития SOA
• Изучение возможностей и проводимые мероприятия в области управления SOA.
• Разработка плана управления SOA.

Согласование и определение - проработка подхода к управлению SOA

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

На этапе определения принимаются различные решения в области управления SOA:

• Создание или реорганизация центра компетенции по SOA
• Определение необходимых процедур по реорганизации ИТ-инфраструктуры.
• Согласование политики многократного использования сервисов между различными направлениями бизнеса
• Создание механизма финансирования для стимулирования многократного использования сервисов.
• Разработка механизмов, обеспечивающих требуемый уровень обслуживания.

Разработка и реализация - ввод модели управления в действие

На этапе реализации решения по управлению SOA претворяются в жизнь. На этом этапе выполняются следующие работы:

• Внедрение механизма мониторинга системы принятия решений
• Создание инфраструктуры, поддерживающей разработанные политики управления
• Внедрение решений для выявления активов и управления ими
• Обучение сотрудников, отвечающих за принятие решений в области бизнеса и информационных технологий, необходимым методам работы и моделям поведения

Функционирование и оценка - мониторинг внедренных решений и управление ими

На этапе оценки осуществляется мониторинг методов и механизмов управления, выявленных на этапе определения и внедренных на этапе реализации.

Это позволяет оценить полученные результаты и запустить новый цикл из четырех этапов управления SOA для повышения эффективности управления. Как правило, на этом этапе выполняются следующие работы:

• Контроль выполнения разработанных политик и методов управления, таких как соглашения об уровне обслуживания, анализ уровня повторного использования и изменения политик
• Анализ показателей эффективности бизнес-архитектуры и ИТ-инфраструктуры.

Инструменты SOA Governance

Эффективное управление предприятия, построенного на основе SOA возможно только с использованием соответствующего инструментария.

Требования к инструментарию SOA Governance позволяют сформировать набор продуктов, отвечающий задачам управления SOA:

• Поддержка архитектурного подхода
• Поддержка элементов сервис-ориентированной архитектуры
• Поддержка процесса управления жизненным циклом сервис-ориентированной архитектуры

Поддержка архитектурного подхода

Инструмент SOA Governance должен обеспечивать поддержку текущей, целевой и планируемой архитектур предприятия. Архитектура предприятия должна содержать не только технический и информационный слои, но и бизнес-слой.

Поддержка элементов сервис-ориентированной архитектуры

Инструмент SOA Governance должен обеспечивать поддержку элементов сервис-ориентированной архитектуры. Наиболее важной является поддержка типов артефактов:

• Логический сервис (бизнес-сервис)
• Технический сервис (веб-сервис)
• Функциональный домен
• Функциональный модуль
• Техническая операция

Поддержка процесса управления жизненным циклом сервис-ориентированной архитектуры

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

Сегодня ни одна - даже очень крупная - компания не может обеспечить полноценную поддержку SOA Governance самостоятельно. Основной путь – это построение интегрированных решений на основе продуктов от независимых поставщиков. Такой путь позволяет использовать лучшие решения в каждом сегменте такого комплексного процесса как SOA Governance.

Ведущие поставщики программного обеспечения предлагают различные наборы инструментов, реализующих SOA Governance. Наиболее функционально полные решения предлагают компании IBM, Oracle, Software AG.

Пример реализации SOA Governance на основе Oracle Fusion Middleware и системы управления архитектурой предприятия Alfabet planningIT

Интегрированное решение на основе alfabet planningIT и Oracle Fusion Middleware позволяет предоставить сквозную услугу по управлению жизненным циклом ИТ-инфраструктуры на основе SOA. Благодаря взаимодействию Oracle Fusion Middleware и alfabet planningIT можно успешно проектировать, разрабатывать и внедрять сервис-ориентированную архитектуру (SOA).

Решение alfabet/Oracle обладает определенными преимуществами перед другими решениями SOA Governance:

• Наличие единого репозитария с поддержкой многоуровневой метамодели, обеспечивающей согласованное описание всей архитектуры предприятия в терминах SOA.
• Сквозная интеграция процесса стратегического планирования ИТ: от оценки бизнес-процессов, которые должны быть поддержаны со стороны ИТ, до мониторинга использования веб-сервисов.
• Сквозная интеграция управления SOA «сверху-вниз» и «снизу-вверх».
• Поддержка процесса совместного управления развитием ИТ с поддержкой большого количества ролевых групп.
• Планирование трансформации ИТ на основе непротиворечивых согласованных между собой планов миграции.
• Прозрачность при оценке ИТ-активов

Процессы, поддерживаемые интегрированным решением

• Реорганизация компании на основе сервис-ориентированной архитектуры.
• Построение целевых и планируемых архитектур предприятия в рамках перехода к SOA.
• Построение планов миграции к SOA.
• Определение сервисов, имеющих стратегическое значение для предприятия.
• Обеспечение миграции на сервис-ориентированную архитектуру.
• Оценка затрат на миграцию ИТ-инфрастурктуры к SOA.
• Управление жизненным циклом веб-сервисов на всех этапах (планирование, прототипирование, разработка, внедрение, исполнение, управление изменениями, оценка эффективности).

Функции, поддерживаемые интегрированным решением.

• Создание в planningIT описания технических сервисов (WSDL), соответствующих технической реализации логических сервисов, их экспорт в репозитарий Oracle.
• Генерация из planningIT проектов Java в Oracle IDE для реализации соответствующих технических сервисов.
• Импорт из Oracle в planningIT существующих технических сервисов для планирования бизнес-приложений и логических сервисов.
• Формирование в planningIT описания бизнес-приложений в терминологии SOA – как набора логических сервисов, реализованных в виде технических сервисов (веб-сервисов).
• Построение в planningIT упрощенных диаграмм процессов BPEL и их экспорт в Oracle.
• Импорт из Oracle BPEL Engine в planningIT статистики об использовании сервисов для целей централизованного планирования SOA.

Компоненты, используемые в интегрированном решении

Компоненты Oracle Fusion Middleware (FMW):

• Oracle Services Registry (UDDI) – центральный реестр сервисов
• BPEL PM & BPEL Designer (JDeveloper) – разработка и выполнение процессов на BPEL
• Датчики (sensors) – сбор и нформации о KPI процесса
• Web Services Manager – управление доступом к веб-сервисам

Компоненты alfabet planningIT:

• Logical Inventory – единый репозитарий на основе развитой метамодели
• Application Architecture Management – управление архитектурой приложений
• Enterprise Architecture Management – управление архитектурой предприятия

Стадия планирование

Система управления архитектурой предприятия и стратегического планирования ИТ Alfabet planningIT поддерживает планирование «сверху-вниз» с возможностью многослойного обзора ИТ-активов: бизнес-требования, бизнес-процессы, организационная структура, поддержка бизнеса со стороны ИТ, бизнес-приложения, сервисы. Это позволяет оценить насколько эффективно ИТ-инфраструктура обеспечивает поддержку бизнес-стратегии, стратегических целей, бизнес-процессов и т.п. Кроме того, становится возможным рассчитать стоимость изменений в ИТ-инфрастуктуре.

С помощью Oracle Fusion Middleware прозрачность планирования ИТ инфраструктуры расширяется для поддержки полного жизненного цикла ИТ-инфраструктуры на основе сервис-ориентированной архитектуры и обеспечения сквозного планирования и управления SOA.

Основным объектом интеграции alfabet planningIT и Oracle Fusion Middleware является объект «Сервис». В репозитарии alfabet planningIT существует артефакт «Технический сервис» (Technical Service), который корреспондирует с термином «Сервис» (Service) в SOA. Такой сервис может быть описан с использованием WSDL. Технический сервис в planningIT может быть создан или повторно использован для технической реализации логических сервисов. Логические сервисы в planningIT могут быть объединены в форме бизнес-приложений. Бизнес-приложение является артефактом репозитария, играющим ключевую роль в процессе планирования, управления, анализа затрат и т.п.

Продукты Oracle обеспечивают интегрированную поддержку проектирования, реализации и внедрения сервисов. Oracle Fusion Middleware реализует сервисную шину предприятия (ESB) и оркестровку сервисов (BPEL), а также предоставляет возможности мониторинга развернутых сервисов с помощью репозитария сервисов.

Система Alfabet planningIT также предоставляет инструментарий для оценки влияния изменений и проведения анализа затрат внедрения изменений. Oracle Fusion Middleware обеспечивает поддержку реализации, развертывания и выполнения сервисов, спланированных и прототипированных в planningIT.

Стадия согласование (определение)

Система alfabet planningIT является идеальным дополнением к Oracle FMW, поскольку она позволяет определить набор сервисов, имеющих стратегическое значение для предприятия. Сервисы могут быть легко оценены с точки зрения их места в архитектуре предприятия и могут быть спланированы в рамках единого процесса, прежде чем нужно будет приступать к их разработке и внедрению.

Использование planningIT для согласованного управления развитием бизнес и ИТ позволяет принимать управленческие решения о том, какие сервисы необходимо развивать, а какие - нет. Планирование уровня предприятия определяет, какие логические сервисы должны быть реализованы для обеспечения поддержки требований бизнеса.

Стадия разработка (реализация)

Для обеспечения технической реализации логических сервисов пользователи planningIT могут детализировать описание логических сервисов в терминах технических сервисов. При этом технические сервисы могут быть импортированы из репозитария веб-сервисов Oracle. Если же необходимого технического сервиса не существует, то описание такого сервиса может быть создано в planningIT и затем опубликовано в репозитарии Oracle (OraSR+WSM) со статусом «В стадии разработки». В то же время генерируется новый проект Java для реализации соответствующего технического сервиса.

Диаграмма процессов BPEL в Oracle соотносится с объектом бизнес-приложение (Business Application) в репозитарии planningIT. Бизнес-приложение в planningIT – это набор бизнес-сервисов, которые поддерживают бизнес деятельность – а не программный компонент. Таким образом, бизнес-приложение может быть описано в виде диаграммы BPEL, описывающей оркестровку технических сервисов.

Бизнес-приложение может быть экспортировано из planningIT в виде проекта BPEL в формате XML. Все технические сервисы, соответствующие бизнес-приложению, должны быть включены в проект в формате XML и экспортированы в репозитарий Oracle (OraSR+WSM). Диаграмма BPEL, разработанная в planningIT также может быть экспортирована для последующего использования в среде разработки Oracle (Oracle IDE).

Стадия функционирование (оценка)

После развертывания сервисов, служба мониторинга Oracle Fusion Middleware позволяет отслеживать статус, использование и влияние любых изменений на сервисы. Эта информация возвращается planningIT, чтобы обеспечить процесс централизованного планирования и управления актуальными и полными данными.

Сквозная интеграция alfabet planningIT с Oracle FMW означает, что предприятия теперь могут вести управление эволюцией элементов SOA и жизненным циклом сервисов на основе надежных и последовательных данных и визуальной информации.

Модуль «Управление архитектурой предприятия» planningIT может использоваться для передачи и агрегирования данных с уровня внедренных сервисов на уровень бизнес-планирования, где менеджеры осуществляют оценку рисков, затрат, доступности и качества ИТ-сервисов для важных бизнес-процессов и продуктов. planningIT может импортировать статистику об использовании сервисов из Oracle BPEL Engine. Эта информация может использоваться для централизованного планирования SOA.

Заключение

Сервис-ориентированная архитектура (SOA) – путь к решению многих проблем, стоящих перед современным предприятием. SOA позволяет обеспечить конкурентоспособность компании в высококонкурентной среде, характеризуемой необходимостью постоянных изменений в бизнесе. Организация, готовая построить у себя сервис-ориентированную архитектуру, рискует столкнуться с большим количеством проблем, связанных с управлением переходом к SOA, а также планированием, развертыванием и функционированием SOA. Эти проблемы решаются за счет внедрения методик и инструментов управления жизненным циклом SOA – SOA Governance.