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

Бизнес-процессы современного предприятия должны быть непрерывными и охватывать не только его собственную деятельность, но и взаимодействие с партнерами и клиентами — в этом случае можно реализовать и краткосрочные (рост доходов и сокращение затрат), и долгосрочные цели (создание гибкой инфраструктуры, позволяющей динамично изменять стратегию, цели, процессы и показатели эффективности деятельности). Достигнуть такой непрерывности сегодня обещает архитектура, ориентированная на сервисы, которая, с точки зрения ИТ, должна охватывать несколько уровней: взаимодействие людей между собой и с информационными системами; координацию и измерение эффективности бизнес-процессов; управление бизнес-логикой и прикладными сервисами и системами, в том числе и унаследованными; интеграцию данных и метаданных в масштабе всего предприятия. Согласно исследованиям Forrester, 67% предприятий и организаций намерены в ближайшее время реализовать сервисный подход к ИТ, а 44% из них считают задачу реализации SOA важнейшей. При этом один из наиболее реальных путей к решению задач интеграции, как отмечают авторы исследования, базируется на создании сервисной шины, через которую взаимодействуют слабо связанные компоненты [1].

Интеграционные решения сочетают механизмы управления бизнес-процессами, сервисами и сообщениями, обеспечения безопасности, администрирования и управления метаданными. Их предлагают и начинающие компании узкой специализации, например Cape Clear и PolarLake, и уже достаточно известные интеграторы корпоративных приложений (Iona, TIBCO, Vitria, webMethods, Sonic Software), а также поставщики платформ, включившие в линейки продуктов средства интеграции данных и приложений (BEA, IBM, Microsoft, Oracle, SAP, Sun Microsystems). В эту группу поставщиков средств интеграции входит и немецкая компания Software AG — разработчик СУБД Adabas, инструментальной среды Natural, технологий EntireX и ApplinX, недавно предложившая корпоративную платформу SOA — crossvision. В Software AG подчеркивают, что создать полноценное интеграционное решение удалось, прежде всего, благодаря опыту компании в области систем управления данными для мэйнфреймов и XML-технологий, а также платформ модернизации унаследованных компонентов.

Среди аналогичных продуктов платформу crossvision выделяют решения в области управления метаданными — в централизованный реестр и репозиторий метаданных crossvision CentraSite сводятся все описания бизнес-процессов и сервисов, структур и элементов данных, их семантики и правил использования. Единым ресурсом пользуются все компоненты платформы, что позволяет не только представить имеющиеся ИТ-активы и их компоненты в качестве многократно используемых сервисов, но и создавать гибкие бизнес-процессы, обеспечивая взаимосвязь и управление всеми инициативами, направленными на построение сервисной архитектуры компании [2].

 

Старт от бизнес-процессов

Термин Business Process Management (BPM) в зависимости от контекста может обозначать методологию совершенствования управления (процессный подход); инструменты, в том числе программные, проектирования и оптимизации деятельности; систему управления бизнес-процессами как элемент корпоративной архитектуры. Сам бизнес, его ИТ-инфраструктура быстро меняются, «размываются» границы подразделений и компаний, поэтому было бы естественно гармонизировать информационные ресурсы и системы, отталкиваясь прежде всего от бизнес-процессов. При таком подходе методы и инструменты процессного управления и сервисная архитектура взаимно пересекаются — если SOA ответственна за стандарты и механизмы среды взаимодействия между людьми и системами, в которой процессы возникают, совершенствуются и управляются, то BPM определяет цели, правила, содержание, структуру и критерии эффективности действий.

Компания Fujitsu Software почти десять лет назад выпустила продукт (нынешнее название — Interstage BPM) для поддержки среды моделирования и разработки сквозных бизнес-процессов, обеспечивающих взаимодействие людей и систем на основе функциональных моделей. В Interstage было сведено к минимуму программирование вручную, что, в частности, и заинтересовало Software AG, интегрировавшую его в свою платформу crossvision.

Рис. 1. BPM и SOA

