iWISE: A FRAMEWORK FOR PROVIDING DISTRIBUTED

PROCESS VISIBILITY USING AN EVENT-BASED PROCESS

MODELLING APPROACH

∗

Claire Costello, Weston Fleming, Owen Molloy, Gerard Lyons and James Duggan

Department of Information Technology

National University of Ireland, Galway

Keywords:

Business process performance management, Business Activity Monitoring (BAM), process modelling.

Abstract:

Distributed business processes such as supply chain processes execute across heterogeneous systems and com-

pany boundaries. This research aims to provide an event-based process model to describe business processes

spanning disparate enterprise systems. This model will be generic enough to support processes from multiple

industry domains. In addition, this paper introduces the iWISE framework as a light-weight process diagnos-

tic tool. The iWISE architecture uses the process model described to provide business process performance

monitoring capabilities.

1 INTRODUCTION

Business processes set forth the steps required for

achieving business goals. Advances in application in-

tegration technologies have resulted in inter and intra-

business activities bridging many different systems.

This factor has contributed to the menagerie of busi-

ness processes executing at any given time within an

organization. In addition, the fragmented nature of

such business processes makes it difﬁcult to monitor

the health of business activities. Near real-time visi-

bility will give business personnel the right informa-

tion at the right time making businesses more respon-

sive to changing business landscapes. Real-time visi-

bility demands an architecture capable of continuous

process monitoring. The iWISE project provides a

common platform for integrating and monitoring ex-

tended business processes. It also provides process

simulation and optimization functions.

The platform uses an event-based process model

for describing business processes. Each event struc-

ture represents enterprise events and contains relevant

business information. The integration of processes,

events and business data provides a foundation for

various process management activities such as moni-

toring, optimization and simulation.

The project’s Industrial Advisory Panel includes

leading Irish-based companies from two application

∗

The support of the Informatics Research Unit of Enter-

prise Ireland is gratefully acknowledged.

domains. Advisors for supply chain integration in-

clude Pepsi Co. and Apple Computers. Advisors

from the ﬁnancial services domain include the Allied

Irish Bank (AIB) Plc. and Voluntary Health Insur-

ance (VHI). Partnership with these advisors ensures

that project developments are applicable in real-world

domains.

This paper describes related work and the iWISE

process monitoring framework. Related research is

discussed in Section 2. Section 3 provides a brief re-

view of process modelling and monitoring. It also ad-

dresses the concept of Business Activity Management

(BAM). Business process models from two different

domains are presented in Section 4. These scenarios

provide an understanding of the main modelling con-

cepts required to model distributed processes. Sec-

tion 5 describes the model used for deﬁning and man-

aging distributed business processes in this research

and its contribution to current process modelling ap-

proaches. The iWISE framework for managing dis-

tributed process models and their runtime execution

data is detailed in Section 6. Future work for iWISE

is discussed in Section 7.

2 RELATED RESEARCH

Process management approaches and techniques are

subject to continuous investigation by both academia

and industry. Some of the trends in BPM include

224

Costello C., Fleming W., Molloy O., Lyons G. and Duggan J. (2006).

iWISE: A FRAMEWORK FOR PROVIDING DISTRIBUTED PROCESS VISIBILITY USING AN EVENT-BASED PROCESS MODELLING APPROACH.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 224-233

DOI: 10.5220/0002497002240233

 SciTePress

Business Process Outsourcing, Business Process In-

telligence and the use of Web service-based archi-

tectures to realize effective BPM solutions (Casati,

2005). The same author also describes a system

currently being developed by Hewlett Packard (Palo

Alto, CA.) which allows users model processes, ser-

vices and metrics using a high level of business ab-

straction. This model then serves as a common model

for using Extract, Transform and Load (ETL) com-

ponents to observe events in the IT infrastructure in

order calculate business-level metrics. The key ele-

ment is the single source deﬁnition of processes, ser-

vices and metrics to facilitate integration of business

information to provide process visibility and impact

analysis.

Research undertaken by the same institution

(Casati and Discenza, 2000) developed a model

for specifying interaction among workﬂow systems

to achieve distributed business process interaction.

The model extends traditional activity modelling ap-

