AWARENESS MODELLING AND ITS APPLICATION IN
COOPERATIVE NETWORK MANAGEMENT
Farhad Daneshgar+ and Pradeep Ray*
+Basser Department of Computing Science, University of Sydney, Australia,
Tel: +61 2 9351 4922, farhad@cs.usyd.edu.au
*School of Information Systems Technology and Management, University of New South
Wales, Australia, Tel:+61 2 9385 5890, p.ray@unsw.edu.au
ABSTRACT
Measuring human cooperation has been a focus
of international research in CSCW [Benford 95],
[Palfreyman 96], [Rodden 96]. This measure is
called “awareness”. This paper introduces an
improved model for cooperative management of
networks and systems.
Although
communication
among
the
collaborating workers in business processes has
always been an important issue to business
organisations, there is no measure for the
effectiveness of collaboration. This paper
presents a model based on “Awareness Levels”
to measure the level of cooperation amongst
different human roles in a business process. The
hypothesis is that collaboration among various
roles within an enterprise environment is
improved by maintaining the awareness levels of
individuals at its desired level. This paper
illustrates the awareness model through its
application in a large telecommunication service
provider organisation. According to this study,
the awareness model seems to be able to explain
some problems of cooperation in this business
environment. Since the model is abstract in
nature, it can be applied in different
organisations and businesses.
The paper starts with a brief description of an
awareness model [Daneshgar 98]. This model is
illustrated briefly in Section 3 with graph theory
constructs. Section 4 presents a study of
cooperative management in a real organisation in
a help-desk based trouble-ticketing environment.
We try to explain some shortcomings in this
environment on the basis of awareness levels.
And finally, in Section 6 we discuss potential
benefits of this model for applications in different
business processes.
2. A COLLABORATIVE AWARENESS
MODEL
This section presents a collaborative awareness
model that has applications in a wide variety of
business environments. Some of the questions
addressed are:
1. INTRODUCTION
(i) In what way, and under what
circumstances, an "enhancement in
communication among collaborative
workers in business processes" will
produce the highest benefit to an
enterprise?
(ii) Is there a universally accepted
definition for the term "enhancement of
communication in business processes"?
(iii) What will be the cost of
implementing various communication
strategies for enhancing communication
in business processes in order to obtain
Effective management of networks and systems
requires cooperation of people within and across
organisations [Dev 93], [Ray 99]. While there has
been substantial progress in the modelling and
presentation of management information, there is
not much research reported on the human face
of the network and systems management. We
call this “cooperative management”. [Sachs 95]
highlights the importance of support for human
sociological, psychological, and organisational
factors in a help-desk based cooperative
management environment. This paper presents
cooperative management from the perspective of
Computer Supported Cooperative Work (CSCW).
1
 a knowledge, gained by a human role (actor),
the same results? Obviously, unless an
agreed
upon
definition
for
"communication in business enterprises
in a collaborative context" exists, the
question of "cost" can only be answered
in a subjective manner.
(iv) How to define/measure the
"awareness" of collaborators in a
collaborative business processes?
about all the objects that lead the role to an
understanding of all the tasks that s/he must
perform within the process. This is referred to as
level-0 awareness which is the lowest level of
awareness an individual requires within a
business process. An awareness lower than this
will disqualify the role for participating in a
collaborative business process.
 a knowledge about all the objects that lead the
role to an understanding of all the related roles
within the process (level-1 awareness).
 a knowledge about all the objects that lead the
role to an understanding of all the roles within
the process (level-2 awareness).
 a knowledge about all the objects that lead the
role to an understanding of all interactions
between all the pair of roles within the process
(level-3 awareness).
 a knowledge about all the objects that lead the