В модели crossvision рассматривается пять уровней автоматизации бизнес-процессов (рис.1).

  1. Уровень основного потока работ соответствует взаимодействию между людьми. Бизнес-процесс — это упорядоченная и координированная последовательность действий, большая часть которых выполняется людьми. Моделирование бизнес-процессов выполняется при помощи компонента crossvision BPM.
  2. Уровень бизнес-правил. Когда процесс детализируется, появляются разветвленные бизнес-правила, согласно которым, например, на основании кредитной истории определяется «надежность» клиента, и от этого зависит характер дальнейшей обработки его запроса. Управляют правилами и обеспечивают их исполнение специальные «машины бизнес-правил» (Business Rules Engine). В качестве такого средства в crossvision BPM встраивается решение JRules от компании ILOG.
  3. Уровень сценариев и мини-процессов пользовательского интерфейса. Здесь при помощи компонента crossvision Application Composer конструируются композитные приложения — бизнес-процесс дробится и ветвится, а отдельные операции представляются экранными формами с определенной последовательностью действий, реализуемой Web-сервисами, и логикой управления.
  4. Уровень межсистемной интеграции для взаимодействия программных компонентов. Для доступа к сервисам может потребоваться адаптация и интеграция существующих и унаследованных систем для придания им свойств Web-сервисов. Эти задачи решаются с помощью компонента crossvision Service Integrator.
  5. Уровень интеграции данных. Здесь формируется единая семантическая модель предметной области деятельности компании. Типичная картина: информация разбросана по нескольким системам и базам данных, с ней работают специалисты разных департаментов, которые зачастую пользуются разной терминологией. За интеграцию данных отвечает компонент crossvision Information Integrator.

Жизненный цикл бизнес-процесса выглядит следующим образом: моделирование — макетирование — реализация — интеграция — управление — оптимизация.

Моделирование. crossvision BPM позволяет не только документировать деятельность, но и создавать исполняемую модель процессов, управляемую бизнес-правилами. Средства моделирования ориентированы на специалистов предметных областей и аналитиков, предоставляя возможность построить графическую модель бизнес-процессса, описать действия, ветвления, реакцию на отклонения, необходимые ресурсы, затраты, время выполнения и метрики эффективности. Действия связываются с соответствующими информационными системами, данными и сервисами. В качестве первоисточников для описания бизнес-процессов могут использоваться должностные инструкции и стандарты предприятия, а также результаты моделирования во внешних системах (например, в ARIS, BPWin, Visio и т.п.). Благодаря контролю последовательности и сроков исполнения задач, всегда можно определить, на какой стадии находится тот или иной процесс, а на случай отклонения от регламента предусмотреть специальные процедуры уведомления. Модели и описания бизнес-процессов позволяют создать основу для подготовки технического задания на информационную систему, реализующую регламенты заказчика, а при их уточнении или адаптации — сократить объем кодирования.

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

Реализация и управление средой BPM и SOA. Генерируемые в процессе разработки моделей компоненты описаний сервисов полностью соответствуют стандартам SOA и сохраняются в едином реестре сервисов и репозитории метаданных. Благодаря поддержке BPEL, LDAP, SOAP, XPDL и других стандартов. и наличию широкого спектра программных адаптеров, агентов для Web-сервисов, «слушателей» процессов (listener), триггеров и средств интеграции с машинами бизнес-правил и другими внешними программными компонентами достигается не только интероперабельность между бизнес-процессами, но и возможность формирования визуального представления о состоянии происходящих процессов. Все это обеспечивает согласование целей и бизнес-процессов компании с ее ИТ-инфраструктурой.

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

 

Сценарии работы

Иметь множество Web-сервисов и располагать технологиями, с помощью которых можно придать существующим системам свойства сервисов, еще недостаточно — успех внедрения BPM и SOA в немалой степени зависит и от того, насколько эффективны и гибки средства сборки многофункциональных композитных Web-приложений (Rich Internet Applications), разработки сценариев и интерфейсов взаимодействия для конечного пользователя. Эти задачи в crossvision возложены на компонент Application Composer (рис. 2).

Рис. 2. Архитектура crossvision. Реестр сервисов и репозиторий метаданных CentraSite объединяет все компоненты

