Корпорация Intalio была основана в 1999. Изначально, компания Intalio поставила задачу создать платформу, содействующую развитию корпоративных приложений и разработке бизнес-процессов следующего поколения. Именно по этой причине компания Intalio и начала разработку Системы управления бизнес-процессами (BPMS). Кроме того, было принято решение использовать совершенно новую модели для развития и продажи созданнного ПО – Open Source. Тогда в июле 1999, корпорация Intalio инициировала разработку решений, которые сегодня уже заслужили всеобщее признание, включая такие широко известные программные продукты, как Geronimo и ODE, система Slide и процессор Xalan.

Когда все только начиналось, каждая созданная строка программного кода, реализовывалась по крайне либеральной лицензии Apache License. Но эта лицензия предоставляла недостаточную защиту прав интеллектуальной собственности создателя кода (в сравнении, например, с Открытым лицензионным соглашением (GPL) или Lesser GPL (LPGL). Когда руководство компании увидело, что масштабное расходование средств венчурного капитала не приносит никакой отдачи, было решено отказаться от Open Source модели. Как оказалось, невозможно выстроить устойчивую бизнес-стратегию дальнейшего развития компании и при этом продолжать отдавать все наработки по лицензии Open Source.

После долгих попыток найти оптимальное решение в 2002 году компания Intalio, в конце концов, выбрала традиционную Корпоративную модель лицензирования программного обеспечения. За последующие два года, было продано двенадцать бессрочные лицензии, при этом затраты достигли огромной суммы (приблизительно 30 миллионов долларов). В таких условиях было решено вернуться Open Source.

В октябре 2005 года корпорация Intalio покупает компанию FiveSight Technologies, которая к тому времени уже разработала Open Source BPEL движок, а уже в первом квартале 2006 года возобновляет использование коммерческой лицензии Open Source (которая была названа COSMO). За последующие восемнадцать месяцев, компания подписала более 500 новых клиентов, расширила количество сотрудников с 15 до 50, и полностью переписала свой продукт, при этом потратив менее 5 миллионов долларов. Именно благодаря курсу, который был взят в 2005 году, корпорация Intalio продолжает приносить прибыль и сегодня. Тем не менее, было решено потратить больше средств на реорганизацию компании, чтобы обеспечить стабильный и динамичный рост.

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

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

Немного о структуре новой модели.

Во-первых, около 80% написанного кода лицензируется в соответствии с либеральной лицензией Open Source, например, Apache License или Eclipse Public License. Корпорация Intalio передает свой код организации Apache Software Foundation (ASF также передаются сопутствующие авторские права) или Eclipse Foundation. Благодаря Open Source лицензированию Open Source код может быть использован кем угодно, безо всяких ограничений. Таким образом, можно активно использовать уже существующих специалистов, способных намного эффективнее управлять Open Source проектами, чем создавать новых, менее опытных.

Во-вторых, было принято решение интегрировать Open Source компоненты компании Intalio с другими Open Source компонентами (в основном Apache), продолжить разработку (Apache ODE, Eclipse STP BPMN Modeler) и объединить это все в так называемую версию Community Edition. Это бесплатный продукт, но это не Open Source. Любой может скачать продукт совершенно бесплатно и использовать для разработки или производства. Особенность данной версии в том, что она доступна только в виде исходников. И для этого есть две причины:

1. Предоставление исходников, сертифицированных для ограниченного набора платформ (Linux и Windows для OS, MySQL для баз данных), облегчает поддержку пользователей. Кроме того, поддержка осуществляется бесплатно.
2. Так компания, располагающая значительными конкурентными преимуществами, может защитить свои права на интеллектуальную собственность (компоненты разработанного решения).

В настоящее время более 50000 компаний по всему миру используют версию Community Edition.

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

Особенности версии Enterprise Edition компании Intalio:

1. Enterprise Edition компании Intalio лицензируется по годовой подписке, а не по бессрочной лицензии, и поэтому приобретается за счет операционных затрат, нежели капитальных расходов. Для большинства корпоративных покупателей, приобретать программного обеспечения и оборудование за счет операционных расходов, намного проще, чем получать разрешение на использование инвестиционных денег.
2. Годовая подписка на Enterprise Edition стоит примерно столько же сколько и ежегодные затраты на обслуживание сопоставимых продуктов, производимых, например, компаниями Oracle или TIBCO.
3. Подписываясь на Enterprise Edition, клиенты получают доступ к 100% исходного кода продукта и право изменять его для внутреннего использования. При этом, клиенты не имеют права на повторное распространение исходного кода, но могут не предоставлять модификации кода компании Intalio. И это выгодно для обеих сторон.
4. Последний момент, возможно, является наиболее важным из всех для клиентов. Раньше только покупая продукцию у крупных поставщиков, можно было гарантировать ее долгосрочную функциональность и поддержку. К сожалению, это уже неактуально. Компании Siebel, PeopleSoft или BEA уже не существуют, и вместе с ними исчезло множество продуктов, которые они продали многим клиентам. Сегодня даже самые крупные компании могут быть приобретены фирмами с частным капиталом, а их продукция переработана или снята с производства. И существует только одно решение этой проблемы: доступ к исходному коду и сообществу, которое может осуществить гарантированную его поддержку.

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

Однако, одного доступа к исходному коду недостаточно для поддержания обратной связи с сообществом пользователей, именно поэтому появилась программа разработки, ориентированная на спрос (D3 – Demand Driven Development). Большинство Open Source проектов редко модифицируются их пользователями, а чем сложнее ПО, тем менее значительные модификации в него вносятся. Так, большая часть модификаций основного кода MySQL осуществлена сотрудниками MySQL AB (теперь Sun Microsystems). Другими словами, предоставление кода по лицензии Open Source не гарантирует получения модификационных изменений от внешних пользователей.

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

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

Реорганизация компании Intalio продолжается. Совершенствование навыков программирования и управления продуктом остаются важными составляющими этого процесса, но особого внимания заслуживают именно проблемы сбыта и маркетинга. Согласно исследованиям, проведенным компанией Goldman Sachs несколько лет назад, многие софтверные компании зарабатывают не на продаже лицензий на произведенное ПО, а на обслуживании и сопровождении своей продукции.

Сегодня корпорация Intalio предлагает:

· отдельные Open Source проекты,

· бесплатную версию Community Edition, содержащую только дистрибутив,

· коммерческую Enterprise Edition версию с полноценным исходным кодом.

Использование новой бизнес-модели позволило компании Intalio значительно сократить маркетинговые расходы. Например, ежемесячно компания тратит около 5000 долларов на Google Adwords, при этом получая более 2000 новых организаций-пользователей версии Community Edition. Кроме того, компания Intalio продает услуги по обучению и повышению квалификации по телефону и email (стоимость составляет 1500 за каждого стажера за двухдневный курс), и проводит телефонную подписку клиентов на версию Enterprise Edition. При этом все продажи осуществляются единым представителем службы продаж по телефону и стажерами (которые называются Process Experts). Компания Intalio является, пожалуй, первой софтверной компанией, которая более 500 действительных клиентов и не одного прямого продавца.

Сегодня корпорация Intalio имеет самую большую пользовательскую базу BPM вендоров и действительных клиентов и развивается быстрее, чем любая другая компания. Представительства компании находятся в США, Великобритании, Франции, Дании, Украине, Сингапуре, Индии, Китае, Японии, Австралии, Бразилии и Венесуэле. И это не предел.

Что же будет дальше? Система BPM 2.0. Корпорация Intalio продвигает систему BPM 2.0 уже более двух лет и пришло время ее обновить. Сейчас команда разработчиков Intalio трудится над созданием продукта под названием Intalio 6.0. Это будет первое воплощение готовой платформы на базе BPM 2.0 для разработки бизнес-процессов, включающее систему мониторинга бизнес-процессов (BAM), интегрированную с системами Alfresco и Liferay, модуль управления бизнес-правилами (BRE) на основе JBoss, совершенно новый графический редактор бизнес-процессов на основе Eclipse и инновационную архитектуру Rich Internet Application на основе TIBCO GI.

Исмаэль Халими (Ismael Ghalimi)

В одной из своих последних публикаций вице-президент Отдела Исследований и Разработок компании Fujitsu Computer Systems Corporation, Кит Свенсон (Keith Swenson), попытался объяснить, почему управление бизнес-процессами (BPM) не является программированием. И хотя с некоторыми аргументами, приведенными в своей статье Китом Свенсоном, можно безусловно согласиться, большая часть содержания статьи является крайне противоречивой. Согласно определению, данному Китом Свенсоном в статье, BPM – это система, в которой бизнес-аналитик создает диаграмму процесса, исполняемую без программирования. Но такая формулировка более чем ошибочна.

В своей статье Кит Свенсон также проводит аналогию между BPM и динамической таблицей, но это лишь упрощенное представление, которое никак не может являться серьезным аргументом. Также как системы BPM, редакторы динамических таблиц (например, Microsoft Excel) являются очень мощными компонентами программного обеспечения, и их использование в среде критически важных условий для обработки транзакций на самом деле требует грамотного программирования.

Изначально (в 1979), первый редактор динамических таблиц (VisiCalc, разработанный Дэном Бриклином (Dan Bricklin) и Бобом Френкстоном (Bob Frankston) задумывался как инструмент, благодаря которому не программисты могли разрабатывать финансовые модели и исполнять их на микро-компьютере. Тем не менее, эти динамические таблицы оставались ‘моделями’ и изначально не могли использоваться в контексте автоматизированной обработки транзакций. И хотя примитивные механизмы импорта-экспорта были разработаны редакторами динамических таблиц второго поколения (например, Lotus 1-2-3) и универсальными ЭВМ в 80-е годы, только 90-х гг. эти редакторы были интегрированы с оперативными системами обработки транзакций. Вся эта работа велась командой Excel под эгидой компании Microsoft, и благодаря существенной финансовой поддержке таких инвестиционных банков как Morgan Stanley. При этом превращение финансовой модели в процесс, исполняемый по шагам, требовало солидной доли программирования, как со стороны инженеров Microsoft, которые создали язык Visual Basic, чтобы поддерживать разработку сложных макросов, так и со стороны IT-специалистов компании Morgan Stanley, чтобы интегрировать такие макросы в различные системы внутренних офисов и систем управления очередями сообщений (MQSeries или Rendezvous).

Если следовать вышеуказанной аналогии, то получается, что Кит Свенсон рассматривает BPM как процесс, при котором бизнес-аналитики создают неисполнимые модели или модели, которые исполняются без интеграции с транзакционными системами. Но кроме того, BPM – это не просто Workflow, это Workflow плюс EAI (Интеграции корпоративных приложений), а компоненты EAI требуют грамотного программирования.

Вопреки мнению Кита Свенсона BPM предназначено не только для бизнес-аналитиков. Нет такого решения, системы или технологии, которые бы позволили бизнес-аналитикам создать процесс, нажать на кнопку и автоматически превратить диаграмму в исполняемый процесс, который будет поддерживать взаимодействия конечного пользователя и межсистемными трансакциями. Таких механизмов просто нет, и не будет. Бизнес-аналитики не хотят нести ответственность за создание и поддержку транзакционных систем или транзакционных процессов интегрированных в систему. Система BPM (2.0) предназначена как для бизнес-аналитиков, так и для программистов. Это способ преодолеть расхождения между бизнесом и IT, путем использования одного языка, одного набора инструментов, одинаково удобных как для бизнес-аналитиков, так и для программистов.

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

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

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

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

Исмаэль Халими (Ismael Ghalimi)

Во-первых, необходимо прояснить один аспект: никто и никогда не должен пытаться написать BPEL код вручную. BPEL – очень сложный язык, имеющий с широкие возможности, поэтому крайне сложно отыскать человека, способного написать подходящий BPEL код вручную. BPEL – очень точный язык. Изначально он задумывался как язык, который автоматически создавается генераторами кода. Другими словами, язык BPEL предназначен для компьютеров, а не людей.

Во-вторых, если все-таки возникла необходимость написать код вручную, важно использовать упрощенную версию BPEL, основанную на менее подборном синтаксисе. Компания Intalio как раз работает над созданием такого языка в рамках проекта Apache ODE. Он называется SimPEL.

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

Теперь время обратиться непосредственно к преимуществам языка BPEL.

BPEL выиграл войну стандартов

Несмотря на то, что сначала компания Intalio проиграла одну битву, когда язык BPEL вытеснил BPML, с выходом BPEL 2.0 (осуществленном при поддержке компании Intalio) война, в конце концов, была выиграна. Все основные вендоры, включая компании Microsoft, Oracle и SAP приняли BPEL 2.0, отказавшись от XPDL.

Нотации BPMN не достаточно

Многие из тех, кто пять лет назад боролся за XPDL, теперь настойчиво утверждают, что ни BPEL, ни XPDL на самом деле не играют важной роли, так как все определяет нотация BPMN. Более того, многие ошибочно полагают, что система BPM предназначена для бизнес-аналитиков, которым важно только, как выглядит процесс. Исполняемые процессы не могут быть созданы только с помощью нотации BPMN. BPMN диаграмма – это всего лишь фундамент. Чтобы процесс заработал, необходима надстройка. BPEL – это строительный материал для ее создания. Стоит выбрать неправильный компонент и получится неправильный строительный материал. Чего же не хватает нотации BPMN, чтобы описывать исполняемые процессы? Данных. Если BPM вендоры утверждают, что только нотация BPMN определяет ход всего процесса, то они попросту пытаются навязать ненужные и затратные мероприятия, утверждая, что создание полностью исполняемых процессов невозможно без разработки индивидуального пользовательского кода.

Язык BPEL построен по правильной математической модели

У любого BPM вендора есть три способа сделать процессы исполняемыми: использовать BPEL, XPDL, или свой собственный язык. При использовании BPEL применяется математическая модель Pi-Calculus, поддерживающая исполнение распределенных и совместных процессов. Модель Petrinet model, которая поддерживает исполнение отдельных процессов, предоставляет ряд преимуществ при использовании XPDL. При использовании собственного языка или модели исполнения, процесс полностью лишен любых существенных математических обоснований, и долго не просуществует. Модели Petrinet подходят для исполнения отдельных процессов, но не могут быть использованы для моделирования исполнения независимых процессов, которые должны исполняться параллельно и синхронизироваться друг с другом. Другими словами, такие модели могут быть использованы для создания отдельных workflow-систем, которые не будут объединяться с другими приложениями или взаимодействовать со многими другими workflow-системами. Все эти интеграции и взаимодействия можно закодировать вручную, но это уже не BPM (по крайней мере, не система BPM 2.0), а традиционная интеграция корпоративных приложений (EAI).

BPEL поддерживает распредёленные транзакции

Благодаря такому явлению как Scope, язык BPEL 2.0 поддерживает распредёленные транзакции, которые исполняются с помощью испытанных двухфазных протоколов фиксации. Ни XPDL, ни любая другая традиционная модель исполнения процесса не поддерживает распредёленные транзакции, что не позволяет использовать их для широкого спектра корпоративных приложений. Распредёленные транзакции также можно закодировать внутри таких программных компонентов как Enterprise Java Beans, но это не BPM (по крайней мере, не система BPM 2.0), а традиционная онлайновая обработка транзакций (OLTP).

BPEL – это стандарт

Выиграв войну стандартов, BPEL стал отраслевым стандартом. А стандарты играют важную роль в построении любых систем. То же самое верно и для системы BPMS. Только если система BPMS построена на основе языка BPEL, процесс, созданный с помощью ее инструментария, может работать на движках других вендоров.

Исполняемых нотаций BPMN не существует

Многие противники BPEL утверждают, что нотация BPMN – это все, что нужно для работы системы, а в скором времени появятся и исполняемые нотации BPMN. На самом деле исполняемых нотаций BPMN не существует. И даже если кто-то и разработает что-нибудь подобное, то он попросту заново изобретет BPEL 2.0, или что-то очень похожее. Другими словами, сочетание BPMN и BPEL – это все, что необходимо для того, чтобы сделать процесс исполняемым, но стоит их разъединить и вся система рухнет.

Исмаэль Халими (Ismael Ghalimi)

За последние три года корпорация Intalio разработала Коммерческую Open Source модель (Commercial Open Source Model – COSMO), которая позволяет клиентам и пользователям воспользоваться преимуществами традиционной Open Source модели (определенными OSI). COSMO предоставляет вендорам надежную и эффективную бизнес-модель, в основе которой лежит получение дохода от продажи лицензий. Следующие рекомендации призваны улучшить представление о данной модели и продемонстрировать ее преимущества и потенциальным клиентам, и вендорам.

Многоуровневая структура

Как показывает многолетняя практика, ни одной софтверной компании ранее не удавалось получить той совокупной прибыли, какую сегодня могут получать традиционные софтверные компании за продолжительный период (более пяти лет), благодаря продаже 100% кода по лицензии, одобренной OSI. Многоуровневая структура позволяет предоставлять ряд параметров решения бесплатно и/или по лицензии Open Source, а полноценное решение может быть использовано только в рамках коммерческого соглашения с вендором.

Двухуровневая или трехуровневая структура

Двухуровневая модель:

• Версия Open Source реализуется по вирусной лицензии (General Public License – Универсальная общественная лицензия, Lesser General Public License – Стандартная общественная лицензия ограниченного применения, или другие лицензии подобного типа);
• Коммерческая версия реализуется в рамках традиционного лицензионного соглашения с конечным пользователем (двойное лицензирование), предоставляя дополнительные характеристики и услуги версии Open Source.

Трехуровневая модель (на примере корпорации Intalio):

• Версия Open Source реализуется по либеральной лицензии (Лицензия Apache, Дистрибутив программ Беркли – Berkeley Software Distribution или Лицензия Массачусетского технологического института – Massachusetts Institute of Technology License и т.д.) и охватывает 80% всей кодовой базы решения;
• Общественная версия предоставляется бесплатно (для разработки и производства), с или без исходного кода;
• Коммерческая версия (называемая в корпорации Intalio корпоративной) реализуется в рамках лицензионного соглашения с конечным пользователем, предоставляет клиенту доступ к полному исходному коду и дает право его модифицировать, не предоставляя модифицированный вариант производителю.

Платформа Open Source

В случае с двухуровневой или трехуровневой моделями более 80% всей кодовой базы предоставляется по простой лицензии Open Source, по определению организации Open Source Initiative. При использовании трехуровневой модели, версия среднего уровня (Общественная версия) может быть предоставлена в рамках лицензии Open Source, но, тем не менее, должна предоставляться бесплатно для разработки и производственного применения.

Доступность исходного кода

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

Лицензирование по подписке

В отличие от традиционного программного обеспечения, реализуемого по бессрочным лицензиям и годовым контрактам на обслуживание, коммерческая модель COSMO основана на годовых подписках, включающих и лицензии на решения коммерческой версии, и поддержку. Поддержка обычно включает обновления, доступ к улучшенной документации, техническую поддержку клиента и т.д. В результате, решение, купленное по лицензии COSMO, приобретается за счет бюджета на целевые расходы (Operating Expenses Budget – OPEX), а не прямых капиталовложений (Capital Operating Expenses – CAPEX).

Публикуется список терминов и выражений встречабщихся в литературе по BPM. Он будет постоянно пополняться и совершенствоваться.

1. compliance specification for BPMN – спецификация \ стандарт соответствия для BPMN

2. flow patterns – структура \ характер исполнения процесса

3. interchange format for BPMN diagrams – формат обмена для BPMN-диаграмм

4. native BPMN engine – встроенный модуль управления BPMN процессами

5. default execution model for executable BPMN processes –

6. executable BPMN specification – исполняемая спецификация BPMN

7. formal semantics –

8. analysis of control flow – анализ потока \ набора команд

9. formal validation techniques –

10. edition layering –

11. subset of the product – ряд параметров продукта \ решения

12. transactional workflow system – workflow системы пошагового исполнения

13. transaction processing –

14. spreadsheet – электронная таблица

15. spreadsheet editors – редактор электронных таблиц

16. mission-critical environment –

17. real-time transaction processing systems – системы управления трансакциями в режиме реального времени \ оперативные системы управления трансакциями

18. transactionally executable – исполняемый по шагам

19. user workflow tasks –

20. verbose language – подробный язык

21. visual BPEL editor – визуальный BPEL редактор

22. core process engine –

23. proprietary process execution language –

24. custom code development – разработка пользовательского кода

25. execution of collaborative processes – исполнение одновременных процессов

26. distributed transactions – распределенные трансакции

27. commit protocol – протокол фиксации

28. arcane specification –

29. enterprise service bus –

30. meta-data repository –

31. business rule engine – модуль управления бизнес-правилами

32. collection of connectors to packaged application –

33. flowchart diagramming tools –

34. interpreting BPEL code natively – встроенный интерпретатор BPEL кода

35. document-centric workflow processes – workflow процесс, ориентированный на работу с документами

36. design workflow user interfaces –

37. proprietary scripting languages –

38. execution of human workflow tasks –

39. runtime environment – условия выполнения \ оперативные средства \ среда выполнения

40. one-time connectors – разовые коннекторы

41. concurrent process instances –

42. component for persistence of process data –

43. enterprise process – процессом масштаба предприятия

44. end-to-end process – сквозной процесс

45. «round-trip» – замкнутый цикл разработки

46. workflow – потоков работ

47. round – trip engineering – циклическую разработку

48. Orchestration Director Engine (ODE) – модуль оркестровки сервисов

49. legacy workflow products – традиционные workflow-решения \ продукты

50. writing deployment descriptor files – написание файлов-дескрипторов

51. native process simulation – встроенный имитатор процесса

52. native rule engine – встроенный модуль управления бизнес-правилами

53. community-led contributions –

54. Demand Driven Development program –

55. contributors –

56. reusable process interfaces –

57. externalized business rules –

58. late-stage binding –

59. instance-level exception handling –

60. ad hoc process simulator – специальные имитатор процесса

61. business-level key performance indicator –

62. system level performance metrics –

На сегодняшний день существует ряд аспектов, которые мешают BPMN стать подлинным стандартом. Во-первых, как определил Брюс Силвер (Bruce Silver) семантика BPMN запутана и неясна, и поэтому требует разъяснений, особенно принимая во внимание элементы спецификации, которые должны отвечать за создание исполняемых процессов. Во-вторых, отсутствие стандартного формата обмена для BPMN диаграмм, который бы позволил использовать диаграмму, созданную одним инструментом, в среде других. В-третьих, если платформа BPMN используется как всеохватывающая архитектура для описания исполняемых процессов, все «аннотации» к спецификациям, с помощью которых красивую картинку можно превратить в исполняемый процесс, также должны также быть стандартизированы, как способ упорядочить (перевести в текст) все эти аннотации.

В определенном смысле вышеупомянутые аспекты связаны с мнением о важности «встроенных BPMN механизмов», которое последнее время активно поддерживается вендорами. И хотя это мнение хорошо выглядит в теории, на практике оно совершенно игнорирует тот факт, что BPMN охватывает только одно измерение процесса – процедуру исполнения. А вот другое очень важное измерение – информацию – недооценивают. Ряд вопросов остаются без ответов: как информация проходит через весь процесс, как она переходит от одного процесса к другому, как она отвечает за исполнение бизнес-правил и т. д. Но добавить это информационное измерение к платформе BPMN, значит заново  изобрести то, что называется BPEL. Поэтому, эффективнее использовать именно BPEL в качестве стандартной модели для исполняемых BPMN-процессов?

Разработанную таким образом систему стандартизации Брюс Силвер (Bruce Silver) и Девид Френч (David French) называют «стандартом соответствия BPMN,» а Исмаэль Халими (Ismael Ghalimi) именует ее «исполняемой спецификацией BPMN.» Эта система стандартизации в точности описывает все элементы, атрибуты и потоки, которые должны быть переведены на язык BPEL для того, чтобы обеспечить тщательное исполнение процесса. При работе с элементами, используемыми только для документирования процесса, спецификация должна точно описывать, какой BPEL-код для каких элементов, атрибутов и структур потока нужно сгенерировать. При таком подходе необходима тщательная и надежная формальная поддержка, например, в виде использования результатов последних научных докладов, чтобы обеспечить формальную семантику и анализ логики,  управляющей процессом исполнения.

Параллельно с этим процессом необходимо работать над форматом упорядочивания стандартов для BPMN. Этот формат должен основываться на XML, четко отражать структуру BPMN графа, и быть достаточно открытым, чтобы вендоры могли вносить необходимые изменения (различные шрифты, цвета, иконы и т.д.). Но особую сложность представляет необходимость создания двух форматов упорядочивания: один для неисполняемых BPMN-процессов, а другой – для исполняемых. При этом первый должен быть элемент последнего. Формат упорядочивания неисполняемых BPMN-процессов может быть разработан на прямую, и иметь четкую структуру исполнения. Для этого необходимо провести тщательный анализ текущей BPMN-спецификации и организовать переговоры между вендарами, во время которых удастся определить тот инструментарий, с помощью которого спецификацию можно будет расширить, чтобы обеспечить поддержку внесенных изменений. Формат упорядочивания исполняемых BPMN-процессов не только предполагает выполнение первой спецификации (для неисполняемых BPMN-процессов), но и исполняемой спецификацией BPMN. Таким образом, получается единая спецификация.

Рекомендации:

Тщательно определить все компоненты уравнения

Если основная задача состоит в определении спецификации исполняемых BPMN-процессов, то для начала важно определить, что означает само понятие «исполняемый». Сделать это можно, выбрав язык исполнения из тех, что уже существуют. На сегодняшний день BPEL самый полный, самый точный и самый широко поддерживаемый язык, поэтому его следует рассматривать как самый подходящий вариант. Более того, если BPEL является языком исполнения по умолчанию, о других языках можно не беспокоиться. Как только происходит добавления других языков (например, XPDL), проект автоматически продолжает работать, необходимо только определить допустимый уровень абстракций. Чтобы решить данное уравнение важно определить все его компоненты, BPMN – с одной стороны и BPEL – с другой. Решение данного уравнения позволяет организовать весь процесс, внося изменения, можно проследить, подходит ли система для работы с другими целевыми моделями исполнения (например, XPDL).

Не уделять много внимания двустороннему перемещению объектов между BPMN и BPEL

Двустороннее перемещение объектов может оказаться бесполезным действием, если пытаться организовать его между двумя языками или нотациями, которые существенно отличаются друг от друга семантически, например, в случае с BPMN и любым другим языком исполнения процесса, оптимизированным для компьютера (например, BPEL). То же самое можно сказать и о UML и Java. Двустороннее перемещение объектов может быть основополагающей задачей только в случае, когда два языка или нотации представляют в сущности одно и то же, например, нотация BPMN и ее производные Значит, должен существовать способ, с помощью которого можно с одной стороны полностью упорядочить BPMN графы, а с другой – графически отобразить упорядоченные нотации BPMN. И этот процесс должен задаваться и прогнозироваться равномерно по всему инструментарию.

Неважно, что BPEL-код выглядит «некрасиво»

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

При необходимости улучшать BPEL

Многие специалисты отмечают, что структура BPMN-процесса не может быть переведена в BPEL язык. В некоторых случаях в этом вовсе нет смысла, так как BPMN граф выполнен неправильно. Грамотно построенный механизм моделирования BPMN процесса должен обнаружить ошибочные или неполноценные графы и предупредить бизнес-аналитика о том, что, несмотря на свою замысловатую и красивую форму, этот граф совершенно бесполезен. В других случаях BPMN граф попросту представляет процесс, который не может быть исполнен ни одной IT-системой и создавать BPEL-код нет никакой необходимости. Хотя бывают случаи, когда BPMN граф может быть переведен в BPEL, но получившийся BPEL-код будет «некрасивым». Тогда бизнес-аналитики могут немного изменить BPMN граф, чтобы генерация BPEL-кода была «чище».  Грамотно построенный механизм моделирования BPMN процесса должен обнаружить такие неточности и подсказать, как можно улучшить и BPMN граф, и получившийся BPEL-код. Кроме того, иногда BPEL язык просто не может представить некоторые BPMN-структуры. В таких ситуациях необходимо отметить данное ограничивающее условие и отправить его авторам BPEL спецификации, которые, в свою очередь, могут учесть данную особенность при сознании последующих версий BPEL. При этом найденный неисполняемый шаблон будет добавлен в раздел неисполняемых BPMN-процессов, и отмечен как «еще неисполняемый».

Теперь возникает закономерный вопрос, какого рода организация будет заниматься стандартизацией? Будет это уже существующая организация или необходимо создать новую? Основная проблема состоит в том, что для создания исполняемой BPMN-модели, необходимо преодолеть расхождения между двумя спецификациями, которые принадлежать двум различным компаниям: BPMN принадлежит компании OMG, а BPEL – компании OASIS. Кроме того, это слияние должно проходить отдельно от взаимодействия с другими спецификациями, интеграция с которыми приведет к провалу. Так была создана организация BPMLab. Это группа экспертов, занимающаяся совершенствованием исполняемых BPMN-процессов путем разработки соответствующих стандартов и поддержки активного взаимодействия между BPMN и BPEL.

Исмаэль Халими (Ismael Ghalimi)

]]> http://bpmlab.ru/%d1%81%d0%be%d0%b7%d0%b4%d0%b0%d0%bd%d0%b8%d0%b5-bpmlab/feed/ 0 http://bpmlab.ru/%d1%81%d0%b8%d1%81%d1%82%d0%b5%d0%bc%d1%8b-bpm-20/ http://bpmlab.ru/%d1%81%d0%b8%d1%81%d1%82%d0%b5%d0%bc%d1%8b-bpm-20/#comments Tue, 23 Dec 2008 01:03:00 +0000 Ivan Adutskevich http://bpmlab.ru/?p=66 Первый подробный доклад по системе BPM был написан 8 лет назад. Эта публикация, специально приготовленная к семинару, помогла не только определить понятие и особенности системы, но и дала толчок возникновению новой отрасли. Тогда акроним, состоящий из трех букв и заимствованный у музыкантов, мгновенно стал сенсацией. И такого успеха не мог ожидать никто.

