information systems development || building a process performance model for business activity...

Building a Process Performance Model for Business Activity Monitoring

Claire Costello and Owen Molloy

Department of Information Technology, National University of Ireland, Galway {c.costello | owen.molloy}@nuigalway.ie

Abstract A formal business process model serves as a common understanding of how business tasks are carried out to achieve end goals. The business process life cycle is managed using Business Process Management tools and methodologies. Business Activity Monitoring provides (near) real-time visibility into process exe-cution notifying relevant personnel of process exceptions. Business process mod-elling captures business and execution semantics, but lacks any foundation for process analysis. This chapter will outline a model for process performance man-agement for use in the monitoring phase of the process life cycle and how this model is leveraged within the iWISE architecture. iWISE provides a single view of business processes spanning disparate systems and departments.

1 Introduction and Motivations

Traditionally, reporting and Business Intelligence systems rely on the details of workflow logs and separate, standalone modules to support process reporting. Mendling and Neumann (2005) provide a comparison of current process model-ling languages with respect to common modelling aspects. WfMC’s XML Process Description Language (XPDL) emerges as the only language of fifteen candidate languages that supports the gathering of statistical data useful for simulation analysis of business processes. There is a need to integrate the development and definition of a process with associated past and expected performance measures. This chapter presents a process model that combines event and other process per-formance information to allow (near) real-time process monitoring and alert gen-eration.

The remainder of this study is organized as follows. Sect. 2 describes the background for this research and provides a context for Business Process Man-agement (BPM) and Business Activity Monitoring (BAM). Process modelling and definition languages are also summarized along with a review of some related

model.

C. Barry et al. (eds.), Information Systems Development: Challenges in Practice, Theory,and Education, Vol.1, doi: 10.1007/978-0-387-68772-8_19,

237

© Springer Science+Business Media, LLC 2009

process monitoring research. Section 4 and Section 5 present the model used as part of this work, whilst Sect. 6 presents the iWISE architecture which uses this

238 Claire Costello and Owen Molloy

Fig. 1. Typical phases of the process life cycle

2 Background

Business Process Management can be defined as ‘supporting business processes using methods, techniques and software to design, enact, control and analyse op-erational processes involving humans, organizations, applications, documents and other sources of information’ (van der Aalst et al., 2003). A BPM system (BPMS) is an integrated software platform that allows for full management of the process life cycle. Managing process performance is paramount to business effectiveness. Melchert et al. (2004) view Process Performance Management (PPM) as a method for ‘collecting and reconciling all operational data related to a certain business process’ to identify areas for process improvement. Neely (2004) defines a per-formance measure as a metric used to quantify the efficiency and/or effectiveness of an action. The terms ‘metric’ and ‘key performance indicator’ (KPI) are also used when discussing process performance.

2.1 Business Process Life Cycle Management

A business process has many phases and constitutes what is widely accepted as the process life cycle (zur Muehlen and Rosemann, 2004; van der Aalst et al., 2003). The life cycle is depicted in Fig. 1 as a closed loop of activities. A process model is captured during the define phase. Once modelled, a process model is transformed into an executable model ready for deployment on process execution architectures. Once deployed, a process is ready to be executed. As a process in-stance is executing, a monitoring module will track its execution against pre-defined metrics and generate exceptions if necessary. The analysis phase may use complex statistical techniques to analyse process execution data and metrics to identify any unwanted trends in the process. Using this information, improvements can be made which lead back to the define phase where the cycle begins once more. This closed loop for process management is similar to the Define, Manage, Analyse, Improve and Control (DMAIC) model of the Six Sigma approach to process improvement (Smith, 1993).

Building a Process Performance Model for Business Activity Monitoring 239

2.2 Process Modelling and Definition Languages