proaches to include the deﬁnition of event nodes

which represent points within the ﬂow where events

should be sent to or received from other processes.

This approach focusses on the cooperation between

distributed processes. By contrast, the aim of the re-

search detailed by this paper is to provide an end-to-

end view of processes using event-driven paradigms

for process visibility.

Visualization of distributed processes, each with its

own meta-model and semantics, is a complex task and

the subject of inquiry in (Bobrik et al., 2005). The

research does not aim to provide an execution frame-

work for distributed business activities, but to provide

a single view of a process spanning multiple hetero-

geneous systems to enable process monitoring. The

challenge exists in translating multiple process meta-

models into a common format for presenting the end-

to-end process view to a user. The result of this work

is a meta-model derived from the Workﬂow Manage-

ment Coalition’s XML Process Deﬁnition Language

(XPDL).

Extending current process modelling approaches or

speciﬁcations is not new. Data Warehouses (DWHs)

provide a comprehensive resource of business data

for supporting decision making processes within or-

ganizations. The extension of Event-driven Process

Chains (EPCs) to include DWH information to pro-

vide a model that shows where and how business pro-

cesses rely on DWH functionality is being explored

(Stefanov and List, 2005).

Both Workﬂow Management Systems and Busi-

ness Process Management Systems document the exe-

cution of process instances using workﬂow logs or au-

dit trails. These resources can be quite hard to analyze

directly. (Eder et al., 2002) details the development

of a meta-model to describe the static and dynamic

aspects as well as organizational aspects of a process.

This meta-model serves as a basis for capturing pro-

cesses in different representation techniques within a

DWH environment. Since Data Warehouses are tra-

ditionally updated in batch-mode, real-time decision

making is hindered by this gap in information avail-

ability. Current research examining the emergent syn-

ergies between process information and “Sense and

Respond” architectures has resulted in the creation

of near real-time process monitoring software. Work

by (Kapoor et al., 2005) details such an approach to

minimize decision making time for exceptions in pro-

cesses.

Work carried out by (McGregor and Schiefer,

2004) aims to enable feedback on the organization’s

performance in a collaborative environment through

analysis of Web service executions. The Solution

Management Web Service (SMWS) framework pro-

vides Web services to deﬁne other Web services from

a performance measurement perspective and to log

and analyze the enactment of Web services.

Continuous process improvement relates to the on-

going analysis and redesign of processes where nec-

essary to increase process quality and reliability. The

Six Sigma approach to quality was developed origi-

nally by Motorola Inc. in the late 1980s to address

the problem with variations in processes in order to

achieve customer satisfaction. Quality may be de-

ﬁned as defect-free performance in all products and

services (Smith, 1993). Despite being a rigorous

methodology, Six Sigma is recognized as an effective

quality programme that reduces process variation and

costs (Caulcutt, 2001) and (Mitchell, 1992). The use

of Six Sigma for process performance measurement

is explored further in (Costello et al., 2005).

3 PROCESS MONITORING

Business Process Management (BPM) has evolved

within the last decade to become a methodology for

supporting a process-centred view of an organization.

The process lifecycle comprises many phases: de-

sign, capture, simulate, execute, monitor, and opti-

mize. Figure 1 illustrates the different layers of tech-

nologies and methodologies for managing the process

lifecycle. At the top of the stack, process modelling

and business content speciﬁcations aid the designer in

capturing and specifying various parameters required

for other stages of the process such as execution and

monitoring. Business content speciﬁcations provide

a common method for developing business informa-

tion such as purchase orders and invoices that can be

used for inter-company collaborations. The Universal

Business Language (UBL) is an example of such a

speciﬁcation. The main output of these standards is a

library of reusable components for building business

iWISE: A FRAMEWORK FOR PROVIDING DISTRIBUTED PROCESS VISIBILITY USING AN EVENT-BASED

PROCESS MODELLING APPROACH

225

Figure 1: Modelling, deploymen t and integration technolo-

gies for process management.

documents.

Process modelling speciﬁcations deﬁne notations

for capturing business processes. These standards

typically provide templates and semantics for con-

structs such as processes (tasks or activities), pro-

cess looping, sub-processes, normal ﬂows, join and

