BUSINESS PROCESS MODELLING THROUGH EQUIVALENCE
OF ACTIVITY PROPERTIES
Carla Marques Pereira and Pedro Sousa
CEO-INESC/Link Consulting, SA, Av. Duque de Ávila, 23, 1000-138 Lisboa, Portugal
Keywords: Business Process, Activity Equivalence, Process Equivalence, Zachman Framewok.
Abstract: Since two decades ago, business processes have been gaining attention from IS’ managers, consultants and
researchers and are becoming a key element in driving IT innovation. Despite such prominence, the concept
of business process is not clear enough and even more unclear is the way to depict organization activities
into a process blueprint. We claim that a much more precise and consolidate concept for “business process”
is required. In this paper, we explain the constraints that influence business process modelling and we
propose a solution based on a multi dimensional representation that decomposes processes into the Zachman
Framework dimensions. Upon our solution we build up the concept of process equivalence.
1 INTRODUCTION
Business Process is a common concept in many
knowledge domains related with organizations and
plays a central role in organization management and
design. Many authors consider Business Processes to
be one of the most important concepts in an
organization (Davenport, 1990; Grover, 1995;
Hammer, 2001; Labovitz, 1997; Potter, 1985; Senge,
1990; Dietz, 2006; Eriksson, 2000).
Being a description of organization internal
behaviour, business processes are fundamental to
understand how companies conduct their business,
and therefore how they can improve their efficiency,
monitor their operations, adhere to regulatory
compliance standards, choose the appropriate skills
of their staff to achieve better results, use workflow
engines for process automation and so on.
The purpose of business process modelling is the
construction of a concise, unambiguous
representation of a business or a business area in
terms of the activities that take place in the
organization, either currently ('AS-IS') or in the
future ('TO-BE').
Current business process analyses tools allow
several process modelling notations to be used,
ranging from simple flow charts to more elaborated
models such as UML, BPMN, EPC, IDEF3,
amongst others. Most tools also allow a series of
analysis (impact analysis, what-if scenario analysis,
and process simulation) to be done upon business
process blueprints.
Under such a powerful environment of notations
and tools, business process modelling should result
into business process blueprints that allow a
common understanding and vision of the business
amongst all business stakeholders and other staff.
Unfortunately, this is not what happens in most
situations, where one could find multiple process
blueprints for the same “organization process”. We
found two main reasons for this.
On one hand, different process stakeholders
belonging to different organization areas - for
example business line, IT, Auditing, Compliance, or
Human Resource - have different concerns and look
for different perspectives from the same business
processes. This issue is not at all a new situation. A
very similar situation exists in architectural
blueprints, where different architecture stakeholders
perceive different blueprints of the same system
(IEEE, 2000).
On the other hand, too much of the final process
blueprint is dependent of the team that has designed
it. Different teams always get different blueprints
and it is very hard to assess if they are equivalent or
not.
In practice, the existence of multiple process
perspectives forces the organizations to maintain
various process blueprints, most probably in
different repositories. Since there are, to our
knowledge, no instruments for assessing the
137
Marques Pereira C. and Sousa P. (2008).
BUSINESS PROCESS MODELLING THROUGH EQUIVALENCE OF ACTIVITY PROPERTIES.
In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 137-146
DOI: 10.5220/0001710001370146
Copyright
c
 SciTePress