Сегодня это буквосочетание описывает все, начиная с существовавших workflow решений и заканчивая модулем управления бизнес-правилами, инструментарием для построения блок-схем, генераторами Java-кодов, или даже консалтинговыми услугами по модернизации бизнес процессов. Эта неразбериха, одинаково активно поддерживалась и производителями ПО, и ИКТ аналитиками, так как позволяет и тем и другим свободно продавать свои услуги окончательно запутавшимся пользователям:

Клиенты, с которыми доводилось общаться, в один голос заявляют о том, что нужны перемены. Они уже испробовали первую версию системы BPM, разочаровались, и теперь хотят получить нечто большее это система BPM 2.0. Этот термин изначально был придуман Брюсом Силвером (Bruce Silver). Определение BPM 2.0, оказалось довольно радикальным. Оно не оставляет никаких загадок или неточностей, а значит, что у производителей нет никаких шансов нажиться на этом. Но знаете что? Лучше сделать пользователей счастливыми, чем думать о благополучии производителей. Итак, знакомьтесь – система BPM 2.0!

Используется инженерами

Для начала необходимо развеять самое большое заблуждение, связанное с системой BPM: бизнес-аналитики могут использовать BPM инструментарий для моделирования и публикации исполняемых бизнес-процессов. И даже говоря об элементарном документ-ориентированном workflow процессе, когда бизнес-аналитик определяет, какие пресс-релизы будут печататься на сайте, его компетенция заканчивается там, где начинаются любые трансакции с внутренним корпоративным порталом. Во-первых, ни один программист никогда не позволит бизнес-аналитику копаться в корпоративной ERP (Планирование ресурсов предприятий) системе; во-вторых, ни один бизнес-аналитик не хочет просыпаться посреди ночи от звонка генерального директора, если вышеупомянутая ERP система выйдет из строя. Вывод прост: система BPM 2.0 не предназначена для бизнес-аналитиков без технического образования. Напротив, система BPM 2.0 предназначена для инженеров, которые достаточно подкованы, чтобы свободно общаться с бизнес-аудиторией и могут без труда отличить цикл do-while от выражения for-each. Создатели системы BPM 2.0 не стремятся внушить бизнес-аналитикам, что пришло время избавиться от IT-специалистов. Наоборот, наша задача подтолкнуть инженеров-программистов к пониманию требований бизнеса и применению их на практике, тем самым совершенствуя существующие IT-системы.