split ﬂows, decision points, text annotations, pools

and swimlanes. Examples of such standards include

the Business Process Modelling Notation (BPMN)

and the Uniﬁed Modelling Language (UML). Event-

driven Process Chains (EPCs) model business func-

tions, data and events. Events are created by pro-

cesses or by external actors of the model. EPCs are

used in the ARIS process platform. Integrated Deﬁ-

nition (IDEF) is a set of modelling methods that can

be used to capture business operations. Although cre-

ated by the US Air Force for manufacturing environ-

ments, it has been adapted for other domains. Six-

teen methods, from IDEF0 to IDEF14, are designed to

capture various types of information through process

modelling. IDEF0 to IDEF4 are the most commonly

used methods. In particular, IDEF0 is used to model

the functions of an enterprise by specifying the in-

puts, outputs, controls (constraints) and mechanisms

(resources).

Business integration and service composition tech-

nologies detail the process from an execution point of

view. These speciﬁcations are also known as process

deﬁnition languages and such ﬁles are used as inputs

to process execution engines. In the current technol-

ogy landscape, this space is ﬁlled by Web services-

based integration and composition languages. Ex-

amples of orchestration languages include the Busi-

ness Process Execution Language (BPEL) and Busi-

ness Process Modelling Language (BPML), whilst the

Web Services Choreography Description Language

(WS-CDL) is an example of a choreography lan-

guage. The lower levels of Figure 1 specify the

quality of service and service management technolo-

gies necessary to ensure successful implementation of

business processes.

Business Activity Monitoring (BAM) is a process

performance management technique that equips per-

sonnel at all echelons of an organization with timely

information regarding process execution. This level

of constant feedback helps make decisions more ef-

fective. BAM achieves this by capturing and process-

ing events as they occur within the business IT en-

vironment. Indeed, BAM technology is an extension

of application integration and messaging technologies

that tap into transactions of IT systems (Knifsend and

Debb, 2005). BAM technology relies on a robust def-

inition of both processes and events to deliver such

punctual information.

The iWISE Business Activity Monitoring method-

ology encompasses ﬁve steps: Deﬁne, Measure, An-

alyze, Improve and Control (DMAIC). This method

follows from the Six Sigma methodology for process

improvement (Adams et al., 2003).

Deﬁne Capture the process requirements in a de-

ﬁnable and manageable format. Specify process

name, owner, start and stop events. Identify pro-

cesses that are major control points within the en-

terprise systems. Include in this deﬁnition key pro-

cess or product parameters, acceptable parameter

values, as well as measurements required for ana-

lyzing process execution times.

Measure Continuously calculate key process metrics

as processes are executing using event-based model

deﬁned in previous step. Metrics deﬁnitions are

based on cycle times and other Six Sigma calcu-

lations.

Analyze Analyze enterprise processes for critical

changes based on acceptable limits for key parame-

ters, for example, cycle time measurements exceed-

ing a given target. Provide analysis using applica-

ble tools or techniques such as correlation graphs,

pareto charts and cause-and-effect (ﬁshbone) dia-

grams. Use Web-based dashboard portal technolo-

gies as a central point of process monitoring.

Improve Use dashboard to identify bottlenecks and

inefﬁciencies in the process and propose improve-

ments. Simulate suggested process improvements

to evaluate effect on process design and implement

as approved.

Control Use control charts and other techniques to

verify predictable process states.

3.1 Modelling Distributed Business

Processes

Business IT infrastructures typically include many

enterprise systems. Each system is responsible for

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

226

carrying out operations on behalf of its business users.

It is difﬁcult to model business processes that span

multiple systems. What is required is an end-to-end

deﬁnition of distributed business processes. This re-

search combines the event-driven paradigms of mes-

saging systems and process modelling techniques to

provide a single view of such processes. Each pro-

cess deﬁnition will be enriched with event and busi-

ness object information which will, in turn, be usable

in latter stages of the process lifecycle, such as mea-

surement and analysis.

Business systems generate many events during

daily processing. For example, an order fulﬁlment

process is a sequence of activities required for man-

aging orders received from customers. When a new

order for a product is created, it is can be seen as an

event occurring within the appropriate order system or