coherence or the equivalence of different process
blueprints, this becomes a major drawback for
organizations.
In this paper we address the problem of
establishing the grounds for business process
equivalence, that can be used both for assessing the
equivalence between different process blueprints and
for defining the rules for producing different process
blueprints based on a give master process blueprint
kept in some master process repository.
The outline of the paper is as follows. Section 2
presents the state of the art of different approaches,
techniques and notations to business process
modelling. Section 3 presents our proposal for the
concept of business process in the context of the
Zachman Framework. Section 4 presents our
proposal for process equivalence. In Section 5 we
present our case to validate the applicability of this
process modelling approach. Finally, we draw some
conclusions and describe ongoing research.
2 STATE OF ART - BUSINESS
PROCESS MODELLING
Common definitions of business process concepts
include a sequence of activities producing “value”:
- A process is a course of action, a series of
operations, or a series of changes (Concise Oxford
Dictionary).
- Processes represent the flow of work and
information throughout the business. (OMG, 2005).
- A business process is a collection of activities
that takes one or more kinds of inputs and creates an
output that is of value to the customer (Hammer,
2001).
- Every organization exists to accomplish value-
adding work. The work is accomplished through a
network of processes. Every process has inputs, and
the outputs are the results of the process (ISO,
1995).
- A kind of process that supports and/or is
relevant to business organizational structure and
policy for the purpose of achieving business
objectives. This includes manual and/or workflow
processes (W3C, 2002).
- A process is a circle of causality that describes
a feed back loop of cause and effect. From the
systems perspective, the human actor is part of the
feedback process, not standing apart of it (Senge,
1990).
- Business process is a flow of activities, with
one or more clear starting points and leading to a
clearly defined result (Lankhorst, 2005).
- A Business Process is a coordinated set of
activities that is able to add value to the customer,
and to achieve business goals (Sousa, 2006).
The above concepts of business process are
based on the notion of action and value creation. In
fact, these definitions do not address all the aspects
of the reality that are critical in business process
modelling, such as time, location, motivation and
used resources to produce the output.
Since these aspects make all the difference in the
business world, business process blueprints are
normally represented using specific notations
(BPMN, UML, EPC or IDEF3) that address a wider
scope of dimensions.
- in BPMN, a business process is a network of
‘doing things’. To model a business process flow,
you simply model the events that trigger the
processes, the processes that get performed, and the
end results of the process flow. Business decisions
and branching of flows is modelled using gateways.
A gateway is similar to a decision symbol in a
flowchart. If a process is not decomposed by sub-
processes, it is considered a task – the lowest-level
process. As one drive further into business analysis,
one can specify ‘who does what’ by placing the
events and processes into shaded areas called pools
that denote who is performing a process. One can
further partition a pool into lanes. A pool typically
represents an organization and a lane typically
represents a department within that organization
(although you may make them represent other things
such as functions, applications, and systems).
- In UML a business process consists of one or
more related activities that together respond to a
business requirement for action. A process defines
the results to be achieved, the context of the
activities, the relationships between the activities,
and the interactions with other processes and
resources. A business process may produce events
for input to other systems or processes. A business
process may also invoke applications to perform
computational functions, and it may post
assignments to human work lists to request actions
by humans. Business processes often involve the
assignment of resources, such as human participants,
facilities or materials. Resources to be assigned to a
managed process are specified by selection criteria
to be applied to a defined source of resources. This
may be, for example, people in an organization,
facilities on a campus or materials in an inventory.
ICEIS 2008 - International Conference on Enterprise Information Systems
138