Архитектурный шаблон обеспечивает гибкость композитного приложения путем разделения представления, бизнес-логики, обработки и использования общепринятых стандартов (BPEL, SOAP и др.). Приложение строится в соответствии с архитектурным шаблоном MVC (Model-View-Controller, модель-представление-контроллер), который был впервые предложен в объектно-ориентированном языке программирования Smalltalk, разработанном Xerox PARC еще в 70-е годы и оказавшемся исключительно продуктивным при создании современных Web-приложений.

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

Представление определяет стиль и внешний вид HTML-страниц, с которыми работает конечный пользователь. Страницы формируются в графической среде, располагающей библиотекой из 80 интерфейсных примитивов: меню, всплывающие списки, элементы управления и навигации, Google Maps и др. Современная технология AJAX обеспечивает богатые функциональные возможности и разнообразие внешнего вида страниц.

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

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

 

Сервисы: сборка и оркестровка

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

Оркестровщик сервисов crossvision Service Orchestrator выполняет функции сервисной шины и включает среду времени исполнения и Web-приложение, управляющее маршрутизацией сообщений и служебными порталами для приема и отправки документов по электронной почте, протоколам JMS, SOAP или HTTP. При помощи функций «посредничества» (mediation), технологий XML, Internet и различных шлюзов осуществляется бесшовная интеграция данных, поступающих из различных источников, в том числе из унаследованных систем обработки транзакций (CICS) и баз данных (DB2, Adabas).

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

Сервисы разрабатываются с помощью инструмента Orchestrator Studio, содержащего визуальный конструктор, редактор XML, отладчик и средство развертывания сервисов. Процедура обработки документа задается последовательностью управляющих инструкций на XML и ссылками на встроенные (их около 30) или собственные Java-компоненты функциональной обработки. Проекты сохраняются в реестре сервисов и репозитории метаданных CentraSite.

Web-приложение и среда времени исполнения Service Orchestrator могут устанавливаться на одном или нескольких компьютерах. Web-приложение включает в себя служебные порталы (HTTP, JMS, SOAP, планировщика задач, электронной почты), библиотеку компонентов, маршрутизатор сообщений и Web-интерфейс управления. Среда времени исполнения состоит из хост-менеджера (управление процессами и взаимодействие с порталами), фабрик компонентов (загрузка и выполнение фрагментов кода из Web-библиотек), инструмента разработчика Service Orchestrator Studio (создание последовательностей, правил и шаблонов обработки, отладка и развертывание сервисов), системного журнала и командных файлов администратора.

 

Адаптация к SOA

По данным американской интеграторской компании NEON Systems, в современном мире средствами CICS и IMS/TM, широко распространенных в 70-80 годы мониторов транзакций для мэйнфреймов, сегодня обрабатывается больше транзакций, чем во всей Сети. Кроме того, в информационных активах крупного бизнеса находится сейчас в боевом состоянии свыше 50 тыс. исходных модулей на Коболе, языке ассемблера и PL/I, причем некоторые из них написаны 30-40 лет назад и успешно применяются при обработке особо важных данных. При внедрении новых информационных технологий компании вынуждены считаться с данным наследием — расходы на поддержку унаследованных приложений составляют до 70-80% ИТ-бюджетов (см. Migrating Legacy to the Service-Oriented Architecture, www.clientsoft.com/shadow/whitepaperlibrary.asp). Затраты и риски, связанные с миграцией унаследованных приложений на платформы Linux/Unix и Windows, часто значительно превышают стоимость эксплуатации приложений в существующей среде. Естественно, что компании ищут способы «омоложения» своих информационных систем, и один из многообещающих подходов состоит в их адаптации к среде SOA.

Существует несколько способов придания системе прежних поколений свойств сервиса: применение готовых адаптеров к системам класса ERP, CRM или непосредственно к механизмам управления данными (IMS, CA IDMS, Adabas); построение для имеющегося программного кода сервисной оболочки; создание сервиса, имитирующего интерактивное взаимодействие пользователя. Выбор определяется конкретными требованиями и ограничениями реализации. Готовые адаптеры не решают проблемы полностью: до сих пор работают системы, созданные задолго до появления корпоративных решений, а при доступе к базам данных «в обход» логики приложения теряется функциональность. Поэтому наилучшим вариантом представляется повторное использование «оболочек» (wrapper) для программного кода: обеспечивается доступ к данным, и сохраняются функциональные возможности. В идеальном случае старая система в новой оболочке должна приобрести возможность активно взаимодействовать с современным внешним миром. Однако построить полноценную оболочку удается далеко не всегда: исходные тексты или программные интерфейсы могут быть недоступны или малопригодны. В таких случаях приходится прибегать к методу эмуляции терминала.