database. The creation of the new order is a raw busi-

ness event. The order fulﬁlment process describes the

steps and control ﬂow for managing orders, but these

steps may involve the use of disparate systems. To

create a single view of the process, it is necessary

to capture appropriate raw business events in con-

text of the process and create a model which deﬁnes

these two entities cohesively. This uniﬁes data-rich

raw business events with process models describing

the various business activities of an enterprise. The

iWISE framework provides users with the appropriate

software to describe the business activities and events.

Before presenting a process model which can describe

such distributed processes in terms of processes and

events, two case studies from separate business do-

mains are presented to illustrate the core modelling

concepts identiﬁed for developing the process model.

4 ANALYSIS OF BUSINESS

SCENARIOS

This section presents, diagrammatically, a compre-

hensive breakdown of two business scenarios into

their core activities. These scenarios have been devel-

oped in collaboration with industry partners and rep-

resent fragmented business activities and the points

of interaction with external parties. From the iden-

tiﬁed activities or tasks, a number of messages have

been deﬁned as important integration procedures in

the supply chain context. The messages, their start

and end points, and the potential business informa-

tion have also been identiﬁed. The analysis of these

two scenarios serves as a basis for the process model

developed as part of this research.

The ﬁrst scenario represents the interactions be-

tween a General Practitioner (GP) and a Hospital Lab-

oratory (Lab) (see Figure 2). The second scenario is

simpliﬁed view of a traditional supply chain scenario

and depicts the activities for and interactions between

the manufacturer and wholesaler (see Figure 3). Inter-

actions between the wholesaler and the retailer have

been omitted for clarity. In the case of both diagrams,

each participants’ set of activities are grouped using

the swimlane notation of process modelling notations.

The processes are modelled using traditional UML

activity diagrams. The communication between each

party is depicted using broken lines drawn between

the appropriate process in each swimlane. This inter-

action also carries a message containing relevant busi-

ness information. To fully understand the nature of

these collaborative processes, a set of core modelling

concepts have been determined: process, model, and

event. These concepts are discussed in the next sec-

tion.

Figure 2: Collaborative process between GP and Lab.

5 EVENT-BASED PROCESS

MODELLING

The process model developed as part of this research

includes three important process artefacts: process,

event and model. The process model also contains

other artefacts for representing organizational struc-

ture charts such as organizational unit, role and partic-

iWISE: A FRAMEWORK FOR PROVIDING DISTRIBUTED PROCESS VISIBILITY USING AN EVENT-BASED

PROCESS MODELLING APPROACH

227

Figure 3: Collaborative process between Manufacturer and

Wholesaler.

ipant. Each core artefact is explained in the following

subsections. However, the model does not deﬁne con-

trol ﬂow structures as used in existing modelling ap-

proaches. Distributed processes, when executed, may

be controlled by local systems or local workﬂow sys-

tems. It is not the aim of this research to build a model

that will control process executions (that is the role of

a process execution engine), but to model and analyze

as-is processes using raw system events. In addition,

the model described here is XML-based. Each arte-

fact has a corresponding XML Schema for construc-

tion and validation.

5.1 Processes

A process represents any step, task or unit of work

within an organization. General attributes for a pro-

cess includes a unique ID, process name and descrip-

tion. Organization employees may be responsible for

a process and this information is also recorded with

a process. A process can be associated with many

events. Events are discussed in more detail in Sec-

tion 5.3. A process may deﬁned by another level of

detail. This is captured using another model and is

considered a level deeper in the model hierarchy. In

Figure 4, process P1 has a sub-model M1. Process

P2 has a sub-model M2. There is a one to one rela-

tionship between a process and a model to represent

a sub-model of a process. Process P3 does not have a

sub-model deﬁned.

5.2 Models

At a diagram level, a model contains processes. Im-

portant attributes of a model include a unique ID,

name, and description. An additional boolean at-

tribute, called “root”, denotes a model that is the root

of a model hierarchy. Specifying models in this way is

necessary for efﬁcient retrieval and reconstruction of

models containing processes. In Figure 4, model M0

is not aware of models M1 or M2. A model uses the

concept of a “transition” to relate processes to each

other.

5.3 Events