- Event-driven Process Chains (EPC) is a method
developed by Scheer, Keller and Nüttgens within the
framework of Architecture of Integrated Information
System (ARIS) to model business processes. In EPC
a business process is a collection of elements that are
capable of portraying business information system
while at the same time incorporating other important
features such as functions, data, organizational
structure and information resources as already
described before.
- In IDEF3, a business process is an ordered
sequence of events involving people, materials,
energy, and equipment that is designed to achieve a
defined business outcome. They not only define
what the business does, but more importantly, they
determine how well the business does what it does.
We classify (Table 1) the elements that
characterize each notation in 6 dimensions (what,
who, where, how, when, and why) that are the
common questions to characterize a happening or
situation.
Table 1: Notations’ Elements into the Zachman
Framework’s Dimensions.
Notation Element Dimension
Event When
Activity How
Gateway Why
Swimlane Where (Who)
BPMN
Data Object What
Activity How
Decision Point Why
Swimlane Where (Who)
UML
Action Object What
Unit of Behavior (UOB) How
Object What
IDEF3
Junction Why
Event When
Function How
Organization Unit Where (Who)
Information, material, or resource object What
EPC
Logical connector Why
Unfortunately, neither the syntax nor the
semantics of these notations are well defined. As a
result, a business process represented by these
notations may be ambiguous. Moreover, it is not
possible to check the model for consistency and
completeness. The absence of formal semantics also
hinders the comparison of models between different
notations and prevents the use of powerful analytical
techniques.
Looking into formal business processes
definitions, they are rather limited in scope,
regardless of their accuracy. The most popular
formal technique for business process modelling is
the Petri Net which exhibit concurrency, parallelism,
synchronization, no-determinism, and mutual
exclusion. In this technique the main concern is how
the workflow is represented and not considers the
others dimensions with the same relevance. In other
formal definitions a process is defined mostly by its
outputs (Jagannathan, 1995; Linz, 2000).
As an example of formal approaches limitations,
if two processes have the same output (results) but
use different human skills in different locations and
in different moments, would be consider equivalent
by formal approaches, whereas there are by no
means equivalent in the real world.
Besides the issue of the concept and model of
business processes, there is another relevant issue
that leads the same real process be depicted as to
multiple and different process blueprints.
Although several methodologies or approaches
that conduct us to produce a business blueprint
within a type of graphical where the methodology
for process modelling is understood fundamentally
as an art where the experience and common sense
are mandatory skills.
Regardless these methodologies could follow
top-down approaches (breaking up value creation in
to smaller activates), or bottom-up approaches
(aggregating activities into value creation
granularity) there are no guaranties that the
blueprints obtained will be the similar.
In this cycle of breaking processes into activities
or aggregating activities into processes and represent
them graphically, the boundaries between what can
be designate as process or activity is unclear in most
of the previous methodologies or notations, and the
concept of process equivalence is not applied or
formally stated.
In summary, we presented two causes for the
importance of having a mechanism to analyze
business process equivalence: i) multi-blueprints and
ii) modelling skills.
To tackle these issues, this paper proposes using
a set of modelling rules derived from the Zachman
Framework Dimensions to model business
processes.
BUSINESS PROCESS MODELLING THROUGH EQUIVALENCE OF ACTIVITY PROPERTIES
139

3 BUSINESS PROCESS
MODELLING IN THE
CONTEXT OF THE ZACHMAN
FRAMEWORK
The Zachman Framework (Zachman, 1987) for
Enterprise Architecture is probably the best known
framework for describe an architecture of an
enterprise. It proposes a logical structure for
classifying and organizing the descriptive
representations of an enterprise.
The Zachman framework proposes a matrix-like
structure for classifying and organizing the
representations of an enterprise (Sowa, 1992;
Zachman, 1987). The rows consider six different
perspectives on the enterprise, representing its major
stakeholders: visionary, executive leader, architect,
engineer, implementer and the organization worker.
The columns specify six contextual dimensions
summarized in Table 2.
Table 2: Dimensions of the Zachman Framework.
Dimension Focus Purpose
What Data
The enterprise’s information and its
dependencies.
How Function
The process of creating value to the
organization into its business and into
successive definitions of its operations.
Where Network
The geographical distribution of the
organization’s activities and artifacts.
Who People
Who is related with the major active
elements that animate business processes,
information and IT. It goes from
organizations, to HW servers, passing
thought Departments, Roles and People.
When Time
How each artefact relates and evolves
with time.
Why Motivation
The translation of goals into actions and
objectives.
We support our approach in business process
modelling through based on thee of the six
properties of the Zachman Framework (Inmon,
1997):
- classification: every artifact of the organization
can be uniquely classified;
- recursiveness: the whole framework cam be
applied to further specify the contents of each cell.
Usually one applies the Zachman Framework to an
enterprise, but every single artefact of the enterprise
can be better understood if one applies the whole
framework to it.
- cell uniqueness: which tells that each cell of the
framework must be described with the sufficient
level of detail so that it accomplishes its purpose.
We make use of the Zachman Framework
recursively (Figure 1) to express the characterization
of business processes, but we will focus on the first
two rows of the framework.
WHAT HOW WHERE WHO WHEN WHY
Scope
Business
System
Technology
Component
WHAT HOW WHERE WHO WHEN WHY
Scope
Business
System
Technology
Component
BP
Work Domain
Figure 1: Zachman Framework Recursive Use.
The cell uniqueness is the second rule of the
Zachman Framework, So, each dimension of the
framework is in fact a hierarchy of concepts/values,
typically presented as a tree (Figure 2).
General
Colonel A
Private B
Private A
Ser geant BSergeant A
Captain C
Captain BCaptain A
Colonel B
Figure 2: Dimension Tree (Who’s Dimension).
Generically, we define G as the hierarchical tree on
each dimension (D) of the Zachman Framework:
Di = {G
1
;…; G
n
},
where i is each one of the six dimension of the
Zachman Framework.
In figure 2, we present the tree as show next,
who = {General(Colonel A, Colonel B(Captain A(Sergeant A, Sergeant
B(Private A, Private B)), Captain B, Captain C ))}
ICEIS 2008 - International Conference on Enterprise Information Systems
140