В основе полнофункциональная платформа BPMS

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

Инструментарий в среде Eclipse

Не так давно для того, чтобы превратить карту процесса в опубликованный код требовалось как минимум 7 инструментов: первый – для моделирования процесса на уровне бизнеса, другой – для описания технических деталей, третий – для построения коннекторов с внешними системами, четвертый – для переноса данных туда-сюда, пятый – для определения бизнес-правил, шестой – для создания потока работ пользовательских интерфейсовa, и седьмой – для публикации всех кодов как совокупности компонентов патентованной среды выполнения. Использование этих инструментов требовало разностороннего опыта, протекало в различных условиях, использовало различные языки, а переход от одного инструмента к другому сопровождался потерей информации. Таким образом, весь процесс становился крайне сложным. Ни один пользователь не мог работать с системой без помощи крайне дорогих консалтинговых услуг софтверного вендора, который просто собирал кусочки воедино, а не строил все с нуля, опираясь на четкую архитектуру. Система BPM 2.0 создает весь процесс с помощью одного инструмента, и этот инструмент сформирован в среде Eclipse. Сегодня Oracle и SAP уже поддерживают Eclipse, поэтому позаботьтесь о том, чтобы ваша система BPM 2.0 работала в среде Eclipse.

Активно используется ABAP, PHP и VB программистами

