Claire Costello, Weston Fleming, Owen Molloy, Gerard Lyons and James Duggan
Department of Information Technology
National University of Ireland, Galway
Business process performance management, Business Activity Monitoring (BAM), process modelling.
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.
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 difficult 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 financial 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
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 defining 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.
Process management approaches and techniques are
subject to continuous investigation by both academia
and industry. Some of the trends in BPM include
Costello C., Fleming W., Molloy O., Lyons G. and Duggan J. (2006).
In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 224-233
DOI: 10.5220/0002497002240233
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 definition of processes, ser-
vices and metrics to facilitate integration of business
information to provide process visibility and impact
Research undertaken by the same institution
(Casati and Discenza, 2000) developed a model
for specifying interaction among workflow systems
to achieve distributed business process interaction.
The model extends traditional activity modelling ap-
proaches to include the definition of event nodes
which represent points within the flow 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 Workflow Manage-
ment Coalition’s XML Process Definition Language
Extending current process modelling approaches or
specifications 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 Workflow Management Systems and Busi-
ness Process Management Systems document the exe-
cution of process instances using workflow 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-
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 define 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-
fined 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).
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 specifications aid the designer in
capturing and specifying various parameters required
for other stages of the process such as execution and
monitoring. Business content specifications 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
specification. The main output of these standards is a
library of reusable components for building business
Figure 1: Modelling, deploymen t and integration technolo-
gies for process management.
Process modelling specifications define 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 flows, join and
split flows, decision points, text annotations, pools
and swimlanes. Examples of such standards include
the Business Process Modelling Notation (BPMN)
and the Unified 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 Defi-
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
Business integration and service composition tech-
nologies detail the process from an execution point of
view. These specifications are also known as process
definition languages and such files are used as inputs
to process execution engines. In the current technol-
ogy landscape, this space is filled 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 five steps: Define, Measure, An-
alyze, Improve and Control (DMAIC). This method
follows from the Six Sigma methodology for process
improvement (Adams et al., 2003).
Define Capture the process requirements in a de-
finable 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 definition 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
defined in previous step. Metrics definitions are
based on cycle times and other Six Sigma calcu-
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 (fishbone) dia-
grams. Use Web-based dashboard portal technolo-
gies as a central point of process monitoring.
Improve Use dashboard to identify bottlenecks and
inefficiencies 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
Business IT infrastructures typically include many
enterprise systems. Each system is responsible for
carrying out operations on behalf of its business users.
It is difficult to model business processes that span
multiple systems. What is required is an end-to-end
definition 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 definition 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 fulfilment
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 fulfilment process describes the
steps and control flow 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 defines
these two entities cohesively. This unifies 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 identified for developing the process model.
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-
tified activities or tasks, a number of messages have
been defined 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 identified. The analysis of these
two scenarios serves as a basis for the process model
developed as part of this research.
The first scenario represents the interactions be-
tween a General Practitioner (GP) and a Hospital Lab-
oratory (Lab) (see Figure 2). The second scenario is
simplified 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-
Figure 2: Collaborative process between GP and Lab.
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-
Figure 3: Collaborative process between Manufacturer and
ipant. Each core artefact is explained in the following
subsections. However, the model does not define con-
trol flow structures as used in existing modelling ap-
proaches. Distributed processes, when executed, may
be controlled by local systems or local workflow 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 defined 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 defined.
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 efficient 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
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 definition is linked
to a process definition (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 defined and associated with processes.
Queue Event
Start Event
Interrupt Event
Resume Event
Cancel Event
End Event
This event classification scheme captures the various
states of execution for a process. Each event defini-
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 definition. The XML Schema defines the for-
mat and structure of the business information linked
to an event. For example, an Order Fulfilment Start
Event will contain an XML Schema comprising Pur-
chase Order information and other information rele-
vant to the process.
Figure 4: A model hierarchy.
Another important attribute of the event definition
is required for event correlation purposes. For each
process instance within an enterprise system, events
are generated that contain information specific 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 definitions for each process defini-
tion within the same model. This event correlation at-
tribute is called an “XMLPathExpression”. For exam-
ple, for an Order Fulfilment 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
definition in order to correctly correlate the event in-
stance data at runtime.
Process models can be defined 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 definition
is specified. Finally, a “UnitsProduced” attribute in-
dicates the output volume of the process each time it
executes successfully. Each process definition must
Figure 5: Enterprise process with associated start and end
contain a Start Event and End Event definition. The
remaining event types listed above are optional. This
event classification 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 Fulfilment” 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 specified by
the event definition. The processes are connected via
their events. The End Event (EndEvent1) of “Order
Entry” is linked to the Start Event (StartEvent2) of
“Order Fulfilment”. 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 modification 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 flow be-
tween processes. These links are called transitions
in the process model.
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 definitions and the
business events and data generated by enterprise sys-
tems. Business process integration is achieved in two
phases. The first 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 fulfil the process design function of this frame-
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-
sification 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 Definition
In order to introduce a specific meta-model, which ad-
equately defines 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
define 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-
fine 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 definition 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 modifies a process struc-
ture, the meta model will be generated/altered accord-
ingly. During this phase the user will be prompted to
define various business events within their organiza-
tional unit and attribute them to respective business
processes. Furthermore, interesting parameters can
be flagged from the business information these events
are defined 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
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 flexibility of XML to manipu-
Figure 8: SOA context overview of the Process Capture
late and define 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
defined as part of process models, it manages enter-
prise events received in near real-time. Each event
has an event definition 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 definition using J2EE’s Enterprise Java Beans
(EJB) technology. Each model artefect described in
Section 5 has its own corresponding entity bean struc-
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 definition 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 configured to detect
specific 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 configured 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.
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
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 notification software. Processing of raw business
events is known as Complex Event Processing (CEP).
Such event-driven processing systems provide a flex-
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 definition languages to support interchangeable
business processes. (Mendling et al., 2004) analyze
fifteen of the currently available XML-based business
process modelling languages for completeness using
a set of meta-model concepts extracted from the can-
didate specifications. These concepts include the abil-
ity of the specification 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 Workflow Manage-
ment Coalition’s (WfMC) XML Process Definition
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.
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 configure 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.
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 Workflow Logs. In Proceed-
ings of the 6th International Conference on Extend-
ing Database Technology, pages 469–483. Springer-
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 Workflow 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,
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,
White, S. (2004). Business Process Modeling Notation
(BPMN), Version 1.0. Technical report, The Business
Process Management Initiative (BPMI.org).