Therefore, a business process can be defined as a
set of connected activities with inputs and outputs,
which interact with people, contribute to achieving
business goals, take place in a specific location and
occur during a period of time (Pereira, 2006).
Applying the previous business process
definition, and attending to the dimension hierarchy
level (see figure 2), a business process can be
represented as a concept which is related to others
concepts that belong to a set of elements {D[n,i];…;
D[n,i]}, where n represents the level in the
dimension tree (D) and, i
{what, how, where,
who, when, why}, as figure 3 presents.
Business Process
WHAT
WHERE
WHY
WHO
WHEN
HOW
Business Goals
Actor/Role
Time
Entities
Location
Figure 3: Business Process and the Zachman Framework
Dimensions.
Doing this classification we can realize that any
concept used to represent processes is as a matter of
fact an instantiation of one dimension and, any
dimension can be decompose until the level that one
thinks that is sufficient enough to describe that
process.
For the how’s dimension, we model business
work using a recursive and hierarchical structure for
a single concept which we call process. Processes
can be decomposed infinitely into other processes.
However, we name the leaves of the process tree as
activities. So, activities are processes that have no
further decomposition.
To decompose processes into activities, we will
apply a rule for process decomposition (Pereira,
2006). This, which specifies that a process α should
be decomposed into two or more distinct discrete
activities if one of the following conditions is
satisfied:
- α can be decomposed into two activities such
that they receive/create different data entities.
- α can be decomposed into two activities such
that they are processed using different
applications.
- α can be decomposed into two activities such
that they occur in different locations.
- α can be decomposed into two activities such
that they involve different business actors.
- α can be decomposed into two activities such
that they are performed in distinct periods of
time.
- α can be decomposed into two activities such
that they exist to satisfy different purposes.
So, at this point, we are in conditions to model
business process. For example, one could say that if
a process as an activity k that involves person p1 and
p2 in such a way that one could state that p1 works
before p2, the one could model k as k1 and k2, where
p1 is involved in k1 and p2 is involved in k2. Now,
if p1 and p2 participate in k1, then we could not
decompose k.
Given the two processes modeled as above, how
can we say that two different business blueprints are
equivalents? What criteria should be applied to
choose one instead of the other? As we previously
referred, there are no allusions how to solve this
issue on the methodologies or notations for
modeling business processes. In next section we
present our approach for identify equivalence
between business processes.
4 BUSINESS PROCESS
EQUIVALANCE
As any other modelling and architecting activity,
process modelling is understood fundamentally as an
art where the experience in consultancy, knowledge
of the business and common sense are mandatory
skills.
One could argue that such scenario occurs in any
modelling activity and in fact is similar to other
modelling domains such as data modelling in
database. Indeed the same issues arose, but due to
many decades of consolidation and solid theoretical
models, data modelling has found means to
overcome much of the problems we encounter in
business process modelling. Database conceptual
models together with the relational model provide
sound mechanisms to address such issues.
In fact, in what concerns the first cause presented
on the previous section, multi-blueprints, the
concept of view is a mechanism that allows having
different inspections upon a common and single
BUSINESS PROCESS MODELLING THROUGH EQUIVALENCE OF ACTIVITY PROPERTIES
141