Продукты BPM-системы первого поколения требовали хорошего знания J2EE, или что ещё хуже, патентованных языков описания. И хотя этот язык очень удобен для вендоров ПО, он состоит из сложного набора спецификаций, которые оказываются совершенно непонятными большинству IT-специалистов. Объект-ориентированное программирование – это мощный инструмент, но большинство программистов его не понимают, предпочитая не иметь с ним дела, и отдавая предпочтение чему-нибудь попроще, например, PHP или Visual Basic. И хотя в мире насчитывается 2 миллиона программистов, но лишь незначительная часть из них способна написать EJB компоненты. Еще меньшее количество из них знает, как сочетать спецификацию EJB со стандартом JMS, Servlets и Message-Driven Beans. Сравните их с 3 миллионами PHP кодировщиков и 8 миллионами VB разработчиков, и картина станет ясной. Система BPM 2.0 не для J2EE гуру или, по крайней мере, не только для них. Система BPM 2.0 нацелена на инженеров, которые могут прочитать BPMN диаграмму, понимают язык XML Schema, представленный в виде дерева, переносить и принимать компоненты графических интерфейсах пользователя. Если вы уверены, что можете все это сделать без труда, тогда система BPM 2.0 именно то, что нужно.

BPEL

Раньше не существовало единого стандарта для исполняемых процессов. Язык XLANG был элементом планшета, WSFL еще не существовал, и workflow-специалистам приходилось изобретать комплексы совершенно бесполезных интерфейсов. После того как компания BPMI.org выпустила спецификацию BPML, компаниям Microsoft и IBM пришлось отказаться от XLANG и WSFL соответственно. По политическим причинам компании Microsoft и IBM решили написать свои собственные спецификации, вместо того, чтобы использовать BPML. Так появился WS-BPEL, а год спустя была выпущена в производство первая коммерческая версия спецификации BPML. После трех лет сухих обсуждений, компания BPMI.org объединилась с OMG и отказалась от разработки BPML в пользу BPEL. Тем не менее, важно отметить, что на протяжении последних шести лет не было реального стандарта, что значительно замедлило освоение BPM-системы. Сегодня все изменилось. Спецификация BPEL победила. BPEL 2.0 – это самый подходящий вариант для пользователей, желающих построить процессы, ориентированные на результат, и все крупные вендоры его приняли. Система BPM 2.0 работает на основе BPEL, также как реляционные базы данных функционируют на основе SQL. Инженерам не нужно об этом беспокоиться, ведь если они выбрать подходящий инструмент, нет необходимости писать однолинейный BPEL код. BPEL спецификация – это ядро процесса, вокруг которого все и строится. Если кто-то утверждает, что наличие BPEL не является обязательным или что решение, которое вы собираетесь купить будет поддерживать BPEL в следующем году, вас обманывают. Вас пытаются втянуть в покупку очень дорогого патентованного ПО, от которого придется избавиться уже очень скоро.