The current set of standards for process management complement the process life cycle depicted in Fig. 1 Process modelling languages (PMLs) specify a notation and include the Unified Modelling Language (UML), Business Process Modelling Notation (BPMN) and Business Process Definition Metamodel (BPDM). Process execution or definition languages (PELs/PDLs) are specifications which contain semantics understood by process execution engines. Prominent process execution languages include Business Process Execution Language (BPEL), Business Proc-ess Modelling Language (BPML) and the XML Process Definition Language. The Event-driven Process Chain (EPC) modelling notation contains symbols for func-tions, events and control flow points. An EPC model does not have a correspond-ing machine representation.

Rather than separate the process modelling and monitoring phases using dif-ferent underlying models, this research builds a process model inclusive of fields for metric calculations, in particular, cycle time performance measures. Further enhancements will include the specification of business parameters defined at the process definition phase. The use of a single model will also enable portability of process definitions between various software modules regardless of what phase in the life cycle they apply to.

2.3 Business Activity Monitoring

Business activity monitoring (BAM) is a term coined by The Gartner Group. BAM seeks to ‘provide real-time access to critical business performance indica-tors to improve the speed and effectiveness of business operations. Unlike tradi-tional real-time monitoring, BAM draws its information from multiple application systems and other internal and external (inter-enterprise) sources, enabling a broader and richer view of business activities’ (McCoy, 2002).

The key term in this definition is real time. BI approaches take a historical per-spective providing information retrospective to the time when important events may have occurred. In contrast, BAM is event-driven and provides quick-time visibility by capturing events from operational IT infrastructure. Decision latency is the length of time between the point when an important event occurs during op-erations processing and when a decision should be made to correct any anomalous behaviour. To decrease decision latency and therefore increase responsiveness to changing conditions, organizations need BAM software that will provide real-time visibility into their key operations. A BAM system must be able to detect enter-prise events, integrate event and contextual information on-the-fly and provide in-tuitive interfaces for rules and metrics (Nesamoney, 2004).


3 Related Research

Thomas et al. (2005) describe a loosely coupled architecture overlaid upon a busi-ness process expressed in a PEL such as BPEL. The architecture is agent-based and uses the Web Ontology Language (OWL) for describing performance criteria for business processes and individual activities, but does not show how to model the metric itself or how the parameters of a metric are mapped from operational business data.

A Web service-based intelligent Decision Support System called the ‘Solution Manager Service’ is described in McGregor et al. (2006). The contribution here focuses on the ability to monitor Web service executions which is important given that many process modelling and definition languages are based on Web services.

Haller and Oren (2006) describe an ‘intermediate ontology’ that will act as a common mapping mechanism between the various internal and external process formats used by business systems. However, the measurement aspect of a process is omitted by this ontology and other workflow and process modelling and defini-tion languages (Mendling and Neumann, 2005; Thomas et al., 2005).

McGregor (2002) suggests an amendment to the WfMC reference model that incorporates business performance monitoring information for use with the Balanced Scorecard (BSC) approach to business performance management.

Although the works mentioned here outline various frameworks for process performance monitoring and management, they do not detail a process model that explicitly contains the elements for aiding process monitoring activities in (near) real time. In addition, since a process model is captured at the define phase (see Fig. 1), then a user should also be able to express important business parameter thresholds or control limits such as target cycle time or expected utilization level. The proposition of this research is that performance metrics and relevant metric thresholds should be incorporated into the process model.

4 Modelling Process Performance Information

The process model developed uses XML as its internal representation. The major elements of the model are discussed in this section. The section also details an on-tology representation of the concepts required to capture process performance in-formation.

4.1 Model

At a diagram level, a model contains processes. The XML Schema for a model is shown in Fig. 2a. Important information relating to a model includes a unique modelID, name and description. An additional boolean attribute, called root, denotes a model that is the root of a model hierarchy. This attribute is necessary for efficient retrieval and reconstruction of multi-level models during both the