canonical model. The coherence amongst the
different views is ensured by the canonical model.
We claim that a formal mechanism is needed to
define process views over a single and canonical
business process.
Regarding the second cause, skills for modelling,
data models do tend to be very dependent of the
modeller, but, despite such dependency, the concept
of “model equivalence” is a primitive that allows
checking the equivalence between the different
models.
In data modelling, a concept - for instance and
entity in the Entity Relationship model or a class in
the UML class model- is solely defined by the
properties of that concept (Batini, 1992). For
example, in the case of the Entity Relationship
model, the properties of the concept Entity are its
attributes, an identifier and the relationships with
other entities. Thus two Entities are equivalent if
they have the same properties, regardless of their
name. In figure 4, we present two equivalent
definitions of the same Entity, even thought the
designer name them differently.
Car
plate
make
color
Vehicle
plate
make
color
Driver
drives
Driver
drives
Figure 4: Entity Equivalence Example.
We propose that the same should occur with
business process models, as the following example
illustrates in figure 5. Consider two simple scenarios
(A and B). In scenario A activities were named
Driving and Riding. However, both activities are
associated with a Truck and have John as the driver.
In scenario B, both activities were named Driving,
though the first activity is associated to a car with
Paul as driver, whereas the second is associated with
a Truck with John as driver.
Regardless of the names given to each activity, it
is clear that they are equivalent in scenario A, and
that they are not equivalent in scenario B.
In database models, equivalence goes a step
forward. A database schema Sa (a set of entities and
relationships) is functionally equivalent to a
database schema Sb if, for each query one may think
off for schema Sa, there is a query for schema Sb
that produces the same value.
Figure 5: Activity Equivalence Example.
Defining the processes of scenario A of figure 5
as follow:
Driving {Truck[1,what]; John[1,who]}
Riding {Truck[1,what]; John[1,who]}.
Is it possible to say that Driving is equivalent (≡)
to Riding? To answer this question, we will present a
set of principles that will help us to say in which
conditions two processes are dimensional
equivalents, but at this point, to simplify our
presentation, we consider first the simple case of
dimensional activity equivalence. Dimensional
equivalence is a weak type of equivalence.
A ≡ A’: An activity (A) is dimensional equivalent
to another (A’) when each activity has equal
{D[n,i]
i
; …; D[n,i]} and i is not null.
This means that A and A’ have NO DIFFERENTE
when, what, where, who, and why
So, we can conclude that in the scenario A,
Driving is equivalent to Riding and, therefore the use
of different names for the same meanings could be
detected.
Regarding scenario B of the figure 5:
Driving {Truck[1,what]; John[1,who]}
Driving {Car[1,what]; Paul[1,who]} .
Applying the previous principle, we can
conclude that these activities, despite their equal
name, are not equivalent, because they have
different what and who. This is the case of using
same name for different meanings.
ICEIS 2008 - International Conference on Enterprise Information Systems
142

To address the situation of dimensional process
equivalence, we will use the same principle of
dimensional activity equivalence.
For that we will use the concept of transitive
closure (T), which means, consider a directed graph
G=(V,E), where V is the set of vertices and E is the
set of edges. The transitive closure of G is a graph
G+ = (V,E+) such that for all v,w in V there is an
edge (v,w) in E+ if and only if there is a non-null
path from v to w in G.
P ≡ P’: A process (P) is dimensional equivalent
to another (P’) when P transitive closure (T) is
equal to P transitive closure:
T(P) = T(P’) .
This means that P and P’ have the same when,
what, where, who, and why for all of its children,
if the dimension is used.
Using the following example, Cooking a
Chocolate Cake and Cooking an Apple Cake are two
processes. Let us imagine that the process of
Cooking a Cake can be decomposed in: sift, stir,
sprinkle and cook. Probably we could decompose
some of them a little more, but let assume like this.
For cooking a cake we need ingredients, one or more
people to do it, a specific location, time, and a
motivation. By common sense, if we follow the
same recipe for cooking the cake, we probably will
have the same result. Imagine now that we are going
to cook a chocolate cake and an apple cake. We will
have the same activities, but we need to change
ingredients to have different cakes. Can one say that
Cooking a Chocolate Cake and Cooking an Apple
Cake are dimensional equivalents?
Yes, they are equivalent if we use the how,
where, who and when, because to cook the cake we
have the same activities, done by the same person, in
the same place at same time, however if we consider
the what dimension the ingredients are different and
for that we can not say that they are equivalents.
Resuming, dimensional process equivalence is
translated in the relationship that a process has with
other dimensions. As we referred, dimensional
equivalence is a weak type of equivalence since we
only consider the structural aspect of the process. To
accomplish full equivalence we should also consider
the behavioural aspect of the process, i.e. the flow
among activities. This characteristic will be address
in future work.
5 CASE STUDY
We conduct an experimenting case to validate the
applicability of this business process modelling
approach. We create two different teams, Team A
and Team B responsible for design activities for the
same organization. Each member of team A had as
mission describing those activities recurring to all
the dimensions of the Zachman Framework. The
members of team B should describe activates
aggregated for dimensions, which means, they only
should considered as different activities those whose
the dimension answers were not the same. The
purpose was to produce, as many as possible,
activity schemas and compare them at the end.
Examples of those blueprints are the following
figures that show a real example, for a
Governmental Travel Agency with two processes for
booking trips. The first type of booking is open for
everybody (figure 6); the second one is exclusive for
senior people, which implies specific documentation
to prove that they are in conditions of use the special
price rates (figure 7). We have different blueprints to
represent two processes with activities that have the
same name but we can conclude that they are
equivalent.
During this phase of experimentation and
blueprint’s analysis we develop a tool for controlling
the level of detail in which each dimension will be
used for equivalence evaluation. This Level of
Detail Controller (Figure 8) enables us to set up the
level for each dimension and therefore define the
criteria to apply in the process equivalence analysis.
In the blueprints of figure 6 and 7 the controller
was set upped as we present on figure 9 and in these
conditions the activities Book Reservation are not
equivalents base on what we present previously in
this paper, because they take place in different
locations, one is executed in Reception Desk and the
other in Booking Desk. However, if we reset up the
controller as we show in figure 11 we could say that
those activities are equivalent, because they refer the
same location (where), use the same input data
(what), produce the same output data (what),
produce the same output data (what) and are perform
by the same people (who).
During this experimenting case we have realized
that for applying the principles of equivalence
through the Zachman Framework dimensions leads
to decompose concepts in several levels of detail.
This implies a large number of instances and without
a tool is not very practical for human manipulation
and analysis.
BUSINESS PROCESS MODELLING THROUGH EQUIVALENCE OF ACTIVITY PROPERTIES
143