This modelling approach supports enterprise event

modelling. An event represents something that hap-

pens in an enterprise where events occur as part of

process execution. An event type deﬁnition is linked

to a process deﬁnition (see Section 5.1). General at-

tributes of an event type include a unique ID, name

and description. There are six event types which can

be deﬁned and associated with processes.

• Queue Event

• Start Event

• Interrupt Event

• Resume Event

• Cancel Event

• End Event

This event classiﬁcation scheme captures the various

states of execution for a process. Each event deﬁni-

tion follows the same structure. In particular, an en-

terprise event will contain business information relat-

ing to the context in which the event occurred. For

this reason, an XML Schema is associated with an

event deﬁnition. The XML Schema deﬁnes the for-

mat and structure of the business information linked

to an event. For example, an Order Fulﬁlment Start

Event will contain an XML Schema comprising Pur-

chase Order information and other information rele-

vant to the process.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

228

Figure 4: A model hierarchy.

Another important attribute of the event deﬁnition

is required for event correlation purposes. For each

process instance within an enterprise system, events

are generated that contain information speciﬁc to that

instance. In order to correctly assess a process, the

correct events need to be matched together. This event

instance correlation process is achieved using an ele-

ment from the XML document to uniquely identify

event instances. The same element must be present

across all event deﬁnitions for each process deﬁni-

tion within the same model. This event correlation at-

tribute is called an “XMLPathExpression”. For exam-

ple, for an Order Fulﬁlment process, the Order Num-

ber can be used to match start and end events. Since

this information is included as part of the actual event

business information, then it must be selected at event

deﬁnition in order to correctly correlate the event in-

stance data at runtime.

Process models can be deﬁned hierarchically. In

this case, it is necessary to map events that occur at

lower levels to their parent start and end events. In

this case, the location of the parent event deﬁnition

is speciﬁed. Finally, a “UnitsProduced” attribute in-

dicates the output volume of the process each time it

executes successfully. Each process deﬁnition must

Figure 5: Enterprise process with associated start and end

events.

contain a Start Event and End Event deﬁnition. The

remaining event types listed above are optional. This

event classiﬁcation scheme will be useful for calcu-

lating process cycle time measurements and analyz-

ing process execution. Figure 5 illustrates the rela-

tionship between a process and events. Both “Or-

der Entry” and “Order Fulﬁlment” have a start and

end event. The “Order Entry” process has a Start

Event (StartEvent1) and an End Event (EndEvent1).

Each event carries XML data which encapsulates the

business information associated with the event. This

data is validated by the XML Schema speciﬁed by

the event deﬁnition. The processes are connected via

their events. The End Event (EndEvent1) of “Order

Entry” is linked to the Start Event (StartEvent2) of

“Order Fulﬁlment”. A company boundary may be

represented by the messages sent and received be-

tween its business partners. Any enterprise event may

be modelled and associated with a process.

This approach to modelling captures four essential

views important in the context of a process model:

• The data view: captured using events which carry

business data (XML data that conforms to an XML

Schema). Using this approach, business data is

linked to its creation and modiﬁcation context

within a process.

• The functional view: captured using the process

box notation, which represents an activity in the or-

ganization at any level of abstraction.

• The organizational view: users can model the or-

ganizational structure and express relationships be-

tween units, roles and people. A process owner is

an employee of the organization.

• The control view: processes are linked together via

start and end events thereby preserving the ﬂow be-

tween processes. These links are called transitions

in the process model.

iWISE: A FRAMEWORK FOR PROVIDING DISTRIBUTED PROCESS VISIBILITY USING AN EVENT-BASED

PROCESS MODELLING APPROACH

229

6 iWISE ARCHITECTURE FOR

PROCESS VISIBILITY

The iWISE framework includes the following main

components: the Process Capture Tool (PCT), Event

Server, Process Dashboard Portal and Legacy Lis-

teners (see Figure 6). The process capture soft-

ware allows users to model distributed processes.

Once captured, the process is deployed to the Event

Server component. The Event Server is responsi-

ble for managing process model deﬁnitions and the

business events and data generated by enterprise sys-

tems. Business process integration is achieved in two

phases. The ﬁrst phase, the process capture phase, re-