process capture and monitoring stages. Links between processes are expressed us-ing transition elements. This research does not concern itself with controlling process executions, but instead aims to model and analyse as-is processes which may execute across many different systems. For this reason, complex control structures such as those described in van der Aalst (2003) are not represented here.

(a)

(b)

Fig. 2. Model XML Schema (a) and Process XML Schema (b)

4.2 Process

A process represents a business activity. The XML Schema for a process is shown in Fig. 2b. Along with general attributes such as a unique processID, name and


description, a process is also associated with multiple event definitions. A proc-ess must contain at least a start and end event which help to identify the total proc-essing time for a process. Each event is defined by an EventType element which is described in more detail in Sect. 4.3. A process owner must also be specified. A process owner has typical attributes such as name, email address and mobile num-ber. A process may be defined by another level of detail. This is captured using a separate model (associated by subModelID) and is considered a level deeper in the model hierarchy. There is a one-to-one relationship between a process and a model to represent a sub-model of a process.

Some elements relate to cycle time statistics for a process. Time granularity is expressed using CycleTimeUnits, whilst TargetCycleTime is a constant for the expected processing time of a task. Both these elements must be specified when the process is defined and are inputs to runtime metric calculation modules. The remaining cycle time elements are calculated at runtime and represent an aggre-gate view of process execution over time. Valuable information relating to the cur-rent performance of a process is captured and preserved by these elements. Ele-ments Capacity and EfficiencyTimeUnit must be specified at process design time and are required for calculating process utilization and productivity statistics as a process is executing. These elements described here are not included as part of any current PDL specification.

4.3 Event

A process containing event definitions represents an abstract view of system ac-tivities. All events are defined according to the EventType XML Schema illus-trated in Fig. 3a. Similar to the model and process elements, an event type element also contains general fields for eventID, name and description. A process can be in various states such as queued, started or finished. The model supports an event classification scheme that includes six event types to model process execution: queue, start, interrupt, resume, cancel and end. Each event definition is linked to a process definition using the appropriate element in Fig. 3b.

Events have significance; they happen for a reason. Therefore, an XMLSchema element is provided to describe the expected format of business information rele-vant in the context of an event. This information can also be referred to as the business object, and its XML Schema structure is supplied during event definition. It is important to note that there is no restriction on the business content encapsu-lated as part of an event definition; if information can be observed as part of an event that occurs in the IT infrastructure, then it may also be defined as part of an event making it available during process analysis. In this way, business data can be linked to particular process instances through event definitions.

Events are related to each other through the process they are defined with (re-ferred to as event relativity). Therefore, an event correlation technique is required such that all events related to each other are grouped together for process analysis. This is achieved using the XMLPathExpression element in Fig. 3a which specifies an XPath value from the XML Schema supplied with the event definition. At run-


time, this XPath value is evaluated, based on the XML document packaged as part of the enterprise event. This value must be capable of uniquely identifying event instances for a given process definition. The same value must be present across all event definitions for each process defined within a particular model. For example, for an Order Fulfilment process model, an Order Number could be used to match start and end events for each process within the model.

(a)

(b)

Given the structure of an event definition in Fig. 3a, an event at runtime fol-lows the structure of Fig. 3b. The eventInstanceID is assigned by the source sys-tem or listener software. The Timestamp element is the time when an event oc-curred as recorded by the source system. The EventTypeID relates the event to its appropriate EventType definition. The XMLPayload element is an XML document containing the business information defined by the XML Schema supplied during event definition. The CorrelationID is the value of the XMLPathExpression specified at process design time.

The recursive nature of models and processes allows a model hierarchy to be constructed. Events defined for one process must be reused at the sub-model level. In this way, a process and its associated event definitions can be seen as an aggre-gation of all processes and events defined at the sub-model level. Using this bal-ancing approach, metrics for high-level processes can be derived using lower-level process and event definitions.