DTS
Reception Desk
Check Availability
Inform Customer
Wainting
List?
No
Yes
No
SCG
Trip
Available?
Book Waiting List
Entry Application
Entry Application
(Waiting List)
Book ReservationYes
SCG
TripEntry Application Customer
Reservation
Mary
Susan
Mary
Mary
Susan
Figure 6: Booking Trip Blueprint.
DTS
Reception Desk
Check Documents
Inform Customer
No
Document
Ok?
Yes
Entry Application
Check Availability
Inform Customer
Wainting
List?
No
No
SCG
Available?
Booking Desk
Yes
Entry Application
Paul
Paul
Trip
Peter
Peter
Book Waiting List
Entry Application
Entry Application
(Waiting List)
Book Reservation
SCG
Trip Customer
Reservation
MarySusan
Yes
Figure 7: Booking Trip Senior Blueprint.
ICEIS 2008 - International Conference on Enterprise Information Systems
144

Figure 8: Level of Detail Controller.
Figure 9: Controller Criteria I.
Figure 10: Controller Criteria II.
We used the enterprise architecture tool, System
Architect, to manage all process instances and their
relationships.
The implementation of the proposal approach for
business process modelling holds the necessary
information to achieve two major results:
(1) There is more independency and objectivity
for teams doing the process analysis; this means
that after they populate the tool with business
processes blueprints, this can evaluate them
through the principles of equivalence that we
proposed. (2) It allows us to building specific
views to specific process stakeholders. A view is
a set of dimensions criteria that are different in
processes or activities. For example, a view
including only different why’s would lead to the
common value producing view of processes.
BUSINESS PROCESS MODELLING THROUGH EQUIVALENCE OF ACTIVITY PROPERTIES
145