Располагая отлаженными технологиями адаптации систем как на уровне программного кода (EntireX), так и терминального доступа (ApplinX), разработчики Software AG объединили их в компоненте crossvision Legacy Integrator, добавив визуальные средства проектирования и взаимодействия с реестром сервисов и репозиторием метаданных (рис. 3).

Рис. 3. Адаптация унаследованных систем

При помощи визуального конструктора сервисных оболочек унаследованное приложение можно представить в виде стандартного Web-сервиса. Решается и обратная задача. В программу на языке Cobol, PL/I, RPG, Natural можно встроить обращения к Web-сервисам, как к обычным внешним подпрограммам, процедурам или функциям, не вдаваясь в тонкости XML-спецификаций. Благодаря такому «симметричному» механизму и наличию соответствующих мастеров и помощников сокращается необходимость программирования вручную.

Разработчик должен указать последовательность экранов, определяющих сценарий взаимодействия, и «разметить» экраны (поля данных, функциональные клавиши, граничные условия для обработки списков и т.д.). Чтобы представить в виде Web-сервиса взаимодействие с одним приложением, применяется средство «мгновенной» генерации Instant Web-service, а если необходимо объединить функции и данные нескольких приложений и других ресурсов, добавив функции управления и навигации, применяется конструктор Advanced Web-service. Параллельно обеспечивается не только генерация целевых Web-сервисов, но и соответствующих «клиентских» объектов (компонентов) для Java, C#, VB.NET, при помощи которых можно сразу же проверить, как работает созданный Web-сервис. Описания Web-сервисов на языке WSDL сохраняются в репозитории метаданных, а сами сервисы регистрируются в реестре CentraSite.

 

Семантика и данные

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

crossvision Information Integrator отвечает за интеграцию данных. В дополнение к имеющимся технологиям обработки запросов Adabas SQL Gateway и Tamino X-Node, репликации данных Adabas Event Replicator и Tamino Replication Service, выборки, трансформации и загрузки данных EntireX XML Adapters в платформе crossvision реализовано федеративное представление на основе семантической модели предметной области, позволяющее рассматривать в едином контексте в качестве информационных ресурсов не только базы данных, но и Web-сервисы, приложения, унаследованные системы и другие источники.

В Information Integrator рассматривается несколько представлений данных. На нижнем уровне располагаются источники (реляционные базы данных, базы на основе Adabas и Web-сервисы). На втором уровне представлены автоматически генерируемые по схемам баз данных или спецификациям WSDL онтологии источников, отражающие структуру локальных источников данных. В центре находится создаваемая «вручную» семантическая модель — бизнес-онтология, соответствующая концептуализации предметной области (рис. 4). Отображение онтологий источников на бизнес-онтологии с необходимыми преобразованиями строится архитекторами SOA (с участием экспертов по предметной области). На верхнем уровне определяются внешние представления бизнес-онтологий, соответствующие запросам конечных пользователей. Представленные в качестве Web-сервисов, они могут неоднократно использоваться порталами, композитными приложениями, бизнес-процессами и другими компонентами SOA.

Рис. 4. Семантическая модель и интеграция данных

crossvision Integrator Studio — инструмент архитектора интеграции данных. При помощи этого компонента выполняется импорт метаданных источников и «внешних» онтологий (спецификации на языках RDFS и OWL), строятся модели, задаются правила отображения и преобразования данных и конструируются запросы. Проектировщик пользуется визуальным редактором, но при необходимости может работать и со спецификациями на внутреннем языке логического программирования F-Logic. Запросы, определяющие внешние представления, регистрируются в качестве Web-сервисов и сохраняются вместе со всеми соответствующими артефактами SOA в реестре сервисов и репозитории метаданных CentraSite.