The model developed here links events, processes and business information to provide a comprehensive process description that includes metric thresholds and measurements. With the exception of XPDL which provides a limited set of ele-ments for simulation activities, current process modelling standards do not provide any fields for performance metrics or measurement definitions; this is the contri-bution of this work.

Fig. 3. EventType XML Schema (a) and runtime Event XML Schema (b)


5 Defining Rules for Activity Monitoring

A business rule engine (BRE) is a software component that will execute business rules against a set of facts from a given scenario. A BRE consists of a knowledge base (or rules base), a working memory of facts and an inference engine.

5.1 An Ontology for Performance Management

Lera et al. (2006) state that it is ‘impossible to make a complete ontology that em-braces all existing metrics’ and that the scope of the ontology will depend on the domain of interest. The model discussed earlier has a corresponding ontology rep-resentation. This ontology was developed using OWL (W3C, 2004). A straight-forward mapping of the major components of the event-based model presented in the previous sections leads to the ontology in Fig. 4. This will serve as a basis for writing rules to test the current state of a process with respect to its performance thresholds.

5.2 SWRL for Process Exceptions

SWRL (Horrocks et al., 2004), a W3C member submission, is a Semantic Web Rule Language combining OWL (W3C, 2004) and RuleML (RuleML, 2000). SWRL facilitates rule authoring using ontology concepts as part of rule predicates. In addition to OWL axioms, a knowledge base can now include Horn-like rules written using a logical implication between an antecedent (body) and consequent (head). Since SWRL is based on the RuleML, it inherits the RuleML rule struc-ture.

Fig. 4. Defining concepts for a process metric ontology


Using the knowledge concepts discussed previously, the SWRL rule specifica-tion is used to compose IF-THEN rules to specify when exceptions arise in proc-esses. For example, a rule might be constructed to test the value of a metric for process utilization against a pre-defined lower control limit (UtilizationLCL element in Fig. 2b). The rule given later raises an exception where a process per-formance metric has dropped below an acceptable lower limit. The rule is an IF-THEN rule which is true only when all predicates in the IF portion are true. Each predicate is joined using logical AND, also known as conjunction. A variable is denoted using the ‘?’ symbol, for example, ?x and ?y are variables and are given sample values here. Rule definition (abstract syntax): Sample Rule (with values):

Process(?x) ∧ IF there is a process ?x, e.g., ‘analyse sample’ and

hasBusinessObject(?x, ?b) ∧ A process ?x ‘analyse sample’ has an associated business object ?b, e.g. with value ‘specimen.345’, and

hasPerformanceMetric(?x, ?y) ∧ A process ?x ‘analyse sample’ has a performance metric ?y, e.g., ‘utiliza-tion’ and

hasMetricValue(?y, ?a) ∧ A performance metric ?y ‘utilization’ has a particular value ?a, e.g., ‘85’ and

hasLowerControlLimit(?y, ?z) ∧ A performance metric ?y ‘utilization’ has a pre-defined lower limit value ?z, e.g., ‘92’ and

swrlb:lessThan(?a, ?z) The actual metric value ?a of ‘85’ is less than the pre-defined lower limit value ?z of ‘92’

→ hasException(?x, ?b) THEN process ?x ‘analyse sample’ with business object ?b ‘speci-men.345’ is in an exception state.

From Fig. 4, the OWL classes BusinessObject, Process, Metric and Excep-

tion are used in the SWRL rule definition given here. Through definition of OWL properties, a process ?x has a business object ?b and performance metric ?y. In the sample rule, it may not be fully necessary to track the business object that has given rise to the exception, but for the sake of (near) real-time processing, current business data may be necessary for alerting purposes. The rule given here also uses the SWRL built-in lessThan. The SWRL specification includes a set of built-in predicates (SWRLB), named the ‘SWRL built-ins’, which includes predicates for comparisons, mathematical operations and string handling methods to name a few.


6 iWISE Architecture