A view including only where, what and when,
would by suited for a logistics view of the
processes. A view based on who, would be
adequate for the human resources analysis. A
view based on what and how, would be suited for
and information systems analysis, and so on.
6 CONCLUSIONS AND FUTURE
WORK
In this paper we discussed the difficulty in
modelling business process which consequently
produces different business blueprints. We propose a
business process modelling approach based on the
Zachman Framework Dimensions. We can conclude
that using these criteria for analyzing and designing
business processes and activities we reduce the
number of different blueprints. We also believe that
such an engineering approach for processes would
lead to a solid basis for addressing other domains,
such as Enterprise Architecture, IT Alignment,
Organization Reasoning, etc.
We introduce the concept of dimensional process
equivalence and we are optimistic relatively to its
pertinence and applicability in business processes
blueprints.
Our ongoing and further work also includes
understanding the relationships between the
Zachman Framework’s rows and columns as well as
the joint criteria that can be obtained from them. It is
also important to analyse the correct sequencing of
the criteria in order to define a business process
modelling method within a given context. It is our
intention extends these principles of equivalence to
any concept of an organization.
ACKNOWLEDGEMENTS
Carla Marques Pereira would like to gratefully
acknowledged Fundação para a Ciência e a
Tecnologia (FCT, Portugal) for financial support.
REFERENCES
C. Batini, S. Ceri, C. Batini: Conceptual Database Design:
An Entity-Relationship Approach, Addison Wesley
Publishing Company, 1991
Davenport, T.; Short, J.: The New Industrial Engineering:
Information Technology and Business Process
Redesign, Sloan Management Review, Summer, 1990,
11-27.
Dietz, J.: O.: Enterprise Ontology: Theory and
Methodology. Delft: Springer, 2006.
Eriksson, H.; Penker, M.: Business Modeling With UML:
Business Patterns At Work: John Wiley & Sons, 2000.
Grover, V. et.al.: The Implementation of Business Process
Reengineering, Journal of Management Information
Systems, 1995, 12(1), 109-144.
Hammer, M.; Champy, J.: Reengineering the Corporation:
A Manifesto for Business Revolution. London:
Nicholas Brealey Publishing, 2001.
IEEE: IEEE 1471, Institute of Electrical and Electronics
Engineers, 2000.
Inmon, W. et.al.: (1997). Data Stores, Data Warehousing,
and the Zachman Framework, McGraw-Hill, 1997.
ISO: ISO/IEC 10746 ODP Reference Model, International
Standards Organization, 1995.
Jagannathan, R.: Data Flow Models. In Zomaya, E. (ed),
Parallel and Distributed Computing Handbook. New
York: McGraw-Hill, 1995.
Labovitz , G.; Rosansky, V.: Power of Alignment: How
Great Companies Stay Centered and Accomplish
Extraordinary Things. New York: John Wiley & Sons
Inc, 1997.
Lankhorst, M. et.al.: Enterprise Architecture at Work:
Modelling, Communication, and Analysis. Germany:
Springer, 2005.
Linz, P.: An Introduction to Formal Languages and
Automata. Jones & Bartlett Publishers, 2000.
OMG: Unified Modeling Language: Superstructure,
version 2.0.: Object Management Group, 2005,
www.omg.org/cgi-bin/doc?ptc/2004-10-02.
Pereira, C. et.al.: Criteria for Business Process Modeling
with the Zachman Framework. 3rd International CIRP
Conference on Digital Enterprise Technology. Setúbal,
Portugal, 2006.
Pereira, C.; Sousa, P.: A Method to Define an Enterprise
Architecture using the Zachman Framework. In
Haddad, H., Omicini, A., Wainwright, R. & Liebrock,
L. (Eds.): Proceedings of the 2004 ACM Symposium
on Applied Computing (SAC), (pp. 1366-1371).
Nicosia, Cyprus, 2004.
Pereira, C.; Sousa, P.: Enterprise architecture: business
and IT alignment. In Haddad, H., Liebrock, L.,
Omicini, A. & Wainwright, R. (Eds.): Proceedings of
the 2005 ACM Symposium on Applied Computing,
(pp. 1344-1345). Santa Fe, New Mexico, USA, 2005.
Sousa, P., Caetano, A., Vasnconcelos, A. and Tribolet, J.
(2006): Enterprise Architecture Modelling with UML
2.0. In P. Rittgen (Ed.) Enterprise Modeling and
Computing with UML (pp. 67-94): Idea Group Inc.
Sowa, J. & Zachman, J. (Ed.) (1992). Extending and
formalizing the framework for information systems
architecture. IBM Systems Journal, 31, 590-616.
W3C (2002). Web Services: World Wide Web
Consortium.
Zachman, J. (1987). A Framework for Information
Systems Architecture. IBM Systems Journal, 26(3),
276-292.
ICEIS 2008 - International Conference on Enterprise Information Systems
146