BPMN

Что касается языка исполнения процесса, то раньше BPM решения использовали множество различных нотаций. Некоторые были сосредоточены на компонентах workflow, например, HIM; другие были более техническими, например, UML Activity Diagrams. Однако, большинство из них были патентованными, незавершенными и несовместимыми друг с другом. И тогда компания BPMI.org решила это исправить, но в этот раз с учетом прошлых ошибок и, убедившись, что компания IBM не разрабатывает ничего подобного. Так Стивен Уаит (Stephen White) совершил чудо и разработал платформу BPMN, которая вскоре стала стандартной нотацией для моделирования исполняемых бизнес-процессов. BPMN поддерживает оркестрирование web-сервиса, выполнение workflow, руководит многочисленными бизнес-процессами с помощью плавающих дорожек (swimlane). Система BPM 2.0 работает, благодаря тому, что переход с BPMN на BPEL можно произвести без переписывания кода. Тем не менее, платформа BPMN не совершенна и может позаимствовать некоторые уловки у HIM, но тот факт, что система поддерживает компенсирующие трансакции, спонтанные события, сложные циклы и множество плавающих дорожек, делает ее уникальной, эффективной и незаменимой.

BPMN Дизайнер

Ранние BPM решения, которые поддерживали спецификацию BPEL, предоставляли BPEL редактору только начальный инструмент для разработки, а не реальный полноценный инструментарий для дизайна бизнес-процессов. Проблема в том, что у BPEL очень сложная спецификация, особенно с точки зрения управления данными. Более того, спецификация BPEL очень сильно зависит от сложности спецификации web-услуг и требует, чтобы разработчик вручную синхронизировал многочисленные BPEL и WSDL файлы, чтобы развернуть непрерывный процесс. Для BPEL редакторов это оказалось непросто. Они также разработали модели процесса, которые имели достаточно высокую степень детализации, чтобы быть продемонстрированными широкой бизнес аудитории. Необходима нотация высокого уровня, называемая BPMN, а система BPM 2.0 должна располагать всеми преимуществами этого стандарта, чтобы предложить потребителям именно ту эффективность, которой они хотят добиться от BPM проектов.