The iWISE architecture is illustrated in Fig. 5. Process models are captured us-ing the iWISE Process Capture Tool (PCT) which is a Microsoft Visio-based standalone application. The PCT allows users to construct a process map and de-fine events and metric thresholds linked to a process. The iWISE Legacy Listener components are configured to detect events in IT systems. Once detected, the events are constructed using the format in Fig. 3b and sent to the iWISE Event Server where they are parsed and stored.

The iWISE Event Server is the central component responsible for managing models, event streams and metric calculations using the three software packages shown in Fig. 5: the Model Manager, Event Manager and Metric Manager. The Model Manager receives process models from the iWISE PCT and compiles them for further processing. The Event Manager component receives enterprise events

Fig. 5. iWISE architecture containing the iWISE Event Server as the core

The iWISE software facilitates management of the business process life cycle (Costello et al., 2006). Once a process is captured and deployed, raw event streams are correlated with relevant processes to provide monitoring software with appropriate metrics. iWISE is a common event infrastructure that uses the event-

the phases outlined in Fig. 1 with the exception of the execute phase. Process exe-cution is handled by the systems already in place within an organization. Such sys-tems may include ERP systems or more process-oriented systems such as process execution engines. The iWISE system does not seek to replace these systems but leverage the system events triggered and business data created or manipulated.

based process model described in Sect. 4. The iWISE software addresses each of


from Listeners defined in the format as specified during process capture. When raw events arrive, they are parsed and associated with the correct process. As events are processed, the Metric Manager component generates alerts based on a pre-defined set of rules. It also generates metrics on-the-fly to provide an up-to-date process view for the iWISE Process Dashboard. The iWISE Process Dashboard is a Microsoft portal application that provides a timely snapshot of process performance.

6.1 Generating Process Alerts

7 Conclusions

iWISE supports process exception alerting by executing business rules against thresholds using semantic techniques. This research addresses the major function-ality of a BAM system as outlined in Nesamoney (2004). Most important is the process-aware nature of the iWISE framework and underlying model that incorpo-rates a performance aspect into its structure. Current work is focussing on the ex-tension of the event model to cater for business parameter definitions not related to cycle time to allow calculation of Six Sigma type metrics on a constant basis. Further discussion can be found in Costello et al. (2005). The use of business rules

The iWISE Event Server Metric Manager (see Fig. 5) component detects process execution anomalies in (near) real time and structures these exceptions for further processing by Microsoft Notification Services (MSNS). Before alerts can be gen-

Protégé Ontology Editor is used to create both the ontology and SWRL rules to form the knowledge base required for analysing process runtime exceptions. Once specified, the rules are loaded into the Event Server for access at runtime. At run-time, a Java stateless session bean is invoked at every time interval (set in configu-ration properties before application deployment) to calculate various process

utilization level can be calculated and compared against a minimum acceptable value defined during the process design phase. The details of the process and met-ric are supplied to the Bossam reasoner (Jang and Sohn, 2004), where the SWRL rules are used to reason if the metric supplied, and therefore the process, are out-side normal limits of execution. In the case of process utilization, if the current level is below a minimum level, then that process is out of bounds. When a proc-ess metric is in such an exception state, the monitoring software will supply the exception information to an SQL Server database. MSNS will detect the informa-tion and generate a notification and alert if there are any subscribers defined for the process and metric in question. The iWISE Process Dashboard contains a process alerts subscription management page to allow users to subscribe to pre-defined alerts for processes deployed within the Event Server.

erated, rules must be defined, based on the model described in Sect. 4. The rules are specified using SWRL based on the ontology concepts defined in Sect. 5. The

measurements. For example, using the rule given in Sect. 5, the current process


to monitor process performance is novel compared with the retrospective nature of BI techniques.

References

Costello, C., Molloy, O., Duggan, J., and Lyons, G. (2005). Using Event-Based Process Model-ling to Support Six Sigma Quality. In Sixteenth International Workshop on Database and Ex-pert Systems Applications (DEXA), Copenhagen, Demark, 22–26 August.