quires users to capture the processes and events for a

particular process model. The second phase, the pro-

cess deployment phase, compiles the process model

into objects required for event management. These

steps fulﬁl the process design function of this frame-

work.

Figure 6: Event Server Components.

At runtime, the Event Server manages a continuous

stream of raw enterprise events. The iWISE Process

Dashboard has been developed using the .Net frame-

work, and acts as the central portal and value chain

dashboard. The process model created by the PCT is

presented in the dashboard as a live process view with

drill-down capabilities used to provide access to per-

formance metrics generated by the Event Server. In

addition, the Process Dashboard uses the event clas-

siﬁcation described previously to display current pro-

cess execution statistics to the user, for example, num-

ber of processes started, cancelled, or completed.

6.1 Process Capture and Deﬁnition

In order to introduce a speciﬁc meta-model, which ad-

equately deﬁnes an existing process structure to the

system, one requires a software application to gener-

ate this model. For this purpose, the iWISE Process

Capture Tool is being developed which is a GUI ap-

plication that allows a user to visually construct and

deﬁne their existing business process structure within

a given supply chain. The PCT uses standard BPMN

(White, 2004), a derivative of the UML based on

(Eriksson and Penker, 2000) as visual contructs to de-

ﬁne the overall process structure. The output of this

activity is an XML-based meta-model which encap-

sulates and accurately represents this newly captured

structure. This meta-model is validated against an ab-

stract model schema and using Service Oriented Mid-

dleware is then persisted in a relational datastore. The

tool allows for rapid deﬁnition of an existing process

structure in a user friendly and intuitive environment,

based on simple drag and drop actions of model com-

ponents (see Figure 7).

Figure 7: PCT interface for capturing an existing supply

chain structure.

As the user constructs and modiﬁes a process struc-

ture, the meta model will be generated/altered accord-

ingly. During this phase the user will be prompted to

deﬁne various business events within their organiza-

tional unit and attribute them to respective business

processes. Furthermore, interesting parameters can

be ﬂagged from the business information these events

are deﬁned with for future monitoring. Also, transi-

tions can be applied to business processes and their

respective events which determine potential routes

taken by products/payloads in a given supply chain.

Along with the meta-model generated during the pro-

cess capture phase, the PCT can produce graphical

representations of the models in the Scalable Vector

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

230

Graphics (SVG) format and publish them to the web.

This feature allows iWISE Process Dashboard com-

ponents to retrieve these SVG models which serve as

a base interface on which the dashboard can then ex-

tend in order to provide graphical-based supply chain

monitoring capabilities. This feature enables the user

to drill down through a process hierarchy and view

the impact captured business events are having on the

overall supply chain in real time.

The application was developed for the Microsoft

.NET platform, and acts as a consumer participant

in an extended Service Oriented Architecture (SOA).

The PCT utilizes the ﬂexibility of XML to manipu-

Figure 8: SOA context overview of the Process Capture

Tool.

late and deﬁne business entities within a supply chain.

Then using SOAP-RPC, the PCT is then able to in-

voke remote web services to handle entity persistence

and pass native XML data structures as parameters

(see Figure 8).

6.2 Process Deployment

The iWISE Event Server component is a Java-based

enterprise application and performs two roles for pro-

cess integration. Firstly, it manages process models

captured using the PCT. Secondly, using the events

deﬁned as part of process models, it manages enter-

prise events received in near real-time. Each event

has an event deﬁnition that is linked to a process def-

inition (see Section 5.3). Figure 6 shows the Event

Server architecture. Currently, the Event Server ap-

plication comprises a Model Manager component and

Event Manager component. The Model Manager re-

ceives models created using the PCT and persists the

model deﬁnition using J2EE’s Enterprise Java Beans

(EJB) technology. Each model artefect described in

Section 5 has its own corresponding entity bean struc-

ture.

The Event Server application is deployed within

the J2EE-compliant JBoss Application Server. Inter-

action between the PCT and Model Manager software

component is achieved using Web services technolo-

gies. The Web service methods receive models cre-

ated by the PCT software in XML format. Data per-

sistence for models and events is achieved using EJB

Container Managed Persistence 2.0 with an underly-