role to an understanding of how everything fit
together to make the process (level-4 awareness).
2.1. Towards a General Theory of
Process Awareness
Many definitions currently exist for the term
'awareness' within the field of CSCW (see
[Bannon 91], [Fuchs 95], [Dourish 92], and
[Benford 94]). The foundation of the proposed
model is based on the role-interaction approach
to awareness, partly discussed by Dourish.
According to this definition, " ... participants
inform each other of the activities they perform"
[Dourish 92]. Our proposed definition is based
on the following set of collaborative semantic
concepts:
The above definition provides foundation for a
framework which, in turn, can facilitate
communication among collaborative workers
within business processes. According to the
proposed definition, 'awareness' is regarded as a
measurable knowledge associated with the roles
in a cooperative process. It is defined in terms of
levels; the higher the level, the more aware the
individual will be in a collaborative context.
Initially five levels of awareness have been
identified.
Task - what must be done in order to produce
outcome.
Roles - assignments made to agents for carrying
out tasks.
(Collaborative) Process - a union of one or more
sets of related tasks, a set of roles which perform
these tasks, and a set of artefacts that are used by
the roles for achieving a distinct organisational
goal/objective called process goal. Process goal,
on the other hand, is defined as the long-run
position the process within the organisation
seeks to occupy and the specific performance
targets management seeks to achieve in pursuing
the process (the latter definition is adopted from
[THO84]).
Artefact - a passive object which is used (that is,
exchanged/created/shared etc.) by/between the
roles during execution of their tasks.
Task dependency. Task dependency between the
two tasks (and therefore, between the two roles,
since tasks are performed by these roles) exists
when a single artefact is used/shared by these
two roles in order to perform their tasks.
2.2. Graph Theory Illustration
This section presents the awareness model from
the perspective of graph theory.
A Collaborative Process Graph (from now on
called the 'G graph') is a simple connected graph
that represents a distinct business process, and
consists of a non empty set of role and task
vertices called role(x) and task(x,i) respectively
(where 'x' is the identity of the role and 'i' is the
identity of the task which is carried out by the
role), and a set of undirected pairs artefact edges
in such a way that there is a path between every
pair of distinct vertices of the graph. A path of
length 'n' from any vertex 'X0' to any other vertex
'Xn' is a sequence of edges E1, E2 ..., En on the
graph such that:
E1 connects X0 and X1
Based on the above set of semantic concepts, the
following definition of awareness is proposed.
Awareness is an individual's perception of:
2
E2 connects X1 and X2
E3 connects X2 and X3
.
.
.En connects X(n-1) and Xn
Figure 1 shows a G graph consisting of two
processes. The first process has roles X, Y, T
and V, and the second one has only one role, Z.
The first process is a collaborative process since
there are at least two roles with task dependency,
whereas the second process is not collaborative
yet, since there is only one role in it, and
therefore no task dependency exists in it. In this
figure, hashed circles represent role vertices, and
other circles represent task vertices. Thick
straight
lines
represent
role
artefacts
{role(x),task(x,i)} and narrow straight lines
represent task artefacts {task(x,i), task(y,j)}. In
the first process, there are two roles with degree
of four (ie, X and Y), two roles with degree of
three (ie, T and V), and one role with degree of
one (ie, Z). The degree of task '1' is two which
means this task is connected to one other task
within the process (that is, task 'd'); whereas the
degree of task '6' is 3, meaning that this task is
dependent on two other tasks: tasks '4' and 'b'.
Edges in the G graph represent artefacts and are
used by roles to perform different tasks. There
are two kinds of artefacts in the G graph. One
which has a role and a task as its endpoints and
can be expressed by the set {role(x),task(x,i)}
and is called role artefact; and the other kind
which has two related tasks as its endpoints, is
used/exchanges by/between two roles when
performing their related tasks and is expressed
by the set {task(x,i),task(y,j)} and is called a task
artefact. Task artefacts are specifically important
in collaborative business processes because they
reflect interactions among the roles. Role
artefacts are important because through these
artefacts a role can share his/her knowledge in
different processes An artefact/edge is incident
on each of its endpoints, and two artefact/edges
incident on the same endpoint are called
adjacent. Two vertices 'u' and 'v' are also
adjacent (or neighbours) if the set of {u,v} is an
artefact/edge of the G graph.
The degree of each role(x) vertex represents the
number of tasks that role(x) performs. The
degree of each task(x,i) vertex represents the
number of other tasks that are dependent on the
task(x,i), plus one.
Two roles 'x' and 'y' within a process are
dependent if there exists at least two task
vertices task(x,i) and task(y,j) which are
adjacent.
An edge with just one endpoint is called a loop
which is adjacent to itself, meaning that an
artefact is used either by a task or by a role in a
non-collaborative manner. Artefacts with the
same set of endpoints are said to be parallel,
meaning that more than one interaction is
occurring between the same endpoints
For simplicity, it is assumed in this thesis that
each artefact is unique within the G graph. Such
uniqueness is reflected in the fact that each
vertex within the G graph is uniquely
identifiable, and so is any pair of vertices within
the G graph.
The set of all task artefacts (that is,
{task(x,i),task(y,j)}) in each process represents
the Task Dependency Map for that process.
X
1
V
f
2
d
3
5
6
c
e
4
b
T
a
9
Y
7
8
Z
Figure 1: An enterprise collaborative graph with
two processes
Figure 2 shows the 'task dependency' map for the
process on the top of the G graph using dotted
lines. Each dotted line is called task dependency
path/walk. There are two such paths for this
process which indicates that although the process
is collaborative (that is, a connected graph)
however, not every role has task dependency
with every other role within the process.
The task dependency map (or TDM) of the first
process can be shown by a set task dependency
paths as follow:
TDM = {{a,b,c,d}, {e,f,g,h}}.
(Note that an alternative method of representing
a path is by its vertices)
3
X
1
X
e1
a
e2
T
e15
7
c
e16
e17
e13
e14
e4
e3
f
1
e18
5
e12
6
V
e21
3
e6
d
5
e
e7
e11 h
2
e20
e19
g
b
4
V
Y
e5
6
T
Y
e8
e10
7
2
4
Z
3
e9
Z
Figure 3. Representation of level-0 Awareness
of role X
Figure 2: 'Task dependency map'.
2.3. Awareness Levels
These levels are shown in Figures 3 to 5 by dark
regions on the graph. For example, Level-0
awareness for role X consists of the vertices 1, 2,
3 and 4 plus all the artefacts/edges that connect
these vertices together. Awareness level-1 for the
role X in Figure 4 consists of the following
objects: 1, 2, a, b, c, d, e and g as well as all the
edges that connect these vertices together.
Level-3 awareness describes the context of
knowing all the interactions that occur between
any pair of roles within the process. This
awareness can be captured by accessing all the
task artefacts that are exchanged between any
pair of roles within the process. In this particular
example, levels 2 and 3 awareness for the role X
are the same, and therefore one graph is used to
show both.
X
a
V
f
c
1
e
6
b
g
4
5
h
T
3
7
Y
d
2
Z
Figure 4. Representation of level-1 awareness
of role X
While levels 0 to 3 awareness differ between
individuals, level-4 awareness is the same for all
the roles. This level of awareness is the entire Ggraph; that is, it incorporates all the objects on
the G-graph. For more details about various
aspects of the model refer to [Daneshgar 98].
4
1. The Change Manager is responsible (on behalf
of the telecom organisation under study) for
successful operation of the given changes in the
given set of user organisations.
X
a
f
V
6
c
1
e
g
b
2. The Technician at the Network Management
Centre is responsible for the technical aspects of
this change.
4
5
h
T
Y
d
3
7
3. The Operator at the Help-Desk is responsible
for procedural communication amongst all
concerned, and updates the repository available
for this purpose.
2
Z
4. The User(s) represent contact persons in the
user organisations where the change is being
undertaken.
Figure 5. Representation of levels 2 and 3
awareness of role X
3.
RESULTS
OF
ORGANISATIONAL STUDY
Arrows of interaction show the direction of
human communication. We now describe the
scenario in terms of some numbered interactions
shown in figure 7
REAL
3.1. Troubleticketing Environment
3.2. Scenario Analysis
In this study, we examined a number of real-life
scenarios that indicate problems in a troubleticket environment in a large telecommunication
organisation, as reported by people working in
the organisation. This is a help-desk based
network management process called troubleticketing. In this case, management personnel
cooperate to manage a problem using various
network elements. Whenever there is a problem,
the customer reports that to the help-desk. The
operator then assigns a trouble-ticket to the
problem and assigns to an appropriate technical
person. This person tries to solve the problem
and escalates alarm (calls EXPERT) if the
problem can not be solved within the stipulated
time. The trouble-ticket is closed once the
problem is resolved to the satisfaction of all
concerned [Johnson 92].
The given scenario involves the following
interactions amongst roles defined in the
previous section.
1. The Technician discusses with a remote Test
Coordinator about a suitable time. This task
has adequate tool support in the organisation
understudy.
2. The Technician places change request with
proposed time and user impact statement to
Change Manager . The change impact
statement requires considerable amount of
context
knowledge
regarding
user
configurations. In the absence of an
automated facility, the Technician is not
likely to have this information concerning
user activities and needs. As such this person
is only at level-1 of awareness with existing
artefacts and tools. In order to be effective
this person should be at level-3. This can be
achieved by access to appropriate
repositories to support interactions at this
level.
3. Change Manager takes up with the affected
Users. While the User need not be at a
higher level of awareness, the Change
Manager needs to have adequate level of
awareness through appropriate repositories
non-existent in this case. Users are totally
unaware of the overall system
We now consider a scenario of cooperative
network management in a telecommunication
service provider. This is based on a real study in
an Australian telecom carrier. The scenario may
be described as
The Sydney to Perth wide area link, which is on
an existing 2 Mbps link on a lower version NTU,
needs to be upgraded to a higher version NTU.
For this an outage of 30 minutes is required.
In this case the human roles involved are:
5
4. Related Users discuss impact and examine
proposed time. For this interaction to be
successful, all users need to have a
reasonably high level of awareness about
their own system and requirements. The
coordinating User knows a little more than
others who are ignorant. This may require
both adequate group communication
mechanisms and repositories for all users to
interact effectively.
5. User resubmits request to Change Manager
with possibly an altered schedule. Due to the
lack of adequate level of knowledge, users
may have taken invalid assumptions. The
change manager also is unable help in this
situation. This can waste substantial amount
of time for all concerned.
6. Change Manager issues Permit To Work to
all concerned. The lack of awareness on part
of change manager may lead to missing some
parties concerned with the work. Also some
users may not appreciate the need for
responding within the stipulated time. All
this may cause substantial damage to the
organisation’s interests.
Obviously, each interaction requires a set of
awareness for the roles. Failure to provide them
may lead to dissatisfaction. In order to explore
the linkage between supported awareness and
satisfaction levels, we interviewed users in the
organisation under study for satisfaction levels
for all interactions. The following table shows
the required awareness levels and satisfaction
levels for each interaction.
Interaction
Awareness
Required
Awareness S
upported
Awareness Gap
User Satisfaction
level
1
2
1 for each role
3 and 2
1 for each role
1and 2
No
Yes
8 (High)
3 (low)
3
4
5
6
4 and 1
3 for each role
3 and 4
4 and 3
3 and 0
1 and 0
1 and 3
3 and 1
Yes
Yes
Yes
Yes
3 (low)
3 (low)
3 (low)
2 (low)
Table 1. Awareness Modelling for the Network management Scenario
satisfaction level. Designers of enterprise
network management systems can now work on
the right type of cooperation support for these
interactions. This result was observed in a
number of scenarios studied by us in this
organisation [Ray 99].
In this table we describe the awareness levels for
pairs of roles in each interaction. Each
interaction has two associated awareness levels
for its two roles. For example, in the above
scenario, interaction 2 requires awareness level 3
for the Technician, and level 2 for the Change
Manager. Therefore, the awareness level is
specified as '3 and 2'. The column on awareness
gap shows the existence of awareness gap
between the desired levels (in column 2) and the
actual levels (in column 3) for every interaction.
Satisfaction levels (scale 0-10) are shown for
every interaction, recorded on the basis of
interviews with real operations people in the
organisation under study.
The interview results consistently reveal the
following factors as sources of dissatisfaction:
1. Currently, there is no automatic change impact
notification and therefore all concerned need to
be informed manually (and hence the chance of
omissions). There is a need for a system to
automatically create notification list based on
network topology.
This table shows a direct relationship between
the awareness gap and the satisfaction levels in
the sense that interactions with lower that
required awareness levels have lower satisfaction
levels. On the other hand, the interaction with
support for the right level of awareness has high
2. Although all users are notified, some users do
not respond at the right time. Therefore it is
necessary to include the impact information in
the communication to user In case some users do
not respond, it may be necessary to chase them.
6
Hence the need for a “to do list” for every
change.
3. Identify awareness levels actually supported
3.System workflow should take care of
interlocks. There is need for role agents to look
at certain information and remind users if
necessary automatically
4. Identify
for the above role-task tuplets.
the gaps in awareness
supported in various role-task tuplets.
levels
5. Design tools and artefacts to plug the gaps
identified.
4. Often users/ experts can not be located. Hence
there is a need for mobile computing/
communication solution.
The next step is to provide necessary
hardware/software tools, and artefacts for
supporting the right level of awareness for a each
interaction in the given environment. This
involves the design of a distributed processing
system to achieve the required awareness levels
for different roles in adynamic situation. Here
the considerations are as follows:
These results suggest that the proposed
awareness models are successful in measuring
cooperation levels in the given type of activities,
namely enterprise network management. This
provides a basis for the specification of
cooperative management in an organisational
context, in terms of awareness levels required for
different interactions.
 How to design a distributed system to achieve