Сервер семантик SemanticServer обеспечивает обработку (логический вывод) конструкций языка F-Logic. При отладке и обработке запросов используются онтологии и другие артефакты SOA, хранящиеся в CentraSite.

 

Ядро платформы: управление метаданными

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

SOA обеспечивает возможность сборки и повторного использования сервисов из неоднородных компонентов, правда, присущая этой архитектуре гибкость при реализации крупномасштабных проектов может оказаться большой проблемой. Как только мы переходим от компактных пилотных проектов к решению реальных задач, приходится оперировать сотнями и тысячами сервисов, поддерживающих десятки и сотни бизнес-процессов. Как при этом определить, какие именно сервисы используются, доступны ли они и в какой версии? Какова структура, смысл и местоположение данных, к которым обращается сервис? В какой форме осуществляется взаимодействие с пользователем? Какие правила регламентируют выполнение процессов и какой должна быть реакция на отклонения? Ответить на эти и подобные вопросы, не имея централизованного ресурса описаний компонентов, весьма затруднительно, и именно это обстоятельство, по мнению аналитиков IDC, становится сегодня одним из главных препятствий на пути к SOA [3].

CentraSite — ядро платформы crossvision, разработанное в сотрудничестве с компанией Fujitsu на основе единой концепции процессной интеграции информационных систем. Этот ресурс базируется на SOA и открытых стандартах UDDI 3, WebDAV, XQuery и др. Он обслуживает компоненты Application Composer, Business Process Manager, Service Orchestrator, Information Integrator, Legacy Integrator и обеспечивает контроль и управление всеми элементами SOA (рис. 2).

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

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

Компоненты платформы crossvision взаимодействуют с CentraSite при помощи стандартных интерфейсов: UDDI 3 (абстракный API для реестра Web-сервисов); JAXR (Java API для реестров XML); XQJ (поисковый интерфейс XQuery для Java); WebDAV (защищенный высокоуровневый протокол доступа к объектам и коллекциям в сети), JMX (расширения Java для управления) и SMH (API шины управления). Специализированный API предусмотрен для экспорта и импорта метаданных.

Web-интерфейс, с помощью которого администраторы и пользователи обращаются к CentraSite, базируется на технологии создания пользовательского интерфейса AJAX, позволяющей по протоколу HTTP получать доступ к ресурсу метаданных, а средства визуализации и получения отчетов обеспечивают не только всесторонний анализ сведений об объектах и их взаимозависимостях, но и обратную трассировку внесенных изменений.

Для интеграции продуктов платформы и программ третьих фирм предусмотрены подключаемые модули среды Eclipse: браузер реестра, графический интерфейс бизнес-аналитики и средств подготовки отчетов Eclipse BIRT.

Средства безопасности взаимодействуют с корпоративными инфраструкрными компонентами, использующими протокол LDAP и Active Directory, и обеспечивают идентификацию и авторизацию полномочий групп и индивидуальных пользователей в соответствии с ролевыми моделями (списки управления доступом, Access Control List).

Модель данных и интерфейсы прикладного программирования CentraSite ориентированы на сквозную поддержку описаний компонентов системы на протяжении всего ее жизненного цикла — отношения между экземплярами объектов отражают «историю» их создания. Действия пользователей и их результаты записываются в системный журнал, для которого имеются средства просмотра и получения отчетов. При публикации компонентов, например, нового сервиса, старая его версия должна в течение какого-то времени сохраняться. Это особенно важно в условиях динамической распределенной схемы разработки решений для SOA.

Литература
  1. The Forrester Wave: Enterprise Service Bus, Q2 2006.
  2. Software AG Makes A Strong Initial Showing In ESBs, The Forrester Wave Vendor Summary, Q2 2006.
  3. Rogers Sandra, The Business of Managing Services, IDC 2006.

 

BPM и SOA: лучше вместе

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

Быстрая разработка схем бизнес-процессов. Графический конструктор бизнес-процессов должен быть рассчитан на аналитика прикладной области. На рис. приведен пример бизнес-процесса в графическом конструкторе crossvision.

