The recently coined term «Event-Driven Business Process Management» (EDBPM) is a combination of actually two different disciplines: Business Process Management (BPM) and Complex Event Processing (CEP). The common understanding behind BPM is that each company's unique way of doing business is captured in its business processes. For this reason, business processes are today seen as the most valuable corporate asset. In the context of this article, BPM means a software platform which provides companies the ability to model, manage, and optimize these processes for significant gain. As an independent system, Complex Event Processing (CEP) is a parallel running platform that analyses and processes events. The BPM- and the CEP-platform correspond via events which are produced by the BPM-workflow engine and by the IT services which are associated with the business process steps. In this paper we present a general framework for EDBPM as well as first use cases in the context of logistics and financial services.
Business process modeling became popular in the context of enterprise reorganization and modernization in the early 1990’s. A business process is a structured set of activities designed to produce a specified measurable result for a particular customer or market. The common understanding behind Business Process Management (BPM) is that each company’s unique way of doing business is captured in its business processes. In the last years, BPM has become a common tool in larger IT projects and workflow engines able to execute business processes became quite popular. Business processes are today seen as the most valuable corporate asset.
The term “Event-Driven Business Process Management” is a combination of actually two different disciplines: Business Process Management (BPM) and Complex Event Processing (CEP). In this context BPM means a software platform which provides companies the ability to model, manage, and optimize these processes for significant gain. As an independent system, Complex Event Processing (CEP) is a parallel running platform that analyses and processes events. The BPM- and the CEP-platform correspond via events which are produced by the BPM-workflow engine and by the IT services which are associated with the business process steps. Also events coming from different event sources in different forms can trigger a business process or influence the execution of the process or a service, which can result in another event. Even more, the correlation of these events in a particular context can be treated as a complex, business level event, relevant for the execution of other business processes or services.
In this article we describe the development of event-driven BPM (section 2) as a combination of Complex Event Processing and Business Process Management. We present the challenges in realizing event-driven BPM and describe a conceptual reference model for it (section 3). Section 4 discusses a practical use case of EDBPM in the context of the large logistics company DHL and we demonstrate the feasibility of event-driven BPM showing that it is a powerful tool with a clear business value which has its role in actively or even proactively ensuring better business process insight and situation-aware dynamic business process execution (section 4). The conclusion outline future steps in current running and imminent projects (section 5). 2.
BPM platforms address the operative and tactical level of supporting business including all activities that ensure efficient business process execution such as change management, incident management, problem/disruption management, and all activities which address business process control, delivery and planning such as as business activity and quality management, continuity management. This apparently amounts for situation awareness by reactive measures and detection of critical events, e.g. serious incidents which lead to process disruptions.
Complex Event Processing (CEP, [4]) is a dicipline that deals with event-driven behavior. It is an emerging technology for obtaining relevant situational knowledge from distributed systems in realtime or almost realtime by selection, aggregation, and event abstraction for generating higher level complex events of interest.
We define Event-Driven Business Process Management as event-driven combination of BPM and CEP. The solutions are executed by a BPM platform in combination with a separated CEP integration system, where both are decoupled with each other via interchanging events.
The term “Event Driven Business Process Management” was first used in June 2003 in a white paper of Bruce Silver Associates in connection with the FileNet P8-BPM platform [3]. The term was understood as a synthesis of workflow and Enterprise Application Integration (EAI). Actually, a concept of event processing and real-time BAM was described in that white paper, but only as single event processing without knowing anything about CEP which had not been introduced at the time. Although the book “The power of events” of David Luckham [4] has already been published in 2002, it wasn’t well known until 2004 and there was no working CEP platform yet. In November 2007, the term was explicitly used as a combination of BPM and CEP in an interview with Ruma Sanyal from BEA Systems [5]. 3.
In the following, we roughly outline the basic components needed for operational EDBPM systems. As shown in Fig. 1, basic elements can be taken from BPM platforms as well as CEP applications. EDBPM comprises two modeling layers for businesses processes as well as for events (to be described below). Basically this connects the preoperational abstraction of process modeling with the runtime observations of business process-related events occurring at execution time. Figure 1 shows the principle of how a BPM- and BAM/CEP platform work together on the basis of events. Grey components show workflows with respect to BPM, while blue components deal with real-time BAM/CEP phenomena. With this architecture in mind and given the recent availability of commercial CEP platforms, there will be two different kinds of EDBPM specialists in the future: Workflow modelers or business analysts and event modelers. Their task profile is roughly outlined in the following sections 3.1.
The workflow modeler identifies business processes, starting from the value chain of an
enterprise. He analyses and reengineers or optimizes the business processes by using a
Business Process Analyzing- (BPA) tool based on a standard notation like the Business
Process Modeling Notation (BPMN), invented 2002 by IBM and now standardized by the
Object Management Group (OMG) since 2005, published February 2006 as version 1.0
([8], for an overview of BPM languages see [
The business process models can be transformed into an executable notation of a
workflow engine or a BPM platform respectively. Executable notations are currently
being standardized by OASIS as Business Process Execution Language (BPEL, [
By cooperating with the process owners of the operating departments or even with the Clevel management of an enterprise, the event modeler has to define which BAM view has to be monitored in a dashboard, which alerts are to send to which roles in the organization and which actions shall be started automatically if a certain event pattern occurs. Derived from such BAM views, the event modeler looks for the needed event types and their instances flowing through the event streams of an enterprise or which are saved in an event store. It is a highly skilled task to define the right event patterns for a real-time BAM view. The event modeler has to know the different event sources like messages types in the Java Message Service (JMS) which are realized on the basis of a publish/subscribe model. He has to install the corresponding event adapters delivered by the CEP platform as “out of the box” pre-built features or the event modeler has to care about the development of not yet existing adapters. 3.3.
The event modeler defines event patterns for a BAM view on the basis of an Event
Processing Language (EPL). At present, there is no standard for an EPL although
different commercial solutions for event processing languages exist (see [
We are currently working on several use cases for the reference model sketched above:
Prototype EDBPM implementations are under way in different business environments
(logistics, financial services, automotive, see [
Our use case investigates the technical feasibility of combining actual tools for Complex Event Processing (CEP) and Business Activity Monitoring with the latest Enterprise Service Bus (ESB) infrastructure technology which is used to efficiently deploy and manage business and IT services as a distributed service oriented architecture. In particular, we evaluate if it is possible to technically integrate the Oracle components for CEP, BPEL and BAM into the existing SOA Framework of Sopera/Deutsche Post and to test the functionality and quality by means of a typical business process of the Deutsche Post. This use case serves as a proof-of-concept implementation for a solution combining the goals of a SOA with the advantages of CEP. At the same time it is a prototypical implementation of the reference model described in section 3 above.
For evaluating the capabilities and the interplay of the components, a typical business process of DHL, addressing “shipment”, “monitoring/investigation” and “claim” of packages has been modeled and implemented as test bed for the evaluation of the advantages of combining CEP and SOA. The Sopera services implementing the process functionalities are capable of sending process information and service status information as event streams directly to the BAM and CEP components. The CEP engine queries the event streams according to predefined CEP patterns for detecting relevant complex events. These complex events are displayed within the BAM component in dashboard views and are used to create alerts for predictive business.
The following Oracle components have been integrated into the Sopera ESB in a
proofof-concept prototype implementation (for details, see [
Based on the business process implemented the following excerpt explains the goals of predictive business analysis for the example of a late delivery of a package. The detection of possible errors is based on an event pattern that deals with events having influence on shipment.
A package is delivered by using several types of transport (e.g. plane, truck, van, etc.) which have to pass several areas / regions on a pre-defined way. In every area miscellaneous events may influence shipment and may eventually inhibit timely delivery of the package, e.g. a traffic congestion hinders the van from delivering the package on time to the customer or a storm prevents a plane from starting. Fig. 2 shows an excerpt of the business process that deals with shipment. The package is allocated to a specific type of transportation which is responsible for shipping the package one part of its way. These steps are processed until the package is delivered to the customer. These events influence on shipment as described.
Traffic events RFID events Weather events ...
Start Shipment allocate package to transportation
XOR XOR
The following paragraph describes the event correlation in a patterned structured way. The event patterns are schemas based on research on past business process activities. Patterns are found when events occur regularly and always lead to the same failure. After a pattern has occurred, CEP is able to create a complex event which may trigger proactive reactions. One of the patterns that can be found within the shipment process is the “External Process Influence Pattern”. It describes the influences of external events that affect the shipment delivery, e.g. when traffic congestion is encountered within a certain area, and a truck enters the zone, it is most likely that the shipment will not be on time. This event pattern will be described in the following paragraphs.
Overview
The external process influence pattern describes how to detect external influences on a
logistics-related delivery process. The processes need to reveal information about their
state as well as other events needed to be captured to provide the information about
external process influences. External process influences occur continuously during
process execution. External events are aggregated with process events so that forecasts
are enabled, if the process execution succeeds or if any failures occur. The forecast is
based on key performance indicators (KPIs) which have been defined in advance (cf.
[
Example A logistics related delivery process is a complex process containing many steps until its completion. For example, a package has to be taken over several routes via several means of transportation till it arrives at the destination. Within these routes, there are many influences which cannot be considered at the process design but have influences on the success of the delivery process. Such influences are traffic congestion, accidents, or bad weather conditions.
Context Delivery processes are executed and traced by sending out events at certain processing points. Additional information enters the system via several event streams. During process execution there are several reasons why process execution does not complete. Problem A business analyst will strive to guarantee the successful execution of a business process. The main questions in case of a failed process are: At which step does the process fail? and What is the reason for the business process failure? Solution The CEP platform collects events fired by the business process (process events). It also gathers events coming from external sources (external events). So there are basically two events needed before being able to predict a business process failure. The forecast of a loss is based on the area (areaCode) match of a process event, on the next processing step, with the area of an external event as well as a matching key that identifies the order (timeStamp).
Structure Two types of events are necessary to aggregate the needed information. In fig. 3 these events are ordered according to their abstraction level: On the lowest abstraction level, there are the event types ProcessEvent and ExternalEvent. The moment taken into consideration is always the moment when the event arrives at the system. This means that information about the location within the process is relative to the time as well as the physical location of an item. Events of the type ProcessEvent need to contain the following information: • • • • • • • • • • timeStamp: key identifying the order of the processed events, itemId: key that identifies a processed item, processLoc: location identifying the position in the business process and areaCode: identifier locating the item is physically in the process.
o o timeStamp: key identifying the order of the processed events, areaCode: identifier locating the area of the external information and o probability: factor that allows forecasting the process failure.
The type ProcessFailureForecast is the event which is generated by the correlation of the ProcessEvent and the ExternalEvent. It is further processed to arrive in a BAM view or an alerting system. To retrieve the information needed, it is necessary to process the following fields: timeStamp: key identifying the exact time when the event is correlated, itemId: key that identifies the processed item, processLoc: location identifying the position in the business process now, areaCode: identifying where the item will be physically located next and probability: factor if the item passes in the next step through the area Dynamics Each process step generates several ProcessEvents on the one side while in the meantime ExternalEvents are continuously coming in the system. Once a ProcessEvent enters the system, the system matches the process information with the data of the ExternalEvents for generating a ProcessFailureForecast event. The ProcessFailureForecast event contains the information about how likely the process will fail in the next step of the execution. This forecast has to be done by using metrics derived from relevant KPIs.
Implementation In order to implement the pattern described above, the following steps are necessary: 1.
Collecting events of the type ProcessEvent: The ProcessEvents can be fired either directly out of the process or hard coded out of the services.
Collecting events of the type ExternalEvent: The continuous collection of ExternalEvents occurs independently of the business process instance. An example for an external event flow is TMC (traffic message channel) which radio stations send out as a service in addition to their traffic reports.
Correlating the events in a continuous query: The correlation of the ProcessEvent and the ExternalEvent enriches the process information with valuable forecasting information.
Generation of the complex event type ProcessFailureForecast: The result of the correlation is the ProcessFailureForecast as a complex event type.
The “External Process Influence Pattern” was implemented in the course of the technology integration study at DHL/Deutsche Post AG. Basically, the capturing of both, process data as well as external data could be realized. Thus, the business is provided with a real-time overview of the actual state as well as with predictions on the status of future business activities.
Variations Possible variations of the “External Process Influence Pattern” depend on the incoming event streams. Among them are the analysis of external weather information and its impact on the delivery process as well as human factor information which is related to the driver’s performance.
Consequences The “External Process Influence pattern” provides benefits in the following areas: It is possible to predict the status of future process activities by correlating the actual process data with the information of the external process influences.
Thus, this use case shows how businesses may be enabled to take appropriate
measurements in advance, avoiding losses resulting from failed business processes.
The implementation of a EDBPM use case for the package delivery process at Deutsche
Post AG – certainly a core process in logistics – basically shows that the combination of
business process modeling and (real-time) complex event processing is feasible
(proof-ofconcept). This is a first step in the direction of real-time optimization and prediction of
business process execution ([
In this paper, we have established a first link between the flourishing area of modern business process management and BPM platforms on the one hand and complex event processing and CEP media, on the other hand. We have related the main concepts of both technologies in a general reference model for even-driven BPM and identified new specialized roles in the engineering process. By means of a use case of DHL the integration aspects, the added functionality as well as the business value of even-driven BPM are evaluated and demonstrated.
In summary, currently event-driven BPM is able to detect possible errors within a business process by using the CEP technology and alert responsible persons by using e.g. BAM. This leads to an added business value as compared to pure BPM solutions. However, in future business processes also have to react automatically to such errors, e.g. based on a conditional decision and reaction logic. Further key applications will take place in all domains and first projects on the basis of «Event Driven BPM»-platforms just start 2008:
Current/future research projects, e.g. “Domain specific reference models for event
patterns for a faster set-up of BPM/BAM applications” are currently being prepared [
The practical evaluation of relevant use cases in other domains like financial services or eCommerce.
The development of adequate description formats for complex events and event patterns.
Theoretical models for a realtime business process modeling – observation / monitoring – optimization cycle.
[1] R. v. Ammon, H.-M. Brandl, H.-W. Düster et al., “Business Activity Monitoring of norisbank - Taking the Example of the Application easyCredit and the Future Adoption of Complex Event Processing (CEP)”, Proceedings of PPPJ’06, Mannheim, 2006, http://www.citt-online.com/downloads/Ammon-Greiner-ACMPPPJ06-vs5-engl-final.doc, downloaded 2007-08-19 [2] R. v. Ammon, H.-M. Brandl, T. Greiner, D. Guschakowski, “Complex Event Processing in the Context of Business Ac-tivity Monitoring: An evaluation of different approaches and tools taking the example of the Next Generation easyCredit.”, Preworkshop DEBS’07, H.-A. Jacobsen, Toronto, 2007, http://www.debs.msrg.utoronto.ca/collaborate/Workshop_Agenda [3] Bruce Silver Associates, FileNet P8 – Event-Driven Business Process Management.
Industry Trend Reports June 2003, http://www.ecmunverzichtbar.de/Repository/48/files/69_EvBPM.pdf, http://www.complexevents.com/ [4] Luckham, D. The Power of Events: An Introduction to Complex Event Processing in
Distributed Enterprise Systems. 2002. Addison-Wesley Professional [5] Danielsson, K., Trotta, G. Key Requirements for Event-Driven BPM and SOA.
http://www.ebizq.net/topics/bpm/features/8700.html [6] Dheap V., Ward, P. Event-driven response architecture for event-based computing.
Proceedings of the 2005 conference of the Centre for Advanced Studies on Collaborative research table of contents, Toranto, Ontario, Canada, 70 – 82 [IBM Centre for Advanced Studies Conference archive,]. [8] OMG/BPMI, Business Process Modeling Notation (BPMN) Information, http://www.bpmn.org/, provides links to the current specification and relevant literature