Отсутствие кода

BPMN и BPEL стандарты – это очень мощное сочетание, которое позволяет организовать .весь процесс от картинки до кода без, собственно говоря, написания кода. На создание этих спецификаций было потрачено много сил, и это работа была вознаграждена накопленным количеством комплексных навыков, которых нет ни у одного вендора. Это означает, что большинство BPM решений, основанных на патентованных нотациях и языках исполнения, требуют написания кода, чтобы организовать исполняемый процесс. Двойной клик по аккуратным окнам и стрелочкам, и появляется Java-код или код на любом другом языке программирования. В самом коде нет ничего плохого, но так уж вышло, что написание и поддержание кода оказывается куда более сложным, чем его полное отсутствие. Благодаря системе BPM 2.0 можно выстраивать самые сложные процессы без всякого кода. Например, голландское правительство применяет эту систему для процесса, состоящего из 250 000 активностей. Значит, если система работает в таком масштабе, то она с легкостью сможет работать и в любых других условиях.

Публикация по одному клику

По своей природе бизнес-процессы способны изменяться, а система BPM обещает упростить процесс осуществления изменений. Все это звучит многообещающе, но если разработчику приходится писать множество дескрипторов публикаций и конфигурировать различные интерфейсы web-сервисов, чтобы опубликовать процесс, о легких изменениях остается только мечтать. Для решения этой проблемы, система BPM 2.0 предлагает радикальный метод ‘Публикация по одному клику’. После того, как процесс проверен, все данные отображены, бизнес правила определены, в параметры workflow установлены, стоит просто кликнуть на клавишу и процесс будет опубликован в среде выполнения процесса без дополнительных усилий. Все проще простого.