Дизайнер бизнес-процессов в crossvision реализован в виде Java апплета, что позволяет редактировать схему процесса с любого рабочего места без установки на него специального программного обеспечения. С другой стороны, функциональные возможности апплета все же ограничены, поэтому в crossvision версии 8 появился графический редактор процессов, реализованный плагином к Eclipse. Его важное достоинство — поддержка импорта и экспорта из обоих распространенных на сегодня стандартов XPDL и BPEL.

Модель бизнес-процесса в графическом конструкторе crossvision BPM

Быстрая разработка интерфейса пользователя. В crossvision имеется две возможности: либо средствами самого BPM быстро сгенерировать простые HTML-формы, что по силам аналитику и используется для быстрого макетирования, либо воспользоваться AJAX4 BPM Framework, с помощью которого можно создать Web-интерфейс на основе AJAX, не написав ни единой строчки кода.

Быстрая интеграция с существующими приложениями, базами данных, Web-сервисами. Service Orchestrator представляет собой сервисную шину предприятия (Enterprise Service Bus) со множеством адаптеров, поддержкой BPEL, XSL-преобразований и другими функциями, а Legacy Integrator специально предназначен для интеграции унаследованных приложений, что, с опорой на CentraSite позволяет поддерживать порядок в разрабатываемых Web-сервисах.

Быстрый ввод в эксплуатацию. Пользователь взаимодействует с системой управления бизнес-процессами, разработанной при помощи crossvision, только через браузер, без плагинов и установки дополнительного программного обеспечения. Это важно, когда в работу нужно быстро включить множество сотрудников, зачастую разбросанных территориально, а то и предоставить доступ к системе бизнес-партнерам, при этом полный контроль над всей инфраструктурой BPM/SOA и удобство администрирования обеспечивает централизованный механизм управления и каталог метаданных CentraSite.

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

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

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

Другой типичный пример — финансовая сфера. То, что называется «банковским продуктом», например, новый вид кредита — это ни что иное, как уникальный бизнес-процесс, который проектируют банковские методологи. К сожалению, большинство отечественных банков не знают другого способа создания нового продукта, как написание инструкций в виде Word- документов: неполных, противоречивых и быстро устаревающих. Подход BPM позволяет банку мгновенно реагировать на требования рынка, разрабатывать процессы и быстро предлагать клиентам новые продукты. Аналогичная ситуация и со страховыми компаниями, где тоже стоит задача быстрого вывода на рынок новых продуктов.

Среди особенностей и недостатков crossvision, с которыми нам довелось столкнуться можно отметить следующие:

  • высокая производительность механизма исполнения, например, разбор XML-схемы выполняется однократно, результат сохраняется в базе данных, благодаря чему изменение атрибутов выполняется очень быстро;
  • система спроектирована в расчете на большие нагрузки и совместную работу большого числа пользователей, например, атрибуты процесса в обязательном порядке блокируются перед изменением;
  • инструмент разработки схемы бизнес-процесса автоматически генерирует HTML-страницу, однако при этом эта страничка размещается среди других таких же страниц, в том числе и от других процессов. При неаккуратной работе с именами файлов могут быть коллизии. Аналогичная ситуация наблюдается и при исполнении процесса, когда имеется возможность присоединить к процессу произвольные файлы, взятых из общего пула, и здесь также могут быть проблемы с именованием файлов;
  • crossvision BPM существует в двух версиях: Advanced на базе Apache Tomcat и Enterprise — полномасштабный J2EE сервер, что позволяет достаточно гибко решать задачи пилотного проекта. Сервер J2EE достаточно тяжел и не стоит тратить на него ресурсы, если нет необходимости использовать все его преимущества;
  • в инструменте разработки бизнес-процесса нельзя редактировать сгенерированную страницу — любые изменения возможны только путем ее удаления и новой генерации;
  • достаточно продуманный жизненный цикл (Draft-Public-Private-Obsolete) с поддержкой версий бизнес-процесса и возможностью синхронно и асинхронно запускать подпроцессы, на одном или разных серверах, координируя их выполнение. Любой существующий процесс можно запустить как подпроцесс.

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

Юрий Григорьев (yug@b-k.ru)— директор по разработке компании «Бизнес-Консоль» (Москва)