ing Microsoft SQL Server 2000 database (see Fig-

ure 6).

6.3 Event Management

The iWISE Event Server receives events from Legacy

Listeners installed throughout the business environ-

ment. The listeners are responsible for responding

to new system events, packaging them appropriately,

and sending them to the Event Server for processing

and storage. The Event Manager component manages

a continuous stream of enterprise events using a com-

bination of Web services and Java Message Queue

(JMS) technologies. For each new event, the Event

Manager looks up the event deﬁnition persisted by the

Model Manager during model deployment. This al-

lows the Event Manager to extract the correct data for

event correlation purposes (see Section 5.3).

The principles of Event Driven Architectures

(EDAs) are present in the design of the Event Server

and Legacy Listener software. EDAs use events to

communicate between loosely coupled software com-

ponents. The Legacy Listener is conﬁgured to detect

speciﬁc events occurring within the enterprise sys-

tem and send them, in a format usable by the Event

Manager software, to the Event Server. In this way,

the Legacy Listener produces events and the Event

Manager consumes them. EDA architectures facili-

tate agility since event-driven systems are designed

for unpredictable and asynchronous business environ-

ments. The use of Web services as the transfer mech-

anism allows the addition of newly conﬁgured lis-

teners for distributed event management. Using this

approach, continuous data integration is achieved by

managing the events received from Legacy Listeners

located throughout the business context.

7 FUTURE WORK

The event-based process model introduced previously

is a valuable source of information for Business Ac-

tivity Monitoring software and other value-added ser-

vices. A central operational datastore for process ex-

ecution data and business information logged using

the prescribed event format acts as a repository for

iWISE: A FRAMEWORK FOR PROVIDING DISTRIBUTED PROCESS VISIBILITY USING AN EVENT-BASED

PROCESS MODELLING APPROACH

231

process performance measurement and analysis activ-

ities. This wealth of information can be used to pro-

vide process visibility in near real-time. The Event

Server consumes events as they are produced by the

business systems. These events can be processed and

further analyzed to derive events used to drive alerting

and notiﬁcation software. Processing of raw business

events is known as Complex Event Processing (CEP).

Such event-driven processing systems provide a ﬂex-

ible infrastructure for building real-time BAM soft-

ware (Knifsend and Debb, 2005). Process Mining,

(Agrawal et al., 1998) and (van der Aalst and Weijters,

2004), and statistical control techniques may also be

applied to the iWISE Event Server repository to yield

root cause analysis for out of control processes. In ad-

dition, processes can be simulated using iWISE sim-

ulation software which receives as input the event-

based process model captured using the iWISE PCT.

Using process analysis and simulation data processes

can be optimized with minimal latency in a constantly

changing business environment.

In recent years, consortia of businesses and re-

search institutions have developed process modelling

and deﬁnition languages to support interchangeable

business processes. (Mendling et al., 2004) analyze

ﬁfteen of the currently available XML-based business

process modelling languages for completeness using

a set of meta-model concepts extracted from the can-

didate speciﬁcations. These concepts include the abil-

ity of the speciﬁcation to include statistical data as

part of the business process meta-model. The inclu-

sion of statistical data for activities provides a busi-

ness process monitoring framework with information

to create relevant charts and alerts for its business

users. The study shows that the Workﬂow Manage-

ment Coalition’s (WfMC) XML Process Deﬁnition

Language is the only standardized interchange format

that includes process statistics. However, data cap-

tured is general and caters mainly for simulation ac-

tivities using statistical data such as costs and dura-

tions of tasks.

8 CONCLUSION

Fragmented collaborative and enterprise process visi-

bility requires a framework that integrates processes,

events and business information. This paper de-

scribed a common event-based model for integrating

disparate system processes and introduced the iWISE

BAM software architecture for process performance

monitoring. This approach brings together two im-

portant elements of enterprise modelling to provide

a more cohesive view of processes, the events gen-

erated by processes, and the business data manipu-

lated by the process. The iWISE framework allows

users to conﬁgure and manage event-based process

models using the iWISE Process Capture Tool and de-

ploy these models to the iWISE Event Server. iWISE

Legacy Listeners listen for system events and for-