Генерирует Web-сервисы налету

Большинство BPM решений это замаскированные системы workflow, поэтому они не поддерживают интеграцию с внутренними корпоративными системами. Дистрибутивные трансакции и система надежных сообщений такому инструментарию непонятны. Остальные виды интеграции с корпоративными приложениями всегда была осложнены необходимостью получения специальных коннекторов, например, при интеграции с такими корпоративными приложениями как PeopleSoft или SAP. В конце 90-х EAI вендоры заработали целое состояние, продавая коннекторы. Например, хотите ввести заказ на покупку для этой версии SAP R/3, приобретайте коннектор X, стоимость которого для одного центрального процессора составляла 25.000 долларов. Хотите получить список сотрудников для версии SAP R/3, приобретайте коннектор за те же 25.000 долларов? На самом деле, каждый специалист может налету, без создания кода написать один стандартный коннектор для всех версий SAP R/3 и многого другого, который будет одинаково хорош как для стандартных, так и специальных трансакций. То же самое можно выполнить и для приложения Oracle, PeopleSoft, Siebel, и большинства других. И если у вас не возникнет непреодолимое желание разработать одноразовый коннектор для API интерфейсов, этого не придется делать никому и никогда.

Встроенный интерпретатор BPEL-кода

Все предыдущие BPEL и BPML спецификации основывались на генерировании Java-кода: можно было написать код на языке BPEL, а генератор кода автоматически переводил его в Java-код, который публиковался в Виртуальной Java-Машине или J2EE-серверах приложений. Теперь хорошая новость: вендоры ПО могут относительно легко работать с BPEL. Плохая новость: этот метод не работает. Так же как база данных Oracle не может генерировать C-код для исполнения заданного SQL-запроса, функциональная платформа BPMS не должна генерировать Java-код, чтобы выполнить BPEL-процесс. Генерирование Java-кода только еще больше усложняет публикацию процессов, приводит к разрыву с семантикой процесса и на порядок затрудняет отладку и контроль. И, наконец, все процессы попросту замедляются. Ситуация усугубляется, если приходится иметь дело с моделью EJB компонентов сохранения состояния данных процесса, использующих Entity Beans и Контейнерно управляемое хранение состояния (Container-Managed Persistence). С помощью динамичного компилятора система BPM 2.0 в исходном формате интерпретирует BPEL 2.0 код в байт-код процесса, который в точности отображает Pi-Calculus семантику, и не использует никаких EJB компонентов сохранения состояния, полагаясь исключительно на прямое взаимодействие с базой данных. Поэтому, если для вас важна эффективность и универсальность, то система BPM 2.0 это как раз то, что нужно.

Пользовательский интерфейс Web 2.0

Решения BPM 1.0 базировались на пользовательских интерфейсах Web 1.0, в основном стандартных email-клиентах и web-порталах, использовавших списки задач и формы, созданные с помощью обычного HTML. Система BPM 2.0 пользуется преимуществами Web 2.0 и технологий Office 2.0, такими как AJAX для решения различных задач. И пока система BPM пока еще не воспринимается как передовая и модная технология, именно использование Web 2.0 позволит привлечь в ней внимание самой продвинутой аудитории.