Costello, C., Fleming, W., Molloy, O., Duggan, J., and Lyons, G. (2006). iWISE: A Framework for Providing Distributed Process Visibility Using an Event-Based Process Modelling Ap-proach. In Eighth International Conference on Enterprise Information Systems (ICEIS), Paphos, Cyprus, 23–27 May.

Haller, A. and Oren, E. (2006). A Process Ontology to Represent Semantics of Different Process and Choreography Meta-Models, http://www.m3pe.org/deliverables/process-ontology.pdf.

Horrocks, I., Patel-Schneider, P. F., Boley, H., Tabet, S., Grosof, B., and Dean, M. (2004). SWRL: A Semantic Web Rule Language Combining OWL and RuleML, http://www.w3. org/Submission/SWRL/.

Jang, M. and Sohn, J.-C. (2004). Bossam: An Extended Rule Engine for OWL Inferencing. In Rules and Rule Markup Languages for the Semantic Web. Third International Workshop, RuleML 2004, Hiroshima, Japan, 8 November.

Lera, I., Juiz, C., and Puigjaner, R. (2006). Performance-related Ontologies for Ubiquitous Intel-ligence Based on Semantic Web Applications. In AINA’06: Proceedings of 20th International Conference on Advanced Information Networking and Applications, Vienna, Austria, 18–20 April.

McCoy, D. (2002). Business Activity Monitoring: Calm Before the Storm, http://www.gartner.com. McGregor, C. (2002). The Impact of Business Performance Monitoring on WfMC Standards. In

WfMC Workflow Handbook 2002, Vol. (Ed., L. Fischer), Future Strategies: Lighthouse Point. McGregor, C., Schiefer, J., and Muehlen, M. z. (2006). A Shareable Web Service Based Intelli-

gent Decision Support System for On-Demand Business Process Management, International Journal of Business Process Integration and Management, 1 (3).

Melchert, F., Winter, R., and Klesse, M. (2004). Aligning Process Automation and Business In-telligence to Support Corporate Performance Management. In Tenth Americas Conference on Information Systems, New York, NY, August 5–8.

Mendling, J. and Neumann, G. (2005). A Comparison of XML Interchange Formats for Business Process Modelling, In WfMC Workflow Handbook 2005, Vol. 185–198.

Neely, A. (2004). Performance Measurement System Design: A Literature Review and Research Aagenda, International Journal of Operations and Production Management, 25 (12), 1228–1263.

Nesamoney, D. (2004). BAM: Event-Driven Business Intelligence for the Real-Time Enterprise, DM Review, 14 (3), 38–40.

RuleML (2000). The Rule Markup Initiative (RuleML), WWW, http://www.ruleml.org/. Smith, B. (1993). Making War on Defects: Six-Sigma Design, IEEE Spectrum, Vol. 43–47. Thomas, M., Redmond, R., Yoon, V., and Singh, R. (2005). A Semantic Approach to Monitor

Business Process, Communications of the ACM, 48 (12), 55–59. van der Aalst, W. M. P. (2003). Workflow Patterns, Distributed and Parallel Databases, 13 (7), 5–51. van der Aalst, W. M. P., ter Hofstede, A. H. M., and Weske, M. (2003). Business Process Man-

agement: A Survey. In Proceedings 1st International Conference on Business Process Man-agement, Eindhoven, The Netherlands, 26–27 June.

W3C (2004). OWL Web Ontology Language Overview, http://www.w3.org/TR/2004/REC-owl-features-20040210/.

zur Muehlen, M. and Rosemann, M. (2004). Multi-Paradigm Process Management. In CAiSE'04 Workshops – Fifth Workshop on Business Process Modeling, Development and Support (BPMDS 2004), (Eds., J. Grundspenkis and M. Kirikova), Riga, Latvia, 7–8 June.

information systems development || building a process performance model for business activity...

Documents