ward these to the Event Server. Continuous data in-

tegration is achieved by packaging business data with

raw system events and sending it to the Event Server.

The Event Server processes a continuous stream of

event information and the iWISE Process Dashboard

presents users with up-to-date process information.

This generic approach is applicable to processes from

various business domains. A health-care process and

manufacturing process were presented in this paper

which the iWISE framework can support to enhance

business operational effectiveness through punctual

process visibility.

REFERENCES

Adams, C. W., Gupta, P., and Wilson, C. E. (2003). Six

Sigma Deployment. Butterworth Heinmann of Else-

vier Science.

Agrawal, R., Gunopulos, D., and Leymann, F. (1998). Min-

ing Process Models from Workﬂow Logs. In Proceed-

ings of the 6th International Conference on Extend-

ing Database Technology, pages 469–483. Springer-

Verlag.

Bobrik, R., Reichert, M., and Bauer, T. (2005). Require-

ments for the Visualization of System-Spanning Busi-

ness Processes. In The 16th International Work-

shop on Databases and Expert Systems Application,

Copenhagen, Denmark.

Casati, F. (2005). Industry Trends in Business Process Man-

agement: Getting Ready for Prime Time. In The 16th

International Workshop on Databases and Expert Sys-

tems Application, Copenhagen, Denmark.

Casati, F. and Discenza, A. (2000). Modeling and Managing

Interactions Amoung Business Processes. Technical

Report HPL-2000-159, Hewlett Packard, HP Labora-

tories Palo Alto, CA.

Caulcutt, R. (2001). Why is Six Sigma so successful? Jour-

nal of Applied Statistics, 28(3-4):301–306.

Costello, C., Molloy, O., Lyons, G., and Duggan, J. (2005).

Using Event-based Process Modelling to Support Six

Sigma Quality. In The 16th International Workshop on

Databases and Expert Systems Application, Copen-

hagen, Denmark.

Eder, J., Olivotto, G. E., and Gruber, W. (2002). A Data

Warehouse f or Workﬂow Logs. In EDCIS ’02: Pro-

ceedings of the First International Conference on En-

gineering and Deployment of Cooperative Informa-

tion Systems, pages 1–15. Springer-Verlag.

Eriksson, H.-E. and Penker, M. (2000). Business Modeling

with UML, Business Patterns at Work. OMG Press.

Kapoor, S., Bhattacharya, K., Buckley, S., Chowdhary,

P., Ettl, M., Katircioglu, K., E.Mauch, and Phillips,

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

232

L. (2005). A Technical Framework for Sense-and-

Respond Business Management. IBM Systems Jour-

nal, Vol. 44(No. 1):5–24.

Knifsend, F. and Debb, J. (2005). Using BAM to Em-

power the Organization: Unifying Events and Pro-

cesses. Business Integration Journal, pages 27–29.

McGregor, C. and Schiefer, J. (2004). A Web-Service based

framework for analyzing and measuring busness per-

formance. Information Systems and e-Business Man-

agement, 2(1):89–110.

Mendling, J., Neumann, G., and Nuttgens, M. (2004). A

Comparison of XML Interchange Formats for Busi-

ness Process Modelling. In EMISA: Information Sys-

tems in E-Business and E-Government, Luxembourg.

Mitchell, B. (1992). The Six Sigma Appeal. Engineering

Management Journal, 2(1):41–47.

Smith, B. (1993). Making war on defects: Six-sigma de-

sign. IEEE Spectrum, pages 43–47.

Stefanov, V. and List, B. (2005). A Performance Measure-

ment Perspective for Event-driven Process Chains. In

The 16th International Workshop on Databases and

Expert Systems Application, Copenhagen, Denmark.

van der Aalst, W. and Weijters, A. (2004). Process Min-

ing: A Research Agenda. Computers in Industry,

53(3):231–244.

White, S. (2004). Business Process Modeling Notation

(BPMN), Version 1.0. Technical report, The Business

Process Management Initiative (BPMI.org).

iWISE: A FRAMEWORK FOR PROVIDING DISTRIBUTED PROCESS VISIBILITY USING AN EVENT-BASED

PROCESS MODELLING APPROACH

233