the required levels for different interactions
dynamically?
3.3. Summary of the Proposed CSCW
methodology
 What are the constraints in achieving these
objectives?
In the previous sections, we have illustrated the
use of an abstract measure, called 'awareness
level' to explain some drawbacks in an existing
cooperative management environment.
The
analysis methodology can be summarised as
below:
 How to evaluate such a design?
Answers to these questions are beyond the scope
of this paper.
4. CONCLUSION
1. Identify various human roles, their tasks, and
This study shows that awareness modelling is
potentially a good method for measuring
cooperation levels in a business process, such as
help-desk, in a cooperative management
application. However, more research is needed to
calibrate the model for different organisational
cultures, as well as for less structured tasks.
interactions (shown by the 'task artefacts')
involved in a cooperative management
environment.
2. Define awareness levels required from each
role when performing a task.
REFERENCES
[Benford 94], Steve Benford et al, “Supporting Cooperative Work in Virtual Environments”, The
Computer Journal, Vol 37 No 8, 1994
[Daneshgar 98], Farhad Daneshgar, 'An Awareness Framework for Business Processes', PhD Thesis,
School of Computing Sciences, University of Technology, Sydney, Australia, November 1998.
[Dev 93], Roger Dev, “Managing The Enterprise Network: Command and Control”, Cabletron Systems
Inc, March 1993
[Dourish 92], Paul Dourish et al, “Awareness and Coordination in Shared Workspace”, Proceedings of
CSCW’92 , November 1992
[Fuchs 95], Ludwin Fuchs et al, “Supporting Cooperating Awareness with Local Event Mechanisms:
The GroupDesk System”, Proceedings of the 4th European Conference on Computer-Supported
Cooperative Work, September 1995
7
[Johnson 92], D. Johnson, “NOC Internal Integrated Trouble Ticket System Functional Specification
Wishlist” Internet RFC 1297, January 1992.
[Palfreyman 96], Kevin Palfreyman et al, “A Protocol for User Awareness on the World Wide Web”,
International Conference CSCW’96, Cambridge MA USA 1996
[Ray 99], Pradeep Ray, Michael Fry and Bhumip Khasnabish “A Re-Engineering Methodology for the
Cooperative Management of Enterprise Networks”, the Journal of Network and Systems Management
Special Issue on Enterprise Network Management, March 1999
[Rodden 96], Tom Rodden, “Populating the Application: A Model of Awareness for Cooperative
Applications”, International Conference CSCW’96, Cambridge MA USA 1996
[Sachs 95], Patricia Sachs, “Transforming Work: Collaboration, Learning, and Design”,
Communications of the ACM, Vol 38 No. 9, September 1995.
[Daneshgar 99], "A Methodology for Planning, Analysis, Design and Implementation of Collaborative
Databases: Introducing AWT Software", The Proceedings of the 2nd International Symposium on
Cooperative Database Systems for Advanced Applications (CODAS'99), Wollongong, Australia, March
1999.
8