Встроенный модуль управления бизнес-правилами

До настоящего времени BPM решения делились на два лагеря: те, в которых универсальный модуль управления бизнес-правилами является встроенным, и те, в которых типовое BPM решение не может исполнять сложные бизнес-правила. В результате, большинство потребителей, которые пытались публиковать результаты BPM решения прошлого поколения были вынуждены искать модуль управления бизнес-правилами у независимых вендоров, хотя на самом деле полноценный модуль им был не нужен. В системе BPM 2.0 модуль управления бизнес-правилами является неотъемлемой частью, и может быть использован BPM вендорами там, где это необходимо. Как сказал Джеймс Тейлор (James Taylor), BPM вендоры не могут дальше игнорировать важность модуля управления бизнес-правилами – они должны либо разработать нечто сопоставимое, либо, что более вероятно, позаимствовать решение у производителей изначальной комплектации. В решении BPM 2.0 система управления бизнес-правилами (BRMS) является частью платформы BPMS. Таким образом, можно работать всего лишь с одной платформой, чтобы четко отладить жизненный цикл процесса, формирующего правила. По большому счету, платформа BPMS оказалась тем оружием, которого так долго ждали.

Включает систему BAM, функционирующую в режиме реального времени

Также как и в сфере управления данными существуют отдельные вендоры, занимающиеся обработкой информации (database vendors) и анализом данных (business intelligence vendors), в сфере управления бизнес-процессами существуют отдельные вендоры, работающие с системами BPM и BAM. И если слияние компаний – это длительный процесс, то продукты ассимилируются гораздо быстрее. Так, система BAM является частью комплексного решения BPM 2.0. Система BAM необходима, так как работать без нее с решениями BPM просто невозможно. Это все равно, что водить автомобиль с закрытыми глазами.

Встроенный имитатор процесса

В BPM решениях первого поколения имитация процесса поддерживалась специальными имитаторами, которые основывались на примитивных автоматах, имитировавших исполнение процессов, публикуемых в отдельной рабочей среде. Теперь хорошая новость: такие имитаторы относительно просты в использовании. Плохая новость: они не отражают истинную природу целевой рабочей среды, не могут тщательно смоделировать испытание нагрузкой, и не показывают данных процесса, что представляет большую половину семантики системы, особенно при использовании стандарта BPEL (Язык описания бизнес-процессов). Такие имитаторы подходят для бизнес-аналитиков, которые не вникают собственно в исполнение моделируемого ими процесса, но оказываются совершенно бесполезными для людей, которые создают и отслеживают весь жизненный цикл процесса. Принимая во внимание вышеупомянутую особенность, система BPM 2.0 предлагает другой подход к моделированию, при котором механизм исполнения процессов используется как имитатор. Таким образом, получается, что имитируемые процессы извлекаются из внешних систем, которые моделируются самим модулем управления процессом. Итак, чтобы сымитировать любой процесс, система моделирования автоматически публикует совокупность экземпляров процесса и генерирует случайные величины, чтобы поддерживать имитационные модели, как в методе Monte Carlo. Модуль управления процессами исполняет совокупность имитируемых экземпляров процесса и позволяет инфраструктуре BAM собрать воедино все результаты и показать их бизнес-аналитику, который получает доступ как к ключевым показателям эффективности бизнес уровня, так и к системным характеристикам эффективности. При таком подходе семантика имитируемого процесса сохраняется со стопроцентной точностью и учитывает семантику процесса, который необходимо опубликовать. Более того, сочетая бизнес-индикаторы с параметрами системы, имитатор гарантирует, что и бизнес, и IT будут одинаково хорошо представлены при оценке процессов, опубликованных в продуктивной среде для решения критически важных задач. В конце концов, специальный имитаторы процесса – это всего лишь игрушки в руках бизнес-аналитиков, в то время как встроенный системы имитации – это точный измерительный инструмент, на который BPM специалисты всегда могут положиться.

Динамическая оптимизация процесса

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

Модуль управления процессами на базе Open Source

Скоро модуль управления процессами станет самым важным компонентом любой IT-инфраструктуры. Поэтому необходимо позаботиться о приобретении самого лучшего страхового полиса. Это основная причина, по которой архитектура системы BPMS должна быть выстроена на основе модуля управления процессами на базе Open Source. В этом случае, что бы ни случилось с вашим вендором, вы гарантированно получите квалифицированную помощь. Сеть, которую многие сегодня называют Internet 2.0, была фактически построена на базе web-сервера Open Source Apache, благодаря которому сегодня функционируют 67% всех web-серверов, подключенных к Internet.

Попробуйте уже сегодня и совершенно бесплатно

И последнее. Система BPM слишком хороша для того, чтобы оставаться недоступной для потенциальных пользователей из-за своей высокой стоимости. До недавнего времени, полнофункциональная BPMS-система корпоративного класса стоила более 250.000 долларов. Если необходимо добавить систему поддержки бизнес-правил, систему мониторинга активности бизнес-процессов (BAM) и несколько других корпоративных приложений, стоимость системы возрастет до 500.000 долларов. На мой взгляд, такой высоких ценовой диапазон привел к тому, что за последние шесть лет система BPM не пользовалась большим спросом. Тем не менее, благодаря системе BPM 2.0 эта ситуация изменится, так как BPMS решения корпоративного класса будут бесплатными при условии соблюдения определенных параметров публикации. Появление моделей-гибридов, которые сочетают формат Open Source и коммерческое ПО, будет способствовать тому, что многие вендоры смогут долгое время оказывать поддержку клиентам. В конце концов, и потребители, и системные интеграторы, и вендоры ПО будут только в выигрыше от эффективной работы BPM рынка.

Авторские пометки: разделы про имитацию и оптимизацию были добавлены 6 февраля 2006 года после консультации с Ноэмом Нашми (Naeem Hashmi) и Брюсом Силвером (Bruce Silver). Со временем возможно включение дополнительных разделов или переработка уже имеющихся. Любые изменения будут отмечены специальными пометками.

Пояснения в разделе правила были сделаны 11 февраля 2006 года на основе информации, полученной от Джеймса Тайлера (James Taylor).

Надежный модуль управления правилами должен быть неотъемлемой частью любой BPM 2.0 платформы, а BRMS объединяется с BPMS.

Исмаель Халими (Ismael Ghalimi)