(Springer) Cooperative Management of Enterprise Networks

Cooperative Management of
Enterprise Networks
NETWORK AND SYSTEMS MANAGEMENT

Series Editor:
Manu Malek
LucentTechnologies, Bell Laboratories
Holmdel, NewJersey
BASIC CONCEPTS FOR MANAGING TELECOMMUNICATIONS

NETWORKS: Copper to Sand to Glass to Air
Lawrence Bernstein and C. M. Yuhas
COOPERATIVE MANAGEMENT OF ENTERPRISE NETWORKS
Pradeep Ray
A Continuation Order Plan is available for this series. A continuation order will bring delivery of each new
volume immediately upon publication. Volumes are billed only upon actual shipment. For further information please contact the publisher.
Enterprise Networks
Pradeep Ray
School of Information Systems Technology and Management
University of New South Wales
Sydney,Australia
Kluwer Academic Publishers

New York, Boston, Dordrecht, London, Moscow
eBook ISBN:
Print ISBN:
0-306-46972-3
0-306-46276-1
2002 Kluwer Academic Publishers

New York, Boston, Dordrecht, London, Moscow
All rights reserved
No part of this eBook may be reproduced or transmitted in any form or by any means, electronic,
mechanical, recording, or otherwise, without written consent from the Publisher
Created in the United States of America
Visit Kluwer Online at:
and Kluwer's eBookstore at:
http://www.kluweronline.com
http://www.ebooks.kluweronline.com
Preface
Enterprises all over the world are experiencing a rapid development of networked computing
for applications that are required for the daily survival of an organization. Client-server
computing offers great potential for cost-effective networked computing. However, many
organizations have now learned that the cost of maintenance and support (management) of
these networked distributed systems far exceeds the cost of buying them. For example, it is
hard for the management of a large enterprise to keep track of the number of PCs, PC software
licenses, and their versions. However, the top management of an enterprise is liable for hefty
penalties in case any illegal copy of software is found on any computer(s) owned by the
company. This is rapidly increasing the total cost of ownership (due to the excessive cost of
management) of networked information systems that are now getting more and more
geographically dispersed due to the growth of the Internet and other enterprise networks.
These factors coupled with the growing dependence of corporate businesses on mission-critical management applications have attracted the attention of business managers toward
network and systems management.
Computer Supported Cooperative Work (CSCW) is the new evolving area that promotes
the understanding of business processes and relevant communication technologies. Because
CSCW involves collaborative work amongst people from different disciplines, concepts in
this area are simple and easily understandable to a multidisciplinary team. At the same time
these concepts are firmly grounded on relevant theories from basic research areas, such as
mathematics, psychology, sociology, etc. Hence this book uses CSCW as the medium for
conveying ideas on the integration of business processes with network and systems management.
The subject of network and systems management has evolved greatly over last few years.
This subject has attracted people from disciplines, such as telecommunications, software
engineering, network technology, and artificial intelligence. There have been a number of
books written on this subject by renowned authors all over the world. For example, books
by William Stallings and Allan Leinwand have addressed management communication
protocols (e.g., SNMP and CMIP) and management information models (e.g. Internet MIBs,
OS1 GDMO). Josif Ghetie has written a book on management platforms. Prof. Heinz-gerd
Hegering et al. have written a book covering above issues and integrated management
applications. Besides, there have been specialized books, such as the application of CaseBased Reasoning paradigm in network and systems management by Lundy Lewis. These
are in addition to a number of multi-author books on various aspects of distributed systems
v
vi
Cooperative Management of Enterprise Networks
management. These books adequately address the technical (protocol, information models,
architecture, and software) issues of network and systems management. However, not much
has been written on the problem of the integration of business processes with network and
systems management. This book is aimed at filling this void.
Thanks to the changing business environment, such as the deregulation of the telecommunication industry, it is important to provide an integration of organizational business
processes with network and systems management. For example, these days huge amounts
(worth millions of dollars) of stocks are traded daily over enterprise networks, such as the
Internet. Any down time of networked services may result in huge losses to concerned
organizations. As telemedicine (network-based patient monitoring and diagnosis) technology grows, the health of a networked computing system in medical environments may
become directly responsible for lives saved. Until recently, networked business systems have
been considered totally different from network and systems management. This has resulted
in expensive communication gaps within organizations. Therefore, many enterprises are now
forcing business managers to work closely with technical network/systems support managers
to achieve organizational business goals. These people may have different backgrounds, such
as marketing, engineering, software, and operations. It is important to provide a common
understanding of mission-critical business processes and their linkages to network/systems
management (also addressed as cooperative/service management). There is an acute shortage
of books and tutorials in this area, particularly from the perspective of a team involved in the
development of a reengineered management system. This book addresses the needs of such
a multidisciplinary team.
The organization of the book is discussed in the introductory chapter 1. Chapter 2
provides a brief review of networldsystems management concepts and standards. Although
this chapter touches on major standards in this area, it is not intended to provide a tutorial in
network and systems management. An uninitiated reader may refer to appropriate standard
texts in this area. The objective of chapter 2 is to show the need for business processes
integration, something that is almost nonexistent in modern network and systems management products/standards. Chapter 3 introduces CSCW concepts for this purpose. Chapter 4
develops a methodology (best practice models), called CoMEN for the cooperative management based on CSCW concepts and standard Information Systems (IS) methodologies. It
may be noted that CoMEN is discussed solely for the purpose of illustrating the role of
CSCW concepts for the integration of business processes with network/systems management. There is no intention to establish CoMEN as The Cooperative Management Methodology. The discussion, however, follows some academic rigor to inform the reader about
the research that has gone into this subject. Chapters 5,6, and 7 provide a case-study-based
application of this methodology. This is expected to bring out the richness of CSCW concepts
for this purpose. Like any other IS methodology, CoMEN has a number of phases, such as
analysis, design, and evaluation, presented in chapters 5, 6, and 7, respectively.
This book may be useful in different ways to network and systems management
professionals wishing to know about business process integration, business managers
wishing to integrate their tasks with network/systems management, software system developers wishing to adopt participative design practices, and students and researchers of
network/systems management, telecommunications management, software engineering, and
business information systems. Readers may take different sequences of chapters for reading
depending on the objectives of their study. For example, a network/systems management
Preface
vii
professional may skim chapter 2 to review knowledge and then go to chapters 3,5,6, and 7
in sequence. A business or information systems person will need to read chapters 3,4,and 5
in sequence. A developer may need to read all chapters from 3 to 6. A researcher in this area
may need to read all the chapters and some of the references listed in the bibliography.
However, I would like to emphasize that this is not intended to be a textbook on network and
systems management for an uninitiated reader.
I would like to sincerely acknowledge the contribution of many people to whom I am
indebted for the completion of this book. First, I would like to thank Manu Malek, the editor
of the network and systems management series of Kluwer Academic/Plenum Publishers for
encouraging me to write this book and supporting this effort in various ways. My sincere
appreciation and thanks go to reviewers Lawrence Ho, Praful Dixit, and Shervin Erfani
(whose names were disclosed to me once the book was accepted for publication after two
stages of anonymous reviews) of Lucent Technologies, Bell Laboratories. They have given
substantial amount of time to read drafts of this book and sent their thoughtful suggestions.
I must thank my past employer, the University of Western Sydney, Nepean, Australia, for
extending assistance toward writing this book through the Publication Time-Release grant.
I would like to thank my co-researcher Farhad Daneshgar, Gora SenGupta, a practicing
network and systems manager, Prof. Michael Fry and Prof. Igor Hawyszkiewycz of the
University of Technology Sydney for their assistance in the development of CoMEN. Thanks
are due to my graduate students Ravi Vellanki and Murali Keshaviyenger for helping with
the proof reading and assisting with index preparation. Finally, I would like to thank my
family for patiently bearing with me during the long and arduous process of writing this
book.
Pradeep Ray
Sydney,Australia
This page intentionally left blank
Contents
.,,.......,.....................
Overview . . . . , , . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Background and Motivation . . . . . . , , . . . . . . . . . , , . . . . .
Related Work . . , , . . . . . . . . , . , . . . . . . , . . . . , . . . . .
Organization of the Book . . . . . , . , , . , . . . . . . . . , , . . . .
1.4.1. Part A: Problem and Review . , . . . . . . . , , . . . . . . . .
1.4.2. Part B: Cooperative Management . . . . , , , . . . . . . . . . .
1.4.3. Part C: Application of the Methodology , , . . . . . . . . . . .
1
2
2
3
3
3
4
1. Introduction.
1.1.
1.2.
1.3.
1.4.
2.
, ,
Integrated Management ofEnterprise Networks .
................
2.1. What Is Integrated Management? . . , . , . . . . . . . . . . . . . . . .

2.2. Integrated Management Concepts . . , . , . . , , . . . , . . , , . . . .
2.2.1. Management Model . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2. IntegratedManagementFramework . . . . . . . . . . . . . . .
2.3. ManagementApplications . . . . . . . . . . . . . . . . . . . . . . . . .
2.4. Integrated Management Standards . , . . . . , . . . . . . . . , . , . .
2.4.1. Internet SNMP . , , , , . . . . . . . , , . . . . . . . . . , . .
2.4.2. ISO/ITU OS1Management . . . . . , , , . . . . . . . . . , . .
2.4.3. ISOODP . . . . , , , , , . . . . . . . , . . , , . . . . . . . .
2.4.4. ITU Telecommunications Management Network (TMN) . . . .
2.4.5. TINA . . . , , . , , . . . . . . . . , , . . . . . . . . . . , . .
2.4.6. Distributed Management TaskForce (DMTF) . . . , . . . . . .
2.4.7. Comparison of Integrated Management Standards , , . . . . . .
2.5. Integration with Enterprise Business Processes . . . . . . , . . . . . . .
2.5.1. ProcessManagement . . . . . . . . . . . . . . . . . . . . . . .
2.5.2. Integration of Service Management with Network/Systems
Management , . . . . . , . . . . . . . . . . . . , . . . . . . . .
2.6. RecentDevelopments . . . . . . . . , . . . . . . . . '. . , , . . . . . .
2.6.1. KnowledgeTechnologies . . . . . . . . . . . . . . . . . . . . .
2.6.2. Visualization . . . . . . . . . . , . . . . . . . . . . , . . . . . .
2.6.3. WWW-Based User Interface . . . . , . . . . . . . , , . . . . .
IX
5
6
7
7
8
10
12
12
12
13
14
14
18
18
20
20
21
22
22
23
23
2.6.4. Management Policies . . . . . . . . . . . . . . . . . . . . . .

2.6.5. OpenProblems . . . . . . . . . . . . . . . . . . . . . . . . .
2.7. Chaptersummary . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.
Computer Supported Cooperative Work (CSCW)
.
.
.
...............
3.1. What is CSCW? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.1. An Understanding of Business Organizations . . . . . . . . . .
3.1.2. Communication Technologies . . . . . . . . . . . . . . . . . .
3.1.3. Benefits of CSCW . . . . . . . . . . . . . . . . . . . . . . . .
3.2. The Evolution of CSCW . . . . . . . . . . . . . . . . . . . . . . . . .
3.3. Workgroup Collaboration . . . . . . . . . . . . . . . . . . . . . . . . .
3.4. Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1. Groupware Implementation . . . . . . . . . . . . . . . . . . .
3.4.2. Groupware Development Issues . . . . . . . . . . . . . . . . .
3.4.2.1. Critical Mass Problems . . . . . . . . . . . . . . . .
3.4.2.2. Improvisation Handling . . . . . . . . . . . . . . . .
3.4.2.3. Difficulty of Evaluation . . . . . . . . . . . . . . . .
3.4.2.4. Failure of Intuition . . . . . . . . . . . . . . . . . . .
3.4.2.5. Difficult Adoption Process . . . . . . . . . . . . . .
3.5. Workflows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1. Integrated Management Workflow . . . . . . . . . . . . . . . .
3.5.2. Workflow Classification . . . . . . . . . . . . . . . . . . . . .
3.5.3. Workflow Management . . . . . . . . . . . . . . . . . . . . . .
3.5.4. Workflows at Different Levels . . . . . . . . . . . . . . . . . .
3.5.5. Workflow Reference Model . . . . . . . . . . . . . . . . . . .
3.5.6. Workflows for Management of Enterprise Networks . . . . . .
3.6. Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 . Cooperative Management Methodology
....................
4.1. Cooperative Management Methodology . . . . . . . . . . . . . . . . .

4.1 .1. Why Methodologies? . . . . . . . . . . . . . . . . . . . . . . .
4.1.2. Methodologies for Integrated Management . . . . . . . . . . .
4.1.3. Characteristics of the Problem Domain . . . . . . . . . . . . .
4.2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3. CSCW Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4. CoMEN Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1. CoMEN Concepts . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2. Development of CoMEN . . . . . . . . . . . . . . . . . . . . .
4.4.2.1. Overall System Study . . . . . . . . . . . . . . . . .
4.4.2.2. Process Study . . . . . . . . . . . . . . . . . . . . .
4.4.2.3. Defining Collaborative Service Requirements . . . .
4.4.2.4. Analysis . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2.5. Abstract Specification . . . . . . . . . . . . . . . . .
4.4.2.6. Design and Implementation . . . . . . . . . . . . . .
24
25
25
27
27
28
29
31
32
34
35
35
36
37
37
38
38
38
39
39
40
42
43
43
45
46
47
47
48
48
48
50
51
52
52
54
55
55
55
55
55
56
xi
Contents
4.5. CoMENProcess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1. The Requirements Phase . . . . . . . . . . . . . . . . . . . . .
4.5.2. The Analysis Phase . . . . . . . . . . . . . . . . . . . . . . . .
4.5.3. The Design Phase . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.4. The Implementation Phase . . . . . . . . . . . . . . . . . . . .
4.5.5. The Evaluation Phase . . . . . . . . . . . . . . . . . . . . . . .
4.6. CoMENNotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.1. Rich Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.2. Enterprise Analysis . . . . . . . . . . . . . . . . . . . . . . . .
4.6.3. Process Diagrams . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.4. Action Workflow Diagrams . . . . . . . . . . . . . . . . . . . .
4.7. Advantages of CoMEN . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8. ChapterSummary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5. Cooperative Management Analysis
.......................
5.1. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1. Development of Requirements through Interviews . . . . . . . .
5.1.2. Using Questionnaires . . . . . . . . . . . . . . . . . . . . . . .
5.1.3. Experimentation by Building a Prototype . . . . . . . . . . . .
5.1.4. Observation through Ethnographic Studies . . . . . . . . . . . .
5.2. Requirement Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1. System under Study . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2. Logical Components . . . . . . . . . . . . . . . . . . . . . . .
5.2.2.1. Roles and Tasks . . . . . . . . . . . . . . . . . . . . .
5.2.2.2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2.3. Tools and Artifacts . . . . . . . . . . . . . . . . . . .
5.2.3. ProcessStudy . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3.1. Scenario 1: Upgrade Problem . . . . . . . . . . . . .
5.2.3.2. Scenario 2: No Information with NMC . . . . . . . .
5.2.3.3. Scenario 3: New SoftwareVersion . . . . . . . . . . .
5.2.3.4. Scenario 4: Security Problems . . . . . . . . . . . . .
5.2.3.5. Scenario 5: Architectural Problems . . . . . . . . . .
5.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1. Collaborative Services . . . . . . . . . . . . . . . . . . . . . . .
5.3.1.1. Repositories . . . . . . . . . . . . . . . . . . . . . .
5.3.1.2. Group Communication Interfaces . . . . . . . . . . .
5.3.2. InteractionAnalysis . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2.1. Collaborative Service Evaluation . . . . . . . . . . .
5.3.2.2. Time Utilization of Human Roles . . . . . . . . . . .
5.3.3. Cooperation Analysis . . . . . . . . . . . . . . . . . . . . . . .
5.3.3.1. Awareness Levels . . . . . . . . . . . . . . . . . . . .
5.3.3.2. Scenario 1: Upgrade Problem . . . . . . . . . . . . .
5.3.3.3. Scenario 2: No Information with NMC . . . . . . . .
5.3.3.4. Scenario 3: New Software Version . . . . . . . . . . .
5.3.3.5. Scenario 4. Security Problems . . . . . . . . . . . . .
5.3.3.6. Scenario 5 : Architectural Issues . . . . . . . . . . . .
56
57
58
58
59
59
59
60
60
60
61
63
63
65
66
66
66
66
66
67
68
69
69
71
72
74
74
75
76
77
78
80
80
81
82
83
83
86
87
87
89
91
94
95
96
xi i
5.3.4. Usefulness of the Awareness Model

5.4. Discussion . . . . . . . . . . . . . . . . . . .
5.5. ChapterSummary . . . . . . . . . . . . . . .
...............
..............
..............
6 . Design and Implementation of a Cooperative Management System
96
97
99
......
101
6.1. CoMEN Design Methodology . . . . . . . . . . . . . . . . . . . . . .

6.2. CoMEN Analysis to System Design . . . . . . . . . . . . . . . . . . .
6.3. CSCW Application Design . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1. A Generic Help-Desk Application . . . . . . . . . . . . . . . .
6.3.2. Generic Workflow of a Cooperative Management System . . .
6.3.3. Workflow Specifications . . . . . . . . . . . . . . . . . . . . .
6.4. Distributed Management System Design . . . . . . . . . . . . . . . . .
6.5. Group Communication System Design . . . . . . . . . . . . . . . . . .
6.6. Cooperative Management Architectural Design . . . . . . . . . . . . .
6.6.1. The Cooperative Management Environment . . . . . . . . . . .
6.6.2. Cooperative Management Requirements . . . . . . . . . . . . .
6.6.3. The Cooperative Management Framework . . . . . . . . . . .
6.7. Implementation Framework . . . . . . . . . . . . . . . . . . . . . . . .
6.7.1. Integrated Management Platform Considerations . . . . . . . .
6.7.2. CSCW Platform Considerations . . . . . . . . . . . . . . . . .
6.7.3. The Prototyping Environment . . . . . . . . . . . . . . . . . .
6.7.4. Group Communication Specifications . . . . . . . . . . . . . .
6.8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.8.1. Relevance to Given Scenarios . . . . . . . . . . . . . . . . . .
6.8.2. A Complete Cooperative Management System . . . . . . . . .
6.9. ChapterSummary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
101
104
105
7 . Evaluation
....................................
7.1. Evaluation Methodology . . . . . . . . . . . . . . . . . . . . . . . . .

7.2. Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.1. Evaluation Criteria at the Instrumentation Level . . . . . . . . .
7.2.2. Evaluation Criteria at the Platform Level . . . . . . . . . . . .
7.2.3. Evaluation Criteria at the Management Application Level . . .
7.2.4. Evaluation Criteria at the Human User Level . . . . . . . . . .
7.2.5. Evaluation Criteria for Enterprise Management . . . . . . . . .
7.3. Integrated Management Evaluation Framework . . . . . . . . . . . . .
7.3.1. Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.2. EvaluationCriteriafor CooperativeManagement . . . . . . . .
7.3.3. Evaluation Steps . . . . . . . . . . . . . . . . . . . . . . . . .
7.4. Checklist Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.1. Architectural Features Checklist . . . . . . . . . . . . . . . . .
7.4.2. Application Scenarios Checklist . . . . . . . . . . . . . . . . .
7.5. Heuristic Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.1. Questions Addressed . . . . . . . . . . . . . . . . . . . . . . .
105
107
110
111
112
115
115
116
117
119
119
120
120
121
122
123
123
124
125
125
127
128
129
129
130
130
133
133
134
134
136
136
136
141
141
...
Contents
Xlll
7.5.2. Background of Experts . . . . . . . . . . . . . . . . . . . . . .

7.5.2.1. Expert 1 . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.2.2. Expert 2 . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.2.3. Expert 3 . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.3. Summary of Results . . . . . . . . . . . . . . . . . . . . . . . .
7.5.3.1. Enterprise Management (Level 1) . . . . . . . . . . .
7.5.3.2. Management Platforms. Application, and Human
UserLevels (Level 2) . . . . . . . . . . . . . . . . . .
7.5.3.3. Groupware Support, Usability, and Visualization
Levels (Level 3) . . . . . . . . . . . . . . . . . . . .
7.5.3.4. Group Communication Support Level (Level 4) . . . .
7.5.3.5. Additional Information from Expert 2 . . . . . . . . .
7.5.3.6. Additional Information from Expert 3 . . . . . . . . .
7.6. Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.
Conclusions and Future Challenges

8.1.
8.2.
8.3.
8.4.
.......................
Part A: Integrated Management Problem . . . . . . . . . . . . . . . . .

Part B: CSCW-Based Cooperative Management . . . . . . . . . . . . .
Part C: Application of CoMEN . . . . . . . . . . . . . . . . . . . . . .
Future Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
143
143
144
144
144
144
145
145
145
145
146
146
149
149
150
151
152
Appendixes
A . Help-Desk-Based Groupware Design
......................
153
A . 1. Trouble-Ticketing Database (TBLTKT) . . . . . . . . . . . . . . . . . . 153

A.1.1. Customer Information . . . . . . . . . . . . . . . . . . . . . .
154
155
A.1.2. Call Information . . . . . . . . . . . . . . . . . . . . . . . . .
A.1.2.1. About theCallHistory . . . . . . . . . . . . . . . . .
155
A . 1.2.2. About Actual Work Time . . . . . . . . . . . . . . . 156
A.1.2.3. Using the Stopwatch to Time Calls . . . . . . . . . . 157
A.1.2.4. Call Statistics . . . . . . . . . . . . . . . . . . . . .
157
A .1.3. Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . .
157
158
A.1.3.1. Reassignment . . . . . . . . . . . . . . . . . . . . .
A.1.3.2. Escalation . . . . . . . . . . . . . . . . . . . . . . .
158
A.1.3.3. Notification Lists . . . . . . . . . . . . . . . . . . . 158
A.2. Change Management Database (CHNG) . . . . . . . . . . . . . . . . . 159
A.2.1. Change Management Problems . . . . . . . . . . . . . . . . . 160
A.2.2. Change Management Notifications . . . . . . . . . . . . . . . . 160
A.2.3. About the Problem History . . . . . . . . . . . . . . . . . . . .
160
A.2.3.1. About Actual Work Time . . . . . . . . . . . . . . . 162
A.2.3.2. Researching a Problem . . . . . . . . . . . . . . . . 162
A.2.3.3. Reassigning a Problem . . . . . . . . . . . . . . . . 162
A.2.3.4. Escalating a Problem . . . . . . . . . . . . . . . . . 162
xiv
A . 2 . 4 . Submitting a Change Management Problem Report to the

Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . .
A . 2 . 5 . Viewing Change Management Problem Reports . . . . . . . .
A . 2 . 6 . Problem Statistics . . . . . . . . . . . . . . . . . . . . . . . .
A . 3 . Multiparty Discussion Database (Talk) . . . . . . . . . . . . . . . . . .
A . 4 . The Technical Knowledge Base . . . . . . . . . . . . . . . . . . . . . .
A . 4 . 1 . Database Structure . . . . . . . . . . . . . . . . . . . . . . . .
A . 4 . 2 . Knowledge Base Notifications . . . . . . . . . . . . . . . . . .
A . 5 . Help-Desk Term-Maps Database (HLP-DSK) . . . . . . . . . . . . . .
A.5.1.
Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.5.2.
Defining Labels . . . . . . . . . . . . . . . . . . . . . . . . .
A.5.3.
Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A . 5 . 3 . 1 . How a Base Keyword Works . . . . . . . . . . . . .
A . 5 . 3 . 2 . Designer Keyword Definition . . . . . . . . . . . . .
A . 5 . 3 . 3 . Technician Keyword Definition . . . . . . . . . . .
A . 5 . 3 . 4 . Defining Keywords . . . . . . . . . . . . . . . . . .
A . 5 . 4 . Guidelines for Completing the HLP-DSK . . . . . . . . . . . .
A . 5 . 5. Checklist for a Healthy HLP-DSK . . . . . . . . . . . . . . .
A . 5 . 6 . Accessing the HLP-DSK . . . . . . . . . . . . . . . . . . . .
B.
List of Acronyms
173
...................................
177
.......................................
185
Bibliography
Index
................................
163
163
163
164
165
167
167
168
169
169
169
170
170
170
170
170
171
172
Enterprise Networks
1
Introduction
1.1. OVERVIEW
Enterprise networking refers to a network linking many smaller networks to enable enterprisewide computing with networked business applications. This book is mainly concerned
with network, systems, and service management applications, called integrated management. Because todays organizations are very much dependent on enterprise networks, it is
important to provide an integrated management framework from the perspective of the
overall management of the enterprise. Most integrated management solutions now stress on
the technical aspects, and they ignore human and organizational aspects, which are important
for the effective management of an enterprise. For example, there is a need for people from
different related organizations, such as equipment vendors, software developers, service
providers, and users to cooperate for solving integrated management problems in view of
their complex nature. The major focus of this book is on the cooperation of people for the
integrated management of enterprise networks, called cooperative management.
Because it is in the early stages of development, the subject of cooperative management
draws technological inputs from a number of diverse disciplines including software engineering, telecommunication protocols, artificial intelligence, object-oriented modeling, and
operations management. This book is based on research conducted by the author since 1995
in understanding the means of integration of organizational businesses with integrated
management. Therefore, the contents of this book border a number of areas including
Computer-Supported Cooperative Work (CSCW), information systems methodologies, distributed computing systems, and the existing knowledge in network and systems management.
The research indicates that CSCW concepts are abstract in nature, and they pervade all
stages of the life cycle of an integrated management system. This book illustrates the role of
CSCW in the integration of enterprise networks with the development and application of a
new Cooperative Management Methodology for Enterprise Networks (CoMEN). This leads
to a cooperative management framework for the integrated management of enterprise
networks.
The book is structured into three parts: Part A (chapter 2) is a report on current
technology and the recent status of the integrated management field with particular reference
to outstanding problems. Part B (chapters 3 and 4) explains CSCW concepts with the
development of a methodology for integrated management (CoMEN). Part C (chapters 5, 6
1
and 7) presents an application of the CoMEN methodology in a real-world telecommunication organization. This includes a prototype implementation and evaluation of the resulting
cooperative management framework.
1.2. BACKGROUND AND MOTIVATION

There is now a worldwide trend toward the downsizing of information systems because
of a number of available techniques, such as the client-serverarchitecture. Consequently,
enterprise networks are fast growing in terms of size and of functionality. These networks
are expected to carry multimedia information services encompassing data, voice, graphics,
text, and video to quality-conscious users. As more and more organizationwide applications
are networked, the cost of downtime increases exponentially.36 Effective management of
enterprise networks poses a number of challenging questions. Researchers in network and
systems management have been working on a number of issues including the following:
management frameworks independent of devices and vendors
abstract management information modeling based on object-oriented modeling
automated management paradigms integrated with intelligent agent technologies
distributed management application modeling based on distributed object-based
middleware, and
analysis of complex management problems based on various algorithmic approaches
including artificial intelligence techniques, such as expert systems, model-based
reasoning, and fuzzy logic.
This research field has spurred the development of commercially available integrated
management platforms. However, these platforms fail to solve many management problems
due to the evolving nature of this technology. On the other hand, the human skill base is not
increasing at a pace commensurate with the growth of enterprise networks. This has led to
a number of complex problems from the organizational business perspectives. Therefore,
there is a strong need to tackle integrated management from the perspective of organizational
business processes. Human factors play an important role in these business processes.
1.3. RELATED WORK

The proponents of automation in management processes suggest that increased automation would increase organizational productivity. However, some recent studies conducted
at a large telecommunication organization show that automation without considering human
factors might be counterproductive.146
Leading international telecommunications organizations have undertaken some studies
in the area. For example, there have been some studies on business process reengineering of
network management at GTE Corporation in the United States, at CSELT in Italy59 and at
Nortel Research in Canada.3 Network Management Forum (NMF), an industry group now
known as Tele-Management Forum (TMF), has been developing models for the specification
Chapter 1.
Introduction
of telecommunication service management processes based on international standards for

management interfaces and for business processes in a telecommunication provider organizations.113 These models are concerned with the processes used by telecommunications
service providers to develop, launch, deliver, maintain, and bill for services, and an evaluation
of the extent to which each process is dependent on industry agreements to achieve
end-to-end automation. These efforts are expected to help in the development of a standard
framework in the Service Management Layer of the International Telecommunication Union
(ITU-T)Telecommunications Management Network (TMN) recommendation.82,151 The
Telecommunications Information Networking Architecture Consortium (TINA-C),an industry group sponsored by international telecommunication service providers, has recommended a business model and open interfaces based on distributed object models for the
management of a wide variety of futuristic telecommunication services. 161
A formal methodology is useful in tackling complex problems involving many geographically dispersed groups of people.44 The similar nature of integrated management
processes necessitates the development of formal methodologies for integrated management
solutions. Although there are a number of information system methodologies,'"they cannot
be applied in integrated management due to the peculiarities (e.g., the dynamic, missioncritical nature) of this rapidly developing area.
1.4. ORGANIZATION OF THE BOOK

The previous sections provided the primary motivations for developing a new management methodology for enterprise networks. The body of the book presents a number of
concepts that need to be understood in order to utilize this methodology effectively. This is
followed by a case study in the organization under study, followed by the design and
implementation of a generic cooperative management system based on a help-desk business
model. Finally, a heuristic evaluation is carried out by interviewing experts in enterprise
network management from a cross-section of industries. The following subsections summarize the contents of various chapters of this book.
1.4.1. Part A: Problem and Review
Chapter 2 presents a discussion of integrated management and its evolution. It presents
the existing integrated management frameworks, evolving standards, and a number of
outstanding problems. This chapter presents a comparative view of relevant integrated
management standards, leading to the identification of open problems. Finally, this chapter
discusses some major ongoing research in this area and highlights the need for amanagement
approach that integrates the management of enterprise networks with enterprise business
management.
1.4.2. Part B: Cooperative Management
Chapter 3 examines the different concepts of CSCW and their relevance in integrated
management. This study establishes the potential viability of a CSCW-based approach to
enterprise network management.
Chapter 4 illustrates CSCW concepts through the development of CoMEN, based on

existing information systems methodologies, and some evolving CSCW techniques. Key
elements of this methodology are the following:
Soft Systems Methodology for the study of Cooperative Management processes.
An abstract CSCW model, called Awareness Model, to specify cooperation levels.
It is believed that this methodology constitutes an important step toward using the service
management and business management layers of the TMN hierarchical model.82,151
1.4.3. Part C: Application of the Methodology
Chapter 5 details the process of requirement collection and the analysis phases of
CoMEN, with reference to a real-world enterprise network in a large telecommunication
service provider environment. Whereas the data collection uses an ethnography-based
process, the analysis uses an evolving abstract CSCW model, called the Awareness Model.
This abstraction is important to generalize the results of scenario analysis undertaken in a
particular organization.
Chapter 6 details the process of the design of solutions based on CoMEN. It leads to a
new framework for the design and the implementation of cooperative management of
enterprise networks. This integrates the existing integrated management framework with new
infrastructure facilities required for cooperative management. This uses a variety of design
formalisms, such as a CSCW space-time matrix and Action Workflows. This chapter
discusses a cooperative management design framework, using a generic help-desk-based
business model over Lotus Notes groupware and the Cabletron Spectrum management
platform (selection considerations in Section 6.3). Appendix A presents the Notes-based
design and implementation of CoMEN.
Chapter 7 illustrates the application of a CSCW-based evaluation strategy for integrated
management problems. Because there are no established evaluation criteria for enterprise
network management, this chapter develops a general framework for the definition of such
criteria. The evaluation methodology uses a heuristic technique (used extensively in business
management) of interviewing a few practicing network management experts with substantial
experience in the technical and management issues of enterprise networks in different types
of businesses.
Finally, chapter 8 presents conclusions and identifies some future challenges to both
integrated management and CSCW.
2
Integrated Management of Enterprise
Networks
Todays enterprise networks have multiple hierarchical levels (e.g., Wide Area Networks
(WANs), Metropolitan Area Networks (MANS),and Local Area Networks (LANs)), heterogeneous components and services, and a variety of applications (from transaction processing
to e-mail) geographically spread over multiple locations. These networks are continuously
evolving with newer features and services. A typical enterprise network encompasses a
number of domains of telecommunication administration that are different for different
countries/regions/districts. The world is witnessing rapid growth in the deployment of
distributed applications over networks.
It is important to effectively manage corporate enterprise networks for the survival of
organizational businesses. Consequently, there has been a rapid development in the standardization of models and protocols for network management. However, existing network and
system management frameworks (e.g. Internet Simple Network Management Protocol
(SNMP) and Open Systems Interconnection (OSI) Management) do not yet provide an
integrated model based on modern distributed computing concepts. Whereas International
Standards Organization (ISO) Open Distributed Processing (ODP) proposes a generic model
for all types of distributed processing applications, the Bellcore-initiated Telecommunications Information Networking Architecture (TINA) addresses these issues from a telecom
providers perspective. ITU-T Telecommunications Management Networks (TMN) provides an evolving framework for the integrated management of enterprise networks.
The multiplicity of standards and models in integrated network management often can
be confusing. This chapter presents a brief overview of evolving work in the area of integrated
management of enterprise networks. First, there is a definition of integrated management
and a generic framework for achieving such management in enterprise networks. This is
followed by a discussion of some major evolving international standards related to integrated
management. Finally, the chapter presents some issues related to the integration of organizational business processes with integrated management. It has been observed that many of
the telecommunication network failures are associated with organizational and human errors
in management.146 This leads to the identification of the problem discussed in this bookhow to support cooperation amongst people and processes for the integrated management
of enterprise networks.
5
2.1. WHAT IS INTEGRATED MANAGEMENT?

During the 1970s and the 1980s, the world saw a proliferation of proprietary management solutions from different vendors for their own systems, such as multiplexers, switches,
hubs, and transmission systems. Also, there were different systems for managing networks
and computer systems. These management solutions were only applicable to the specific
systems for which they were designed. It is well known that the success of an enterprisewide
networking and computing system depends very much on the successful integration of these
subsystems. The failure of one subsystem may affect the operation of other subsystems.
Hence, users need an integrated management view of their overall enterprisewide facilities
that may include, for example, a transmission system from one vendor, multiplexers from
another vendor, and computers from a third vendor.
It generally requires a seamless integration of business, applications, systems, and
network management, which in general involves the following:
Using multivendor distributed management applications for managing heterogeneous client-serverenvironment.
Handling multimedia, multisession, and multipoint communications.
Interfacing business processes/practices with integrated management.
Although the Internet and ISO-OSIManagement standards define network management objectives, there is a need to define integrated management encompassing all aspects
of a networked service.132 A modern information infrastructure may be seen from the
following viewpoint:36
Computational Infrastructure
Management Infrastructure
Figure 2.1 shows different aspects of computational and management infrastructures and
their relationships as three concentric ellipses. Whereas the upper half represents the
computational aspects, the lower half represents the corresponding management infrastructure. A computing user interacts with the systems through applications and services (e.g.,
e-mail), which are supported by systems (e.g., operating systems, file systems), and by
communication systems (e.g., modems, multiplexers, etc.). Similarly, the management
operators and other staff are concerned with the availability of the services and with their
management. The management of networks and systems supports Service management.
Effective management of a client-serverenvironment would require an integration of the
management of all aspects of an information system consisting of communications, systems,
and application aspects.
Whereas network management is mainly concerned with the management of the
communications infrastructure (e.g., links, protocols), systems management deals with other
distributed facilities such as software distribution, print services, and file services. Applications/Services management provides a higher level view with respect to end-user applications such as electronic mail and video conferencing. These services are now distributed. It
is necessary to have integrated management encompassing network management, systems
Chapter 2.
Integrated Management of Enterprise Networks
Figure 2.1. The information infrastructure.
management, and services management. For example, a stockbroker may be performing

some calculations using a financial service located at a remote application server (not known
to the user). This application could be using network services, such as directory services
implemented over Transmission Control Protocol/Internet Protocol (TCP/IP) protocols. Any
failure in the network will appear as a calculation service failure to the stockbroker. It could
also appear to be a problem with the local system of the stockbroker. Therefore, it is difficult
to separate service management problems from underlying network or systems management
problems. On the other hand, there could be a different set of people for solving problems
in these different areas. For example, from this stockbrokers perspective, the networked
service over the Internet would be provided by the Internet service provider (e.g., CompuServe), the network connection to home would perhaps be the responsibility of the local
telecom service provider (e.g., Bell Atlantic), and the local PC might be under service with
a local PC shop. This necessitates integrated management.
2.2. INTEGRATEDMANAGEMENTCONCEPTS
This section provides a brief overview of the concepts and technologies used in
integrated management.
2.2.1. Management Model
Todays enterprise networks and services use heterogeneous components from different
vendors spread over distant geographical locations. Hence, it is necessary to collect and
analyze management information from different devices and systems distributed over the
enterprise network. Many networked organizations such as telecommunications service
providers, electricity network operators, and railroad operators use a central control location
Figure 2.2.
Conceptual management model.
(also called a management center) for this purpose. This is the location of the centralized
management station. A management solution involves transferring of management information from all network elements to this management station. International Standards Organization (ISO) and the Internet Engineering Task Force (IETF) have defined management
standards for this purpose.
Both of these standards embrace the manager-agentmodel consisting of a manager at
the management station and an agent at the remote managed element, as shown in Fig. 2.2.
Manager and agent are data communication software entities that communicate through a
management communication protocol. Managers and agents may have one-to-many and
many-to-one relationships. Whereas ISO OS1Management uses the Common Management
Information Protocol (CMIP) on the OSI 7-layer communication protocol stack,84 Internet
Management uses the Simple Network Management Protocol (SNMP) on the UDPAP
protocol stack as the management communication protocol between the manager and the
agent. In both of these protocols, the manager uses get commands to retrieve information
from, and set commands to modify management information at remote-managed elements
(hardware or software) through an agent.98,117,155
A typical enterprise network consists of hardware and software of diverse types from
different vendors. Managed Objects (MO) provides a standardized format to represent the
resources/elements that need to be managed, The Management Information Base (MIB) is
a collection of MOs. These are defined using the ISO standard language Abstract Syntax
Notation 1 (ASN. 1) or its subset.
A manager (management station) performs the management (monitoring and control)
function by accessing information from various elements. ISO has defined five basic
management functions: Fault management (identification and rectification of faults), Configuration management (changes in configuration, e.g., software versions), Accounting
management (tracking and charging for resource usage), Performance management (analysis
of system performance), and Security management (mechanisms for authentication, access
control of resources)-in short FCAPS.84
2.2.2. Integrated Management Framework
As discussed earlier, organizations in the 1970s and the 1980s used to have different
management solutions for their different subsystems, such as communication systems,
Chapter 2.
computers, and some applications. Once organizations realized the importance of the
integration of the management of enterprisewide networks, they started demanding a
common framework for the management of heterogeneous, multivendor facilities. This
provided a motivation for all concerned to develop management solutions that integrate to
provide a common enterprisewide view. Figure 2.3 shows the resulting framework for
integrated network management being adopted in the deployment of integrated management
today. It consists of the followingelements.65
Instrumentation
Management Platform
Management Applications
The instrumentation element provides hooks for collecting management information from
the managed devices/elements. They are generally implemented by the vendor in the form
of an MIB as part of a device/system. There are now Internet and ISOATU-Tstandards for
the definition of MIBs for a variety of devices, protocols, and elements for enterprise
networks. For example, Host MIB defines MOs for desktop systems (CPU, memory
utilization, and printer), and Ethernet MIB defines MOs for ethernet LANs. Many such MIBs
are now commercially available from a number of vendors of networking products.156
A management platform provides a common distributed computing platform for the
management of heterogeneous devices/systems using multiple communication protocols,
Application Programming Interfaces (APIs), a common user interface, and a set of generic
management services based on client-serverarchitecture. Whereas the management user/application is the client, the platform provides the server functions required for network
management (e.g., naming and addressing, management communication, object management, and a common database). A number of industry groups and international standards
organizations (e.g., IETF, ISOATU-T, Network Management Forum, Desktop Management
Figure 2.3.
Integrated management framework.
10
TaskForce-DMW) have produced standards for various elements of management platforms.114 Presently there are a number of commercially available integrated management
platforms, such as HP Open View, Cabletron Spectrum, IBM NetView/6000, and Sun
Solstice.52,68
It is necessary to use a common distributed object model at the platform level to hide
the differences in management protocols (e.g., CMIP and SNMP) and in information models
(e.g., OSI and the Internet) in heterogeneous managed elements. Although many platform
vendors provide proprietary object models, it is felt that standard object models, such as
Object Management Groups (OMG) Common Object Request Broker Architecture
(CORBA) and Microsoft Distributed Common Object Model (DCOM) would provide a
basis for this interoperability.119.139
Management applications (e.g., trouble-ticketing, inventory, etc.) have traditionally
been developed by system vendors, user organizations, and telecommunication carriers,66,1 16
and their requirements vary from organization to organization. Hence, management solutions
vary widely. For example, the network management center of a large telecommunication
organization may have more than 50 different types of software for solving different
management problems. Some of these incorporate sophisticated computational techniques,
such as expert systems, model-based reasoning, and intelligent agents. It is not possible for
one organization to provide all sorts of management solutions. It is possible to achieve a
substantial amount of productivity gains by sharing software among different applications.
This necessitates a distributed object-based (e.g., CORBA) framework for the interoperability of management applications developed by multiple groups of people. ISO/ITU-T
standardization on TMN, ODP, DMTF Web-Based Enterprise Management (WBEM), and
the Bellcore-initiated Telecommunications Information Networking Architecture (TINA)
are efforts in this direction.127
2.3. MANAGEMENT APPLICATIONS

Figure 2.4 shows a functional model of integrated network management in a corporate
organization. According to the head of network operations in a large multinational organization, Until now, network management has been focused on hardware failures in static
networks, but the real network problem is seldom a hardware failure. It is the constant change
induced by software changes, workstation additions and moves, and growth. New releases
of software affect the network, often with undesired side effect.38
The emerging network management requirements in a heterogeneous environment can
be summarized as the following:
A unified knowledge base usable by moderately knowledgeable network help-desk
support staff.
Automatically updated topologies, configurations, and inventory of all devices in the
network.
Intelligent, self-healing, self-adjusting networks that know how to ease periodic
congestion dynamically.
Chapter 2.
Figure 2.4.
11
Functional model of enterprise network management.
Predictive what-if tools to analyze trends, simulate new traffic loads, and plan
upgrades for transport network and access facilities.
A secure network management framework capable of managing security support
such as access control, encryption, and key distribution.
Two key technologies are now being investigated to reduce operator workload, improve
service levels, and reduce operating costs in complex multivariable management systems.
These are the following:
Distributed Object-based Management Systems, such as OMG CORBA-based management. These systems enhance management software productivity (reduce development and maintenance costs, better quality) through reuse and encapsulation, using
object-oriented software.93,119,123
Intelligent and adaptive techniques, such as expert systems, intelligent agents, and
data mining.54,101,20 They provide help in correlating multiple MOs to solve management problems.
In the telecommunications world, there are now a number of ongoing major efforts to
standardize the definition and deployment of services independent of telecommunication
equipment, such as switches and transmission equipment. Management applications and
services can be viewed as specific instances of such services. Because the management of
services or of applications is hard to distinguish from the management of networks and
systems, integrated management facilities are needed.
On the other hand, these services play an important role in the organizational business
processes.3,113 Whereas some management applications, such as help desk, have wide
applications in all types of businesses, many applications are specific to certain types of
businesses.150
Subsequent sections discuss some relevant standards and their limitations.
12
2.4. INTEGRATED MANAGEMENT STANDARDS

This section presents a brief outline of the major network, systems, and service
management standards.
2.4.1.
Internet SNMP
Although some of these standards are being implemented by some telecommunications

provider organizations, LANs and the Internet-based solutions and standards have been most
prominent in the corporate management information systems sector. This has resulted in the
widespread adoption of the Internet management standards, including SNMP and Internet
MIBs, as the network management framework for networking devices and equipment. This
is mainly a standard at the instrumentation level of the integrated management framework
described in Fig. 2.3. According to the approach currently being taken, the management
problem reduces to the development of MIBs for the managed elements.157 The IETF has
defined a number of network management MIBs, such as Bridge MIB (for managing network
bridges), and systems management MIBs, such as Host MIB (for managing host computers).
The IETF has also developed a number of standards for the modeling and management
of distributed applications and services in an enterprise network. Some of these are Network
Service Monitoring MIB (RFC 1565), Directory Monitoring MIB (RFC 1566), and Mail
Monitoring MIB (RFC 1567).117,156 Although these MIBs are useful for the identification of
application attributes that need to be managed, the management framework of SNMP does
not provide any means of expressing management as a distributed processing application.
Although SNMP is now a widely used standard at the instrumentation level, vendors
need to provide abstract models for the representation, aggregation, and correlation of
management information for solving management problems at the platform level. Therefore,
SNMP has a limited utility in the development of distributed management applications. The
IETF has been working on improving SNMP features for this purpose through the release
of the newer versions of SNMP, namely SNMP version 2 and SNMP version 3.148
2.4.2.
ISO/ITU OSI Management
ISO and ITU have jointly collaborated on producing OSI Systems Management standards (IS0 7498-4). These standards are aimed at the management of OSI communication
systems. As mentioned before, OSI Management uses the manager-agentmodel, using a
management communication protocol called CMIP. The structure of management information in OSI Management uses an object-oriented view. Therefore, OSI MIBs are defined as
managed object class libraries. Management functions have been classified into five categories: Fault management, Configurations management, Accounting management, Performance management, and Security Management (FCAPS). A number of systems management
functions have been developed to bridge the functionality gap between low-level managed
objects and high-level FCAPS functions.117,155
As in the case of the Internet SNMP, OSI management solutions largely depend on the
development of appropriate managed objects. A number of such MIBs have been developed
for telecommunication provider applications, such as Synchronous Digital Hierarchy (SDH)
system and switch management. In the area of general enterprise service/applications
Chapter 2.
13
management, ISO/lTU have taken up work on some specific applications such as electronic
mail (X.400) management. However, the focus of all these works is on the management of
open communication systems as defined in OSI They do not address issues related to a
heterogeneous, distributed processing environment. Therefore, OSI management standards
may not be adequate for defining high-level distributed management services and applications.
2.4.3. ISO ODP
The purpose of ISOs ongoing standardization effort, ODP, is to develop a framework
that specifies an architecture integrating support for distribution, interoperability, and portability. Fundamental to this reference model (RM-ODP) is the notion that distributed
processing systems can be studied and described from several viewpoints, presented here
with respect to the OSI Management model:
The enterprise viewpoint studies organization wide requirements and policies.
The information viewpoint addresses information structure issues of distributed
applications.
The computational viewpoint expresses the functionality in distribution-transparent
manner.
The engineering viewpoint describes mechanisms for providing distribution transparencies.
The technological viewpoint describes the implementation and testing aspects of a
distributed system including relevant hardware, software, and standards.83
The enterprise viewpoint allows the description of the enterprise-level view of a distributed
system, encompassing huma/organizational roles, their obligations, permissions, and prohibitions. This helps in presenting a distributed network/systems management infrastructure
in the context of the organizational business entities. This is very important from the point
of view of providing a seamless integration between business management and network
management.
The information viewpoint provides a mechanism to represent the structure of information in a distributed system, through schemas (the state and structure of management
information), relations (between managed objects), and a set of integrity rules (assertion
about a schema). The information specification can be through a variety of methods (e.g.,
Entity-Relationship (ER) diagrams, and languages such as ISO ASN. 1).
The computational viewpoint shows the interfaces of objects participating in a distributed system. Whereas network management standards, such as SNMP and CMIP, define
operational interactions between manager and managed objects, the ODP computational
view allows other interfaces, such as streams. For example, multimedia objects may need
stream interfaces for their management.
The engineering viewpoint describes a distributed system in terms of structural entities
called objects; clusters, capsules, channels, and functions. OMG CORBA has now become
a standard for the implementation of object-based distributed systems. Therefore, RM-ODP
now has adopted OMG CORBA as the infrastructure model at the engineering level. Hence,
14
an ODP engineering viewpoint may be expressed in terms of CORBA Object Request Broker
(ORB), stubs, skeletons, basic object adapters, and CORBA clients/servers.
The technology viewpoint is concerned with the implementation of an object-based
distributed system.
RM-ODPprovides a conceptual framework for the study and development of distributed systems including management applications. Some of these concepts are used in
evolving standards in the area of distributed telecommunications, such as TINA described
in section 2.4.5. Ray, Loge, Gay, and Fry138 describes a help-desk-based trouble-ticketing
application from ODP viewpoints.
However, ODP viewpoints do not provide adequate mechanisms to describe network
management processes integrating business processes. For example, ODP viewpoints do not
provide any model for describing human interactions as part of an organizational process.
Therefore, there are a number of open issues in the integration of business processes with
management applications, as is discussed in section 2.5.1.
Corporate computing users have adopted a number of vendor-proprietary distributed
object-based solutions for the management of enterprise network.18,70,78,159
Sections 2.4.4 to 2.5.6 describe some emerging standards in the telecommunication
service provider domain.
2.4.4.
ITU Telecommunications Management Network (TMN)
A TMN is a network to provide surveillance and control of another telecommunication

network.151 It defines a layered logical architecture of management for services and systems
for telecommunication. Business/Enterprise Management Layer (BML) is concerned with
the overall management of the telecom carrier business. Service Management Layer (SML)
is concerned with the management of services provided on the network; for example,
Intelligent Network (IN). Network Management Layer (NML) is concerned with a network
with multiple elements. Element Management Layer (EML) is concerned with individual
network elements; for example, multiplexers and switches.
TMN defines an architectural framework consisting of reference points and interfaces
between different building blocks of a telecommunication system, such as operations
systems, workstations, mediation devices, and network elements. These reference points and
interfaces correspond to the instrumentation in the integrated management framework. TMN
uses the OSI management information model, and the OSI CMIP protocol for this.117,155
The focus of TMN is on the management of telecom equipment (switches, transmission
gear, etc.). Hence, most of the work has been done at the lower layers, that is, EML and
NML. Standards for higher layers are in the early stages of evolution.3,113,173
2.4.5.
TINA
Bellcore-initiated TINA provides a set of specifications for the deployment and management of scalable, multivendor, distributed services over a heterogeneous network. It uses
the ISO ODP modeling concepts, the OMG distributed object model CORBA, the ITU IN
standards, and the ITU TMN management hierarchy.161 TINA was born out of the need for
the independent development of two aspects of telecommunication businesses: the commodity or transport business concerned with carrying bits over a network; and the growing
Chapter 2.
15
value-added-service business, such as the Internet services. TINA has adopted a distributed
object-based client-serverparadigm for this purpose. This architecture provides a software
infrastructure to support the following properties: openness, flexibility against regulation,
uniform support of management, support of multipart, multimedia services, inherent mobility support, scalability, separation of service control from the switch, reusability of software,
compatibility with existing networks and services, and technological evolution.130
TINA addresses these and a few other related issues by proposing a new architectural
model with a number of levels (see Fig. 2.5). The Native Computer and Communication
Environment (NCCE) represents a heterogeneous networked computing environment. The
Distributed Processing Environment (DPE) provides the distribution transparencies to
systems-independent applications and services implemented over an NCCE. Figure 2.6
positions the above mentioned different integrated management standards in the context of
the basic Integrated Management Framework (IMF) shown in Fig. 2.3.
The native computer and communication environment consists of operating systems,
networks, and related services, such as databases, protocol stacks for data, and audio/video
communication. Although TINA does not prescribe any specific distributed system model,
OMG CORBA is being accepted as the DPE for most TINA implementations. The applications at the information networking services level are developed using a number of TINA
catalog services (object templates) being developed for various applications.
TINA has modified the CORBA Interface Description Language (IDL) to include some
real-time functionality, such as multimedia streams. The modified language is called TINA
Object Definition Language (ODL). TINA inherited some of the original concepts of
Bellcore Information Networking Architecture (INA), consisting of building blocks and
contracts. 143
A building block is a software product that contains one or more computational objects.
It is built, installed, and maintained as a unit. Objects in a building block share a set of
properties, such as common security features, common access interface, and common
location. A service provided by an object contained in a building block that is visible outside
the building block is called a contract. Building blocks are categorized as user level, service
level, or data level depending on their type of use.
Figure 2.5. TINA software architecture.
16
Figure 2.6.
Network management standards in IMF.
Whereas the TINA DPE and building blocks provide an architecture for the development
of applications and services, the TINA business model and reference points provide business-level interfaces between different business roles, as shown in Fig. 2.7. TINA defines
interfaces (reference points) between the following telecommunication business roles:
consumers (i.e., the end customer), connectivity providers (a network operator), retailers (a
retail service provider), third party service providers (distributors), and brokers.161
Reference points are specifications of interoperability between administrative domains.
As shown in Fig. 2.7, the following reference points are currently being specified in TINA:
Retailer interdomain reference point (Ret).
Broker interdomain reference point (BKr).
Third party interdomain reference point (3Pty).
Retailer-to-retailer interdomain reference point (Rtr).
Connectivity service interdomain reference point (Cons).
Terminal connection interdomain reference point (TCon).
Layer network federation interdomain reference point (LNFed).
Client-serverlayer network interdomain reference point (CSLN).
Whereas the OSI management model considers management from the perspective of
FCAPS functions, the TINA management architecture also considers a number of additional
dimensions, namely:
Partitioning: TINA services and management are organized into three layers, namely
service, resource, and DPE.
Chapter 2.
Figure 2.7.
17
TINA business reference model.
Computational: this dimension is concerned with the management of various aspects

of DPE, such as event management.
Life Cycle: this represents different phases of the service life cycle, such as conceived
(not planned), not installed, installed, and activated.62
As shown in Figure 2.8, TINA defines the object-oriented framework for the implementation
of the middle three layers of TMN; that is, the service management layer, the network
management layer, and the element management layer. The business management layer and
the network element layer are outside the scope of TINA. Although the TINA business
reference model defines reference points for the interoperability of services across domain
boundaries, TINA does not provide any methodology for the integration of business
management with service/network management. In addition, substantial work needs to be
done before TINA can be used for the development of service management solutions.
Because business management issues have not been addressed in TINA, human and organizational factors have not been considered in the TINA framework. Unlike Internet SNMP
and OMG CORBA, TINA has not yet been accepted in the integrated management and
distributed systems industries.
TMN Layers
TINA Layers
Business Management Layer

Service Management Layer
Network Management Layer
Element Management Layer
Network Element Layer
Figure 2.8. A layer-wise comparison of TINA and TMN.
18
2.4.6. Distributed Management Task Force (DMTF)

A discussion on integrated management standards would be incomplete without a
mention of the recent developments in systems management standards, initiated by the
industry group DMTF, consisting of major computer and software vendors. DMTF efforts
originated from the need for controlling the total cost of ownership (TCO) of PCs. Although
the hardware cost of PCs is falling, the TCO is increasing due to rising costs of tracking and
updating software versions, licenses, and the support in a geographically distributed enterprise environment. DMTF has announced a number of standards-Desktop Management
Information (DMI), the Common Information Model (CIM), and WBEM.
Although SNMP and OSI Management have a number of MIBs for managing different
types of networks and applications, these are too elaborate for the cost-effective management
of PC components, such as VGA cards, monitors, SCSI disk drives, and PC-Windows
software. Hence, DMTF DMI defines a simple management framework to support the
management of PC components based on instrumentation interfaces, called Component
Interface (CI), and an ASCII Management Information Format (MIF) that provides management data for a PC component. This management software, called DMI Service Provider,
can support management applications through a Management Interface (MI). This also
provides mappings from SNMP (Fig. 2.9).
DMTF has standardized a management platform level object model, called CIM, to
integrate management information from diverse network elements. DMTF has also standardized a WBEM specification, based on CIM and a web-based protocol, called HyperMedia
Management Protocol (HMMP).163
2.4.7.
Comparison of Integrated Management Standards
Table 2.1 presents the applicability of different management standards on the integrated
management framework described in Fig. 2.3. At the instrumentation level, SNMP MIBs
and OSI Managed Objects are now standardized. At the platform level, TINA DPE, CORBA
ORB, and OSI System Management Functions are the major standards. Most platform
Figure 2.9.
DMTF Desktop Management Information (DMI) architecture.
20
vendors add many other proprietary features for effective management support. The management application level can be divided into two layers: TMN BML and TMN SML. At the
SML, the major standards are TINA building blocks, CORBA objects, and ODP computational and information viewpoints. At the BML, the only well-known standard is the ODP
enterprise viewpoint. This area offers substantial scope for research. In the subsequent
chapters, this book presents some developments from other areas, such as workflow management and groupware. Table 2.1 presents a brief comparison of these standards from the
perspective of management applications.
Although Internet SNMP is extensively available in the market, it has very limited
capability in supporting distributed management applications and their integration with
business processes. DMTF, TINA, ODP, and TMN standards support distributed processing.
However, none of them support human cooperation.
2.5.
INTEGRATION WITH ENTERPRISE BUSINESS PROCESSES
Thanks to the rapid development in management technology, it is now possible to get

raw management data (using standard MIBs) from various network devices and applications.
With the growing popularity of management standards like SNMP, more and more components will become manageable from a remote console. However, manageability here
means the ability to get and modify certain predefined parameters from these devices and
applications. This does not necessarily translate to an increase in management productivity.
Hence, there is a growing focus on service management, concerned with the specification,
monitoring, and control of a business service based on some accepted measures. Service
Level Agreements (SLAs) incorporate a summary of these agreed-on measures, such as
percentage availability, number of failures, and so on.131
It is unlikely that these concerns will be adequately addressed with the present focus on
the management of equipment. Effective management of information infrastructure depends
very much on the experience and expertise of the people operating the management systems.
This requires a thorough understanding of the process of management and the success of
management applications will depend on the effectiveness of the process knowledge/study.66
This is evident with the widespread use of the trouble-ticketing application-one of the few
well-understood management processes.
2.5.1. Process Management
A process is a representation of knowledge organized into the design of an action whose

results will meet a goal.41 Process knowledge can be categorized into the following classes:
task knowledge, relating to the specification, design and performance of a task; and context
knowledge, relating to the rest of process knowledge concerning the goal, its motivation, and
the environment/context. For example, connecting a line requires the task knowledge related
to finding the right connector, cable, necessary tools, and the required points. Context
knowledge may include the telephone numbers of people who need to be contacted in case
of a problem in the task.
Process management is primarily concerned with the integration of task and context
knowledge in application. Processes vary from place to place and from organization to
Chapter 2.
21
organization. There is a growing realization69 that management applications should be

designed around key work processes. For example, trouble-ticketing automates the process
of problem management. Future management systems are expected to incorporate process
management that enable the operations staff to shift its focus from managing equipment to
managing processes. Management will become a distributed, cooperative problem-solving
activity.
2.5.2.
Integration of Service Management with Network/SystemsManagement
Figure 2.10 shows a view for the integration of network/systems management with
enterprise business processes. Whereas network/systems management objectives are to
provide the integration management of heterogeneous elements, service and business management is primarily concerned with the optimal utilization of major organizational resources, namely people and organizational knowledge. Because todays network
management concentrates only on the factors related to technical systems, processes of
management solutions address only technical aspects. However, modern business is very
much customer oriented. Let us take the example of stock broker application discussed in
Section 2.1. In this case, the business objectives are to quickly identify market opportunities
and to convert them into deals. Although interoperability of heterogeneous systems is
important, it would be more important to locate and access efficient networked computational services and appropriate well-maintained knowledge bases. Most existing networked
systems do not address these functions.
Therefore, many of the business processes involve customer- and people-related factors.
In an enterprise network, both technical and marketing groups use similar information
infrastructure (e.g., relational databases and the help-desk model). However, their processes
are different. For example, both groups may be using Oracle databases and Lotus Notes
Groupware. However, they cant share information because of different processes. Increas-
Figure 2.10.
Integrating service management with network/systems management.
22
ing competition in the information service marketplace has created a strong demand for the
integration of business processes with network management processes in an enterprise.
There are no industrywide models for integrated management because of differences in
networks, in roles, in policies, in forms, in checks, and so on in different organization.94 It
is, however, quite clear that the integration of business processes with network/systems
management requires the following considerations:
Integration of business goals with network/systemsmanagement policies.
Integration of tools and techniques to enhance cooperation of multiple groups of
people.
Continuous development and easy access to an organizationwide knowledge base.
Some recent research has shown that to solve the previously mentioned problem of integration, it is necessary to define a new process centeredenvironment(PCE), encompassingtools
for the specification, development, and deployment of business process-oriented management solutions, independent of computing, networking, and network management environments.1,125However, this is a complex problem because of the involvement of a number of
diverse groups of people and organizations.
The following sections describe some of the emerging developments to address the
previously mentioned problems.
2.6. RECENT DEVELOPMENTS

This section provides a brief overview of some recent developments that address the
problem of the integration of business processes with network/systems management.
2.6.1. Knowledge Technologies

Traditionally, rule-based expert systems have been considered as auxiliary tools for
network management. Over 40 such systems have been used in Regional Bell Operating
Companies (RBOCs) in the United States for diagnosing faults in external telephone
equipment.54 Network management researchers are now experimenting with a number of
Artificial Intelligence (AI) techniques, such as expert systems, case-based reasoning, fuzzy
logic, and intelligent agents for integrated management.100,120 This can range from rerouting
circuits in case of failure to alerting operations personnel of the impending failure of a
network element.
However, expert systems can handle only narrowly focused problems within a stable
environment. Many network management problems do not offer such an environment, and
expert systems are likely to need extensive maintenance and may become obsolete before
effectively used101
In contrast to traditional SNMP agents, Intelligent Management Agents (IMAs) can
perform useful management activities independently of central managers or operators. For
example, IMAs may be able to correlate faults, determine problems, and take corrective
actions. Alternately, they may turn raw data into useful information, such as network
Chapter 2.
23
topology information. IMAs are functionally both managers and agents. Human operators
may query IMAs directly.77 Pham and Karmouch124 have provided an overview of evolving
mobile intelligent agent technologies and their relationship with the manager-agentparadigm of integrated management. Oliveira and Labetoulle120 have explored the problems and
issues relating to the use of programming concepts for intelligent agents in managing
distributed systems.
According to a news report, Computer Associates (CA) is adding to its popular
enterprise network management product, UniCenter, a new feature, called The New Dimension (TND), that will alert administrators to new network problems based on neural
networks.32
2.6.2. Visualization
A fundamental feature of an advanced network management station is the capability to

present to the human manager a complete picture of the relevant scenarios. The overwhelming volume and complexity of the information involved in network management scenarios
pose a major challenge. Examples of data visualizations that are relevant for network
management are the network topology at different levels of abstraction, the presentation of
network configuration information, and the display of management information bases and
their history traces.27
Modern management platform technology seeks to solve this problem by providing
color graphic window-based user interfaces, a common integrated database at the platform
level, and flexible (object-oriented) management information models.
Researchers are working on presenting the processed management information with
respect to multimedia conceptual network models and virtual reality.92For example, a
management problem could be presented with respect to the TMN hierarchies and the ISO
FCAPS functional model. Such facilities, however, consume a large amount of computing
resources (processing power) and network bandwidth. Today's managers need to be more
and more mobile, necessitating the use of mobile terminals with limited features due to
restrictions in bandwidth, power, and size.37,81,133
2.6.3. WWW-Based User interface
In an enterprise network management environment, users need to share various types

of information, such as MIBs for managed devices, change schedule databases, customer
configurations and contracts, vendor equipment documentation, text discussion e-mails, and
so on from different sources. Many organizations now have WWW-based group support
services for sharing information.9
Whereas SNMP provides a common standard at the instrumentation level of management framework, the WWW may provide such a standard for sharing information at the
platform and the user level. This is quite convenient as network managers can now manage
the network from any place and from any platform. For example, GTE has adopted
ubiquitous web-based management interfaces for service provisioning because large number
of employees need to share common information for this purpose.11
There are now two major industry efforts evolving a common approach to web-based
management72;WBEM and Java Management API (JMAPI).
24
Many vendors, such as Cisco Systems, have introduced WWW-based management

tools. As discussed in section 2.4.6, an industry consortium consisting of BMC, Cisco
Systems, Compaq, Intel, and Microsoft, called WBEM consortium (all WBEM work was
transferred to DMTF in 1998), and the DMTF are working on a web-based integration of
management services offered by diverse management platforms using CIM and XML (see
WBEM web site http://www.dmtf.org/wbem/).
JMAPI provides a set of extensions to Java basic classes for integrated management
solutions in a heterogeneous environment. This core set of APIs can be used across a diverse
array of computing environments.
The next generation of User Interfaces (UIs) may move beyond the standard windows,
icons, menus and pointers (WIMP) paradigm to involve elements such as virtual realities,
head-mounted displays, sound and speech, pen and gesture recognition, animation and
multimedia, limited artificial intelligence, and highly portable computers with cellular or
other wireless communication capabilities.112
2.6.4. Management Policies
Management policies provide a flexible framework for the definition of management

objectives, independent of underlying implementation mechanism.152 As shown inFig. 2.1 1,
policies are the link between the two disciplines of corporate management and technical
management of networks, systems, and applications. From the corporate management point of
view, policies achieve a certain set of goals within the corporate operating environment with
human elements. This is represented by the corporate management process cycle in Fig. 2. I 1.172
The second cycle shown concerns the interaction between policies and resources
through underlying technical control mechanisms, as defined in TINA, CORBA, OSI, DMI,
and SNMP. Policies are enforced through enforcement instructions to resources. The
enforcement actions need to be monitored for feedback in order to reinforce or to alter a
policy. Although management policies have been successfully used in the management of
network equipment, such as routers, researchers are now working on more sophisticated
Figure 2.1 1. Management policies.
Chapter 2.
25
policies based on intelligent agents. Although some researchers have defined notations and
languages for the development of policies, there is no methodology for the definition of
policies that would incorporate human interactions.
2.6.5. Open Problems

As seen in the previous discussions, the area of management applications is in a nascent
stage. Many new paradigms, such as process management, AI techniques, and new tools for
visualization are being introduced to tackle complexities in the development and the
deployment of distributed management applications. However, most organizations are very
much dependent on the individual skills of network support people in tackling real-world
problems. With the growing complexity of modern enterprise networks, it is becoming more
and more necessary to harness management expertise across organizations. The OmniPoint
2 recommendations from the Network Management Forum (NMF) have started some work
toward the integration of telecommunication service provider businesses, services, and
network management.114
Recent developments, such as SNMP v3, TINA reference points, CORBA-based
management, and intelligent-agent-based management concentrate on providing more and
more refined object-oriented software architecture for enterprise wide integrated management. However, the fundamental open problem is how to relate integrated management
objectives to management application development. This requires a methodology (including
models, processes, and notations) that would provide a seamless integration of business
processes with integrated management.
2.7. CHAPTER SUMMARY

This chapter has discussed the existing standards and some evolving ones in the area of
integrated management. This framework consists of three major elements: instrumentation,
platforms, and applications. There was a discussion on various evolving standards for
network and service management, such as SNMP, OSI, CORBA, DMI, TINA, and TMN.
This was followed by a presentation of the problem of the integration of organizational
business processes with network/systems management. Then there was a discussion of some
recent advances, such as multimedia visualization for management, web-based management,
application of knowledge technologies, and management policies.
The complexity and diversity of management applications calls for powerful abstraction
techniques to translate real-life business requirements to technical management solutions.
Although there has been substantial progress in the standardization of management interfaces
for network components and management platforms, the success of future management
systems will depend on the efficient harnessing of task and context knowledge related to
such systems. Because this involves remote cooperation of experts/operators/technicians
within and across organizations, cooperative management processes are expected to form a
part of the management infrastructure of enterprise networks. Therefore, the cooperative
management of enterprise networks is mainly concerned with integrated management as a
CSCW process. The next chapter discusses some CSCW basics, followed by its application
in integrated management.
3
Computer Supported Cooperative Work
(CSCW)
The objective of this book is to develop integrated management systems that provide
seamless integration with enterprise business processes. Chapter 2 discusses some recent
developments in this area. Whereas researchers in this area are working on the application
of techniques from diverse disciplines, such as software engineering, artificial intelligence,
and network engineering, this book explores techniques from the newly developing area of
CSCW.
This chapter begins with a definition of CSCW and a discussion of its major benefits.
This is followed by a brief overview of the evolution of this subject. Finally, there is a
discussion on two major components of CSCW, groupware and workflows.
3.1. WHAT IS CSCW?

Computer-supported cooperative work, or CSCW, is the body of theory and practice which is concerned
with the use of computers to support and enhance the work activities of groups. It involves work from a
number of fields including: human-computer interaction, sociology, organizational psychology, user
interface software, and distributed systems.55
CSCW is fusion of the understanding of a business organization with the possibilities

of computer and communication technologies. This definition was developed by Tom
Rodden of the Center for CSCW at Lancaster University.141 There are a number of other
definitions of CSCW.26
The objective of CSCW is to provide effective networked computing support for
organizational business processes involving human participation. The computer and information technologies have traditionally focused on the optimal utilization of expensive
machines and software. The rapid reduction in the cost of hardware and of commodity
software is changing this notion. Mark Weiser of Xerox PARC visualizes a world, in the
not-so-distant future, when there will be tens or hundreds of computers for every human
worker in a workplace, at least in the developed world.171 Although computer and communication technologies are striving for better tangible quality of communication (e.g., higher
resolution of image, higher fidelity of audio and video, and higher bandwidth of transmis27
28
develop ways and means of achieving better utilization of human resources in an organization, at the cost of suboptimal, or even wasteful usage of computing machines. Consequently,
a large section of people in the world does not feel comfortable in using the latest information
technology. 104
On the other hand, the growing need for people to work in groups necessitates the
support for group processes through information technology. For example, in many cases,
group members may need to collaborate from geographically distant locations. Therefore,
researchers in CSCW have been working on developing schemes and configurations of
networked computing and human-computerinterfaces to support cooperative work among
people across cities, countries, or continents. Although CSCW uses sophisticated technology,
such as video conferencing, workflow management, groupware, autonomous agents, and
distributed object computing, the objective is to facilitate collaborative work among people
through appropriate user-friendly tools. Any difficulty in using these tools would hinder
collaboration. However, these tools should not compromise basic human rights, such as
privacy and security.
3.1.1. An Understanding of Business Organizations
Laudon97 defined business organizations from the perspective of information technology as follows:
Global networks
Enterprise networks
Re-engineering of business processes
Virtual organizations
Organizationwide information access
Today's enterprises operate on a global scale. Operations are no longer dependent on
location. For example, a network management problem in Sydney, Australia, may be solved
through on-line computer communication among a help-desk operator in Bangalore, India,
a Cisco expert in the United States, and a traveling HP OpenView expert connected through
a wireless connection.
Enterprise networks encourage collaborations within and across departmental/divisional boundaries in a multilocation organization. This calls for both customer and product
orientation. Widely dispersed task forces become a dominant work group. This would be the
information organization for a typical multinational company, such as IBM.
Advances in distributed computing have given so much flexibility to companies that
business processes are being redesigned to save substantial cost and afford an enormous
competitive advantage. For example, some insurance companies are now processing applications in 3 days as opposed to 17 days, as was previously the case.97
Work is no longer tied to a geographic location. Knowledge and information can be
delivered anywhere they are needed, at any time. Work, and hence computing facilities,
become portable. This encourages telecommuting, leading to substantial savings in organizational expenses. Most management professionals today carry pagers and cellular phones,
making themselves available instantly for work from any location at any time. Additionally,
Chapter 3.
29
making themselves available instantly for work from any location at any time. Additionally,
thanks to user-friendly interfaces and electronic mail, people at all levels in an organization
can access and disseminate information.
Having looked at the business processes, the reader may now want to explore the
possibilities of communication technologies.
3.1.2.
Communication Technologies
This subsection presents a brief overview of communication technologies relevant to

CSCW. Figure 3.1 shows the cooperative environment for a management professional
involved in CSCW.
Successful operation of CSCW systems requires effective communication at a number
of communication interfaces, such as human-computer interaction, computer-mediated
human-human communication, and support for changing membership in various
groups.64,128,170 The major objective of this technological support is to diminish the cognitive
gap between concepts easily understood by users and those used by system designers. The
key elements of this support are as follows: easy access to information, improving usability,
and maintaining awareness.
Easy access to information is achieved by multimedia object-oriented document databases, such as those used in Lotus Notes.102 Usability can be expressed in terms of a number
of factors, such as the effort required to reach a specified level of performance (learnability),
the speed of execution and errors made (throughput), the extent to which system can
accommodate changes after design (flexibility), and the positive attitude engendered in users
by the system (attitude).48 Recently a number of "tool-sets",such as the Human Factors in
Information Technology (HUFIT) toolkit, have been developed to provide human factors
input to the design of Information Technology (IT) products. British Telecom uses a similar
method, known as TELSTAR, in which human factors specialists complete forms on task
characteristics and for the definition of user needs.128
Awareness of other people's presence and work is one of the most important factors in
collaborative environments. Participants in a CSCW process need to know of other group
members and their activities, their attitudes, the types of artifacts (tools, office facilities)
used, the usage rate, and so on. The objective of the requisite interfaces is to keep other
Figure 3.1. Network manager i n a C S C W environment.
30
purpose. These are achieved using autonomous agents and various messaging systems in real
life.
These requirements translate to a variety of metaphors, such as windows, icons, menus,
and pointers in todays user interfaces. Multiwindow displays and multimedia technology
are playing important roles in this technology framework.
We now discuss some enabling communication technologies that help fulfill above
human communication needs:
Human Computer Interaction (HCI)
Computer Telephone Integration (CTI)
Multimedia Networks and Services
Media Processing
Wireless Mobile Communication
Autonomous Agents
The Association of Computing Machinery (ACM) Special Interest Group on Computer
Human Interaction (SIGCHI) defined HCI in terms of four aspects: use and context (social
organization of work, human-machinefit/adaptation), human information processing (language/interaction), computer aspects (user interfaces, dialogue techniques), and the development process (design, implementation, and evaluation approaches).39,128
CTI can be defined as a technology platform that merges voice and data services at the
functional level to add tangible benefits to business application.170 CTI is possible now
because of programmable features in modern telephone switches. It allows substantial office
productivity through the integration of computer, telephone, and fax services. CTI can be
used for both outbound and inbound calls. Outbound CTI is useful with outgoing calls, such
as in a telemarketing campaign, where a large number of people need to be called by a set
of agents. Inbound CTI is useful with incoming calls, such as with Automatic Call Distributor
(ACD) services used by many customer service organizations (e.g., banks) to direct callers
to a variety of options through touch-tone telephone keys.
Multimedia services are now becoming affordable due to recent developments in a
number of related technologies, such as high bandwidth optical fiber media, high-speed ATM
and other networking protocols, and low-cost multimedia encoders with high compression
ratios, Recent developments in the related Internet protocols allow desktop multimedia
conferencing based on shared video, audio, and network-based whiteboards.
Media processing includes some developing processing technologies, such as speech
synthesis, speech recognition, hypermedia systems, video mail, intelligent image processing,
and WWW technology. Many of these features are now being used by organizations in
applications, such as marketing and advertisement, and in geographical information systems. 170
Thanks to recent developments in infrared, microwave, and satellite technologies, it is
now possible for mobile people to participate in group activities from a distance through
cellular phones, pagers, and wireless data devices. Although mobile systems have limited
bandwidth, high compression multimedia encoders may be able to communicate video,
audio, and images for some applications adequtely.81
Chapter 3.
31
The concept of intelligent/autonomous agent has been derived from Distributed

Artificial Intelligence (DAI).109 Agents are conceptual entities that assist various roles
(human/information system) in a workflow/CSCW environment. Recent trends in distributed processing use intelligent agents that interpret a scripting language such as TCL or Java,
enabling sophisticated new management functions to be loaded into existing management
agent interpreters. A variation on this concept is the use of mobile agents that move around
the network performing actions on behalf of users.105
Table 3.1 presents how these communication technologies support CSCW process
requirements. In this table * means that the particular CSCW requirement is met by that
enabling mechanism. For example, awareness is supported by all the enabling technologies,
that is, HCI, CTI, mobile communication, and multimedia tools. These technologies are put
together as part of the design of a cooperative management systems in chapter 6.
3.1.3. Benefits of CSCW

The benefits of CSCW can be summarized as follows: efficiency, quality, networking,
knowledge-sharing, better customer service, cost-effective, concurrent processes, and control over intellectual property and copyrights.64CSCW allows better use of peoples time by
reducing time spent on activities, such as making copies, distributing paper, and manual
tracking of information. This is particularly important for management professionals who
are always busy.
CSCW provides better access to information to all within an organization, making
everybody aware of the latest information and activities of other members in a team. As
discussed in subsequent chapters, the right level of awareness is very important in such jobs.
CSCW allows people at different locations in an organization to stay in touch better
through the latest communication technologies, such as videoconferencing. Integrated
management processes need cooperation from distances within and across organizations.
Therefore, this feature is very important.
The CSCW environment provides various tools to support joint working among coworkers at distance, in all phases of knowledge sharing, such as document preparation,
consultation, joint design, contextual discussions, and contextual evaluations. Because good
management people are scarce, such tools are very useful in integrated management
problems. CSCW supports this through better tracking of customer information, using
models, such as help-desk. Help-desk-based trouble-ticketing is one of the most popular
integrated management applications.
Table 3.1. Technology Support for CSCW

Technology Support
HCI
CTI
MultimediaNetworking
Mobile Communication
Media Processing
Information Access
*
*
*
*
Usability
Awareness Support
*
*
*
*
32
CSCW reduces costly travel by a number of people over long distances to allow joint
meetings. In the case of integrated management, this also saves the cost of nonavailability
of a scarce professional during travels.
CSCW systems allow different team members to work concurrently in spite of differences in location and time zones. Because many mission-critical applications are now
dependent on networks, the cost of down time is very high. Therefore, during a network
failure, it is imperative to have a number of investigations proceed concurrently, thereby
reducing the down time.
CSCW systems support hypertext interfaces, obviating the need for contentious document sharing processes, such as copying. Besides, tools are available to automatically keep
track of any violations in copyrights or intellectual property rights. Busy management people
do not need to worry about such issues.
3.2. THE EVOLUTION OF CSCW

According to Grudin,57 CSCW was born in 1985 with some unsolved problems ofOffice
Automation (OA). These problems are related to the understanding of system requirements.
Building technology was not enough. OA professionals needed to learn how people worked
in groups and organizations and how technology affected them. Hence, technologists needed
to learn from economists, from social psychologists, from organizational theorists, from
educators, and from anyone else who could shed some light on group activity. Applications
include desktop conferencing, collaborative authorship, electronic mail, electronic meeting
rooms, and group support systems.
This section categorizes CSCW systems in terms of four concentric ellipses, similar to
Grudin rings,57 as shown in Fig. 3.2. Whereas the upper half of each ellipse represents the
enterprise network infrastructure, the lower part represents the corresponding management
infrastructure. The following description presents integrated management as a CSCW
process. The innermost ring represents small networks managed by individual technicians.
The outermost ring represents the management contexts of large organizations, such as public
telecommunication service providers. Larger enterprise networks may encompass a number
of smaller networks.
Although these are the two extremes of CSCW systems, there has been a proliferation
of networks in the inner two rings. For example, as small networks prow to medium size,
management may require the cooperation of four to five persons located at different places
(the second innermost ring). On the other hand, many corporate networks now own
sophisticated management platforms with multiple groups of people at different locations
(second outermost ring). Cooperabon requirements for these categories of CSCW systems
are described later in this chapter.
Large organizations have people in multiple divisions/departments within the organization and people from external organizations such as customers and vendors cooperating to
manage networks and their services. These organizations use a variety of platforms and tools
for the operation and management of their networks and businesses. People in these
organizations are familiar with the interplay of social dynamics, organizational systems, and
human factors with integrated management pocesses.57 As an example of how CSCW might
be relevant to such organizations, Suchman described an anthropological approach to the
Chapter 3.
Figure 3.2.
33
CSCW view of enterprise network management.
study of human and machine intelligence. She and many other researchers in sociology feel
that human behavior varies depending on the situation.58 This makes it difficult to generalize
observations, Hence, there is a need for so-called situated study of human cooperation.
She argued that the planning model of interaction favored by the majority of AI researchers
does not take sufficient account of the situatedness of most human behavior. Suchman
concluded that many humans are more guided by an objective than by a meticulous plan.
Therefore, much effort in producing rigorous plans may not increase productivity in all
situations. This finding is quite significant for the development of group support systems
required in a CSCW environment.
CSCW in some countries also reflects cultural norms, such as national homogeneity,
strong trade unions, and extensive social welfare systems. For example, Scandinavian
participatory or collaborative design approach reflects priorities, such as the need to support
workers who have lost their jobs due to automation.
Integrated management systems emerged from two different streams, namely telecom
network management and corporate LAN management. Whereas corporate LAN management is of recent origin, network management in telecom carrier organizations is a fairly
developed and complex organizational process. Corporate enterprises may use formal
network management platforms or Operation Support Systems (OSS) to manage and operate
their networks, perhaps spanning across continents. These organizations employ qualified
network management personnel. However, there is now a tendency to use increasingly
sophisticated help-desk systems to operate networks while using fewer skilled people.61,178
34
Figure 3.3. Workgroup computing for systems management.
Such organizations, therefore, need cooperation across multiple groups of people with
different levels of competence in integrated management.
The recent growth of multiple LANs and intranets have made many organizations
critically dependent on a small group of, say, four to five support technicians. These scarce,
skilled people must be adequately supported for the survival of organizational businesses.
Therefore, small-group support is becoming increasingly important for commercial integrated management product developers.
We incorporate these contexts into the development of a cooperative management
methodology for the management of enterprise networks based on CSCW. This will require
an understanding of the major constituents used in CSCW. As shown in Fig. 3.3, CSCW can
be viewed as an infrastructure standing on three main props: workgroup collaboration,
groupware, and workflows.64 A number of empirical studies have been reported on all these
three aspects in the CSCW literature.49 The following sections present a discussion of these
cscw components.50,141
3.3.
WORKGROUP COLLABORATION
Workgroup collaboration is a term used to define the modes of collaboration, that is,
cooperation (following rules), coordination (protocols for joint work), and sharing (the same
information). In a real CSCW system, various aspects of workgroup collaboration are
supported through groupware and through workflow mechanisms.
Gwynne61presented an application of workgroup computing in systems management
applications involving the support and software updates of PCs and PC-based software.
Although the cost of PCs is falling, the management support costs are increasing. According
to the Gartner Group, these management and support costs are 60% to 90% of the total cost
of ownership of the system. Systems management vendors, such as IBM, are now working
on workgroup computing solutions that would allow remote troubleshooting and configura-
Chapter 3.
35
tion management of user PCs by vendor technicians and specialists from their offices.
Intelligent agents are being incorporated in these systems to assist human technicians. Figure
3.3 shows how such a scheme could work.
In this diagram, each workgroup, represented by an ellipse, has a collection of PCs and
their users. A vendor organization (as well as a reseller) may have a number of internal
workgroups, such as hardware, software, sales, and service workgroups. They also have a
group of workgroup administrators who support some home users directly. These vendor
workgroups are connected (through networks) to client workgroups through support centers
that maintain a database of user system configurations and software updates. Workgroup
administrators test and keep track of updates in software and in configurations through
management software incorporating intelligent agents. Whereas a small business organization may have just one administrator, a large corporate organization may have a number of
administrators supporting different workgroups at different location/business divisions.
This workgroup-based management software allows administrators to see the client screens
at any point of time. However, this raises some questions related to the privacy of individual
users.
The challenge is to provide efficient CSCW systems without compromising the individual human rights, such as privacy and freedom.97 These are discussed in the next section.
3.4. GROUPWARE
Whereas CSCW represents the goal of collaborative work, Groupware is concerned
with the technological realization of CSCW objectives. Peter and Trudy Johnson-Lenz, the
originators of the term groupware, defined it an intentional group processes plus the
software needed to support them.58 Groupware is software specially designed for use in a
group environment. Desktop conferencing, videoconferencing, co-authoring applications,
network mailing lists/newsgroups, meeting support systems, and group calendars are key
examples of groupware. Groupware systems need to support and process a variety of
information types, including text, data, voice, video, and images. Therefore, such software
often needs multimedia network infrastructure.
3.4.1. Groupware implementation

As described in Grudin,57 groupware can be developed on various levels of software
infrastructure, such as the following: operating systems, networking, telecommunications,
network file servers, databases, code management, and electronic mail. Because groupware
has a fast growing market worldwide, many software developers are interested in CSCW
from the perspective of developing better and more efficient groupware products.
Groupware may include the following components:
Group database (e.g., document databases)
Group communication mechanisms (e.g., email, videoconferencing)
Mail-enabled applications (e.g., Lotus Notes, Macros)
Support for distributed objects (e.g., Microsoft OLE, OMG CORBA)
36
Figure 3.4. Group communication in space-time representation.
Group databases could be specialized databases, such as in Lotus Notes, or adaptations of

existing databases, as in DEC LinkWorks.25,102 In addition to standard features of a database,
a group database needs to have facilities for defining various levels of access for different
application data to various group members. These databases may be based on relational or
object-oriented technology. For example, Lotus Notes uses an object-oriented database.
Some of these databases (e.g., Lotus Notes) have hypermedia storage features encompassing
text, graphics, audio, video, and so on. Some groupware products use commercially available
relational databases, such as Oracle, Sybase, and so on.
Although one part of groupware is a database, the other important part relates to group
communication mechanisms. Figure 3.4 shows a variation of a widely used space-time
matrix for the representation of group communication mechanisms.58 Although electronic
mail is now used universally for asynchronous group communication, researchers are
experimenting with synchronous desktop conferencing mechanisms, thanks to recent developments in multimedia communication technology.170 The relevance of various communication mechanisms in enterprise networking environment is discussed in chapter 6.
Object-oriented software technology offers a number of advantages in CSCW systems
implementation, such as reuse and encapsulation. Distributed object models, such as OMG
CORBA and Microsoft OLE, are now being extensively used in the development of
groupware as discussed later in this chapter.
3.4.2. Groupware Development Issues
Although groupware is now being embraced in a variety of workgroup applications,

it is important to be aware of some problems. Repeated, expensive groupware failures
have resulted from not meeting certain challenges in design and evaluation.24 Grudin58
has identified a number of specific problem areas in the development of groupware as
follows:
Chapter 3.
37
Groupware applications often require additional work from individuals who do not
perceive a direct benefit from the use of the application.
Groupware may not enlist the critical mass of users required to be useful, or it can
fail because one individual in the group does not want to use it.
Groupware can lead to activity that violates social taboos, threatens existing political
structures, or otherwise discourages users crucial to its success.
Groupware may not accommodate the wide range of exception handling and improvisation that characterizes much group activity.
Features that support group processes are used relatively infrequently, requiring
unobtrusive accessibility and integration with more heavily used features.
Intuitions in product development environments are especially poor for multiuser
applications, resulting in bad management decisions and error-prone design processes.
Groupware requires more careful implementation in the workplace than single-used
product developers have confronted.
Whereas the first four points require better knowledge of the intended users workplace, the
final three require changes in the development process. Some of these problems are explained
in the following section with particular reference to integrated management.
3.4.2.1. Critical Mass Problems
Achieving a critical mass of users is essential for group communication systems. One
organization wide voice-messaging system initially failed to obtain a critical mass of users.
Those who tried to leave messages were discouraged when recipients did not use the system.
This system succeeded, and was appreciated by the initial detractors, when the top management forced a critical mass to use by removing the alternative (message-taking receptionists).57
In an integrated management environment, many platforms offer facilities for the
customization of GUIs for different user terminals. This helps in avoiding the critical mass
problems. This is quite important in view of the expensive nature of management platforms.
3.4.2.2.
Improvisation Handling
A wide range of error handling, exception handling, and improvisation are characteristic
of human activity. Consequently, real work practices in an organization may vary substantially from standard procedures of work. Iishii80 described the range of problems and
consequences for designing groupware to support documented office procedures.
The main sources of information were an office work handbook made by the general affairs department and
interviews with clerical workers. While collecting information, we found that the office workers made many
shortcuts and modifications to the standard procedures designed in the handbook. Therefore, it was no easy
task to determine the actual work procedure, even when it was defined clearly in the handbook.
The author concluded that AI techniques beyond the state of the art would be required to
make the system useful.
38
Patricia Sachs146reported an interesting study of the work practices in a trouble-ticketing

environment in the NYNEX Corporation in the United States. In a telecommunication
trouble-ticketing system, an automated system monitors the time utilization of technicians.
For example, often senior technicians need to spend time on informal job-specific assistance
to newer colleagues. This time cannot be accounted for in formal trouble-ticketing systems.
The various admissible work accounts do not include the often important task of informal,
on-the-job training of new technicians. Therefore, the senior technicians have to devise
work-arounds to keep the automated trouble-ticketing running. Developers need a proper
understanding of prospective users workplaces. This has led to participatory design methodologies in Scandinavian countries.56
3.4.2.3. Difficulty of Evaluation
Task analysis, design, and evaluation are much more difficult for multiuser applications
than for single-user applications.The backgrounds or personalities of other group members
do not affect an individualssuccess with a particular word processor.Groupware is affected
by such factors, and often it must interface simultaneously to users with different and
sometimes shifting roles, preferences, and backgrounds. For example, much of a persons
use of a graphics program can be observed in a single hour, but group interactions need to
be observed over days or weeks. Groupware evaluation methods are less precise. Field
observations are complicated by the number of people involved at each site, the variability
of group composition, and the range of environmental factors that affect the use of the
technology.
3.4.2.4. Failure of Intuition
Often an application becomes unworkable because of errors of judgement at the
conceptual stage. Decision makers rely heavily on informed intuition. Most product development experience is based on single-user applications, for which intuition can be a more
reliable guide. A manager with good intuition quickly gets a feel for the use of a word
processor or a spreadsheet. However, the same person can fail to appreciate the intricate
demands of a groupware application that requires participation by a range of users. One
approach to solving this problem is to add groupware features to an already successful
application. Thus, in an integrated management environment, it is advisable to adapt existing
frameworks for group cooperation instead of designing new cooperative management
solutions from scratch.
3.4.2.5. Difficult Adoption Process
Adopting a CSCW system requires the consent of all likely users of the system;
otherwise, the system may not be used effectively. For example, a word processor that is
immediately liked by one in five prospective customers and is disliked by the rest could be
a big success. However, a groupware application to support teams of five nurses that initially
appeals to only one nurse in five is a big disaster. Groupware must be introduced very
carefully, leaving little to chance.58 Integrated management systems also have the problem
of adoption due to the high complexity of modern networking environments and scarcity of
required skills.
Addressing this issue may require a two-pronged strategy. First, existing, accepted
applications need to be consolidated by adding groupware features. Second, there is a strong
Chapter 3.
39
need to involve users in development right from the initial stage. These issues need to be
considered in evolving a methodology for cooperative management, discussed in the next
chapter.
We have so far discussed the problems arising out of the nondeterministic nature of
CSCW systems. However, not all business processes are nondeterministic. For example,
many large organizations (e.g., insurance companies) are faced with the mammoth task of
processing and keeping track of ever-growing piles of paper documents and their processing
as per the statutory rules and procedures. This aspect of CSCW systems, called workflows,
is discussed next.
3.5. WORKFLOWS
According the definition provided by the Workflow Management Coalition (an industry
body standardizing some aspects of workflows), workflow is concerned with the automation
or computerized facilitation of business processes (in whole or in part) where documents,
information, or tasks are passed between participants according to a defined set of rules to
achieve, or to contribute to, an overall business goal. Workflow is often associated with
Business Process Re-engineering (BPR), which is concerned with the assessment, analysis,
modeling, definition and subsequent operational implementation of the core business processes of an organization (or other business entity). Denning and associates have provided
a web-based graphic tutorial on various aspects of workflows.
Most of the modern business processes are anchored on the processing of various types
of documents and their routing to different human roles in an organization. Thanks to the
recent advances in image processing and compression technologies, it is now possible to
handle all of these documents in electronic form. These can be accessed within minutes, by
any member of the organization, anywhere over the enterprise network. Once the documents
are available in electronic form, they are processed, shared, and routed by workflow software
that use e-mails as the means of communication between interacting human roles. These
techniques provide a means of effective communication between business managers, analysts, and technicians responsible for integrated management. Hence, workflows play an
important role in providing an integration of business processes with network and systems
management.
3.5.1.
Integrated Management Workflow
Figure 3.5 depicts three management workflows in a telecom carrier.51 The New
Connection Provisioning workflow captures the process of telephone service provisioning
for a new customer. Task T0 involves an operator collecting information from the customer.
When sufficient customer data is collected, task T1 is performed to verify whether the
information provided by the customer is accurate, and to create a corresponding service order
record. On completion of T1, tasks T2,T3, and T4 are initiated to perform three line-provisioning activities. The objective of a provisioning activity is to construct a circuit from a
customer location to the appropriate telephone and to allocate equipment to connect the
circuit. T2, T3, and T4 provide alternate means (in increasing order of cost) of achieving this
objective. The manual work, T5, is initiated by providing installation instructions (via
40
Figure 3.5. Telecommunication service management workflows.
hand-held terminals) and is completed when human engineers provide necessary work
completion data. Task T6 involves changes in the telephone directory, whereas T7 updates
the telephone switch to activate service and then generates the bill. Finally, task T8 involves
a human operator who calls the customer to inform him or her of the establishment of the
requested service and verifies that the provided service meets the customers needs.
In addition to the tasks involved, the workflow defines the following task dependencies:
T1 starts after the completion of T0; T2, T3, T4, and T6 can be performed concurrently after
task T1 is completed; T5 must start after the completion of T3 and T4; T7 is performed after
the completion of T2, T5, and T6; and T8 starts after T7 is completed.
3.5.2.
Workflow Classification
There are now about 70 workflow products available in the market. It is important to
characterize them according to different application domains, and communication mechanisms, depending on the CSCW environment. There is no commonly agreed-on way of
characterizing workflows. Delphi Systems classify workflows according to development
environment (Adhoc, Transaction-based, Object-based, and Knowledge-based), and communication model (mail-centric, document-centric and Process-centric).95 These are described as follows:
Adhoc workflows are intended for highly dynamic workgroups, where there are no
rules or set pattern for moving information among people. These are intended for
customized or for unpredictable processes. The user acts as the workflow developer
and manager. They are typically implemented using available tools, such as Lotus
NOTES. In the service management world, these workflows are often generated
using scripts to analyze some special problems.
Transaction-based workflows involve repetitive and predictable structured business
processes, such as loan applications or insurance claims. They encompass precisely
Chapter 3.
41
defined rules and complex, lengthy processes involving multiple information systems. They are automated through programs running on transaction processing
systems. Help-desk based trouble-ticketing is an example of such workflows in an
integrated management environment.
Object-based workflows allow the design of workflows based on a reusable library
of workflow modules. These can be put together or customized through graphical
development environments. These are becoming increasingly popular due to their
ease of use. Such workflows are becoming available as sample scripts from the
vendors of management platforms, such as HP OpenView.
Knowledge-based workflows are concerned with the integration of AI techniques to
allow workflows to infer correct routing, scheduling, and exception routing beyond
its original definition. Researchers are experimenting with some such workflows as
part of intelligent-agent-based management. 120
Similarly, workflows can be classified according to communication mechanisms as
follows:
Mail-centric workflows make use of e-mails for notification. There is an emerging
trend to use intelligent agents to process e-mails on behalf of the human role.
Document-centric workflows mimic the traditional concept of associating papers
with folders and their processing rules. Lotus Notes adopts this paradigm in all its
applications.
Process-centric workflows are adopted by many high-end workflow products based
on traditional databases, such as Oracle, Sybase, and Informix. In many ways,
development tools resemble high-level programming language95
According to Geogakopoulos, real-life systems fall somewhere between the two extremes defined in Fig. 3.6. Whereas human-oriented workflow implementations often control
and coordinate human tasks as in CSCW, system-oriented workflow implementations control
and coordinate software tasks (typically with little or no human intervention), as in transaction processing systems. Consequently, system-oriented workflow implementations must
include software for various concurrency control and recovery techniques to ensure consistency and reliability.
The next section discusses some management issues relating to workflows.
Figure 3.6.
Functional characterization of workflows.
42
Cooperative Management ofEnterprise Networks
3.5.3. Workflow Management

The Workflow Management Coalition defines workflow management as a system that
completely defines, manages, and executes workflows through the execution of software
whose order of execution is driven by a computer representation of the workflow logic.
Similar to any other heterogeneous distributed systems, workflow management systems need
to deal with application integration, interoperability, implementation correctness, maintainability, usability, and reliability. Workflow management involves activities from modeling
processes to synchronizing the activities of information systems and those of the people that
perform the processes. A workflow management methodology consists of the following:
Process modeling and specification
Process reengineering: requires methodologies for optimizing the process
Workflow implementation and automation
Modeling a process involves interviewing people with expert knowledge about the
process. When enough knowledge about the process is obtained, workflow specification is
performed to capture the process. For example, GTE Telephone Operations has undertaken
a large process reengineering effort.43 GTE Telephone Operations formed reengineering
teams (20-25 employees) to capture existing business processes by conducting 1,000
interviews and 10,000 observations and by producing corresponding workflow specifications that involved the following:
A workflow model that typically includes a set of concepts that are useful to describe
processes, their tasks, the dependencies among tasks, and the required roles (i.e.,
skills of the individuals or information systems) that can perform the specified tasks.
Different abstraction levels of specifcation; for example, a workflow specification
may describe a process at the highest conceptual level necessary for understanding,
evaluating, and redesigning the process. Another workflow specification may describe the same process at a lower level of detail required for performing workflow
implementation.
workflow notations in commercial workflow systems use rules, constraints, and/or
graphical constructs to describe the ordering and synchronization of tasks in a
workflow and use task attributes to describe the tasks and roles to perform them.
The objective of reengineering methodologies is to optimize business processes. Optimization strategies depend on, the reengineering objectives (e.g., increasing customer satisfaction, reducing the cost of doing business, introducing new products or services).
Reengineering methodologies are currently an art.51 Scientific American 118 reported an effort
undertaken at NYNEX, USA to reengineer the process for provisioning of requests for T-1
lines. Eckerson43 described the GTE Telephone Operations reengineering effort and the
RAPID methodology used for improving customer service and reducing the information
system costs. However, these are all proprietary methodologies, not available openly.
Workflow implementation requires methodologies/technology for using information
systems and people to implement, schedule, execute, and control the workflow tasks as
described by the workflow specification. Workflow specification and implementation can be
Chapter 3. Computer Supported Cooperative Work (CSCW)
43
loosely coupled (e.g., workflow specification and implementation are done by software
engineers) or tightly coupled (e.g., workflow specifications are provided as direct input to
workflow management systems that either generate code or interpret specifications for
controlling workflow execution). Most commercial workflow systems are tightly coupled.
3.5.4. Workflows at Different levels
As discussed in the previous sections, workflows provide an information process
infrastructure on top of heterogeneous distributed systems to implement business processes.
It is possible to develop and implement workflows at different levels in the distributed
computational infrastructure of an organization. For example, some researchers in France
are developing special computational operators to implement work processes involved in
applications, such as joint paper writing and tele-teaching applications. This operator (called
Coo) allows two or more people to concurrently edit a document (at different levels of
responsibility and commitment) to meet an agreed-on deadline.53 This is an example of
workflow at a low level.
There are other researchers and business organizations now working on the development
and implementation of business-to-business workflows at a higher level. For example,
researchers at the Swiss Federal Institute of Technology (ETH) are working on a project
called Workflow based Internet SErvices (WISE) to develop and deploy the software
infrastructure necessary to support business-to-business electronic commerce in the form of
virtual enterprises. This involves a combination of a number of related tools and services
from different organizations. For example, in WISE, project monitoring and data analysis is
displayed through a software notation called Structware, and coordination is done through
a multimedia conferencing tool called Cobrow.129
Such large workflow projects involving multiple organizations require that heterogeneous workflow systems in different organizations must interoperate. This necessitates the use
of standards for the interoperability of workflows. The Internet SWAP Working Group,79 the
Workflow Management Coalition (WMC),177 and the Object Management Group119 are
working toward providing such standards.
3.5.5. Workflow Reference Model
The WMC has developed a framework for the establishment of workflow standards.
This framework includes five categories of interoperability and communication standards to allow multiple workflow products to coexist and interoperate within a users
environment. Figure 3.7 shows a reference architecture to facilitate the interoperability
of workflows at different levels. This involves the identification of a number of generic
components that are supported by different workflow products to different extents.
Hence, this reference model provides a common architecture for the definition and
implementation of workflow. The most important component is called a workflow
enactment service that may consist of one or more workflow engines in order to create,
manage, and execute workflow instances.
A standardized set of interfaces (between generic components), and data interchange
formats are defined for the interoperability between different workflow products. WAPIs
(Workflow APIs) and Interchange formats may be considered as a unified service interface,
44
Figure 3.7.
WMC workflow reference rnodel-components and interfaces.
consisting of five interfaces to support the management of five functional workflow management functions, namely the following:
Workflow Definition Interchange (Interface 1): A process definition import/export
interface.
Client Application Interface (Interface 2): Provides a set of commands for worklist
manipulation, and some functions, such as connection/disconnection, process control, data handling, and so on.
Invoked Application Interface (Interface 3): Supports additional functionality required for the interoperability with existing commercial workflow products that use
other standards, such as OSI TP, X.400, and so on.
Workflow Interoperability Interface (Interface 4): Allows different commercial workflow systems to pass work items seamlessly between each other.
Administration and Monitoring Interface (Interface 5): Includes CMIP and SNMP
based MIBs for various aspects of management, such as user, role, audit, resources,
and process supervisory functions.
Some leading workflow software vendors, such as Staffware have, are developing products
based on these standards.154 In view of the rapid growth of the Internet-based electronic
commerce services, the WMC has developed a white paper for the development of Internet
services based on the previously described reference model.176
In view of the growing adoption of distributed object models for distributed processing,
CORBA and DCOM are expected to play increasingly important roles in the implementation
of future CSCW systems.
Chapter 3.
45
3.5.6. Workflows for Management of Enterprise Networks
Having seen some of the recent developments in the area of workflows, one may now
ask, What is its relevance to the management of enterprise networks? The answer is that
workflows will provide the programming infrastructure for the provisioning, the management, and the services distributed over enterprise networks. Traditional programming
languages and tools are too specificto a particular computational environment. For example,
the primitive for an internet connection between processes A and B may be expressed as the
following:
Create A-B= (A, B, ipaddr A, ipaddr B, QoS)
In this expression, ipaddr A and B correspond to the internet addresses of the node for process
A and the node for process B. QoS specifies the level of Quality of Service (QoS) for the
Internet service. It is expected that such expressions will incorporate standard API calls
specified by the WMC and by other standards bodies. In this way, workflows are likely to
provide a means of the integration of organizational business processes with heterogeneous
network and systems management solutions.
In view of the rapid deregulation of telecommunication services worldwide, different
service providers need to share information on services, processes, and customers. Such
information is typically encapsulated in the proprietary trouble-ticketing system of each
service provider. Figure 3.8 shows the workflow for the operation of a telecommunication
service involving multiple telecom service providers. In this diagram, end-user problem
resolution requires a cooperation among Service Provider SP1 and Service Provider SP2
through their help-desk-(H-Desk)-based trouble-ticketing systems. ITU-T X. 790 (Trouble
Management Function) provides a standard for the interoperability of trouble-ticketing
systems of different service providers. It provides functionality for reporting of troubles on
services or resources on a managed network or system, tracking the progress of trouble
Figure 3.8.
lnteroperability of trouble-ticketing systems of different providers.
46
resolution, and clearing and closureof trouble.Differentproprietary trouble-ticketing system

workflows can interoperate through a generic trouble-ticketing system defined in X.790.86

This chapter has described the constituents of a CSCW system, namely workgroup
computing, groupware, and workflows. The objective was to understand and to optimally
support human organizational processes through computer and communication technologies. Unlike with artificial intelligence, there is no emphasis on developing machine learning
and intelligence. However, intelligent agents are being incorporated in CSCW systems to
better support group-based human tasks.
Because human behavior is often difficult to predict, the development of such systems
offer a number of problems. For example, each group member needs to make other members
aware of his or her tasks without compromising his or her own privacy. This makes the task
of workgroup administrators quite difficult. Researchers are working on some novel awareness mechanisms for this purpose.75This chapter has discussed these issues as part of
groupware development. Although groupware development presents a number of problems
related to human factors, there are a number of commercial workflow products available in
the market. The major problem is how to provide interoperability for these diverse workflow
systems.
Although this subject is now evolving, many of its concepts and techniques appear quite
relevant for integrated network and systems management solutions. For example, many
enterprises are now concerned about the increasing cost of management of their networked
services in spite of the decline in hardware and software costs. Although the functionality
and complexity of emerging distributed systems is increasing, the skill base (number of
people with the right skills) for supporting them is unable to keep pace with market
requirements. Hence, the emphasis of future management solutions should be on how to
optimally utilize the available skill base.
Although the WMC has suggested a common architecture and common interfaces,
groupware researchers can only give some guidelines and methodologies for developing
groupware systems. The next chapter uses these CSCW concepts for the development of a
methodology for the cooperative management of enterprise networks.
4
Cooperative Management
Methodology
As discussed in chapter 2, the effective management of enterprise networks requires solutions

that integrate organizational business processes (involving human groups) with integrated
management techniques. Chapter 3 has discussed some CSCW concepts and their relevance
to integrated management. The next question is how to incorporate these concepts in the
formulation of a strategy for the development of cooperative management solutions. Some
researchers have suggested the inclusion of groupware as part of the integrated management
platform architecture because existing management platforms do not support CSCW.168
However, it is not sufficient to include only a CSCW constituent, and one needs to embed
CSCW in the overall design approach (called methodology in information systems
parlance) to cooperative management.
This chapter presents a CoMEN based on CSCW and recent developments in Information Systems (IS) methodologies. Whereas this chapter discusses various aspects of CoMEN,
the chapters 5, 6, and 7 discuss an application of this methodology in a real cooperative
management environment.
The chapter begins with a general discussion of the nature and the components of a
methodology with reference to recent developments in IS methodologies, CSCW, and
integrated management. This is followed by a description of the structure of the methodology
CoMEN in terms of its model, its processes, and its notations.
4.1. COOPERATIVE MANAGEMENT

METHODOLOGY
Most management solutions are software based. Almost all components of an integrated
management framework (e.g., platforms, applications, and instrumentation) use some sort
of software. Hence, the quality and reliability of a management solution is dependent on the
quality and reliability of the constituent software. The quality of a software product is
largely determined by the quality of software development and maintenance processes used
to build it.42Organizations involved in IS and in software engineering have invested a
significant effort since the late 1980s in developing models and identifying practices that can
lead to more effective software management.
47
48
4.1 .1. Why Methodologies?

The objective of the development of software engineering methodologies is to provide
a guideline for the development of quality software within cost constraints for complex
applications. For example, there have been many methodologies for the development of
object-oriented software. The Unified Modeling Language (UML) is emerging as a standard
for this purpose.96The OMG has accepted it as the standard methodology for CORBA-based
systems development. However, UML does not solve many of the problems of the requirements of engineering for cooperative processes. Hence, it is necessary to look at some soft
methodologies that support human cooperation.
The concept of a methodology has been debated for a considerable period in the
information systems literature.44,121 Generally, methodologies are a combination of concepts
and models, processes and guidelines, formalisms and tools, which may include graphical
and textual notations, documentation standards, and possibly Computer-Aided Software
Engineering (CASE) tools.4The aim of a methodology is to provide a process of developing
better systems based on the following attributes: they should be more complete, effective,
correct, robust, economical, maintainable, flexible, and understandable. Dutta and associates42 have documented the growing use of software management practices (standard
methodologies) in various European countries.
Methodologies are most often applied when a systems complexity or size gets to apoint
where it is no longer possible for a single person or a small team to comprehend the system
design fully, or where effective communication is lost between those requiring the system
and those designing the system. For example, a large system design requires effective
communication between different groups, possibly separated in time and space, concerning
the details of a problem.4,44
4.1.2. Methodologies for Integrated Management
Integrated management systems are developed by multiple vendors and users located at
different geographical locations. Besides, these systems are also fairly complex and difficult.
Cooperative management brings in additional complexity in terms of human factors. Therefore, these systems are likely to benefit from the application of methodologies.
There is no publicly available documented methodology for integrated network and
systems management. Designers of such systems have traditionally adopted methodologies
for software engineering (e.g., CASE tools). However, CASE tools have not been widely
accepted due to the lack of a number of desirable characteristics, such as user orientation,
rigorous modeling, and support for problem solving.87CSCW system development methodologies address these issues. This discussion, therefore, leads to an examination of the
specific characteristics of the cooperative management problem domain.
4.1.3. Characteristics of the Problem Domain
Our problem domain (integrated management) has a number of specific characteristics resulting from the technical nature of this area and the background of the people
working on such problems. These characteristics have implications for the methodology
to be applied, unlike in the case of general IS methodologies whose focus is on MIS
Chapter 4.
Cooperative Management Methodology
49
systems for use in large organizations. Some characteristics of the problemdomain are now
discussed.
The first characteristic is the focus on management information modeling that, as
discussed in chapter 2, suggests that all integrated management problems can be solved
by the appropriate definition and implementation of managed objects. Whereas much
research in this area concentrates on managed objects (instrumentation), there is less
attention on a unified structuring of management applications due to their diversity. As
discussed in chapter 2, an integrated management platform provides the environment for
management applications by hiding the low-level instrumentation problems from management applications. Therefore, a management platform needs to play an important role
in this methodology.
The second characteristic is the scarcity of skills for the efficient management of
enterprise networks. This shortage is caused by the increasing complexity and rapid changes
in such systems. There is a growing need for tools that not only support the automation of
management tasks but also allow free cooperation among all concerned, such as technicians,
vendors, experts, and customers.
The third characteristic is the existence of organization-specific cooperative work
practices dependent on the background of the people involved in the operations and
management of enterprise networks.146 Hence, there is a need to evolve a generalized
methodology that would allow the study and development of enterprise management
applications in different organizations. This necessitates the use of CSCW techniques in a
cooperative management methodology.
The fourth characteristic is the multidisciplinary nature of integrated management
systems. There has been substantial work on the object-oriented representation of
managed objects (e.g., OSI Guidelines for the Definition of Managed Objects
[GDMO]).155 In addition, many of the evolving techniques in distributed object architecture (e.g., ODP, DCOM, CORBA) are applicable in integrated management applications.83,119,139 However, none of these methodologies take cognizance of human
cooperation aspects.
The fifth and last characteristic relates to the difficulty in the evaluation of integrated
management systems. Although there has been some work on the performance evaluation
of network management platforms106,107 there is no available methodology for the
evaluation of integrated management applications. Although some of the existing methodologies of Object-Oriented (OO) systems can be applied partially, there is a need for
defining a new methodology encompassing CSCW and OO and integrated management
technologies.
As discussed in chapter 2, integrated management is concerned with two major
aspects:
Technical issues concerning the modeling of managed elements, communication of
management information, and interoperability of information models.
Human/social issues are concerned with the cooperative work of people dealing
with the planning, installation, operation, provisioning, and maintenance of these
systems.
50
4.2. RELATED WORK

The Patricia Seybold Group (PSG) of the United States has developed a road map for
the selection and deployment of integrated management solutions for client-serversystems
in modern enterprise.145 The suggested eight steps are as follows:
1. Select a pilot project/application area.
2. Select a primary management protocol (e.g., SNMP, CMIP).
3. Select one of the three management approaches (protocol centric, platform centric,
or application centric).
4. Select the agents required to manage key resources (e.g., devices, services, etc.).
5. Select a management platform.
6. Select query and reporting applications.
7. Select a problem resolution application.
8. Select other required management applications.
Although this road map provides a general guideline for integrated management in modern
enterprise networks, this methodology presupposes the availability of required management
applications. Evans48 presented the role of OSI standards in the planning and procurement
process of communication systems in an organization. The Network Management Forum
(NMF) has developed integrated management solution guidelines, called the Service
Provider's Integrated Requirements for Information Technology (SPIRIT).115 Although all
these efforts are directed at standardizing some integrated management processes, none of
these take cognizance of human factors in such processes.
Blasko10 has presented telecommunications operations planning methodology consisting of process definition, process flow modeling, and analysis/simulation. CSELT Italy has
developed a methodology and tools for the optimal allocation of people and resources for
telecommunication service processes. It integrates simulation software and some AI techniques for the support of mobile communication services.59 SAP AG is a company with 3 1%
of the market in enterprisewide client-server solutions in the world today. They have
developed a workflow-based methodology for business process automation. SAP has announced a distributed architecture based on COM/DCOM/CORBA. However, this methodology does not consider the human cooperation aspects of CSCW.
Eurescom initiated a project P714 in 1997, to investigate the provision of CSCW tool
sets and possible service concepts for telework/telecommuting purposes. This project seems
to be of great interest to Public Network Operators (PNOs), such as STET Italy, Deutsche
Telecom, FINNET Finland, and Telenor Sweden. This project team has adopted the following process for investigation:
1. Selection of possible tasks suitable for telework.
2. Selection of suitable CSCW tools to support these tasks.
Chapter 4.
51
3. Identification of the scenarios.

4. Carrying out trials within the framework of the scenarios.
5. Evaluation of the trials.
6. Production of the recommendation of telework.46
Section 4.1.3 presents a discussion on user-centered systems design methodologies with a
view to develop a CSCW-based cooperative management systems development methodology.
4.3. CSCW METHODOLOGIES

Entity Relationship (ER) modeling, dataflow diagrams, and data dictionaries, along with
structure charts, form the basis of traditional information system design methodologies. One
of the main drawbacks of these structured methods is that they focus too much on the system
and not sufficiently on the users. A CSCW methodology is necessarily a user-centered
scheme. Besides, workflow designs and distributed systems designs call for specialized
techniques, discussed later in this chapter.
Thanks to the rapid growth of service industries worldwide, a number of texts and
research publications in this area are now available in the market. These publications discuss
methodologies for the design and management of services based on theories, such as Total
Quality Management (TQM). These methodologies emphasize continuous cooperation at
all stages among users and designers for the development and deployment of services. During
operation, customer feedback is systematically analyzed for the improvement of services.
These methodologies are applicable to any service industry including airlines, hotels/restaurants, telecommunications, information systems, and healthcare.73,131
Any methodology consists of three major components: model, process, and notations.
A model (actually a metamodel) is a set of concepts that are used to construct a model
of the problem. A metamodel should be coherent, consistent, and appropriate for the domain
to which it is applied. For example, Soft Systems Methodology (SSM), Object Modeling
Technology (OMT) and Structured Systems Analysis and Design Methodology (SSADM)
follow different models.4,144 Some of these models are discussed in subsequent sections
while deriving the methodology CoMEN.
The process is the series of steps, phases, or activities required to construct a system.
The process should include a life-cycle model. There are a number of information systems
life-cycle processes, such as the waterfall model, the spiral model, and the fountain model.
However, the traditional Systems Development Life Cycle (SDLC) based on the waterfall
model (discussed in section 4.3) is the most extensively used.
A notation may be textual, graphical, or a combination of both. It is a means of
expressing the model. The notation should provide a concise and minimalist approach to
expressing models but should be comprehensible. The notation provides a set of description
techniques used in developing actual documents produced during the construction process.
ER diagrams, Data Flow Diagrams, and so on are examples of notations.4
52
4.4. CoMEN MODELS

In order to create an effective integration of business processes with technical functions,
it is important to understand the evolution of enterprise management theories. These can be
categorized into three classes: Technical-Rational (e.g., TQM), Behavioral (e.g., user
participation in design), and Cognitive (e.g., development and management of organizational
knowledge). All three types of factors need to be considered in designing a solution for
enterprise management.97
Because cooperative management is mainly concerned with human and organizational
cooperation, this discussion considers analysis methodologies incorporating strong user
participation. Checkland initiated the development of human-centered design methodologies, SSM.22These methodologies are based on participative approach (involving users in
all phases) of information system development. Depending on the philosophy and practices
involved, user-centered design approaches can be classified as participative design (Scandinavian approach) or sociotechnical design.
Participative design is one where users participate by analyzing organizational requirements and planning appropriate social and technical structures to support both individual
and organizational needs. Greenbaum and Kyng56focused on the essential difficulty of
designing human-computer systems: different models of tasks, domains, and systems
employed by users and by designers. Mumford defined a sociotechnical approach as one
which recognizes the interaction of technology and people and produces work systems which
are both technically efficient and have social characteristics which lead to high job satisfaction.
All human actions take place within wider contexts, or situations. The essential aspect
of understanding situations from a systems perspective is to consider the system as a
whole.158,174 One of the most popular descriptions of this holistic view is SSM. CoMEN is
based on this methodology.
Another important consideration of such methodologies is the qualitative study of
problems in CSCW situations based on the cooperation of researchers and practitioners. Such
methodologies, also known as Action Research [AVI98], involve the study of real organizational workplace problems through actual work scenarios and constituent interactions
among human roles. Some sociological techniques, such as ethnography, are used in this
area. In view of the growing use of such techniques in the development of information
systems, leading publications in this area (e.g., Communications of the ACM and IEEE
Software) have devoted special issues on this subject.17
The next subsection presents some related concepts (model) that will be used in the
development of CoMEN.
4.4.1. CoMEN Concepts
CoMEN uses some CSCW terminology to describe the process of cooperative management. The simple and intuitive nature of these concepts help in the adoption of the
methodology by people from different backgrounds, namely, management staff, network
technicians, help-desk operators, software developers, and users. Here is a summary of the
major terms used in CoMEN.
Chapter 4.
53
Roles and Activities

Scenarios
Interactions
Tools/Artifacts
Repositories
Group Communication Systems
A Measure for Cooperation
As discussed in section 3.3, the development of successful groupware requires a thorough
understanding of the workplace environment. This includes both the computing facilities
and the human elements. Study of the human roles and general activities is the first step in
this process. This requires a first-hand experience of working in such an organization. The
necessary information needs to be collected by interviewing key people in the organization.
Having identified the roles and major activities of the business process, it is necessary
to select some instances of situations (scenarios) that illustrate the typical problems facing
such organizations. Because this task requires a thorough understanding and experience
within the organization, it is necessary to interview experienced person(s) for this purpose.
The sequence of activities in a scenario can be formally described and classified as
different types of interactions among people in different roles. Some generic types of
interaction are request, negotiation, discussion, operation, and so on. Some of the workflow
concepts can be used here. As described in section 3.3., many workflow representation
techniques can be used for this purpose.
Tools/artifacts are hardware/software facilities that support collaborative work; for
example, desktop conferencing interfaces and software. A repository represents a software
application including database functionality. Object-Oriented (OO) techniques could be
useful in developing and implementating repositories. Repositories are integral parts of
CSCW tools. As described in chapter 3, people in different roles access CSCW repositories
through group communication mechanisms. Thanks to the recent developments in mobile
and multimedia communication technologies, there are now a number of available communication strategies.
There are no available standard measures of group cooperation. A measure of cooperation in the context of the application domain is expected to show an increase in the level of
cooperation with increasing values of the measure. In chapter 5, an abstract measure of
cooperation is defined for the analysis and design of cooperative management systems.
It is necessary to select a representation formalism for this information. In the absence
of any standards in this area, one could use tables and process activity maps, described in
chapter 5.
Cooperative management systems often involve the reengineering of software management processes. Many organizations have achieved an order of magnitude gain in productivity and efficiency through reengineering projects, though some such projects have been
dismal failures.97 James Teng and associates162 have reported the results of a study conducted
to link the implementation success of a multistage reengineering project with some characteristics of the project. These results strongly suggest that efforts directed at reengineering
project stages, such as social design, process transformation, and evaluation are likely to be
54
more effective than efforts at other stages, such as the analysis of existing procedures and
technical designs.162
4.4.2.
Development of CoMEN
This phase of CoMEN is based on Checkland's SSM. This phase produces an analysis
in terms of an abstract measure of cooperation (awareness). This level encompasses activities
relating to the requirements of study and analysis, and it is based on the SSM described
previously (Fig. 4.1). In this diagram, activities in each stage are defined within a rectangular
box, and notations are specified next to arrows between boxes. Steps 1,2, and 3 are concerned
with the collection of information and its analysis in tabular form. Data is collected on the
basis of real-life application scenarios. Steps 4 and 5 bring in abstraction in this analysis.
Because there are no available measures of cooperation, it is necessary to first define a
measure of cooperation. Thereafter one starts analyzing given interactions with respect to
this measure (awareness level). The objective is to explain the existing problems on the basis
of this measure. Step 6 carries out a reality check of this abstract analysis with the real
scenarios. Step 7 is concerned with the design and implementation of the required CSCW
systems in terms of awareness levels.
This book uses CSCW techniques, such as the analysis of practical scenarios based on
concepts, roles, interactions, artifacts, and tools in a real application environment.56,64 Such
user-centered development methodologies are now being adopted in a number of different
types of system.5 For example, De Troyer and associates discuss such a scheme for the
design of kiosk web sites.166 Here is a summary of the CoMEN methodology in terms of the
stages of its process.
Figure 4.1.
CoMEN scenario analysis.
Chapter 4.
55
4.4.2.1. Overall System Study

This stage of CoMEN presents the overall big picture of the system including the
major human roles, activities, and the environment. This produces a high-level description
of the organization view including some major management concerns in a graphical form.
This stage produces a Rich Picture of the environment: including major human roles, their
concerns, and major interactions (using artifacts and tools) in the context of integrated
management processes.
This stage also involves the identification of logical components for further detailed
study. The major logical components are the following: human roles and tasks: human roles
and their major tasks, activities and interactions: the dynamics of real life processes, and
collaborutive facilities: some frequently used software, hardware and information structures.
4.4.2.2. Process Study
This stage involves a study of some sample scenarios in terms of human roles and their
interactions. The scenarios for study are chosen in consultation with people actually working
in the environment. This study reveals certain generic process sequences that have a strong
bearing on the efficiency of the process. This stage produces graphical activity maps of the
interactions of human roles in certain chosen scenarios at the workplace. In order to keep
the focus on human interactions, the collaborative facilities are not shown in these diagrams.
4.4.2.3. Defining Collaborative Service Requirements
This stage captures the availability or nonavailability of collaborative service facilities
in each interaction in scenarios under study. The collaborative facilities are categorized as
repositories and communication tools. Repositories represent application services using data
stores and associated processes. Communication mechanisms are facilities to access repositories, such as.synchronous, asynchronous, remote conference, local meeting, and so on.
This stage produces an interaction table that explicitly shows the existing collaborative
facilities and possible future improvements for every interaction in a scenario.
4.4.2.4. Analysis
This stage (the combination of Steps 4, 5, and 6 in Fig. 4.1) involves the analysis of
information collected during the previous steps. There is a need to define an abstract model
for measuring cooperation (awareness model) for this purpose. The analysis is based on this
model. The major tasks involve the matching of scenarios to collaborative services and the
identification of gaps in collaborative services available on the basis of user satisfaction
levels. CoMEN uses an evolving CSCW awareness model to produce an awareness matrix
(discussed later) for this purpose. Analysis of this information is carried out using abstract
parameters, such as human role awareness levels. This leads to a conceptual design for a
cooperative management system.
4.4.2.5.
Abstract Specification
This stage corresponds to Step 7 of Fig. 4.1. It is concerned with the design of the
required CSCW system to provide appropriate awareness levels for all interactions.
56
4.4.2.6. Design and Implementation

This corresponds to Step 8 of Fig. 4.1. It involves the implementation of the CSCW
systems to achieve the desired awareness levels of roles for all interactions. This is followed
by an evaluation of the system from the perspective of integrated management requirements.
4.5. CoMEN PROCESS

TQM theories suggest that the quality of a product depends on the quality of the process
for making the product. Applying the same theory for software development, the development process becomes an important part of a development methodology. There could be five
different approaches to systems development; development based on the SDLC, prototype
development (incremental development based on user participation), standard packagebased development (depends on the availability of a package that would exactly fit the
requirements), end-userdevelopment (user develops solutions using 4 GL tools, no programming involved), and outsourcing (development by a third party). Although SDLC is perhaps
the most expensive (in time and cost) among all of the previously mentioned approaches, it
is the most established conceptual framework for IS development. Therefore, CoMEN uses
SDLC to illustrate the development of a cooperative management methodology. Developers
may skip some steps in this process, if necessary. Prototyping is used to support user
participation in the development process, as required in the SSM.
Figure 4.2 shows a realistic iterative model of SDLC based on the waterfall model. This
model shows that there can be a loop back from any stage to an earlier stage. In some cases,
there can be several concurrent subprojects at, for example, the business analysis stage and
that loop back may come from any subprojects at any subsequent stage.121
Although there are a number of other life-cycle models, such as Boehm's Spiral for
software development,128 CoMEN uses the waterfall model in view of its simplicity and
widespread use in information systems. Figure 4.2 shows an adaptation of this model for a
Figure 4.2. Iterative cooperative management life-cycle model.
Chapter 4.
57
cooperative management methodology. In view of the importance of human/organizational

study in a CSCW approach, major steps for a cooperative management methodology can be
redefined as the following:
1.
2.
3.
4.
5.
Initiation/requirements gathering
Requirements analysis
System design
Implementation
Evaluation
4.5.1. The Requirements Phase
The requirement process is part of the first level of the cooperative management
methodology (Fig. 4.1). This level of the methodology is based on role theory, which is
widely used for enterprise modeling. This theory postulates that individuals in an organization occupy roles, and there are authority, responsibility, functions, and interactions associated with each role.103
This section examines the process of arriving at the requirement specification based on
organizational roles. This subprocess is concerned with the collection of information related
to cooperative management problems from a real organization. This may involve the
researcher getting hands-on experience with the environment and tools in the problem
domain, and interviewing people with long experience in the given environment and tasks.
The questions one needs to ask at this stage can be categorized as follows:
1. Roles and Activities
What are the human roles in the given environment?
How many persons are involved in each role?
Can a person have more than one role?
Are there any reporting protocols to be followed?
What tasks must be carried out by these roles?
Can these tasks be supported by tools or by artifacts?
2. Typical Scenarios
What are typical scenarios in the organization that depict cooperative management and its problems?
What kind of interactions are there (explanation, negotiation, conflict, service
request, idea generation, etc.)?
3. Interactions
What roles are involved in an interaction?
How are the interactions sequenced-are there strict procedures or interactions

defined as the situation evolves?
What artifacts (repositories and group communication systems) are used in an
interaction?
58
How do existing problems in the system relate to the given scenarios and
interactions?
These are some of the general questions that need to be addressed at this stage. There are a
number of questions specific to an application. These are discussed in chapter 5 of this book.
4.5.2. The Analysis Phase
This phase involves a high-level analysis of the information obtained in the previous
phase. In a typical information system, the analysis phase involves the following: the analysis
of information flow in the organization and the associated analysis of material flow, and data
analysis could involve the preparation of a graphic representation, referred to generically as
a data structurediagram.121In this case, however, the analysis of given situations is performed
with respect to a measure of cooperation. Because there are no available measures of
cooperation, it is necessary to first define a measure of cooperation. Thereafter one starts
analyzing given interactions with respect to this measure. The objective is to explain the
existing problems on the basis of this measure.
In addition to the analysis of cooperation levels, it is possible to analyze some of the
workflows in given situations using representation techniques, such as Action Workflow
discussed later in this chapter. The analysis is described in detail in chapter 5.
4.5.3. The Design Phase
It is often difficult to determine exactly where information system analysis ends and
system design starts. In some situations requiring straightforward implementation of an
existing system, the emphasis moves quite heavily toward an early need for creative system
design. On the other hand, in situations like the one in this study, there is a need for a critical
analysis of scenarios before system design can begin.
A system design typically includes the representation of system components from
different perspectives. An examination of traditional information systems methodologies
shows that these perspectives can be as follows:
1. Process-oriented perspectives specify the supposed functions of the information
system.
2. Data-oriented perspectives are derived from database technology and emphasize the
data structure of the system.
3. Behavior-oriented perspectives give importance to time-dependent (temporal) aspects of information systems, unlike in the process- and data-oriented perspectives. 121
It is felt that a design process, which aims to be complete, should take into account all three
perspectives. For example, a list of business activities would have a process-oriented
perspective, a list of events would have a behavior-oriented perspective, and a list of attributes
would have a data-oriented perspective. With the recent advances in Human-Computer
Chapter 4. Cooperative Management Methodology
59
Interaction (MCI) design techniques, a system design may also have an HCI perspective in
addition to the previously mentioned three.
It is desirable to design system components at this stage in such a way that they are
independent of the specific tools and environment for system implementation. This allows
the reuse of the design in different environments, a goal of modern information systems. The
OO technology supports this objective. Therefore, it is advantageous to divide the design
stage into two subphases: system design and implementation design. Whereas the system
design needs to consider process-oriented and behavior-oriented perspectives, the construction design phase uses data-oriented perspectives dependent on the type of DBMS used.
There are a number of system design formalisms being used now. In addition to HCI
techniques, they use concepts from distributed systems (e.g., ISO ODP) and from
object-oriented technology (e.g., Rumbaugh's OMT). These need to be integrated with
evolving standards, such as the CORBA Interface Definition Language (IDL) and standards
in structure of management information (e.g., OSI GDMO).
4.5.4.
The Implementation Phase
This phase starts with the construction design phase of the iterative life-cycle (Fig. 4.2).
This design is largely tool and environment dependent. This implementation can have a
number stages depending on the type of project. Chapter 6 discusses a prototype implementation of a cooperative management system based on an integrated management platform
called Spectrum, and a commercial groupware product, Notes.
4.5.5. The Evaluation Phase
This phase evaluates the resulting framework. Depending on the type of project, the
evaluation may involve the testing of the framework and/or the prototype against an
evaluation criteria for cooperative management. These evaluation criteria depend on the type
of problem domain. Although some areas have well-defined evaluation criteria, other areas,
like integrated management, do not have any commonly agreed-on evaluation parameters.
Therefore, it is necessary to devise an evaluation strategy for this project. Nielsen and
associates111 have provided a description of the issues in the usability testing of CSCW
systems.
Although there are a number of techniques for the evaluation of human-computer
systems,39 this book uses the heuristic evaluation technique, involving the interviewing of
experts in integrated management on the basis of the prototype and framework description.
The rationale is discussed in chapter 7.
4.6. CoMEN NOTATIONS

There is no comprehensive standard notation for CSCW systems. However, literature
suggests a proliferation of graphical representation techniques, as illustrated in the following
sections. Many of these are based on the mathematics of graph theory.99 As shown in Fig.
4.3, CoMEN scenario analysis uses a number of notations, such as rich pictures, activity
60
Figure 4.3.
Activity-based process diagram for connection provision.
maps, interaction table, awareness matrix, and so on. Here is a list of notations used in the
CoMEN scenario analysis phase.
4.6.1. Rich Picture

A rich picture is an informal macrolevel view of areal-world cooperative work situation.
It shows the characters (roles), working context, internal and external environment using
cartoon characters, and various pictorial annotation techniques. This presents the holistic
view of a cooperative work environment. This is used to get an overall picture in the
requirement-gathering stage of the project.
4.6.2.
Enterprise Analysis
This technique is based on IBM's Business Systems Analysis that presents a holistic
view of an organization in terms of organizational units, functions, processes, and data
elements. This notation involves the development of matrices of organization/processes and
processes/data based on interviews with people involved in the organization.
For example, Table 4.1 shows the involvement of various human roles in an organization
with respect to certain processes related to a new product development and marketing. This
helps in capturing the overall organizational perspective for CSCW. Table 4.2 shows a matrix
showing the roles of various information repositories in these organizational processes.
Requirements of processes with respect to information repositories have been classified as
the following: R = Read Access, W = Write Access, and N = No Access. Enterprise analysis
provides a formal methodology to carry out the first few stages of SSM. These matrices can
be used to capture and analyze various types of organizationwide information.
4.6.3. Process Diagrams
This technique is based on human-computer interaction studies, called activity analysis.128 In this case, a CSCW activity is graphically modeled in terms of human roles and their
interactions. Whereas ellipses represent human roles, directed arrows represent interactions.
Chapter 4.
61
Table 4.1. Process/Organization
Processes
Matrix
Marketing
Manager
Specifying a product
Developing a product
Launching in market
Delivering a product
Finance
Operations
Manager
Manager
M
M
M
S
S
R&D
Manager
M
S
M
M
M
M
S
S
S
S
S
S
Customers
Note: M = Major Involvement, S = Some Involvement
Figure 4.3 illustrates the use of activity-based process diagram notation for a part of the
new connection provision process in a telecommunication system as described in Fig. 3.5.
This process is composed of several human roles (user, operator, and engineer), and their
interactions. Although this notation provides a simple representation for CSCW processes,
these process diagrams do not capture process objectives such as customer satisfaction.
Therefore, CoMEN uses other matrix notations/tables for the analysis of cooperation. These
notations are illustrated in the next chapter.
4.6.4. Action Workflow Diagrams

This representation stems from Winograd and Flores Conversion for Action Model.174
This methodology assumes that the objective of business process reengineering is to improve
customer satisfaction. It reduces every action in a workflow to four phases based on
communication between a Customer and a Performer (Fig. 4.4). They are as follows:
1. Preparation: When the customer prepares to ask for something and performer offers
to do some work for the customer.
2. Negotiation: The two entities agree on the work to be done and clarify the terms.
3. Performance: Work is done to produce and deliver agreed results.
4. Acceptance: The customer reports satisfaction (or dissatisfaction) with the work.
Each workflow loop between a customer and a performer can be joined with other workflow
loops to complete a business process. The performer in one workflow loop can be a customer
in another workflow loop. The resulting business process reveals the social network in which
Table 4.2. Process/lnformation
Matrix
Processes
Customer
Information
Specifying a product
Developing a product
Launching in market
Delivering a product
R
R
R/W
R/W
Product
Development
Information Market Analysis
Tools
R
R
R/W
R/W
R
R/W
R
R/W
N
N
Cooperative Managementof Enterprise Networks
62
a group of people, filling various roles, fulfills a business process. Harris and associates63
have provided an understanding of Action Workflow notation from the perspective of
participation and coordination.
Figure 4.5 illustrates a business process for procuring materials. The main workflow
loop (procure materials) requires several secondary workflow loops during the performance
phase (verify status, get bids, place order). A buyer in the procurement office acts as the
customer in the secondary loop. The loop Verify Status allows the buyer to verify the stock
status of the item from the stores. The buyer then gets bids from suppliers before finally
placing an order. The workflow is completed when the buyer reports to the user that the
materials have been procured.
It may be noted that workflow specification based on this Action Workflow methodology
does not indicate which activities can occur in parallel or if there are conditional or alternative
actions. The communication-based and activity-based workflow models can be combined
when process reengineering objectives are compatible with both models. Therefore, methodology CoMEN will need to use both of these models. This is discussed in detail in chapters
5 and 6.
Figure 4.5.
Action workflow diagram for new connection provision.
Chapter 4.
63
4.7. ADVANTAGES OF CoMEN

This section presents a brief discussion of CoMEN from the perspective of enterprise
management. As discussed earlier, CoMEN provides a CSCW-integrated methodology for
the development of integrated management applications. Although there are some guidelines
available for the development of cooperative management solutions,145CoMEN is perhaps
the first attempt to define a methodology for the development of CSCW-integrated management systems. Existing solutions have made use of either traditional methodologies, such as
SSADM and OO methodologies, such as Rumbaughs OMT, and UML. None of these
methodologies consider human interactions and workflows for CSCW, though UML provides a description methodology called Use-cases. They provide a semistructured mechanism for defining the interaction between an OO system and human users.96However, a
CSCW system design methodology needs to describe human interactions and the support
provided by existing tools and communication mechanisms, as in the case of CoMEN.
Although this methodology is applicable to a variety of CSCW systems, the next chapters
illustrate this methodology for a cooperative enterprise management system.

This chapter began with a definition and with components of a methodology (from
information systems research). It appears that the complex nature of enterprise networks
necessitate the use of a formal methodology for the development and implementation of
solutions in integrated management. This was followed by a discussion on some evolving
methodologies for CSCW. Finally, CoMEN was presented.
Many of the concepts are abstract in nature. These will become clear as this methodology
is applied to a real-life situation, as discussed in subsequent chapters. This chapter has
presented a general view of the methodology and its constituents. However, it is not possible
to describe all the details and optional choices for each stage of the process. The methodology
adopted for each individual subprocess (e.g., analysis, design, evaluation, etc.) is discussed
in subsequent chapters.
5
Cooperative Management Analysis
The major objective of this book is to investigate some emerging organizational and systems
concepts (CSCW) to increase the effectiveness of integrated management. This led to a
discussion of various aspects of CSCW from the perspective of integrated management in
chapter 3. It was concluded that the benefits of CSCW would be best realized through the
development of a methodology that would integrate these concepts in the analysis and
design of integrated management systems. This was illustrated in chapter 4 through the
development of CoMEN. The next task involves the application and evaluation of this
methodology in a real enterprise network. Whereas this chapter presents the analysis phase
of the methodology, the next chapter discusses the design and implementation of cooperative management systems based on CoMEN.
This chapter presents the requirements gathering and analysis phases of CoMEN
through a case study approach, similar to that used by a number of systems development
methodologies.44 In this chapter, the following questions are addressed:
What are the cooperation requirements of real-life enterprise integrated management?
To what extent do existing tools and artifacts satisfy these requirements?
How can these requirements be translated to a high-level CSCW system design?
Whereas chapter 4 briefly discusses the overall methodology for cooperative management,
this chapter starts with a brief description of the methodology adopted for gathering
requirements for cooperative management and the analysis of the collected data. This is
followed by an overview of the trouble-ticketing (help-desk-based integrated management)
process and the human roles in the environment under study. These roles are used to describe
a few practical management scenarios in a large telecom organization. This is followed by
a discussion of existing tools, group communication mechanisms, and user satisfaction
levels, with a view to discovering means of improving the effectiveness of integrated
management in a cooperative environment. Finally, there is a discussion of a new model
for measuring cooperation to analyze the data related to the previously mentioned scenarios.
This study has been summarized from integrated management perspective in Ray. 135 Ray137
has presented this methodology from the perspective of general cooperative system development.
65
66
5.1. METHODOLOGY
As shown in Fig. 4.1 of chapter 4, the requirements and analysis phase is based on CSCW
SSM. The idea is to perform analysis on the basis of an abstract measure of cooperation called
awareness, as is described in section 5.3. First, it is necessary to collect information from a real
organization with a large enterprise network.
There are a number of methods of gathering data, such as the following:13,91
5.1.1. Development of Requirements through Interviews
This allows in-depth information gathering from a few persons (as appropriate in this
case). The success of this approach depends on the choice of people for interview and the
kind of rapport between the interviewer and interviewee(s).
5.1.2.
Using Questionnaires
This is a commonly used method for getting responses to predefined questions from a
number of users. This is used for many consumer surveys for statistical data collection.
However, this method is not suitable for theory construction in a specialized area (e.g.,
integrated management).13 Hence, this method is not used in CoMEN.
5.1.3.
Experimentation b y Building a Prototype
In this method, a rough system or simply an interface to the system is built and users
are asked to experiment with it. Their reactions are used to define system requirements
iteratively. This method will be used in the evaluation phase of this project.
5 . 1 . 4 . Observation through Ethnographic Studies
This approach uses the viewpoint of users within the systems, instead of being guided
by analysts specific questions. Hence, analysts need to observe or possibly participate in
relevant activities, and interviews are conducted in situ, in an informal manner. There is an
emphasis on the examination and analysis of user interactions, communication links,
artifacts, and tools. The SSM and many other CSCW methodologies suggest this method.
This project uses this methodology for requirements gathering. Activity graphs and enterprise analysis are the notations used at this stage.
Ethnography can be made to fit in with other methods of information gathering. For
example, it can be used to bring social issues into analysis, because it emphasizes interaction.
Ethnography uses some of the following techniques:
Analyzing peoples roles: this gathers information on work practices of people
carrying out a particular task.
Analyzing interactions: interaction analysis defines how users work together in
groups. This involves simple sketches and scribbles for the describing communities
of work practice that are spontaneously formed around a task.
Chapter 5.
67
Analyzing location: the study of what happens at a particular place over a period.
This often involves video/photographic snapshots.
Analyzing artifacts: this pictures the role of an artifact in the flow of work, especially
with reference to teamwork.
Task analysis: a study of system processes from the user's viewpoint (information
needed by the user, what the user does with it and where it is obtained).90
This phase of CoMEN systems analysis uses studies based on ethnography in areal enterprise
network and develops requirements through interviews of people working in the organization.
The questions one needs to ask at this stage can be categorized as follows:
1. Roles and Activities
What are the human roles in the given environment?
How many persons are involved in each role?
Can a person have more than one role?

Are there any reporting protocols to be followed?
What tasks must be carried out by these roles?
Can these tasks be supported by tools/artifacts?
2. Typical Scenarios
What are typical scenarios in the organization that depict cooperative management and its problems?
What kind of interactions are there (explanation, negotiation, conflict, service
request, idea generation, etc.)?
3. Interactions
What roles are involved in an interaction?
How are the interactions sequenced-is there a strict procedure or interactions
defined as the situation evolves?
What artifacts (repositories and group communication systems) are used in an
interaction?
How do existing problems in the system relate to the given scenarios and
interactions?
These are some of the general questions that need to be addressed at this stage. There are a
number of questions specific to an application that are discussed later in this chapter.
5.2. REQUIREMENT PHASE

In order to carry out ethnographic studies, a researcher needs to have a feel for the
environment. The long enterprise network background of this author helped him visualize
the work environment. In this case, there was a need for familiarization with modern
integrated management platforms, such as HP OpenView and Cabletron Spectrum, before
embarking on requirements gathering.
68
In this case, data was collected through informal interviews with network specializes
and operators in the organization under study. Typical problematic situations were recorded
as scenarios for analysis. These scenarios were extracted through informal chats with
people in the organization.
ISO andITU-T categorize management applications in terms of FCAPS management.82
The network vendor summit in the United States in 1995 developed a few important scenarios
for the comparative evaluation of integrated management platforms provided by different
vendor organizations.45 These scenarios, called shootout scenarios, belong to the following
major management application areas:
Asset Management is concerned with the identification of connection/disconnection
of network components.
Fault Management is concerned with the opening and escalation of trouble-tickets
for faults with the least human intervention.
Software Distribution/Configuration is concerned with remote configuration and
deployment of network software.
Performance Management is concerned with the anticipation of system problems
based on performance data.
Application Management is concerned with the identification of problems at the
application level (e.g., e-mail), described in chapter 2.
Although these areas were considered technical problems, people in the given organization felt that most difficult problems were those related to the integration of business
processes with network/systems management. Some of these are classified as change
management that is concerned with undertaking changes in system configuration due to
organizational restructuring, relocation, and technological changes, involving groups of
people. Therefore, all the scenarios in this chapter belong to this category. The other
types of problems are categorized as Problem Management. These aspects are described
in subsequent sections.
Section 5.2.2 answers various questions related to requirements gathering, and section
5.2.3 describes the scenario processes on the basis of constituent interactions.
5.2.1. System under Study
We are studying a trouble-ticketing application within the context of a distributed
computing infrastructure of a telecom service provider. This system has more than 300
subnets, more than 5000 nodes and interfaces, nearly 170 routers/intelligent hubs, and
225-X.25 packet switches. This is a heterogeneous system with protocols, such as TCP/IP,
DECNet/OSI, AppleTalk, and Local Area Transport GAT). The investigation involved
working experience with the major tools (e.g., platforms, simulators, help-desk software)
and a series of discussions with people using these tools as part of their jobs in the
organization under study.
Trouble-ticketing is used widely in the telecommunication industry, where wide area
network problems need to be resolved within the minimum possible time using the services
Chapter 5.
69
of remotely located personnel working at different hours. It has built-in mechanisms for the
following:
Running diagnostics
Assigning technicians
Accessing related knowledge bases
History record keeping related to the trouble-ticket
Interpersonal communication facilities, such as electronic mail
Facilities for automatic monitoring of trouble-ticket status and alarm escalation
Tools for coordination among a number of persons from different organizations.88
Thus, trouble-ticketing is an instance of asynchronous cooperation from remote locations.
In this case, management personnel cooperate to manage a problem using various integrated
management tools. It may be noted that in telecommunication organizations, trouble-ticketing is the term used for a help-desk-based application for trouble/fault management.
However, the term is used in this book uses to represent any collaborative process (including
change management) that uses the general semantics of help-desk-based trouble-ticketing.
This would help in the development of generic cooperative management solutions.
5.2.2.
Logical Components
This section describes various roles and tasks (revealed by the study) of the integrated
management process under evaluation. Figure 5.1 shows the process diagram of the system
in the organization under study. In this case, human roles are situated at Network Management Center (NMC) buildings, local offices, remote sites, external organizations (within and
across countries), and so on. This diagram shows two distinct classes of activities (i.e., change
management and trouble management). It may be noted that it is not possible to show all
interactions of all roles in Fig. 5.1, Therefore, it only shows some representative interactions
to illustrate the overall organizational perspective. The subsequent sections present all
interactions of roles individual work scenarios.
As shown in Fig. 5.1, the management problems can be broadly classified as probledfault management and change management. In a problem management scenario, the
problem could be generated either by the user or by the network management surveillance
facility. There are four categories of expected response in the order of priority (time available
of acknowledgement within a bracket): Normal (2 hours), ASAP (30 minutes), High Priority
(10 minutes) and Critical (immediate). On the other hand, changes in a change management
scenario could be initiated by reconfiguration requirements with or without network service
performance obligations. Available time is usually a few days.
5.2.2.1, Roles and Tasks
Figure 5.1 shows an overview of various human roles (in the organization under study)
and their interactions, using certain tools and artifacts, where arrows denote interactions.
Major roles are in square brackets and their interaction support is shown in small letters
70
Figure 5.1.
Process chart of the system under study.
adjacent to arrows. The major roles (number of persons in bracket) and their tasks can be
described as follows:
[A] Support-center Operators (15-20)
[B] Front-line Support Staff (10)
[C] Test Technicians (2-4)
[D] In-house Experts (4)
[E] NMC Managers (2)
[F] NMC Planners (2)
[GI Change Initiators/Managers (20-100)
[HI External Experts
Chapter 5.
71
[U] End-users (1 0000)

Any problem or change is reported at the support center, where operators and their manager
are equipped with a number of tools including an automated help-desk facility. As shown in
Fig. 5.1, these operators log the call on the help-desk system (issue a trouble-ticket number)
and notify appropriate front-line people. Front-line staff are technicians who first interrogate
users to identify the nature of the problem, and they transfer the problem to another skill if
required, refer to and ask for documentation to specify network elements involved, and/or
carry out discussions with experts and vendors on the formulation of a strategy/hypothesis.
For a test involving multiple sites, each site needs to have a person playing the role of a test
technician, unless the test is totally automated. They select the testing methodology for each
hypothesis on the basis of available information, coordinate testing at various sites, arrive at
test conclusions, and seek expert advice within and outside the organization in different areas.
In-house experts coordinate activities of technicians at local/remote sites, and they
conduct further tests to verify the effects of activities, check with the user/NMC if the
situation is rectified/ok, notify the support center and enter the details into the help-desk
system, and resolve and close the trouble-ticket after updating the solutions database.
NMC managers perform technical and management performance monitoring and reporting. NMC planners perform capacity planning by analyzing previous problems, consulting the solutions database, and discussing with vendors and other external experts. They
discuss new problems in relevant internet newsgroups if required.
A change can be initiated by people from provisioning, projects, and business groups
within the organization or by vendors. Change initiators log in their requests through the
help-desk.
External experts are either part of vendor organizations or of some other agency. They
are contacted via telephone/e-mail to solve new problems. Usually there are about two
end-user representatives playing the role of user in each open problem.
Figure 5.1 shows role interactions with numbered arrows showing the types of sample
interactions. It is not possible to show all interactions in one diagram. Section 5.2.3 shows
interactions in a few practical cooperative management scenarios in more detail.
5.2.2.2.
Scenarios
Scenario analysis is an important technique in the analysis of CSCW systems. The

Eurescom project P714 carried out a series of internal trials based on real work situations,
modeled as scenarios, that explored various combinations of telecommuting activities. This
project has identified the following seven scenarios of telework:
1. PRONTO: to evaluate the preparation of a presentation on a laptop while travelling
to a conference.
2. JDOC: to evaluate joint authoring of documents from a distance.
3. EDU: to test the feasibility of conducting distance education from home using a
mixed mode of education materials.
4.
VIM: to identify the impact of home environment on the effective development of

a virtual meeting, using an IP/ISDN-based videoconference.
72
5. FLEXMAN: to test the possibility of managing a group from home using CSCW
tools for coordination.
6. TELSU to evaluate the effectiveness of information technology tools for remote
customer support.
7. BASIC: to evaluate the usefulness of telecommuting tools (e-mail, the WWW) when
working in a mobile environment with access to company networks.46
Whereas the above scenarios are concerned with CSCW for telecommuting in general, this
book needs to consider scenarios concerned with the management of enterprise networks. A
help-desk-based trouble-ticketing system is widely used as a process for enterprise management. Scenarios 4,5, and 6 integrate with trouble-ticketing in a general context. Figure 5.1
shows the application of a trouble-ticketing environment in fault and change management.
The scenarios for study have been chosen in consultation with practicing network management people to highlight some problem areas. It may be noted that most of the scenarios
involve change management. In the environment studied, change management was in fact a
more pressing issue than fault management. Here is a summary of these scenarios.
1. Upgrades: Problems arising out of the process of the upgrading of communication
equipment, such as multiplexers, modems, and so on.
2. No Information with NMC: These faults arise due to the lack of information on
changes being carried out at a remote site. A remote engineer calls for certain
information that is nonexistent at the NMC. Usually there is a time lag between a
change and its reflection in the network database.
3. New Software Version: Problems arise due to a new software version on newly
installed systems, such as routers.
4. Security: These problems arise due to conflicting security needs of people accessing
the same network elements/services.
5. Architectural Issues: These problems occur due to inherent limitations of certain
network architecture.
These scenarios are described in detail in section 5.2.3. At this stage, one can use enterprise
analysis to summarize the involvement of human roles in these scenarios (Table 5.1).
Table 5.1 indicates the relationship (M, S, N) between human roles and scenarios
(processes/activities). This is analyzed further as part of the awareness model, described later
in this chapter.
5.2.2.3. Tools and Artifacts
This telecom organization uses a number of tools and artifacts along with the help-desk
systems. As shown in Fig. 5.1, these tools and artifacts provide interaction support through
various levels of access control and through different types of communication mechanisms.
Some of these tools are listed as follows:
1. Lotus Notes
Chapter 5.
73
Table 5.1. Role/Scenario Matrix (Enterprise Analysis)
Roles
Scenario 1
Scenario 2
Scenario 3
Scenario 4
Scenario 5
M
M
M
M
N
S
M
M
M
M
S
S
M
M
M
M
M
S
M
M
N
M
M
M
M
M
M
M
M
S
Operator
NMC technician/manager
Testtechnician
Change initiator
Expert
Customer
Note: M = Major Involvement, S = Some Involvement, N = No Involvement
2. Integrated Management Platforms (Sun Solstice, HP Openview)

3. Quantum Help-Desk
4. VeriSoft Integrated Directory
5.
CiscoWorks on Sun Solstice
6. LAN Analyzers
7. Network Modeling and Simulation Tools
8. Specialized Custom-built Tools
Notes is a CSCW environment for distributed applications based on a client-server
paradigm, and it supports databases of structured and unstructured data that can be replicated
in entirety to multiple servers and to portable clients via various communication mechanisms.
Notes supports the routing of documents through a built-in e-mail system that has special
features to support workflow systems. These documents support text, data, graphics, video,
and so on.102
The organization uses commercially available integrated management platforms OpenView, Sun Solstice, and NetView/6000 from HP, Sun, and IBM, respectively. They provide
support for management communication using protocols such as SNMP, Remote Procedure
Call (RPC), OSI, and so on. Each of these provides a common management database and
powerful Graphical User Interfaces (GUIs; e.g., Motif-based) using color graphic workstations. In addition, these platforms have support for a number of management services, such
as directory services, object management services, and autodiscovery of network nodes.132
These tools use information provided as structured data.
Quantum is a general purpose, help-desk software with facilities for trouble-ticket
management, e-mail, bulletin boards, skill databases, customer administration, call reports,
and so on. These applications use a combination of text, data, and graphics.160 VeriSoft
provides an organizationwide directory service with integrated telephone/e-mail/fax/pager
facilities to locate and communicate with any person within a large multisite organization.
This mostly uses text and data. CiscoWorks is a software provided by Cisco Systems for the
management of Cisco routers. LAN analyzers are a set of tools provided by LAN vendors,
such as Microsoft and Novell, for the management of LANs. This application uses data, and
74
graphs for representation. The system under study uses network simulation packages, such
as OPNET and COMNET, that allow performance studies based on different network
configurations, protocols, and traffic characteristics. These tools use data and graphics. In
addition, there are a number of specialized software tools developed to handle some repetitive
chores not supported by the tools mentioned previously.
In the organization under study, the trouble-ticketing system has been evolving. The
following sections describe some sample scenarios that highlight the evolutionary nature of
this application environment.
5.2.3.
Process Study
This section describes some real integrated management scenarios in a help-desk

environment from the perspective of the human cooperation involved. These scenarios
represent some of the major problematic situations encountered in the telecom organization
under study. These are described using the roles and interactions shown in Fig. 5.1. Each
scenario is illustrated with a process diagram with corresponding roles and interactions listed
in the subsection. Each interaction is characterized within brackets with roles and interaction
types shown in Fig. 5.1. For example, the first interaction in Scenario 1 shows (Role B/D
<-e-> Role C). This means that Roles B/D interact with Role C in a bidirectional interaction
type, discussion (e). The type classification will be useful later in the inheritance of some
common properties of an interaction. For example, each interaction may be described later
as a UML Use Case96 or as an ODP enterprise object.83An asterisk (*) with the interaction
indicates that there are tools (from the set described in the previous section) available to
support the interaction. Section 5.3 uses this information to evaluate collaborative services
in this environment.
5.2.3.1. Scenario 1: Upgrade Problem
The Sydney-to-Perth wide area link, which is on an existing.2 Mbps link on a lower
version Network Termination Unit (NTU), needs to be upgraded to a higher version NTU.
For this, an outage of 30 minutes is required. This involves the following interactions (Fig.
5.2) among roles defined in the previous section.
Figure 5.2. Process diagram for Scenario 1.
Chapter 5.
75
1. NMC technician discusses with aremote test technician about a suitable time (Role
B/D <e> Role C).
2. A NMC technician places a change request with a proposed time and user impact
statement to the change manager (Role B/D -o> Role G).
3. The change manager takes up with the affected users (Role G -d> Role U).
4. Related users discuss the impact and examine the proposed time (Role U1 <d>
Role U2 <d> Role U3).
5. A user resubmits a request to the change manager with possibly an altered schedule
(Role U -t> Role G).
6. The change manager issues a permit to work to all concerned (Role G -d> Role
U, B, D).
7. The help-desk operator is notified before the start of work (role G -n> Role A).
8. The help-desk operator alerts users regarding the start of work (Role A -n> Role
U)
9. Work coordination between local and remote sites (Role B/D -o> Role C, Role C
-o> Role B/D).
10. Check if OK (Role B/D -d> Role U)
11. The help-desk operator notified of completion (Role B/D -n> Role A).
This scenario uses all six types of interactions described in Fig. 5.1. Existing automated tools
and artifacts do not support the majority of the interactions, additionally, a number of
interactions require cooperation of multiple human roles simultaneously.
5.2.3.2. Scenario 2: No Information with NMC
Technicians/provisioning engineers at a remote site are doing installation work and call
NMC asking if the router configuration is ready for the site. They also ask NMC to test
connectivity of the newly installed equipment at the remote site. NMC was unaware that this
work was done. This involves the following role interactions (Fig. 5.3):
1. The remote site test technician contacts NMC technician and asks for configuration
and testing to be done (Role B -e--> Role C).
2. The NMC technician contacts the change manager to inform him or her that they
are not aware of the permit to work and to get additional details (Role B -n> Role
G).
3. The NMC technician contacts the help-desk operator to see if he or she has any
details (Role B <d> Role A).
4. The help-desk operator contacts users who have ordered provisioning and informs
NMC (Role A <e> Role U).
5. The NMC technician contacts users to find the need (Role B <f> Role U).
76
Figure 5.3.
Process diagram of Scenario 2.
6. The NMC technician consults an expert if required (Role B <e> Role D).
7. The NMC technician coordinates with remote site test technician for the required
configuration and testing (Role B -o> Role C).
8. The NMC technician puts in a complaint to the NMC manager (Role B -r> Role
E/F).
9. The NMC manager speaks to the change manager about the lack of change
information at NMC (Role E -e+ Role G).
This scenario uses most of the interactions defined in Fig. 5.1. Existing automated tools
support none of the interactions.
5.2.3.3. Scenario 3: New Software Version
A business manager/capacity planner orders a new router to be installed at a remote site.
The new router comes with a new version of the operating software. This new version
software creates compatibility problems with the older version equipment. Role interactions
(Fig. 5.4) are as follows:
*1. The order for installing a new router to NMC is placed (Role E/F -t> Role B).
'2.
An NMC technician puts in a change management request to the change manager

(Role B -o> Role G).
3-10. Same as in Scenario 1.

11. Several users report strange network problems to an NMC technician (Role U -n>
Role B).
'12-13. NMC technicians observe their own monitoring equipment, discuss the situation, and contact experts (Role -o> Role BD).
Chapter 5.
Figure 5.4.
77
Process diagram of Scenario 3.
14. NMC experts coordinate with remote test technicians (Role D -0> Role C).
15. NMC experts discuss with NMC technicians (Role D <e> Role B).
16. NMC technicians coordinate with remote test technicians (Role B -0> Role C).
17. NMC experts discuss with change managers to resolve the problem jointly (Role
D <e> Role G).
This scenario uses all of the interactions defined in Figure 5.2. Existing tools do not support
many of the interactions and multiple human roles need to interact simultaneously on several
occasions.
5.2.3.4. Scenario4: Security Problems
It has been decided to shift an application running on a system on the Network
Operations Center (NOC) network to the corporate network. NOC and corporate networks
are separated by a firewall. The application in question was used originally by NOC users
but needs to be extended to corporate users as well. For this reason, a larger machine with
spare capacity already existing on the corporate network is chosen to run the application.
During the testing phase, an objection is raised by the NOC security expert that the operation
in this manner jeopardizes the security of the NOC network. Role interactions (Fig. 5.5) are
as follows:
*1. A user (U,) asks for a change (Role U -0> Role G).
*la & 1b. The change manager notifies users U3 and U4 but misses U2 (U, is an NOC
security expert; the change manager has not yet included U2 in his notification list
. because network security was not a prime consideration until now) [Role G -nRole u,, u,].
"2. The change manager to the NMC manager/technician (Role G -0> Role B/D).
78
Figure 5.5. Process diagram of Scenario 4.
*3. An NMC technician opens the firewall to allow the NOC access to the new system
(Role B -o> Role B).
4. An NOC security expert (U2) raises an objection (Role U2 -t> Role B).
*5. An NMC technician consults with an NMC expert on security impact (Role B
<e> Role D).
*6. An NMC expert discusses security with U2 (Role D <e> Role U2).
7. The NOC security expert (U2) and the originator (U1) discuss (Role U2 <e> Role
U1).
8. User U1 withdraws the project from the change manager (Role U1 -o> Role G).
*9. The change manager includes NOC security in the modification list (Role G <o->
Role U2).
*10. The change manager requests the NMC manager/technician to undo the changes
(Role G -o> Role B).
This scenario uses almost all of the interactions defined in Fig. 5.1. Although most of the
interactions have support from existing tools, this scenario highlights the negative consequences of missing communication with one human role in certain situations.
5.2.3.5. Scenario 5: Architectural Problems
The NMC manager alerts customers that the network is slow because of architectural
constraints. The network needs a new architectural solution. Introduction of a large capacity
Ethernet/FDDI switch is required so that massive file/data transfers can occur directly via
the switch without affecting traffic on LAN segments. Role interactions (Fig. 5.6) are as
follows:
Chapter 5.
79
Figure 5.6. Process diagram of Scenario 5.
*1. NMC and the business manager discuss the problem and the proposed solution and
allocate a budget and so on (Role E <e> Role Gb).
*2. The NMC manager finalizes the solution in consultation with the expert (Role E
<e> Role D).
*3a. The NMC expert consults with a vendors expert (Role D <e> Role Gv).
3b. The NMC expert and an NMC technician discuss implementation (Role D <e>
Role B).
4-12. Same as 2-10 of Scenario 1 (Upgrade Problem).
*13.
The NMC expert liaises with a user and gets feedback on the results of the action
(Role D <t> Role U1).
14. The NMC expert requests special monitoring action from a NMC technician (Role
D <o> Role B).
*15. The NMC expert discusses the result with an external expert and possibly repeats
steps 3b through 15 until all concerned are satisfied (Role D <o> Role Gv).
This scenario uses many of the interactions in Fig. 5.1. Existing tools do not support some
interactions. This also emphasizes the need to communicate with a number of human roles
simultaneously.
This section has briefly described interactions of human roles in some practical situations in a real-life help-desk environment. Whereas interactions marked (*) have some kind
of automated tools available (at least in part), the rest of the interactions need to be performed
manually. According to practicing management users, these are the most vulnerable (problematic) points in the system. Therefore, research is required to support interactions not
presently supported by existing tools.
80
We now present a discussion on collaborative services with a view to evaluating their

applicability in a trouble-ticketing environment.
5.3. ANALYSIS
The purpose of this section is to produce an analysis of the previously discussed scenario
information, using abstraction techniques corresponding to steps 4 and 5 of CoMEN in Fig.
4.1 of chapter 4. This will help in the abstract modeling of the system to expose gaps in the
support for interactions in the existing system. Such an abstraction is necessary to define a
general framework of CSCW design for cooperative management that presents a variety of
situations.
Successful collaborative work requires information sharing, knowledge of group and
individual activity, and coordination.40,51,64 These factors are important for abstract modeling
and for the design of a CSCW system. Dourish and Bellotti40 defined a parameter called
awareness to represent the understanding of the activities of others, which provides a
context for ones own activity. Awareness information is required to coordinate group
activities in various application domains. Although they discussed this concept for a text
editing task area, awareness is likely to be useful in integrated management where context
knowledge is as important as the task knowledge (section 2.6.1).
It is necessary to consider as context both the content and the character of individual
contributions to enable other members to tailor their own work accordingly.40 There is very
little reported work on attempts to define measures of awareness. Benford and associates
defined two measures, focus and nimbus, for an interpersonal means of creating
awareness. Whereas increased focus makes a person more aware of actions of other members
of a group, by increased nimbus a person can make other members of the group more aware
of ones actions. This book has defined awareness levels to signify the level of cooperation,
as is discussed in section 5.3.3.
There is a close link between ethnographic analysis and the HCI design techniques
discussed in chapter 6. This section carries out ethnographic analysis at two levels:
Interaction Analysis: describes the user satisfaction levels and CSCW services with
respect to interactions in various scenarios described previously. This produces an
interaction table based on Enterprise Analysis notations discussed in the previous
chapter.
Cooperation Analysis: discusses the levels of cooperation for various interactions
with respect to an abstract measure. This stage produces an awareness matrix.
The next section describes various collaboration services in use in the organization under
study.
5.3.1. Collaborative Services
For two or more people to work together, they need to coordinate both the content and
the process of what they are doing. They cannot coordinate without assuming a vast amount
of shared information and common ground (knowledge, assumptions, etc.). Whereas con-
81
Chapter 5. Cooperative Management Analysis
tent-based grounding depends on repositories, process-based grounding depends mostly on

the medium of communication. Process-based grounding changes with the medium of
communication. There could be a number of dimensions of variation (constraints) of
grounding due to media changes such as the following:
Copresence: A and B share the same physical environment.
Visibility: A and B are visible to each other.
Audibility: A and B communicate by speaking.
Cotemporality: B receives at roughly the same time as A produces.
Simultaneity: A and B can send and receive at once and simultaneously.
Sequentiality: A's and B's turns cannot get out of sequence.
Reviewability: B can review A's messages.
Revisability: A can revise its messages for B.126
Here are the grounding constraints for seven types of media. The grounding of collaboration depends on two types of CSCW facilities: repositories and group communication
interfaces.
Repositories involve certain data sets and methods to be performed. These could be part
of existing tools or they could be certain desirable facilities not yet available. Whereas a
repository is a service object that implements a particular automated service, group communication mechanisms depend on the nature of the collaborative task, as discussed in chapter
3.57These collaborative services are often included as part of Computer Mediated Communications (CMC) systems.
5.3.1.1. Repositories
Repositories are implemented using various tools and artifacts described in section
5.2.2.3. In the system under study, these collaborative services are available in the form of
the following:
T1: An MIB in the management platform.
T2: A customer information base in the help-desk system.
Table 5.2. Communication Effectiveness for Different Media
Medium
Face-to-face
Telephone
Video teleconference
Terminal teleconference
Answering machines
Electronic mail
Letters
Constraints
Copresence, visibility, audibility, cotemporality, simultaneity,
sequentiality
Audibility, cotemporality, simultaneity, sequentiality
Visibility, audibility, cotemporality, simultaneity, sequentiality
Cotemporality, sequentiality, reviewability
Audibility, reviewability
Reviewability, revisability
Reviewability, revisability
82
T3: Trouble-ticket history in the help-desk system.

T4: A problem knowledge base in the help-desk/Lotus Notes.
T5: An electronic mail part of the help-desk/Notes/other standalone systems.
T6: A discussion databases in the help-desk/Notes.
T7: Network news facilities via Internet access.
T8: Special management tools.
5.3.1.2. Group Communication Interfaces
It is customary to describe group mechanisms in terms of a space-timematrix., This
section classifies various group communication situations prevalent in a management
workplace (Fig. 5.7). Communication mechanisms can be classified as the following:
C1: Same time, same place (face-to-face meetings).
C2: Same time, different place (synchronous voice/data network, desktop conferencing).
C3: Same time, different unpredictable place (calls to mobile phones/pagers).
C4: Different time, same place (e-mail, handwritten notes).
C5: Different time, different place (asynchronous e-mai/voice mail/fax).
C6: Different time, different unpredictable place (mobile e-mail/fax).
Chapter 5.
83
C7: Different unpredictable time, same place (NMC problem meetings).

C8: Different unpredictable time, different place (e-mail).
C9: Different unpredictable time, different unpredictable place (mobile e-mail/paging).
Although C1 is the most common type of group situation, C2 involves different types of
communication tools. Plain Old Telephone System (POTS) is an example of this type. In
integrated management, such needs arise for multilocation synchronous applications, such
as videoconferencing, and also for managing multilocation configuration changes. Recent
growth in cellular mobile telecommunication has made available the C3 type of communication to mobile personnel. In integrated management, such situations arise while contacting
a mobile technician or expert. C4 is a common situation in any service organization with
people in different shifts. Although handwritten notes have been traditionally used in this
situation, e-mail offers a much more convenient alternative. A C5 situation arises when people
from different time zones and locations need to communicate. In integrated management,
such situation arises when an expert in a different country needs to be consulted. It is not a
common requirement. C6 is a variation of the previous situation with a scope for mobile
people at each location. C7 and C8 situations are similar. They represent electronic communication between service providers and users for change management. A C9 situation can
arise in the management of networks with mobile users where a user location may not be
known.
5.3.2. Interaction Analysis
This section analyzes the human role interactions in various scenarios with a view to
unearthing gaps in collaborative services in existing systems. The first subsection presents
a consolidated view of information gathered in order to help correlate recorded user
satisfaction levels to collaborative services. This is followed by a more detailed analysis of
situations of extensive usage of certain types of communication mechanisms, such as pagers
and cellular phones.
5.3.2.1. Collaborative Service Evaluation
This section presents an attempt to assess the effectiveness of various CMC tools in this
cooperative management environment. Gay and Lenthi50 discussed a study conducted on
engineering design students in a laboratory environment in the United States to see the
utilization of collaborative services in a project requiring group cooperation from a distance.
This study shows that students do not make effective use of the database resources and
communication tools, perhaps due to the lack of adequate training and information on the
use of such facilities. The best collaboration services need to support diverse aspects of usage,
such as social, psychological, and technological factors. These would include communication and data access tools, on-line monitoring and experts, multiple representation for clarity,
and archived exchanges and records. These facilities are categorized into repositories and
group communication systems in this study.
Therefore, it is necessary to get direct feedback on the utilization of various collaborative
tools in this environment. This chapter presents a discussion on the tools and group
84
communication mechanisms in the system under study. The data was collected for all
interactions in the scenarios by interviewing management professionals working in the
organization. The objective was to answer the following questions for every interaction:
What are the group communication systems and cooperation repositories being used
now for the particular interaction?
What is the level of satisfaction with this type of interaction (did this situation cause
any major problems in the past)?
If this interaction is not adequately supported now, what type of tools/communication
facilities could improve the support?
The information is presented here in a tabular form (Table 5.3) with the following
headings: Interaction Type, Tool Type, Group Communication Mechanisms, and Satisfaction
Level (SL). Interactions are derived from scenarios in section 5.2.3. (<1,2> means Interaction
2 of Scenario l), tools are listed in section 5.3.1.1. (T1 to T8), and group communication
mechanisms are listed in section 5.3.1.2 (C1 to C9).
Satisfaction level is a value between 0 and 9 (0 is the lowest satisfaction level) recorded
according to the response from people working with the existing system. The satisfaction
level of 0 is given for those interactions with a known network disaster in this situation. This
information was collected by interviewing people working in the organization under study.
It may be observed that there are no user recommendations for improvement for interactions
where the existing satisfaction level is 8 or more. That means that available tools and
communication mechanisms now adequately support these interactions. Only 25% of the
interactions belong in this category. Some interactions involving group work have caused
recent network service disasters. The satisfaction level is 0 in these cases, and they represent
nearly 20% of all cases.
Whereas C2 represents the most common group communication situation, most of the
existing interactions are supported by POTS. POTS has a number of limitations, such as
visual cues for collaboration/annotation using other artifacts, and it is not useful for mobile
people. Present day dynamic enterprise network environments require instant communication between mobile people. Therefore, user recommendations on future group communication (almost all cases) support mobile computing and multimedia conferencing technology
(C2,C6). Users suggest a number of new collaborative tools for a variety of new, evolving
management situations (e.g., security management). Many of these tools would consist of
specialized repositories with automatic learning capabilities (an evolving knowledge base).
For example, in Scenario 4 the list of contact persons evolves with time.
Some tools, such as network simulation packages, will need to be integrated with
management platforms as required in Scenario 5. Often the update of platform knowledge
bases is unable to cope up with rapid flare-up of related events as in Scenario 2. Such
situations may be prevented with better group communication systems. There are a number
of interactions, such as <1,8 to 1,11> that rely on traditional voice telephone communication
and on repositories based on human memory. These activities are often vulnerable to failures.
Although Table 5.3 captures all data gathered from the organization under study, it is
not quite effective because the role information is not present. CSCW systems development
involves increasingly effective support for various human roles. This necessitates an analysis
of roles, interactions, and relevant support repositorie/communication mechanisms. Enter-
Chapter 5.
Table 5.3.
Collaborative Service Evaluation
Scenario, Interaction
<1,2>
<1,3>
<1,4> & <1,5>
Tool
Group
Communic.
T8-Change
C5
mgmt syst.
T8-Change
C5,C1
mgmt syst.
T8-Change C2 (POTS)
mgmt syst.
T3, T5
C5
85
SL
User Recommendations Group

Communication, Remarks
C2
C2
C2 (video
conference)
C5
<2, all>
None
C2 (POTS)
C6, C2, C3
System design should

prevent this
<3,1>
<3,2>
C5,C2
C5
8
3
C2
Automatic change
impact notification
<3,12>, <3,13>
T2, T7
T8-Change
mgmt syst.
T2,T5
<3,17>
T2,T5
<4,1>
T3
C5,C3,C2
(POTS)
Cl,C3,C2
(POTS)
C5
<4, la, 1b>
T8
C5
<4,2>
<4,3>
<4,5>
T8
T5
None
C5
C5
C1, C3, C2
(POTS)
8
9
0
<4,6>
None
C2(POTS)
<1,6>
Automatic change
impact notification
Automatic change
impact notification
Automatic change
impact notification
No ack. from users
4
2
<4,9
T8
C5
<4,10>
<5,1>
T8,T1
<5,2>, <5,3a>
T2
<5,4>
<5,5>
T8-Change
mgmt syst.
None
C1,C5,C2,
(POTS)
C1, C5, C6,
C2 (POTS)
C5
<5,6>
<5,7>
T2, T5
T2
C2(POTS),
C3
C1,C5
C3,C2,
(POTS)
C2(video
Need for solutions
conference), C6
database
C2, C6
Knowledge of network
impact of shifting
application
?-evolving Automated means of
knowledge finding out change impact
base needed
?-evolving Security hole detector

knowledge
needed
base needed
?
Tool needed for security
impact study
C2, C3, C6
T7 linkage to T2 required
C6
User tool needed for

verification
8
5
C2, C6
86
prise analysis is used to summarize the collaboration support for different scenarios, as shown
in Table 5.4. This table shows all roles within the organization. User role interactions have
been omitted for simplicity. Table 5.1 and Table 5.4 form the backbone of cooperation
analysis discussed in section 5.3.3.
The next section presents a brief picture of the mobility requirements of human roles.
5.3.2.2. Time Utilization of Human Roles
One of the major modern communication techniques (mobile wireless communication)

supports human roles on the move. This requires a further investigation of the mobility and
group activities of different human roles in the telecommunication organization under study.
The following questions were asked:
What percentage of time is spent on meetings involving three or more persons?
What percentage of time is spent outside the office?
What percentage of these people has mobile communication devices?
The actual data were collected for various roles defined in section 5.2.2.1 through movement
registers in the organization. In some cases, the percentage varies from person to person,
from site to site, and from month to month. In such cases, an average figure was taken.
These figures (shown in Table 5.5) reveal some interesting facts in this environment.
Most highly paid professionals spend nearly 50% of their time in meetings. Many of these
roles require people to be mobile and to spend 30% to 80% of their time outside of offices.
Consequently, this telecom company has provided almost all of them with mobile
phones/pagers. However, there is scope for improving the productivity of meetings with the
right type of devices for cooperation and communication.
Thus, there is a strong support for repositories with mobile wireless communication
access. The organization under study is a telecom provider and hence allows free use of
mobile phones and pagers to all of its network management personnel. However, cost may
be a deterrent for many other organizations. Mobile computing applications (e.g., mobile
mail-enabled applications, etc.) may be more cost-effective than cellular mobile phones.81
These devices use asynchronous packetized data communication and hence make more
efficient usage of wireless communication channels. Multimedia tools, such as desktop
Table 5.4.
Scenario,
Interaction
<1,2>
<1,6>
<2, all>
<3,1>
<3,2>
Collaboration Support based on Role/lnteraction
Operator
T 2, T 5
(C5, C3, C2)
-
NMC
Technician/
Manager
T8 (C5)
T2, T5
(C5, C3, C2)
T2, T5
(C1, C3, C2>
T3 (C5)
Test
Technician
T3, T5 (C5)
T2, T5
(C5, C3, C2)
-
Matrix
Change
Initiator/
Manager
Expert
T3, T5 (C5)
T8(C5)
T2, T5
(C5, C3, C2)
T3 (C5)
T5 (C5,
C3, C2)
-
Chapter 5.
87
Table 5.5. Time Utilization of Human Roles
Human Role
Number of
Persons
Support-center operators
Support-center coordinators
NMC technicians
Test technicians
In-house experts
NMC managers
Change initiators
End-users
Vendor experts
15-20
4-5
10
2-4
4
2
60
10000
-
Percent of Time Percent of Time Percent of Time

Spent in
Spent outside
Spent with
Meetings
Office
Mobile Com.
5
45
5
5
60
70
75
20
30
10
60
10
50
25
50
50
80
100 (shared)'
100
100 (shared)'
100
100
100
100
25
100
videoconferencing, could be of great use in improving visualization and hence communication among multiple users.33,132 These aspects are considered in the design of a framework
for CoMEN in chapter 6.
5.3.3. Cooperation Analysis
Tables 5.1 and 5.4 suggest that a role interaction matrix could be the format for arriving
at the design objective of the required cooperative management system. This would necessitate the characterization of collaboration support (repositories, communication mechanisms) with respect to cooperation requirements. Because cooperation requirements vary
from organization to organization, and from application to application, it is necessary to carry
out an abstract modeling of the scenarios as suggested in the Steps 4 and 5 of CoMEN.
Figure 5.8 shows a model of all interactions in terms of required and available awareness
levels. This will then be correlated to user satisfaction levels. If there is a relation between
awareness and satisfaction levels, it will be necessary to work out a new design with the
required awareness levels. Because this is a new experimental model, it may be necessary to
try a number of awareness related parameters before one or a combination is found useful
in this task domain.
5.3.3.1. Awareness Levels
As discussed in section 5.1, the process of management is important for bringing out
effective management solutions, and process knowledge consists of task knowledge and
context knowledge. Whereas task knowledge relates to the specification, design, and performance of the task, context knowledge relates to the rest of the process knowledge
including relationships between various roles, tasks, and the environment of the task. In order
to characterize these aspects in a group environment, one needs to be concerned with levels
of the following:
Task knowledge for a particular interaction
88
Figure 5.8.
CSCW analysis of cooperative network management.
Knowledge of people involved and their roles in the task within the organization
Knowledge of other preoccupations of these people within the department/division
Knowledge of interrelationship of various tasks in the department/division
Knowledge of other activities of people concerned with the task (external to the
organization)
Researchers have been experimenting with various measures for cooperation. There is an
emerging consensus that awareness would be the best way of defining cooperation. 140
Awareness is defined using a parameter called awareness level.30,31 This is likely to be the
most important parameter to characterize awareness in an interaction. According to this
definition, the level of cooperation (in increasing order) in a particular work context can be
expressed in terms of several levels of awareness as follows:
Level 0: Concerns knowledge related to the given interaction
Level 1 : Level 0 + knowledge related to contact addresses of people involved in the
interaction
Level 2: Level 1 + knowledge related to contact addresses of all people in the
interaction context
Level 3: Level 1 + knowledge of activities of people involved in the interaction
Level 4: Level 2 + knowledge of activities of all people involved in the interaction
context
In a group situation, the required level of awareness for different members of a group can be
different. Because the requirement for this information varies from task to task, and from
interaction to interaction, people need to keep switching awareness levels. This subsection
reports the results of a study on relating the appropriate level of awareness to satisfaction
Chapter 5.
89
levels in various interactions, discussed in section 5.3.2. However, as stated in the definition
of SSM, one needs to go through a number of iterations in changes to arrive at well-formed
abstract root definitions.128 Therefore, in this evolving theory of awareness, one needs to
consider the following additional aspects of awareness, if necessary:
Rate of transition of awareness: This indicates the rate at which awareness level
changes for a particular role in response to specific situations. This is important
considering the fact that in a dynamic organization, awareness levels need to change
in response to changes in the market and the environment.
Usability of awareness: This is a parameter that measures the usability of a given
awareness level in achieving a task.
Awareness and security: It often is not possible to raise the awareness level for
certain human roles in order to protect the privacy and security of the organization
and its people.
Although the last two points offer some interesting research prospects, they are not discussed
in this book. Therefore, interactions are modeled using required and supported awareness
levels of various roles in an interaction, support for transition of awareness, and tools to
support the required awareness levels. First, the problems in different scenarios are expressed
in terms of the previously mentioned model, that is, in terms of what is the required level of
awareness and what is supported by existing tools, resulting in a matrix of awareness levels
for various interactions. In the next stage, schemes are developed to realize the required levels
of awareness using group interaction databases, communication mechanisms, and autonomous agents. A mathematical description of this model is available in Daneshgar and Ray.
For the sake of brevity, the analysis presents only those interactions (in various
scenarios) for which the satisfaction is low (less than 5). A brief description of each scenario
is followed by the cooperation analysis of interactions of low satisfaction levels. This may
lead to a discovery of a relationship between awareness level and satisfaction level.
5.3.3.2.
Scenario 1 : Upgrade Problem
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 unsatisfactory interactions are as follows:
1. The NMC technician discusses with a remote test technician about a suitable time
(Role B/D <c> Role C). The dissatisfaction here is caused by the manual and
hence error-prone method of communication. Often the remote test technician
cannot be contacted because the person is busy at a customer site, and e-mails to his
office go unanswered because the person hardly has time to read them. On the other
hand, the customer, and the business manager is pressing hard for the change. The
lack of appropriate communication mechanisms causes a mismatch between the
required and the supported awareness levels.
*2. The NMC technician/expert places a change request with the proposed time and
user impact statement to the change manager (Role B/D -s> Role G). The change
impact statement requires a considerable amount of context knowledge regarding
90
user configurations. In the absence of an automated facility, the NMS 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 artifacts and tools. In order to
be effective this person should be at Level 3. Appropriate repositories to support
information at this level can achieve this.
*3. Change manager takes up with the affected users (Role G -n> Role U). Although
the user need not be at a higher level of awareness, the change manager needs to
have an adequate level of awareness through appropriate repositories (nonexistent
in this case). Users are totally unaware of the overall system.
*4. Related users discuss impact and examine proposed time (Role U1 <c> Role U2
<c> Role U3). 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. A user resubmits a request to the change manager with possibly an altered schedule
(Role U -f> Role G). Due to the lack of adequate level of knowledge, users may
have taken invalid assumptions. The change manager is also unable to help in this
situation. This can waste substantial amounts of time for all concerned.
*6. The change manager issues a permit to work to all concerned (Role G -o> Role U,
B, D). The lack of awareness on the part of the change manager may lead to his or
her missing some parties concerned with the work. In addition, some users may not
appreciate the need for responding within the stipulated time. All this may cause
substantial damage to the organizations interests. Table 5.6 shows the awareness
analysis for Scenario 1.
DIAGNOSIS
The low level of user satisfaction can be partly attributed to the lack of required
awareness support. There are other relevant factors described as follows:
1. Because there is no automatic change impact notification, all concerned parties need
to be informed manually and hence the chance of omissions will be present. There
is a need for a system to automatically create notification lists based on network
topology.
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 users. In case some users do not respond, it may be necessary to chase them.
Hence there exists the need for a to do list for every change.
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. Often users/experts can not be located. Hence, there is a need for mobile computing/communicationsolutions.
Chapter 5.
91
Table 5.6. Awareness Level (AL) Matrix o f Scenario 1
Scenario,
Interaction
Awareness Required
Awareness Supported
3-2 (Role B/D need

AL 3 concerning
users and their
needs)
<1,2>
<1, 3>
<1,4>
<1,5>
<1,6>
5.3.3.3.
1-2 (Role B/D are at

AL 1 without any
knowledge of user
organization people
or their systems
performance needs)
3-0 (Role G has AL 3
4-1 (Role G needs
due to lack of
AL 4 concerning
knowledge of user
user needs, in
addition to how
people performance
providers technical
requirements and
performance
their relationships.
framework would
Users have AL 0,
affect each user.
no knowledge of
Users should be
the technical
educated to AL 1
framework or of
technical
each others needs)
framework)
3-3 (All users U need 1-0 (coordinating
user U1 has AL 1
AL 3 concerning
technical
knowledge of
framework and
technical
each others
framework, but
configuration needs)
none about other
users needs, like
other users
themselves)
3-4 (Role U need to
1-3 (Coordinator U1
have AL 3 and G at
has AL 1 and G has
AL 4 defined above) AL 3 defined above)
3-1 (Role G lacks full
4-3 (Roles G and U
need to have AL as
knowledge of all
defined above)
affected users who
have AL 1 defined
above)
User
Satisfaction
Level
3
Remarks
Low user satisfaction
is caused by the
gap in awareness
levels supported.
Appropriate tools
are needed.
No ack. from users
Scenario 2: No Information with NMC
Technicians/provisioning engineers at a remote site are doing installation work and call
NMC asking if the router configuration is ready for the site. They also ask NMC to test
connectivity of the newly installed equipment at the remote site. NMC was unaware that this
work was done. In this case, all interactions are unsatisfactory:
1. The remote site test technician contacts an NMC technician and asks for configuration and testing to be done (Role B -s> Role C). Because there is no information
92
with NMC, the NMC technician cannot help. The remote technician could have
helped if the person had a much higher level of awareness of context information.
2. The NMC technician contacts the change manager to inform him or her that they
are not aware of a permit to work and to get additional details (Role B -f> Role
G). The change manager is more aware of the situation, but the level is not
adequate to be able to help in this regard.
3. The NMC technician contacts the help-desk operator and sees if he or she has any
details (Role B <c> Role A). The help-desk operator has no information.
4. The help-desk operator contacts users who have ordered provisioning and informs
NMC (Role A <o> Role U). Users can help partially with the basic needs.
5. The NMC technician contacts users to find need (Role B -c> Role U). This
activity requires a very high level of awareness on the part of the technician in order
to derive context information from bits and pieces. This is not supported in the
system.
6. The NMC technician consults an expert if required (Role B <c> Role D). This
will be considered a waste of time for the expert who is more concerned with
knowledge in his or her specialized domain than in a general awareness of work
contexts.
7. The NMC technician coordinates with a remote site test technician for the required
configuration and testing (Role B -o> Role C). After all these efforts, the
technician may only have partial information, requiring the test technician to be
more knowledgeable than the person needs to be about the work context.
In this scenario, existing automated tools support none of the interactions. Table 5.7 shows
the awareness analysis for Scenario 2.
DIAGNOSIS
The internal reasons for the organization not supporting these features are not of interest
to us. Although some telecom organizations have bulletin boards in the NOC, they do not
solve the problem. This problem may require an effective knowledge base not available in
the organization.
awareness support. There is a need for the right awareness level for every human role. There
are other relevant factors described as follows:
1. In this case, the urgency of the situation made change management action proceed,
bypassing the normal procedure. Besides, the person concerned forgot to update
the database after the operation was over. This highlights the need for a mobile
computing facility and a universal to do list customized for every role.
2. There is a need for automatic notification to all concerned. In case of emergency,
there should be an automatic message to all concerned with the change initiators
name so that users can remind the person.
Chapter 5.
93
Scenario,
Interaction
<2, 1>
<2,2>
<2,3>
<2,4>
<2,5>
<2,6>
<2,7>
Awareness Required
Awareness
Supported
User
Satisfaction
Level
1-0(remote
2-2 (both roles
should have AL 2
technician knows
concerning the
the technical job,
user need and
does not know
technical job).
user details. NMC
tech knows
nothing).
2-3 (Role B should 0-1 (Role B knows

have AL 2
nothing, Role G
defined above and
only knows of the
name of the job,
role G should
none about the
have AL 3 that
user or the overall
includes the
knowledge of the
context)
work context.)
2-2 (Both Roles B 0-0 (Both roles
know nothing)
and A need to
have AL 2
through help-desk
postings)
2-2 (Both Roles A 0-1 (Role A knows
nothing, Role U
and U need to
only knows the
have AL 2)
job, not
provisioning
4-2 (Role B needs 2-1 (Person in Role
to know all
B only knows the
contractual and
technical aspect
technical details
of the job).
to reconstruct the
help-desk info).
4-4 (Roles B and D 2-3 (Although Role
need to have full
D knows the
technical and
intricate technical
commercial
details, lacks
details to derive
knowledge of the
the original work
particular user
context correctly).
contract details).
4-3 (Both roles
2-1 (existing role
need high level of
artifacts support a
technical and
much lower level
commercial
of AL).
knowledge to
resolve the
problem).
Remarks
This is a disaster
scenario. User
satisfaction level
is zero in all
interactions.
System design
should prevent
this.
94
CooperativeManagementof Enterprise Networks
5.3.3.4. Scenario 3: New Software Version
A business manager/capacity planner orders a new router to be installed at a remote site.

The new router comes with a new version of the operating software. This new version
software creates compatibility problems with the older version equipment. In this case, many
interactions are common with Scenario 1 (section 5.2.3.2). The unsatisfactory role interactions are as follows:
*2. The NMC technician puts in a change management request to the change manager
(Role B -s> Role G). This interaction is similar to interaction4,2> discussed in
section 5.3.3.3. However, the software version change requires a higher level of
awareness than for the hardware version change discussed in Scenario 1.
*17. NMC experts discuss with change managers to resolve the problem jointly (Role
D <c> Role G). In this case, the expert is unaware of the context of this change.
In the absence of any automated facility, this expert may need to know a substantial
amount of details. This is expected to stress the busy schedule of the expert.
Consequently, the solution may get delayed.
Table 5.8 shows the awareness analysis of Scenario 3. Existing tools do not support many
of the interactions and multiple human roles need to interact simultaneously on several
occasions.
DIAGNOSIS
awareness support. There are other factors described as follows: Most of the problems are
User
Scenario,
Interaction
<3,2>
<3, 17>
Awareness Required
Awareness Supported
4-4 (both roles B and 3-4 (Role B as AL 3,

G must be fully
since the person is
aware of the
not aware of all
technical aspects of
contractual
obligations of to all
the new version,
concerned users).
and its impact on
all concerned
users).
4-4 (in order to
0-4 (the Role D is a
effectively solve
hardware expert,
the problem, both
has AL 0 since the
person has no
roles need to have
AL 4 defined
knowledge of
above).
relevant contracts,
nor about this
software version).
Satisfaction
Level
3
Remarks
Some interactions
lack adequate
support.
Chapter 5.
95
the same as in Scenario 1. Hence, the same diagnosis applies, and there is a need for
mechanisms to quickly change the awareness levels of human roles, such as the expert in
this case. This measure of the rate of change of awareness is being called the transition of
awareness. As discussed in subsequent sections, a mobile computing solution can support
the transition of awareness.
5.3.3.5. Scenario 4: Security Problems
It has been decided to shift an application running on a system on the NOC network to
the corporate network. NOC and corporate networks are separated by a firewall. The
application in question was used originally by NOC users but needs to be extended to
corporate users as well. For this reason, a larger machine with spare capacity already existing
on the corporate network is chosen to run the application. During the testing phase, an
objection is raised by the NOC security expert that the operation in this manner jeopardizes
the security of the NOC network. The unsatisfactory role interactions (section 5.2.3.3) are
as follows:
*la & 1b. The change manager notifies Users U3 and U4 but misses U2 (U2 is NOC
security); the change manager has not yet included U2 in his notification list because
network security was not a prime consideration until now [Role G -r> Role U3,
U4]. The creation of security notification requires a thorough knowledge of the
activities of users and their services. It is not possible to have this level of awareness
without a proper linkage between the service database and the management database. Consequently, there is a chance of missing somebody who should have been
informed.
*5. The NMC technician consults an NMC expert on security impact (Role B <c>
Role D). The NMC technician knows the procedure in general and the users to be
affected, but the person does not have much information on the specific security
requirements of this client/application. On the other hand, the NMC expert knows
the intricacies of the technical aspects of a firewall, but the person is not aware of
security requirements of any department/users. In addition, the expert is unaware of
the overall context of the change.
6. The NMC expert discusses security with U2 (Role D <c> Role U2). This discussion
is likely to be pleasant due to the lack of the contextual knowledge on part of both
the NMC expert and U2.
Table 5.9 shows the awareness analysis of Scenario 4. This scenario uses almost all of
the interactions defined in Fig. 5.1. Although most of the interactions have support from
existing tools, this scenario highlights the negative consequences of missing communication
with one human role in certain situations.
DIAGNOSIS
awareness support. There are other relevant factors that are described as follows: This is a
new area and any organization needs to evolve a knowledge-base continuously. This
knowledge-base should help in the generation of notification lists, there is a need for agents
96
Table5.9. A w a r e n e s sLevel (AL) Matrix o f S c e n a r i o4
Scenario,
Interaction
Awareness Required Awareness Supported
User
Satisfaction
Level
<4, la, 1b>
4-1 (Role G must

3-1 (Role G has AL
have full
3, unaware of
knowledge of the
some people
security
affected by the
framework and
security
concerned people).
framework).
<4,5>
3-2 (Both roles lack

4-3 (Both roles B
and D need to have full knowledge of
knowledge of the
all concerned
security
people, some
framework and
people are missing
concerned people,
in their databases).
Role D need not
know all contract
details).
4-3 (Role D needs to 3-2 (Although both
have the AL of
roles know about
role B in this
the security
interaction, role U
framework, they
must have been
lack full
raised to AL 3
knowledge of all
through training
affected people,
on security
and how they are
framework).
affected).
<4,6>
Remarks
In this case, lack of
awareness has
created a
potentially
dangerous
situation for the
organization.
for security hole detection, and a mobile computing solution is required to optimally utilize
the time of experts.
5.3.3.6. Scenario 5: Architectural Issues
No awareness matrix is produced for this scenario because existing tools adequately
support most of the interactions. The gaps relate to specialized integrated management tools
(not of interest in the analysis here).
5.3.4. Usefulness of the Awareness Model
The results of this study suggest that lower user satisfaction levels could be caused by
the inability to support the right level of awareness. The reverse may not be true. In addition,
the applicability of this theory in other domains of application needs to be verified. It may
be noted that the definition of awareness level is not precise due to the evolving nature of
this theory. In addition, this allows the adjustment of definitions iteratively for a particular
problem domain.
Chapter 5.
97
Given this outcome, it is now possible to undertake a high-level design of a cooperative

management system for enterprise networks on the basis of required awareness levels. The
idea is to come up with a conceptual design followed by a prototype implementation for
evaluation. However, this presents a number of interesting problems:
1. Because awareness level requirements vary from interaction to interaction, it is
necessary to change awareness levels accordingly. Human users need the right tools
at the right place and time (space-timematrix). This points to some communication
requirements, such as multimedia visualization (model-based data interpretation)
and mobile computer-based notification agents. In a groupware system, this is
achieved by cooperation databases.
2. The implementation of the desired awareness level may be in conflict with
individual privacy or with organizational security requirements. Hudson and
Smith75 suggested a few schemes for handling this in a CSCW situation. For
example, people talk privately while working. That should not be transmitted to
co-workers. However, co-workers need to know some important information, such
as whether the person is in the office, or on what problem he or she is concentrating.
The previously discussed schemes muffle private conversations and create some
artificial symbols that are transmitted to co-workers.
3. Awareness may not be properly usable. For example, large amounts of information
may not increase awareness. The right kind of integrated management tools are
needed for awareness-based action.
4. Effectiveness of available tools for awareness control, such as interaction-level
access controls, dynamic interaction databases, and autonomous agents, is important.
Although researchers are working on systems with learning and adaptation capabilities at
the experimental level, no definite solutions are known for the problems described by the
previously outlined scenarios.
Solutions to many of these problems are complex, and they may need in-depth studies.
In CoMEN, the awareness analysis is used to derive a generic framework for the cooperative
management of enterprise networks. This is described as part of systems design in chapter
6. It may, however, be noted that awareness levels are not the only means defining awareness.
Benford and associates have defined two variables, called focus and nimbus for this purpose?
These are discussed in more detail in section 7.2.4 in chapter 7.
5.4. DISCUSSION
The following points summarize the findings with respect to some basic issues addressed
in this study of the cooperation in the management of an enterprise network.
1. Roles and interactions have been described separately for the five representative
scenarios. Whereas all the documented scenarios are concerned with change
98
management, the problems in fault/problem management are identified in a general

form in section 5.2.2. Some tasks are routine and have well-developed procedures/tools, whereas other interactions are manual and evolve with the situation.
2. Time available: As described in section 5.2.2., fault management needs to be done
within short time frames (30 minutes for problem resolution). Configuration/change management can be done over much longer time frames.
3. Type of information used: Routine tasks have a standard structure of management
information.98,1 17,155 However, integrated management uses a variety of repositories, such as a customer information base, trouble-ticket history, a solutions
knowledge base, and so on. These are supported as part of a number of software
systems, such as management platforms, groupware systems, help-desk systems,
and so on.134
4. Group communication interfaces: All scenarios have a substantial amount of
informal information exchange based on e-mail/telephone communication. There
is a requirement for various group communication mechanisms, such as asynchronous and synchronous cooperation using mobile and multimedia technologies.76
5. Drawbacks: Although existing communication tools are mostly equipped for
person-to-person communication, group communication techniques need to be
integrated with the system because many functions require a number of persons to
be contacted repeatedly. Often network service problems are caused by the failure
to inform the right persons at the right time. Although there are solutions for routine
known problems, many novel situations arise during operations and they need to
enhance the corporate knowledge base (e.g., the impact of security configuration
changes). Existing systems do not have adequate learning capabilities. Fault
management has short time frames and needs better techniques to locate and to
communicate with busy people, such as experts on the move. Many of the tools
and applications used in todays network management environment (e.g., network
simulation systems) are not yet integrated.19
6. Suggestions for improvement include the integration of multimedia and group
communication with integrated management platforms and applications,70,168 flexible workflows and autonomous agents in integrated management solutions, and
mobile computing facilities (this would minimize the time to locate a person and
to get a response in the shortest possible time).132
It seems that effective cooperative management in an enterprise network would require
a two-pronged strategy. First, there will be a need for continuous development of organization/application-specific multivendor management solutions on integrated management
platforms, such as IBM NetView 6000, HP OpenView, and so on. This is already taking place
in various forms in organizations all over the world. Second, there is need to develop new
management frameworks integrating group support techniques with existing management
platforms. This offers exciting research opportunities involving newer technologies, such as
mobile and multimedia communication systems.
Chapter 5.
99
Once these new cooperative management frameworks are available, the focus of
attention will shift to providing a design methodology for cooperative management repositories. This would require abstract parameters, such as the awareness levels defined in this
chapter. Chapter 6 discusses the design and implementation of a sample trouble-ticketing
application based on these concepts.

This chapter has described an actual application of CoMEN analysis methodology in a
real enterprise integrated management environment. The analysis used a few real-life
scenarios suggested by practicing management professionals. Existing collaborative systems
(tools and group communication interfaces) were evaluated with respect to their utility in
these scenarios. This has helped us understand the need for more effective cooperative
management systems. Time utilization analysis of various human roles in this environment
substantiates the need for effective group communication technologies in a mobile environment.
This was followed by an abstract analysis of these practical scenarios. This has lead to
the definition of a new model for support for cooperation based on a measure called
awareness levels. Unsatisfactory scenario interactions were analyzed with respect to awareness levels. It seems that low user satisfaction levels were caused by inadequate support for
awareness. More study is required to establish such a methodology in the development of
integrated management systems. However, this discussion has illustrated the types of
concepts being used in CSCW-based cooperative management systems.
It is interesting to note that the results are applicable to many other service industries
that use help-desk-based systems for customer support. A help desk provides a common
platform for many specialized groupware applications including real-time services. Therefore, help-desk-based applications could be one of the most suitable, real environments for
the study of complex Quality of Service (QoS) issues in future collaborative services using
multimedia and mobile communication technology.
This chapter has presented the first two stages of CoMEN (requirement gathering and
analysis). The subsequent stages of the CSCW-based methodology (design, implementation,
and evaluation) are illustrated in the next two chapters.
6
Design and Implementation of a
Cooperative Management System
This chapter describes and illustrates a CSCW-based design and implementation of integrated management systems. In view of the inadequacies of the existing integrated management frameworks described in chapter 2. It is necessary to define an architectural framework
for cooperative management to incorporate CSCW features. The following questions are
addressed: How should one design a cooperative management solution? and What is the
architectural framework necessary for cooperative management?
A systematic study of various situations of cooperative management in alarge enterprise
network is described in chapter 5. This involved the collection of data and its analysis to
reveal gaps in existing support systems for enterprise management. A high-level definition
of a cooperative management system was abstracted on the basis of a parameter called
awareness level. The available information suggests a close link between the support for
awareness level and the satisfaction level of such systems for enterprise management.
Therefore, an abstract measure like awareness level may be used for the design specification
of cooperative management software. The question is how to realize a cooperative management system from this abstract measure.
This involves the following constituents: a generalized workflow design for the application domain, a groupware-integrated communication framework for integrated management, and the design of reusable management application software. These three aspects are
discussed in this chapter as part of a CSCW design methodology. Cooperative management
solutions vary from organization to organization. Therefore, it is necessary to develop a
generic cooperative management system (e.g., based on the help-desk model).
This chapter finally discusses a prototype implementation of a help-desk-based cooperative management system to elicit feedback from real management users on the effectiveness of CSCW-based cooperative management.
6.1. CoMEN DESIGN METHODOLOGY

In the previous chapter, workplace scenarios were discussed with respect to roles and
interactions involved in the business process. Although that methodology was useful in the
identification of gaps in the support of abstract awareness levels, a methodology is now
101
102
needed to realize a cooperative management system based on specified awareness levels.

Figure 6.1 shows the steps involved in this methodology. Step 1 involves the design of
workflows from the role-interaction sequences in the analysis stage. At this stage, notations
such as Action Workflows are used. Step 2 initiates the distributed system design. This may
involve a design using open distributed systems standards, such as RM-ODP, UML, and
CORBA, as per steps 3 to 5. Alternately, one could develop a design based on the proprietary
tools of a groupware platform, such as Lotus Notes, as shown in Step 6. Step 7 involves the
architectural design for implementation, in case the open-standards-based 00 design is used
in Steps 3 to 5. In the case of a design based on a proprietary platform, Step 7 involves the
design of group communication mechanisms as discussed in chapter 3. Step 8 involves
system configuration for implementation according to the desired evaluation objectives.
Although this methodology shows the scope of different design techniques, it is not
essential to go through all of its steps in real life. For example, many implementations (e.g.,
the prototype discussed in this chapter) may not realize a cooperative management system
from RM-ODP viewpoints.
The design process starts with the workflow design, as discussed in section 4.4.4 in
chapter 4. Figure 6.2 illustrates the workflow design for Scenario 2 of the case study, using
Action Workflow notation. The next stage involves the high-level distributed management
Figure 6.1. C o M E N s y s t e m design methodology.
Chapter 6.
Design and Implementation of a Cooperative Management System
103
Figure 6.2. Workflows of Scenario 2 of case study.
system design based on RM-ODPviewpoints (discussed in detail in Ray 138) and on UML
use cases.96This is followed by the groupware design based on some groupware platform.
The procedure may involve rigorous OO design based on a distributed object platform, such
as OMG CORBA, or the application may be directly developed on the groupware platform
using platform-specific facilities. Finally the applications are coded, implemented, and
evaluated. All these steps are briefly illustrated in this book in chapters 6 and 7.
This methodology assumes the availability of management instrumentation, including
MIBs. This can be achieved by linking the groupware platform to a management platform.
Examples of cooperative management systems include trouble-ticketing, inventory
management, and provisioning. In view of the extensive use of the help-desk-based troubleticketing system, this process is being used to illustrate the steps of the aforementioned
104
methodology. Although there are many trouble-ticketing systems successfully operating with
telecommunication organizations, recent deregulation in the telecommunication industry is
forcing organizations to redesign trouble-ticketing systems to make them interoperable.47
Such changes would be necessary in many future cooperative management systems to allow
for the changes in the business environment. Therefore, it will be necessary for the designers
of cooperative management systems to follow a methodology, such as CoMEN, in order to
protect investments in software developments.
The subsequent sections illustrate the various steps of the aforementioned design
methodology.
6.2. CoMEN ANALYSIS TO SYSTEM DESIGN

The analysis phase of CoMEN has produced a simple model for cooperative management specification based on awareness levels. At present there is no technique that could
develop design specifications based on the awareness model. The question is how to arrive
at an OO system design specification based on awareness levels. Some researchers are
suggesting the concept of electronic workspace that would define repositories, access
mechanisms, and collaborative services for a CSCW system.65 A workspace in a collaborative computing infrastructure would consists of three major components: task space (that
defines the task at the process level), object space (that defines data and associated shared
methods), and message space (for communication among different members of a workgroup). Workflow engines provide the mechanism for communication between these workspaces.125 This is a promising technique the future design of CSCW systems from awareness
level specification. However, other techniques need to be used until the workspace-based
technique develops further.
Workflow for Scenario 2 of this case study is illustrated using Action Workflow notation
in Fig. 6.2. Each interaction of this scenario is represented by a loop. The roles involved in
the interaction are assigned customer and performer roles as per the Action Workflow
convention. Depending on the interaction contexts, one interaction loop is connected to
another through any of the phases of the loop, namely preparation, negotiation, performance,
and acceptance. This helps in the identification of data and knowledge requirements in each
phase of a loop.
Similarly, each scenario can be further analyzed in terms of workflow loops. This helps
a designer to view the requirements of different workflow phases, namely preparation,
negotiation, performance, and acceptance. However, this is too specific to the organization
under consideration, and it only captures the existing processes. An effective cooperative
management design involves the reengineering of the work processes to exploit the capabilities of the latest software and communication technologies. Reengineering of business
processes is still an art.97 This section presents a discussion of the workflows of the case
study scenarios to obtain a generalized process model of a cooperative management system.
As discussed in the case study scenarios in chapter 5. the major cooperative management
weaknesses can be summarized as the following:
1. Luck of Appropriate Notifications lists results in inadequate or no notifications to
concerned people during a change process. It is necessary to integrate the notifica-
Chapter 6.
105
tion list of a service with that of the management. This also points to the need for a
groupware structure to support discussions.
2. Lack of Workflow Automation results in too much reliance on individual recollections
and discipline. This causes confusion and misunderstanding among people working
in the project, leading to the wasting of enterprise resources. This also points to the
need for mail-enabled groupware applications and the need for bringing together a
number of tools and facilities in the same electronic workspace. A cooperative
management system needs network links to managed resource MIBs, to management analysis, to simulation and monitoring tools, to appropriate knowledge repositories, and to discussion group facilities.
3. Lack of Appropriate Group Communication Mechanisms results in too much delay
in changing the awareness levels of concerned human roles. For example, mobile
communication facilities enable quick transition of awareness levels.
4. Lack of Effective Knowledge Base results in too much reliance on a few skilled
technicians leading to inefficient customer support and to uncontrollable delays in
change implementation. This necessitates a mechanism for the creation and maintenance of context-sensitive knowledge repositories.
It is necessary to develop a generalized workflow of a cooperative management system,
keeping these factors in consideration. The next section discusses the design of a generic
cooperative management application based on the help-desk business model.
6.3. CSCW APPLICATION DESIGN

This section describes the design of a cooperative management application (troubleticketing) that captures the major problems of the scenarios described in chapter 5. In
addition, it is necessary to demonstrate real-life mechanisms to solve the problems in the
given scenarios. In order to arrive at a generalized scheme, the application design needs to
be independent of specific business processes existing in an organization. It is necessary to
demonstrate that this generalized model can be adapted to different organization-specific
processes. Therefore, the subsequent sections present the design and implementation of a
cooperative management application with semantics applicable in a wide range of organizations using enterprise networks.
6.3.1. A Generic Help-Desk Application
As discussed in chapter 5, there are two major components of the help-desk application:
Problem/Fault Management
Change/Configuration Management
Problem management needs two types of activities:
106
1. Help-desk operations on recording, assignment, and monitoring of the problem

resolution (the core application based on trouble-ticketing).
2. Analysis and discussion among concerned people using a problem knowledge base.
Change management events start with discussion among users, technicians, change managers, and so on, on certain user requirements. This is followed by the formal change
management process started by the permit to work. Subsequent activities and discussions
focus on open tickets as in the case of problem management.
Both of these two application components can be defined using the help-desk-based
trouble-ticketing workflow described in Fig. 6.3. This uses Action Workflow loops described
in chapter 3. This business model is used not only in the telecommunication organization
studied in chapter 5, but also in a variety of business organizations, such as banks, the travel
industry, or any customer support organization.
Each loop shows an aggregate interaction that can be broken down into more specialized
interactions. In this case. management personnel cooperate to manage a problem using
various network elements. Whenever there is 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 the expert)
if the problem cannot be solved within the stipulated time. The trouble-ticket is closed once
the problem is resolved to the satisfaction of all concerned.88,160
The operator/technician has a number of facilities to generate reports on these troubletickets, as required by the management, customers, and statutory bodies. For example, a
report may include the history of actions, statistics of open times/action time, and an
attachment from the management platform containing the status of various MIB variables
of the part of the enterprise network under investigation. These may also include other
interpersonal/group communication (in the form of memos, e-mails, faxes, letters, charts,
etc.) related to the trouble-ticket.
Figure 6.3.
Help-desk business model.
Chapter 6.
107
One pertinent question is why it is necessary to consider a model like trouble-ticketing

that has been successfully implemented in many organizations worldwide. Thanks to the
deregulation in the telecommunication sector, it is necessary for heterogeneous trouble-ticketing systems of different telecommunication service providers to exchange meaningful
information to solve the problems of todays enterprise networks spanning many countries
and jurisdictions of many telecommunication service providers. This is a difficult problem.
Eurescom project P 612 was initiated in 1996 to improve the level of automation between
PNOs within Europe through laboratory trials and through implementing automated capabilities for trouble-ticket exchange and ordering/provisioning processes. This project is in
the process of preparing recommendations that would help business managers to assess their
trouble-ticketing systems and their interfaces and to develop information models for implementing interoperable trouble-ticketing systems. The idea is to define a standard generic
trouble-ticketing process model with a standard trouble-ticketing interface that would need
to act as a gateway between proprietary domain-specific trouble-ticketing systems and
external trouble-ticketing systems belonging to other service providers. This uses the ITU-T
X.790 recommendation on Trouble Management Functions that specifies needed functionality for reporting troubles on services or resources on a managed network, tracking the
progress of trouble to solution, and clearing and closing of trouble.47However, this project
has not defined any methodology for the modeling of trouble-ticketing or of related
cooperative management processes.
6.3.2. Generic Workflow of a Cooperative Management System
Figure 6.4a describes the overall workflow in this application. This overall picture
presents the interaction among a number of related workflows:
Help-desk (W1)
Update customer profile (W2)
Assign technician (W3)
Distribute/monitor call (W4)
Invoke management platform/simulator (W5)
Browse/modify knowledge base (W6)
Seek expert help (W7)
W1 is the main workflow that shows the front end of a customer service process. All external
humans or processes interact with the organization through this workflow. It incorporates
features, such as the transcription of customer call detail, the generation of a trouble-ticket,
starting the monitoring clock, providing the initial feedback to the customer, logging of all
actions on the trouble-ticket, and so on. W2 is a subordinate workflow used for the integrity
of the common notification list. W3 is a vital subordinate workflow in this process. As
discussed in chapter 5, mistakes (wrong assignment) can cause avoidable delays in solving
the problem. W1, W2, and W3 are three workflows that constitute the primary cooperative
system workflow. Depending on the type of help-desk application (problem management or
change management), this primary workflow may be called Trouble-Ticket (TT) workflow,
or Change Management (CM) workflow.
108
Figure 6.4b. Primary workflow trouble-ticketing (TT).
Chapter 6.
109
W4 (like W7) is a subordinate workflow that connects the main workflow to the
subsidiary workflow, TALK (Multiparty Discussion Workflow). TALK provides support
for user-friendly structured multiparty discussions on some issues related to a
change/problem. This incorporates workflows for logging all contributions on the
subject, alerting concerned managers in case of customer complaints, automatic display
of the relevant commercial (e.g., competitors information), feedback to customer,
alerting concerned people, and so on.
The W5 workflow integrates different tools, such as an integrated management platform
and a simulator within this cooperative management environment. This also illustrates a
possible mechanism for seamless integration between enterprise management and technical
network/systems management. This provides mechanisms for the specification and filtering
of management information from the integrated management database.
W6 connects to the subsidiary workflow called Knowledge Base (KB). This assists in
the development and maintenance of an organization KB for relevant technical information.
This provides a mechanism for anybody (e.g., technicians, experts, customers) to initiate a
submission into the KB, but its classification is done (in categories of rules and notes) by an
authorized person in the organization. This workflow protects the integrity of the KB.
Figure6.4c. Multiparty discussion workflow (TALK).
110
In addition to these there are supporting processes, such as escalating a call to higher
level of management. The next section describes workflows TT, CM, KB, and TALK, using
Action Workflow notation.
6.3.3. Workflow Specifications
This section presents the workflow designs of a primary workflow (TT), and other two
workflows TALK and KB, developed using Action Workflow notation. These three workflow
specifications are shown in Figures 6.4b, 6.4c, and 6.4d.
As shown in Figure 6.4b, the trouble-ticketing activity starts with the leftmost workflow
followed by a number of interconnected workflows, such as Support Call, Log Call Info,
Log Customer Info, Notification, and Research Problem. On the other hand, this diagram
also shows the use of subsidiary workflows KB and TALK through related workflows, such
as Submit Technical Note and Research Problem. Figure 6.4c shows the constituents of the
workflow TALK and its linkage to the primary workflow TT. Figure 6.4d shows the
constituents the workflow KB and its linkage to the primary workflow TT. Having illustrated
Figure 6.4d. Knowledge base workflow (KB).
Chapter 6.
111
the workflow design stage of the methodology, one can now move on to the next stage, that
is, distributed systems design, discussed next.
6.4. DISTRIBUTED MANAGEMENT SYSTEM DESIGN

Because most of the present cooperative systems are based on distributed computing, it
is important to describe the design using distributed processing concepts. Ray134 provided a
detailed description of a trouble-ticketing-based integrated management using RM-ODP.
This conceptual-level design is illustrated using the computational viewpoint ofRM-ODP.83
This illustration presents the distributed system design to realize the trouble-ticketing
workflow discussed in the previous section.
This section presents an ODP distributed processing view of the generic help-desk
application described in the previous section. Because RM-ODP describes distributed
systems, objects representing human roles are software objects directly interacting with the
human roles named. Because the trouble-ticketing database holds vital information being
shared by all other objects, this object is defined as having multiple interfaces (Fig. 6.5).
Other objects are as follows:
1. Customer computing facilities (Customer objects). This is a distributed system
client object that encompasses the client computing interface and the client communication interface (e.g., e-mail, voice telephone). A client will need an interface
to specific trouble-tickets and summary information including relevant feedback
information.
2. Technician workstations and interfaces (Technician objects).
3. Help-desk operator workstation and interfaces (Operator object).
4. Business manager interfaces (Manager objects).
5. Organizational knowledge base development and retrieval (Knowledge base object).
6. Access to management information at the management platform (Integrated Management Platform object).
Figure 6.5 shows these ODP computational objects and their interfaces. This provides
a high-level conceptual design of cooperative management software, independent of the
implementation environment. This design can be expressed in terms of notations, such as
OMG CORBA IDL for implementation on an Object Request Broker (ORB) platform.
Alternately, this design can be implemented on a proprietary groupware platform. such as
Notes. The second option is adopted in this illustration, as discussed later in section 6.7.
It may be noted that this stage of the design methodology is optional. The more the
complexity of the cooperative management system, the more will be the necessity of this
stage, mainly used for the high-level design of a distributed system. The next section presents
a discussion on the role of communication technologies and CSCW tools in enhancing
awareness levels.
112
3-InputCall Information,
Customer Information
Output Call Statistics,
Customer Reports
1-Customer Inputs,
Reports Outputs,
2-InputComments, Action Taken,
Reassign Technician, Call Expert, Update Knowledge Base, etc.,
Output Previous Action History, Test Results, Expert Views, etc.
4-InputComments, Action Plans, Customer Feedback
Outputs Escalated Calls, Customer Complaints, Statistics
5-InputsStored Knowledge Rules And Notes,
Outputs Submitted Draft Rules / Notes
6-InputsManagement Platform MIBs, Alarms, Events
Outputs Management Platform Commands
Figure 6.5. Trouble-ticket computational viewpoint.
6.5. GROUP COMMUNICATION SYSTEM DESIGN

In chapter 5, cooperative management requirements were abstracted using an awareness
model in the scenario analysis phase of this methodology. Modeling with awareness levels
is now in a nascent stage. This subsection discusses how awareness levels may be translated
to CSCW requirements, such as repositories and group communication configurations. It
may be possible to arrive at a relationship between level of awareness, transition time
between awareness levels, user satisfaction in a cooperative process, and tools required to
support that process. There is also the concept of the usability of awareness that depends on
the security and administrative policies of an organization. Awareness usability also depends
on the quality of information available.
Figure 6.6 shows the level of awareness for different group communication mechanisms.
This has been derived from similar work in the area of CSCW.126 It is now possible to
calibrate different cooperation facilities for different levels of awareness. Table 6.1 illustrates
this concept. As discussed earlier. the subject of awareness modeling is in a very early stage
of development. Therefore, it is not possible to arrive at any quantitative requirements for
CSCW facilities. However, one can find some qualitative requirements. For example, mobile
communication enhances the speed of transition of awareness from one level to another in
Cooperation Repositories
Chapter 6.
113
'Agent Integrated Multimedia

*Structured Data
'Voice
*Multimedia
Image
+ Fax
*Fax
'Text E-mail
'Paper
Letters
Low
Figure 6.6.
Awareness Level
High
Calibration of cooperation repositories for awareness.
a CSCW environment. This is due to the very nature of mobile communication devices, such
as pagers, mobile phones, or mobile data systems. No matter who the person is, and wherever
the person is, he or she can be reached almost immediately using mobile communication
(used extensively in the organization under study discussed in chapter 5). This explains the
user support for mobile multimedia tools in alleviating existing problems. For effective
usage, one needs to have an appropriate intelligent agent repository for filtering and event
processing.
Hence, there is a need to support for a variety of group communication media, such as
e-mail, mobile data, multimedia displays, mobile phones, pagers, and so on. Groupware
Table 6.1. Awareness Level Calibration of CSCW Tools
Awareness Level
Cooperation Repositories
Level 0: concerns knowledge Paper procedures, forms

related to the given interaction
Level 1: Level 0 + knowledge Group mailing lists, forms
related to contact addresses
of people involved in an interaction
Level 2: Level 1 + knowledge Directory systems, lists, forms
related to address of all people in the interaction context
Level 3: Level 1 + knowledge Structured data + knowledgeof activities of people inbase + directory system
volved in the interaction
Level 4: Level 2 + knowledge Agent integrated multimedia
of activities of all people involved in the interaction context
Group Communication Systems

Paper/computer-basedsystems
Telephone, group e-mail
Telephone, global e-mail, fax

E-mail list + multimedia
visualization
Wireless mobile computers with
intelligentagents
114
applications and repositories need to select any combination of these group communication
media depending on the CSCW requirements. This can be expressed in terms of the
space-timematrix discussed in section 3.2. Figure 6.7 illustrates the use of the time-space
matrix in the definition of communication requirements. These communication requirements
can be implemented with the groupware and management platform interacting with various
high-performance computing functions described later in this chapter.
The CSCW functionality is implemented on a groupware platform using the following
features: interaction databases and repositories to support the right level of awareness, group
communication mechanisms to enable the appropriate transitions in awareness, and autonomous agents to support the right type of awareness at the right time.
Although there are no methodologies to derive these design parameters from awareness
levels, one can work on the basis of the following broad guidelines derived from awareness
models:
l The right awareness level can be maintained by a proper choice of repositories
(interaction databases and application agents). For example, users may have access
to different levels of notification lists, directory structures, and event logs/audit trails
in an organization. Autonomous agents are designed to create appropriate notifications, event logs, audit trails, and so on.
Figure 6.7.
Group communication in network
management
Chapter 6.
115
Group communication mechanisms decide the transition time between awareness

levels. For example, a user with a mobile computing device would be accessible
always and hence awareness transition time will be very low, unlike in situations
where a user does not have a mobile device and hence may not enable transition of
awareness levels when the person is away from the office.
The previous discussion shows how awareness levels may be linked to some group
support system requirements.
As discussed earlier, the formal translation of awareness levels to CSCW design will
require a substantial amount of additional work.30,134 Rodden140 described a new protocol
for the monitoring of some awareness information for users cooperating in a CSCW
environment.
Having discussed the workflow design, the distributed object interface design, and the
interaction communication design, one can now design and implement the groupware
applications. However, existing management platforms do not provide adequate facilities for
this purpose. The next section presents a new groupware-integrated architectural design of
cooperative management systems.
6.6. COOPERATIVE MANAGEMENT ARCHITECTURAL DESIGN

This stage involves the architectural design and the platform selection for the implementation of a cooperative management system. The next section examines the requirements
of the changing management environment.
6.6.1. The Cooperative Management Environment
The modern enterprise network is dynamic in nature. As more and more applications
are networked, the complexity grows exponentially. However, the skill base for the planning
and maintenance of such networks is not growing so quickly.36There is a shortage of people
with the required skills in this area of fast technological changes. Consequently, the expertise
of skilled people needs to be shared within and across organizations. Many businesses today
are critically dependent on their information technology organization. Increasing competition forces organizations to deploy the latest communication technologies (e.g., mobile and
multimedia) for efficient management of enterprise networks.
The existing integrated management frameworks are not capable of handling such a
wide range of dynamic management requirements involving people and equipment. Hence,
there is a need for a new framework for the cooperative management of enterprise networks.
Figure 6.8 presents the nature of a cooperative management environment in a telecommunication organization. In such organizations, trouble-ticketing applications provide a
framework for supporting a number of management tasks, such as fault management and
change management. This diagram shows that a typical change management project requires
interactions among a number of divisions/groups within the organization and its customers.
In addition, many projects require frequent communication with external groups, such as
vendors. They need to use a variety of tools distributed over the geographical spread of the
116
Figure 6.8.
An emerging cooperative management environment.
enterprise network. Many people in these groups are mobile, and hence there is a need to
support the mobility of group members.
Some organizations are exploring the effectiveness of multimedia communication for
integrated management. Trouble-ticketing, a help-desk-based cooperative management system, provides an example of a popular cooperative management model. This system is shared
by a number of groups of people, such as specialists, business managers, help-desk staff, and
technicians, to coordinate and support a variety of management tasks.88
6.6.2. Cooperative Management Requirements
This requires an integration of integrated management platforms, mobile/multimedia

communication systems, and sophisticated business workflow/groupware tools. On the other
hand, the heterogeneous nature of multivendor telecommunication solutions necessitates
distributed object modeling standards to be used for such solutions. Thanks to the recent
growth in web-based information networks, much of tomorrow's applications may be based
on the migration facilities of distributed objects, as supported by the JAVA language and
distributed applets.16,167 Therefore, it is be necessary to have WWW-based group user
interfaces for management applications. Some integrated management products now support
HTTP-based management communication at the instrumentation level.72,165
A cooperative management framework needs to facilitate cooperation of people with
the following broad features: a standard distributed object-based management platform,
support for a wide variety of visualization mechanisms, groupware facilities, and
WWW-based access. Management platforms are required to support the interoperability
Chapter 6.
Design and implementation of a Cooperative Management System
117
of multivendor management applications in a heterogeneous environment. The existing

integrated management platforms, such as Cabletron Spectrum, incorporate distributed
object models that are proprietary in nature. Hence, many object-based management
applications are not interoperable across platforms.6 These will need to integrate existing
integrated management platforms with standard distributed object models, such as
CORBA. Some work on this has been reported in Pavlou.123 Integration of Internet-based
client-server computing with OO technologies and relational databases presents a
number of design challenges. Amjad Umar discusses these issues in Object-Oriented
Client/Server Internet Environments. 167
Multimedia visualization (e.g., audio annotation) may be quite useful in the effective
assimilation of management information based on complex hierarchical management models.92,132 A recent study shows that an effective visualization system for a group meeting
system can be six times more effective than a human facilitator.23 In addition, desktop
conferencing is becoming more popular, thanks to Internet facilities such as Multicast
Beckbone (MBONE). This study shows that more than 60% of people are provided with
some mobile communication tools, such as pagers or cellular phones. Mobile data computing
facilities are now becoming popular due to their cost effectiveness.81
Interactive OO multimedia databases are required to implement effective group support
systems. These would allow efficient intermixing of various types of artifacts, for example,
letters, memos, test results, models, handwritten notes, speech conversation, and so on, as
encountered for group communication in a management environment. Commercial products,
such as Lotus Notes, support such databases.102 There is a need to support workflows and
autonomous agents to support enterprisewide integrated management solutions that integrate
with business processes.120 There is now a growing consciousness of the need for a secure
cooperative management environment, particularly in view of geographically dispersed
enterprise locations and the mobility of management personnel.
We now discuss an architectural framework to support the previously discussed coop135
erative management requirements.
6.6.3. The Cooperative Management Framework
As discussed in chapter 3, a groupware system presents a number of challenges.

Therefore, a design strategy based on an existing system is likely to have a higher rate of
success than a totally new design. Hence, the illustrative implementation adopts an architectural framework based on an existing management platform, such as HP OpenView, IBM
NetView6000, Sun Solstice, Cabletron Spectrum, and so on, as described in chapter 2.
This section presents a discussion of the architectural aspects of a cooperative management system. Figure 6.9 shows a high-level view of the framework that integrates CSCW
and mobile/multimedia communications with integrated management platforms.
This framework consists of the following major blocks: native hardware/software, an
integrated management platform (and relevant instrumentation to access management information), multimedidmobile computing functions, groupware support, and management
applications with WWW-based user interfaces. The native heterogeneous environments of
emerging enterprise networks consist of different hardware (e.g., workstations and PCs),
different operating systems (e.g., UNIX, Windows, DOS, Netware), different communica-
118
tion equipment (e.g., hubs, bridges, routers), different databases (e.g., INGRES, ORACLE,
Notes), and different protocol suites (TCP/IP, SPX, AppleTalk, OSI).
This framework uses an existing integrated management platform that provides
complex software with support for OO programming and common management support
functions. These platforms provide well-developed management instrumentation including management communication protocols (e.g., SNMP) and standard MIBs. These
platforms also provide powerful topology-based GUIS.132 The platform uses a standard
object model, such as CORBA, for the interoperability of multivendor objects in a
management solution.93
Multimedia and mobile computing requires a number of performance critical functions
that are now evolving for various environments. 108 These would be accessible to applications/groupware through APIs. Shared media facilities for CSCW need these types of special
functions. Because such high-performance functions are not provided as part of management
platforms, they need to be implemented separately as shown in Fig. 6.7. Although existing
platforms provide some of these features in vendor-proprietary form, it would be better to
incorporate a standard model for interoperability purposes. The IMA has recommended a
CORBA-based object framework for multimedia functions.15 Researchers have identified a
number of such functions including an incremental client server (that communicates only
the status changes), and an intelligent broadcasting facility for a wireless mobile environment. 133
Valta and Jager168 have outlined the advantages of integrating a CSCW platform with
integrated management facilities. The illustrative architectural design suggests a new CSCW
Figure 6.9.
Architectural framework for cooperative management.
Chapter 6.
Design and implementation of a Cooperative Management System
119
layer on the management platform. This layer would allow various CSCW functions, such
as workflows, agents, and access control features to be developed and modified according
to the characteristics of the human group/organization using the system. These CSCW
applications would integrate various group support facilities (e.g., shared databases) with
the management platform facilities and group communication mechanisms. This layer may
also support WWW-based user interfaces.
The design of groupware application incorporates databases, agents, and different
communication mechanisms. This book is mainly concerned with the enterprise perspective
of this integrated management framework. Therefore, subsequent discussions concentrate
on the groupware layer of this framework (Fig. 6.9).
Various human roles interact through groupware and application support at this level.
Existing platforms provide powerful GUIs, but they do not provide any support for group
cooperation. Therefore, it is necessary to support features provided in a groupware platform,
such as Lotus Notes. Cooperative management applications can be implemented on this
groupware platform. A cooperative management application, such as a help desk running
over a groupware-integrated management platform, would provide a representative implementation to evaluate the cooperative management framework and the methodology for
cooperative management solutions.
The next section discusses an implementation strategy for this architectural framework
and a prototype implementation of a help-desk-based cooperative management application.
6.7. IMPLEMENTATION FRAMEWORK

The objective of this implementation is to serve as a proof concept only. This would
help to communicate the completeness of the CoMEN methodology to practicing network
managers. The discussion on the prototype implementation is presented as a case study.
First, it is necessary to select an integrated management platform, such as IBM
NetView/6000, HP Openview, Cabletron Spectrum, or the like and a CSCW platform, such
as Lotus Notes or and DEC Linkworks. This would be followed by the implementation of
a representative cooperative management application, such as help-desk-based trouble-ticketing.
Therefore, the overall strategy of implementation consisted of the following components: the selection of integrated management platform, the selection of a groupware
platform, and a generic help-desk-based application based on the previously mentioned
platforms to demonstrate a cooperative management framework for enterprise networks.
We now discuss the selection of a management platform and a groupware platform for
this project.
6.7.1. Integrated Management Platform Considerations
From the cooperative management perspective, the following platform features are of
particular interest:
1. Support for a Command Line Interface (CLI) to support the integration of a
groupware platform with a management platform.
120
2. A distributed object model (preferably standard-based such as CORBA).

3. Support for the integration of AI paradigms for the filtering and interpretation of
management information.
4. An OO management database that would be useful in handling multimedia management information.
6. A topology-based GUI to support various management functions.
The technology for management platforms is now evolving, and commercially available
platforms offer many of these features. Although any management platform with a networkbased CLI would have been enough for this prototype implementation, the illustrative design
used Cabletron Spectrum due to its availability in the research lab. A CSCW platform is
needed to realize the required awareness levels.
6.7.2. CSCW Platform Considerations
We needed to select a groupware platform that would supplement CSCW features on

the management platform described previously. The CSCW platform needed to interoperate
with the management platform while offering a common interface to the end-user. At this
level, some of the options were a system based on groupware platforms, such as Lotus Notes,
DEC Linkworks, and Microsoft Exchange. Lotus Notes was selected because of its availability in many enterprises including the organization under study.
Lotus Notes supported the following:
An incremental client-serverthrough selective replication
Multimedia visualization through Object Linking and Embedding (OLE) objects
An OO multimedia document database to implement flexible CSCW repositories
Mobile users through Notes mobile clients
A user-defined workflow through Notes macros
A variety of user interface tools, such as forms, buttons, menus, and OLE objects
A WWW-based user interface
These considerations prompted the use of Lotus Notes-based groupware and multimedia
platforms in order to develop a prototype to demonstrate the overall concept.
6.7.3. The Prototyping Environment
Figure 6.10 shows the integrated management environment in an enterprise, with

reference to the prototype. It consists of the following elements:
A Lotus Notes-based cooperative work environment on Windows 3.1/PC486.
A Cabletron Spectrum management platform of an ULTRIX 4.3/DEC 5000/240.
Chapter 6.
Figure 6.10.
121
A prototyping environment.
A variety of Notes supported group communication mechanisms, such as an Ethernet

LAN using the NETBIOS protocol, a TCP/IP-based WAN (static), and PhoneNotes
WAN with mobile wireless access.
Notes-based special computing functions, such as Microsoft OLE/Dynamic Data
Exchanger (DDE) to support a variety of media formats (text, audio, video, graphics,
etc.), and PhoneNotes-based mobile user support.
CooperativemanagementapplicationsimplementedasNotesdatabases(seeAppendixA).
We used Lotus Notes running on a PC/486 with Windows 3.1. Notes accesses Spectrum
information through its remote CLI. This would mean that the color graphic views of
Spectrum information are unavailable on the PC. This would be the case in a mobile
workstation. This arrangement was preferred because users would be able to distinguish
between the services offered by a GUI versus a text-based display. In short, the PC emulates
a mobile workstation for the prototype implementation.
6.7.4. Group Communication Specifications
As discussed in chapter 5, the right level of awareness support requires interaction-specific communication support. One scenario may have a number of types of interactions
requiring different types of awareness and communication specifications. This section
122
Figure 6.11.
Communication devices for Scenario 1.
illustrates the different types of communication requirements through a typical action

scenario with respect to the trouble-ticketing database. Figure 6.11 illustrates this process
by recalling the diagram of Scenario 1 from chapter 5.
In this case, the communication requirements may be summarized as follows: User U1
uses a standard telephone, user U2 uses mobile phone, and user U3 uses e-mail; the test
technician uses a mobile data device with a text interface; the change manager uses a mobile
cellular phone; and an NMC technician and the operator use network workstations with color
GUIs. These mechanisms are shown next to the roles in Fig. 6.10.
These communication mechanisms are supported in the prototype as follows:
The DECStation 500/240 is a 19 Color GUI device similar to that with an NMC
technician/operator. This display is provided to see if there is any loss of functionality
due to the text interface, in which case all management users would go through a
Notes user interface.
Mobile data interfaces and other text user interfaces are simulated by a PC/386
Windows-based Notes display.
PhoneNotes provides users with standard telephones or cellular phones to directly
communicate with a Notes-based cooperative management system.
This shows how group communication requirements can be defined for different role
interactions. These can be mapped onto the time-spacematrix shown in Fig. 6.6.
6.8.
DISCUSSION
Having described the groupware design, one can now compare the design with some of
the requirements generated during the analysis.In addition, the discussion covers the impact
of not implementing all features of the framework.
Chapter 6.
123
6.8.1. Relevance to Given Scenarios

This design of multiple Notes databases incorporates the following features of a typical
trouble-ticketing environment:
1. Coupling of information related to service changes and to fault management: This
is achieved by close linkages between the two databases, TT and CM. This strategy
promotes free discussion among all those concerned on various issues related to
problems. This is achieved by linking the two databases, TALK and KB.
2. The system implements a number of important and problematic workflows in this
environment: This includes the reassignment of calls, call escalation, knowledge
rule approval, change approval, and consulting an expert/knowledge base.
3. The system implements a number of group communication mechanisms: This is
done through mails created by users and by workflows. E-mails would work in both
LAN (NETBIOS) and WAN (TCPDP) environments. Multimedia documents have
support for OLE objects (text, video, sound, etc.). There are voice mails (static and
mobile) to remote users through the Phone Notes voice synthesis mechanism.
4. The system implements support for relevant integrated management features: This
is done through button-operated access to the Cabletron Spectrum Integrated
Management Platform that implements many integrated management facilities
including SNMP MIBs andprotocols. Spectrums Virtual Network Machine (VNM)
implements a Model-Based Reasoning (MBR) to cut down management traffic in
the network.
5. There is support for efficient client-serverrequired for mobile/multimedia communication: Notes version 4.0 supports Incremental Client-Serverthrough Selective
Replication. Data-in-Air (broadcasting) can be easily incorporated in this implementation by assigning one network port for broadcast data and by designing a
simple macro for data broadcasting.
6.8.2. A Complete Cooperative Management System
The previously described application framework realizes a generic help-desk-based
cooperative management system based on CoMEN. However, the solution of all cooperative
management problems would need to integrate a number of additional features, such as the
following:
Synchronous cooperation mechanisms including multimedia
Support for mobility of cooperating people
A real wireless communication infrastructure for broadcasting
Network and system simulators (OPNET)
Platforms supporting ODP standards (CORBA)
Diverse heterogeneous native computer and communication facilities/elements
A common integrated user interface
124
Full implementation of such architecture would require a substantial amount of additional

resources. However, it should be possible to evaluate the cooperative management framework with the implementation described in this chapter.
The next chapter discusses the formal evaluation of a cooperative management system
design as part of the CoMEN evaluation process. This will be involving an evaluation of the
cooperative management design by experts in enterprise networking.

This chapter has discussed a high-level conceptual design and prototype implementation
of cooperative management systems. Because the existing integrated management frameworks described in chapter 2 cannot support the required cooperative management features,
such as support for CSCW and mobile and multimedia communication, it was necessary to
define a new cooperative architectural framework. This was followed by a description of a
methodology for expressing cooperative design requirements for groupware integration.
Finally, this chapter discussed an implementation framework using a management platform
and Lotus Notes.
Having discussed the design and prototype implementation of a cooperative management system using CoMEN, it is now necessary to evaluate this design. The evaluation of
the design will help show the suitability of the design for the cooperative management of
enterprise networks. It will also help evaluate the overall methodology for cooperative
management presented in this book.
7
Evaluation
This chapter describes the strategy for the evaluation of the cooperative management
design and implementation, and hence the methodology for the development and deployment of cooperative management solutions (CoMEN). There is no standard methodology
for the evaluation of integrated management systems. This stage addresses the following
questions:
What should be the evaluation criteria for a cooperative management system?
Given a proof-of-concept implementation, how does one evaluate the cooperative
management framework in an enterprise environment?
What do the results of evaluation suggest regarding the effectiveness of CoMEN?
Although there are a number of integrated network management systems in use today, there
has been little work reported on the comprehensive evaluation of such systems. Meyer and
associates107 described some work on the evaluation of network management platforms.
Czarnecki29 described evaluation criteria for management information models used in the
instrumentation part of an integrated management framework. However, there is no reported
work on the holistic evaluation of an integrated management system. This chapter presents
a hierarchical model for the evaluation of integrated management systems.137 This uses
inputs from the evaluation methodologies in a number of disciplines, such as telecommunications85 and software engineering.12
The evaluation methodology uses a template for the reporting and analysis of information for the evaluation of integrated management systems. First, an evaluation is undertaken
on the basis of the enterprise networking scenarios presented in chapter 5. Then, a heuristic
evaluation is carried out by a contextual interview of enterprise networking experts from
different service industries using help-desk-based network support to elicit some feedback
on the framework and the cooperative management methodology.39,71 Finally, there is an
analysis and conclusions are drawn from these interviews.
7.1. EVALUATION METHODOLOGY

Whereas most of the traditional evaluation in the area of networks and systems give
attention to quantitative network related factors, such as throughput, delay, response time,
125
126
and load, cooperative management is more concerned with the human and group activity
measures, such as usability and usefulness for workgroup computing. Hence, the methodologies are different in these two cases. Traditionally, network/service performance evaluation has been done either through simulation or by collecting data on live networks.
Statistical models have been applied to arrive at generalized quantitative performance
figures. The same methodology will not work for CSCW systems because of the difficulty
in generalizing experimental results, as discussed in section 3.3.1. Besides, it is difficult to
apply known quantitative system models to predict human behavior due to the unpredictable
nature of group behavior, as mentioned in section 3.3.1.
Evaluation is concerned with gathering data about the usability of a design or product
by a group of users for a particular activity within a specified environment or work
context. 128 This is a general definition of evaluation relevant to this work. The method of
evaluation depends on the reasons for doing evaluation. Preece and associates defined four
reasons for doing evaluations:
1. Understanding the real world: This attitude pervades various stages of this methodology that helps investigate how users use technology in enterprise management
workplace and how designs of tools/artifacts can be improved for cooperative work.
This chapter is concerned with the evaluation of a cooperative management framework and methodology. A few representative scenarios for enterprise management
were identified in chapter 5. A cooperative management framework needs to solve
problems highlighted with respect to these scenarios.
2. Comparing designs: This allows the comparison of the new frameworks and designs
with existing integrated management frameworks with respect to the requirements
of cooperative management. A set of evaluation criteria are needed for this purpose.
3. Engineering towarda target: In this case designers have a target, which is expressed
in some form of metric, and their goal is to make sure that their design produces a
product that reaches this goal. This may be the objective in the next phase of the
methodology.
4.
Checking conformance to a standard: Because there are no standards for the

evaluation of cooperative management, this aspect is not relevant in this project. 1 28
Once the objectives of evaluation are known, one can select a method for evaluation. Preece
and associates128 categorized these methods as the following: collecting users opinions,
experiments and benchmarking, interpretive evaluation, and predictive evaluation. The first
method finds out about users attitudes toward a product or a system by using questionnaires
and interviews. The second method is based on collecting data on system usability in a
controlled laboratory experiment. Usability parameters are defined later in this chapter
(section 7.2.4). In the third method, data is collected in informal and naturalistic ways (e.g.,
from a real operational system) with the aim of causing as little disturbance to users as
possible. The kinds of methods that belong to this category include participative and
contextual evaluation (from HCI) and ethnography (from anthropology). The aim of the
fourth kind of evaluation is to predict the types of problems that users will encounter when
Chapter 7. Evaluation
127
using a system without actually testing the system with users. This may be done by using a
modeling technique such as keystroke analysis or by getting experts to review the design to
discover the problems that typical users are likely to experience.
All four types of evaluation methodologies are relevant in this project. Users opinions
need to be collected with respect to certain evaluation metrics. Interpretive evaluation can
be carried out using a contextual interview of users with the prototype. Predictive evaluation
would involve heuristic evaluation of CoMEN by a few experts.
The evaluation was carried out through a contextual interview (around the prototype)
of experts with substantial experience in managing real enterprise networks. This was
followed by a predictive evaluation of the framework with respect to real-life enterprise
management scenarios described in chapter 5.
Chapter 6 has produced a high-level design framework and a prototype implementation
of a generic cooperative management system for an enterprise network. This will be used in
the evaluation methodology. This is achieved by conducting a laboratory interview of experts
in this area from the industry. These people are subjected to an informal interview on the
basis of the architectural framework and the prototype implementation. This, however,
necessitates certain evaluation criteria
Because there are no standard evaluation criteria for integrated management systems,
first it is necessary to formulate a new framework for the definition of evaluation criteria for
integrated management systems. This framework is then applied to the project. A basic
questionnaire was developed for experts on the basis of evaluation criteria selected for
cooperative management of enterprise networks.
The next section presents the formulation of evaluation criteria for the management of
enterprise networks.137
7.2. EVALUATION CRITERIA

An integrated management system incorporates technology inputs from a number of
disciplines, namely the following: telecommunication networks; computers (hardware and
software); HCI and CSCW; and AI.
Telecommunication service providers have well-defined network performance criteria,
such as availability, Bit Error Rates (BER) and their variability, and distortion for various
types of communication media. Many of these are considered in the definition of Internetstandard MIBs.142 ISO has defined QoS parameters, such as delay, throughput, jitter, error
rates, and so on for OSI protocols. Whereas standards bodies are now working on defining
a standard methodology for defining, categorizing, implementing and testing QoS,85 researchers are grappling with the problem of ascertaining the correlation between MIB
variables and network/service end-to-end parameters that affect service-level agreements
between customers and service providers. Whereas these are defined for a wide range of
applications/services, integrated management can be seen as a class of services.
Designers of computer hardware, operating systems, and utilities have traditionally been
concerned with computer performance criteria, such as, utilization of memory/CPU/I/0 and
throughput/response time. These are reflected in the definition of systems management
information defined by the Internet [RFC1514] and the DMTE98 Recent developments in
distributed systems have significant impact on the emerging enterprise network and systems
128
management solutions.110 Researchers in software engineering are working on evaluation

metrics for software development from the perspectives of users, developers, and managers.12
HCI is one of the fastest growing areas of research with inputs from a number of diverse
disciplines, such as computer science, sociology, psychology, anthropology, and so on.
Evaluation criteria in this area are concerned with human and organizational perception of
integrated management systems. These are mostly subjective parameters, such as security,
integrity, flexibility, usability, and so on.39,126
Many network management systems incorporate AI techniques, such as expert systems,
model-based reasoning, case-based reasoning, and so on.54,101 Most of these techniques are
being applied to problems such as fault diagnosis and resolution. The criteria in this case
involve the computation of the probability that the AI system can correctly diagnose the given
class of network/service problems in an enterprise network environment.
Therefore, there are no universally agreed-on criteria for the evaluation of integrated
management systems. This section presents a discussion of evaluation criteria being explored
in these diverse areas, with a view to arriving at criteria for evaluating enterprise management
systems. This discussion is based on the model of integrated management (presented in
chapter 2), consisting of the following criteria: instrumentation-level, platform-level, applications-level, and the human user level.
Instrumentation-level criteria are concerned with parameters for evaluating management communication protocols and management information variables (MIBs) related
to remote managed devices and systems. In this class, one considers issues, such as types
of accessible management information, efficiency of management communication, and
so on.
Platform-level criteria are concerned with support for heterogeneous environment (e.g.,
CMIPBNMP) and management infrastructure services (e.g., naming and directory setup,
access control, object management, GUI, AI techniques). Therefore, important issues would
be scalability, flexibility, usability, security, functionality, and so on.
Criteria at the application level would be concerned with many of the issues stated
previously in addition to management application-level factors, such as performance,
efficiency, distribution transparency, and so on. We need to add to this some evaluation
criteria at the human user level to cater for cooperative enterprise processes in an
organization.
The human user level is concerned with the evaluation of parameters related to the
usability and acceptability of an integrated management system to various human roles in
the enterprise. Some of such parameters are ease of use, ease of learning, visualization
support, and so on.
7.2.1.
Evaluation Criteria at the Instrumentation Level
As discussed earlier, this stage is concerned with the system capabilities in accessing
management information (i.e., flexibility/efficiency of access). Depending on the management task at hand, the user may specify the following types of evaluation criteria: the
management information level or the management communication protocol level.
Czarnecki and associates29 have proposed a scheme for the evaluation of management
information structure (OO vs. Table-driven) lists of objects, and types of managed de-
129
vices/systems supported (types of MIB available). Depending on the type of network/devices, they can be classified as type of network (e.g., Internet MIB-II for TCP/IP networks),
type of media access (e.g., Ethernet/Token Ring MIB), type of application (e.g., Internet
Service MIB/Mail Monitoring MIB), and special features (e.g., Remote Monitoring
(WON) MIB, Mobile MIB).
Management communication protocol can be categorized in terms of definition options
(e.g., CreateDelete, SNMPv2 Conformance Statements), application layer protocol (e.g.,
CMIP vs. SNMP), underlying protocol stack (e.g., Common Management Information
Protocol (CMIP) over Logic Link Control Layer (LLC), SNMP over IPX), data collection
strategy (polling vs. event-driven), command confirmation (confirmed vs. unconfirmed,
connection oriented vs. connectionless), flexibility of access (e.g., CMIP scoping and
filtering), robustness (ability to retrieve information from remote devices when the network
is falling apart), authentication and access control (e.g., SNMPv2 security), and efficiency
(e.g., implementation size, speed of execution, load on underlying networks).
7.2.2. Evaluation Criteria at the Platform Level
Metrics at this level are concerned with the evaluation of platform support for enterprise
network and systems management systems.106 Parameters can be categorized as follows:
management communication level, management database level, Distributed Processing
Environment (DPE) level, and management services level. Management communication at
this level is concerned with issues, such as support for multiple management communication
protocols (e.g., XMP API for SNMP/CMIP) and support for vendor proprietary protocols
(e.g., DECNet, DBM SNA). Management database-level parameters are database structure
(OO/Relational/Flatfile), database access (proprietary, standard SQL support), and database
access performance.
Distributed processing issues are support for open standards (e.g, CORBA), support for
heterogeneous object models (e.g., OMG Object Management Architecture (OMA) and ISO
GDMO), and support for DPE management.161 Management services-level parameters are
scalability (e.g., number of nodes managed), efficiency (polling rate, number of traps
processed, load placed on the underlying network), security features (e.g., multilevel access
control), and functionality with APIs (e.g., X/Open Object Management (XOM) API,
Model-based Reasoning, and ISO General Relationship Model (GRM)-based relationship
modeling).
7.2.3. Evaluation Criteria at the Management Application Level
Metrics at this level evaluate support for distributed management functions and interoperability of heterogeneous management solutions. This is a new area with inputs coming
from distributed system performance, software engineering, and telecommunication networks engineering.12,107 Application-level parameters can be categorized as follows: support
for heterogeneous platforms, distribution transparency, application functionality, and performance. Support for heterogeneous platforms can be at the object model level and at the
operating system level. Distribution transparency can be measured in terms of the conformance to evolving standards, such as RM-ODP,CORBA, and TINA. Application functionality is best measured through the support provided for OSI standard functions (Fault
130
Management, Configuration Management, Accounting Management, Performance Management, and Security Management). In addition, there are a number of issues, such as the
support for customization and support for evolving network user services (e.g., multimedia
services and mobile services).
As discussed earlier, the performance of networks and systems is traditionally measured
with quantitative parameters, such as response time, memory requirements, and load on the
distributed computing (network and systems) infrastructure.
This is only an illustrative list, and it is not meant to be exhaustive. These parameters
have been defined with respect to the integrated management framework. However, it is
possible to define these parameters with respect to some other model, such as TMN
hierarchy.
7.2.4.
Evaluation Criteria at the Human User level
This aspect is quite significant for enterprise management in view of the growing
scarcity of skilled integrated management professionals and the need for such people to
cooperate within and across organizations.134 This draws inputs from CSCW and from
HCI.33,39 The complexity of the task of visualization of large amounts of management data
with respect to abstract management models underscores the importance of virtual environments.7 These parameters can be categorized as follows: usability, groupware support, and
visualization. Some examples of usability parameters are ease of learning, ease of use and
flexibility, documentation support, and conformance to ISO Usability Standards. Awareness
parameters are defined as the level of awareness, focus (higher focus of a group member
enables that person to know more about another members activities), and nimbus (higher
nimbus of a group member enables a group member to publicize more information about
his/her own activities to others in the group).7
Evaluation of groupware support is now a subject of substantial research. Group
decision support systems are now being defined in terms of shared electronic workspace,
shared pointers, and available repositories. Group communication support systems may
be defined and compared according to communication synchronism (asynch-e-mail,
synch-conference), or type of communication network (e.g., static, mobile, and multimedia).
Visualization can be evaluated with respect to visual models that are used for management information presentation (e.g., TMN), hypertext-hypermedia techniques for browsing
of management information, and multisensory user interfaces (e.g., virtual reality).
Each of the previously mentioned categories would need some measure of implementation experience for procurement purposes. The above list is by no means exhaustive.
However, this gives an indication of the complexity of the task of defining standard evaluation
criteria for integrated management systems.
7.2.5. Evaluation Criteria for Enterprise Management

To summarize the preceding sections, Fig. 7.1. shows a hierarchical model for the
definition of evaluation criteria for enterprise management. Management applications vary
widely depending on the type of network/system/services, organization, user, and other
environmental factors. Hence, it is not feasible to define a standard set of measurement
131
Figure 7.1.
Enterprise network management evaluation criteria.
parameters for the evaluation of all integrated management systems. However, it is possible
to select a subset of evaluation criteria for any specific enterprise management systems or
for parts thereof. These evaluation criteria can lead to the formulation of experiments or
questionnaires for evaluation, depending on the method of evaluation.
We need a flexible framework for the description and evaluation of integrated
management systems from an enterprise perspective. This study is mainly concerned
with the human cooperation aspect of enterprise management. Therefore, an evaluation
of a cooperative management framework for enterprise networks will involve parameters
at these levels: the enterprise management level, the human user level, and the groupware
support level.
The next section formulates a framework for the specification and recording of the
evaluation criteria.
132
Table 7.1. Evaluation Criteria for CoMEN

Name
Categorized As:
Ease-of-learning
Usability
Ease-of-use
Usability
Support for standard

user interface
Usability
Documentation support
Usability
Group decision support
Groupware
support
Group communication support
Groupware
support
Visual models
Hypertext/hypermedia/support
Visualization
Visualization
Multisensory user in- Visualization

terfaces
UI implementation
on experience
Visualization
Defined As:
Effort required by a
new user to learn
its operations
User effort required
for fault-free
operation
Whether any user
interface standard
(e.g., Motif) is
supported; if yes
what they are
Level of userfriendly
documentation in
text/hypermedia
Whether any group
decision support
systems are
supported; if yes
what they are
Whether any group
communication
support systems
are supported; if
yes what they are
What visual models
are supported for
the presentation
and control of
enterprise network
behavior
What hypertext/
hypermedia
facilities are
supported to assist
in the browsing of
management
information
Whether any
multisensory user
interfaces (e.g.,
ear, touch) are
supported; what
they are
How much
implementation
experience exists
(years, installations); quality
Type
Quantified As:
Subjective
Graded user opinion

(scale of 1-10)
Subjective
Graded user opinion

(scale of 1-10)
Boolean;
Enumerative
Boolean value with

values true or
false
Subjective
Graded user opinion

(scale of 1 - 10)
Boolean;
Enumerative
Boolean value with

values true or
false; list
Boolean;
Enumerative
Boolean value with

values true or
false; list
Enumerative
List
Enumerative
List
Boolean;
Enumerative
Boolean value with

values true or
false; list
Number;
Subjective
Number/fractions;
Graded user
opinion (scale of
1-10)
133
Table 7.1. Continued
Name
Categorized As:
work service
Response time
Memory requirements
Type
Defined As:
Is there support for

Functionality new network
services (e.g.,
Support for new net- Application
mobile
multimedia); if
yes what they are
Application
Average response
Measurable
Performance
time for a set of
criticalcommands
Application
Performance
Load on the distrib- Application

uted infrastructure
Performance
to execute
Memory
Quantified As:
Boolean;
Boolean value with
Enumerative values true or
false;list
Measurable
requirements for
the application
software to execute
System load in terms Measurable
of network
bandwidth
required at all
Quantitative value in
time (seconds)
Quantitative value
(megabytes)
Quantitative values
(Mbits/sec)
interfaces
7.3. INTEGRATED MANAGEMENT EVALUATION FRAMEWORK

There has been substantial work on the formulation of metrics for the evaluation of
software systems.12 However, they do not address the specific needs for integrated management. The ISO Basic framework for QoS addresses many of the networking and networked
service related issues related to enterprise management. Therefore, this evaluation framework is based on QoS-Basic Framework."85
In this framework the evaluation parameters are defined as quantitative items (subjective
or measured). The user specifies these and they need to be monitored by some means
(real-time or off-line). The parameter values may include not only numbers (e.g., boolean,
integer, real, complex numbers, etc.), but also vectors, matrices, ranks, and names of states.
Efforts are required to achieve maximum consistency of definitions across different parameters by defining generic parameters and then specializing them to particular environments
and deriving others from them. A template is now defined for defining and evaluating an
integrated management system.
7.3.1. Template
A definition of an evaluation parameter needs to include the following information:
Name of the parameter
Defined As: explains its purpose and intended usage
Type: subjective/measurable/enumerative
134
Quantified As: how the parameter is quantified, giving units in which values are
expressed
Categorized As: into which broad category the parameter falls
Derivation: if there is a derived parameter

Optional further information
Each of the criteria listed in the previous section can now be described in the previously
described template. For example, Response Time of a management application can be
described as follows:
Name: Response Time
Defined As: an average of time taken in getting a response after a command is given
Type: Measurable
Quantified As: time value in seconds
Categorized As: Application Performance
Derived Parameter: Application throughput
This type of template is useful for the recording and subsequent automated analysis of
evaluation data.12The next section discusses the application of this evaluation framework to
CoMEN.
7.3.2. Evaluation Criteria for Cooperative Management
There has been some work on the evaluation criteria at the instrumentation and platform
levels in integrated management systems.106,107 There has also been a substantial amount of
development at the instrumentation and platform levels in modern integrated management
systems, such as Sun Solstice, IBM NetView/6000, HP OpenView, Cabletron Spectrum, and
so on. This is a growing area with most of the research being done by vendors of such
platforms. However, not much has been done on human cooperation aspects of enterprise
management.
Some of the major concerns not addressed in the emerging enterprise networks include
support for cooperative corporate processes, user mobility, and multimedia visualization.
There are no publicly available evaluation criteria for such issues. This considers evaluation
parameters mainly relating to levels of human users (section 7.2.4). The results are summarized in Table 7.2.
This section has shown how this evaluation template can be used to specify evaluation
criteria for cooperative management of enterprise networks. However, the same framework
can be used for the evaluation of any other type of integrated management system.
7.3.3. Evaluation Steps
Both predictive and interpretive methods of evaluation are used. The steps are as follows:
checklist evaluation, followed by heuristic evaluation. The checklist evaluation carries out a
checklist with boolean and enumerative parameters of the framework with respect to the
135
Table 7.2. Architectural Feature Evaluation for CoMEN

Name
Categorized As:
Support for CORBA Platform
High performance
computing functions
Platform
Support for standard Usability

user interface
Group decision sup- Groupware

Port
support
Group communication support
Groupware
support
Visual models
Visualization
Hypertext/hypermedia support
Visualization
Multisensory user in- Visualization

terfaces
Defined As:
Type
Value
Whether the
Boolean
FALSE
platform supports
the OMG
CORBA object
model
Whether the
Boolean;
TRUE; Spectrum
platform supports
Enumerative
Mobile phone
mobile/multimedia
interface for
alarms and
computing
functions; if yes,
messages, Notes
what they are
selective
replication
Whether any user
Boolean;
TRUE; Motif,
interface standard
Enumerative
Microsoft
(e.g., Motif) is
Windows 3.1
supported; if yes,
what they are
Whether any group Boolean;
TRUE; Notes
decision support
Enumerative
Databases, Macros
systems are
supported; if yes,
what they are
Whether any group Boolean;
TRUE; e-mail, static
communication
Enumerative
and mobile
support systems
phones, WAN
are supported; if
yes, what they are
What visual models Enumerative
Spectrum GUI
are supported for
supports
the presentation
topological
and control of
network maps
enterprise
network behavior
What hypertext/
Enumerative
Notes supports
hypermedia
hypertext/
facilities are
hypermedia
supported to
through Microsoft
OLE/DDE objects
assist in the
browsing of
management
information
Whether any
Boolean;
FALSE
multisensory user
Enumerative
interfaces (e.g.,
ear, touch) are
supported; if yes,
what they are
136
required features and scenarios described in chapter 6. The heuristic evaluation is done
through a contextual interview of experts in integrated management using the prototype
implementation. In both of these steps, evaluation parameters are expressed using the
framework described in section 7.3.1.
7.4. CHECKLIST EVALUATION

This phase carries out evaluation for the following features: management framework
architectural features and cooperative management scenarios.
7.4.1. Architectural Features Checklist
First, this carries out a checklist of major architectural features supported in this
implementation. This is shown in Table 7.3. The chosen implementation framework supports
almost all of the required features.
7.4.2. Application Scenarios Checklist
This phase provides a checklist of support provided for the scenarios described in
chapter 5. There is a mapping of the process graphs for the scenarios to this implementation
based on Notes databases. Chapter 6, section 6.4.3 describes the general deficiencies and
generic schemes used to overcome them for cooperative management in the organization
under study. This section presents a discussion on how various roles and interactions are
supported with the new cooperative management framework.
Figure 7.2 shows the interactions of various human roles with respect to relevant Notes
databases and group communication functions. There are two types of repositories, namely
the following: Discussion database 1 supports e-mail-based discussion amongst various
parties involved and Change operation database 1 supports the performance of the upgradation job. Various human roles perform their interactions using these repositories and various
group communication mechanisms. All user interactions depend on telephone-based or
WAN-based e-mail (a). All operator interactions are through the help desk system and are
static LAN-based (b). Interactions 6 and 11 are static LAN-based for NMC people and
WAN-based for remote people. Interactions 1, 9, and 10 for the technician and 1,9, and 10
for test technician are mobile e-mail-based (d).
In scenario 1, the delay is caused by the inability to track an expert/user at the appropriate
time. Therefore, more and more users should be encouraged to use mobile e-mail systems
on Public Mobile Data Networks. In addition, it may be necessary to use desktop conferencing among roles B, C, and U at the time of system testing after upgradation.
Problems with the existing system are as follows:
1. Users may not have facilities to share the Notes databases mentioned here. However,
it should now be possible to provide static internet e-mail connectivity to all users.
2. The change impact statement is prepared manually and is vulnerable to omission of
some potentially affected parties. Hence, it is necessary to devise some automatic
137
Table 7.3. Heuristic Evaluation of CoMEN

Question
How happy are you
with existing network management
systems (rate on
scale 1-10,10 =
most)?
Categorized As:
Enterprise
Management
(Level 1)
Do you think the co- Enterprise

Management
operative management framework is
(Level 1)
likely to be useful
in integrated rnanagement in your
organization, and
why (enumerate
and describe)?
Are the problem sce- Enterprise
narios relevant to
Management
your organization?
(Level 1)
Which ones are
most applicable?
Does the demonManagement
strated application
Applications
framework support
(Level 2)
the type of helpdesk activities in
your organization?
How important is
Management
Applications
Change Management (rate on scale
(Level 2)
of 1-10,10 =
most important)
How important is
Management
Applications
Problem Management?
(Level 2)
Expert 1
Expert 2
Expert 3
7, Network
management
needs far
greater
integration
with network
operations
3, Help-desk
3, Does not cover
relative to
large enough
existing design
part of
aims, good (6),
network, or
overall
provide
satisfaction is
specific info to
low (3)
pinpoint the
problem
Yes, because it
Yes
Possibly, I may
will provide a
have a firm
means to link
view on this
network
after the
operations with
implementation
management
of HP
OpenView in
our
organization
All
0, 1,2,3,5
1,2,3,5
Yes
Yes
Yes
8, Very important 8, Very important.

We have strict
change control
policies
10
10
10
Yes
Do you feel a short- Human User
age of required
Level (Level 2)
skills in Enterprise
Network Management? (yes/no)
Yes
Yes
Do you think the sup- Human User

Yes
port for human coLevel (Level 2)
operation
necessary in enterprise network management? (yes/no)
Yes
Yes
(continued)
138
Table 7.3 Continued

Question
Categorized As:
Is it possible to describe the roles

and their activities
in your help-desk
application?
(yes/no; Why?)
What are the most
difficult parts in
the usability of the
given user interface on PC/Notes?
What about the loss
of visual functionality due to loss of
dynamic GUI in
PC/Notes? Is it acceptable (scale of
1-10, 10 = mostly
fine)?
Do you think support
for multimedia
visualization is important for integrated
management in
your organization,
and why? (enumerate and describe)
Do you think support
for mobility is important for integrated management in your organization, and
why? (enumerate
and describe)
Expert 1
Expert 2
Expert 3
Human User
Yes
Level (Level 2)
Yes
Yes
Usability Level
(Level 3)
None, user
friendly
interface
None, better than

some standard
help-desk
products
None
Usability Level
(Level 3)
9/10, not too

8, Not important
much of an
issue, 99%
troubleshooting
done without
GUI
Visualization
Multimedia (data Possibly
Level (Level 3)
+ audio) is
being used in
integrated
management
and any
enhancement
would aid
productivity
Group
Yes, expertise is
Yes, mobility of
Communication
with a limited
people
Support Level
set of people,
(Level 4)
who are mostly
mobile
8, Mostly okay
Yes, certainly;
graphics and
text are needed
to represent
most problems
Yes, technical
people are
more highly
relied on as
systems
become more
complex
cross-checking algorithms for this purpose. The problem of omissions exists in some
other scenarios as well.
3. Although it does not take much time to affect a change, it may lead to some severe
problems if all parties do not stick to the procedures. It may be necessary to devise
interlocks to prevent such situations.
4. Often there are problems after a change because of pre-existing nondocumented
status or some major technical problems. In this case, experts need to be
contacted quickly and they require efficient mobile computer-based solutions to
139
Figure 7.2. Group interactions in Scenarios 1, 2, and 3.
provide help within a short time. Such experts are usually very busy with multiple
problems.
5. Existing systems do not provide any mechanism to check human errors, such as
omissions of certain parties in a group communication process. Consequently costly
mistakes occur.
6. Although existing systems provide support for powerful GUIs, often, costly mistakes are made in allocating a problem to a particular user group.
Scenarios 2 and 3 are special cases of Scenario 1, highlighting the need to add new roles of
experts to solve the postoperative problems in changes. These are added as shaded arrows
to the Scenario 1 diagram. There is also a need to have a reliable change operation database
system. In addition, a new thread (postoperative discussion) is added to the discussion
database.
New interactions have been added to cater to Scenarios 2 and 3. Users report strange
problems through a static WAN (Interaction 12). Experts, technicians, and remote test
technicians communicate through a discussion database, using mobile WAN interfaces
(Interactions 12, 15). In-house experts use mobile LAN interfaces to check color GUIs of
an integrated management platform (Interaction 14) from a change operation database.
Although the diagram shows all communication through Notes databases, some interactions
(e.g., 14) will need to have access to a management platform database as discussed in the
system design aspects in chapter 6.
Advantages of this system are the following:
1. Notes databases and macros allow quick implementation of cooperative change
management applications with required features, such as mail-enabled operation,
shared databases, workflows, and so on. Proper workflow design can avert disasters
140
like Scenario 2. Whereas people in a real organization move often from one place
to another, the makeup of groups also keep varying. Therefore, acommon automated
repository is required to handle such changes in a foolproof manner. This is expected
to alleviate problems 1 through 3 and 5 in the previous list.
2. Notes gateways exist for various static WAN/LAN standards, such as TCP/IP, IPX,
and so forth. Hence, it is possible to provide asynchronous cooperation for all of the
roles shown in the previous scenarios.
3. However, Notes does not support synchronous cooperation mechanisms, such as
multimedia conferencing. The support for mobile LAN/WAN communication will
require certain specialized solutions. These issues are required for solving Problem
4 (and partly Problem 6) and are considered in the next level of design.
4. Spectrum MBR is expected to alleviate Problem 6 by reducing trouble-tickets, In
addition, many passive objects can be given human properties; for example, aura,
focus, and nimbus.7
In the case of Scenario 4, the solutions are similar to those described in the previous
case, except that a new security impact Notes database has been added (Fig. 7.3). This helps
in checking security holes and assists in the preparation of the security impact statement.
Scenario 5 has roles and interactions similar to previous cases except that a new Notes
capacity planning database has been added to store results and information relating to
capacity planning.
This scenario may require the integration of network performance simulators with a
management platform. In addition, multimedia visualization tools would be required to help
a planner correlate management information with various conceptual models for management (e.g., TMN).
Figure 7.3.
Group interactions in Scenario 4.
141
7.5. HEURISTIC EVALUATION

This is an evaluation of the cooperative management framework and methodology
CoMEN. This evaluation involved experts in network operations and management from a
number of service business sectors, such as telecommunications, higher education, and
banks. It consisted of separate interviews of each of these experts by the researcher. Each
interview is conducted in two stages: In the first stage, the researcher presented his or her
methodology and framework to the expert. In the second stage, each interviewee was invited
into the research lab where the prototype implementation was demonstrated. The first stage
lasted for about an hour during which time the expert got an idea the overall methodology
and the framework/methodology of CoMEN. In the second-stage meeting (lasting an hour)
the interviewer first summarized user opinions for various scenarios and presented a unified
analysis for all these. Then the researcher explained the framework and the role of this
framework in solving the problems to the expert.
The demonstration consisted of the following steps. First, the researcher presented the
design with respect to the major deficiencies in the support of cooperative management in
the existing framework for integrated management. Then the researcher enumerated the
Notes databases in the prototype implementation and explained their features. This was
followed by a demonstration of automatic workflow design and construction, especially
mail-enabled applications. Then the researcher showed a quick customization of workflows.
The researcher then showed the differences in the user interfaces in a Spectrum GUI and in
a text-based interface for Notes used for cooperative management. Next, the expert was
shown access to external repositories, such as Spectrum using buttons. Various group
communication mechanisms were simulated.
Finally, each expert was asked to answer a questionnaire incorporating questions related
to this project. Many of these questions led to long discussions between the researcher and
the expert. The main points of these discussions were recorded. In view of the evolving nature
of evaluation criteria for enterprise management, a generic questionnaire has been formulated
to check the assumptions and the validity of solutions in view of widely varying requirements
in these industries.
7.5.1. Questions Addressed
This study concentrated on variables relevant to an enterprise perspective on integrated management, such as points related to organizational processes, human factors,
and overall company business perspectives. In view of the large expected structural
variations in different organizations, it is necessary to take a top-down, flexible approach
to these interviews.
The idea of expert interviews is to ask a general set of questions that address issues at
various layers in the hierarchical evaluation criteria shown in Fig. 7.1, Here are some sample
questions at each of these levels:
1. Enterprise Management (Level 1)
Are you aware of any methodologies for integrated management solutions?
(Yes/No)
142
Do you think this methodology is likely to be useful in enterprise management,

why? (Enumerate and describe)
Do you think the cooperative management framework is likely to be useful
in integrated management in your organization, why? (Enumerate and describe)
In what way could this framework be improved for better productivity in your
organization? (Enumerate and describe)
Are the scenarios described relevant to your organization? (Enumerate applicable
ones)
Did you face problems similar to ones described in these scenarios? (Yes/No,
Describe)
Are there any scenarios that you would like to add to what we have considered?
(Describe)
Would you like to add any points to the evaluation of this methodology?
(Enumerate and describe)
What will be the cost repercussions on integrated management if these features
are used? (Enumerate and describe)
2. Management Platforms Level (Level 2)
Do you use any integrated management platforms? What are they? (Enumerate
and describe)
3. Management Application Level (Level 2)
Is there a trouble-ticketing/help-desk-based management for networks in your
organization? (Yes/No)
Does the demonstrated application framework support the type of help-desk
activities in your organization? (Yes/No, Describe why)
How important is Change Management? (Rate in a scale from 1-10, 10 = most
important)
How important is Problem Management? (Rate in a scale from 1-10,10 = most
important).
4. Human User Level (Level 2)
Do you feel a shortage of required skills in Integrated Management? (Yes/No)
(If yes what should be done)?
Do you think that support for human cooperation is necessary in enterprise
network management? (Yes/No)
Is it possible to describe the roles and their activities in your help-desk application? (Yes, No, Why)
5. Groupware Support Level (Level 3)
Does your organization use any tools for human cooperation (groupware) in
network management? (Enumerate and describe)
143
6. Usability Level (Level 3)

What are the most difficult parts in the usability of the given user interface on
PC/Notes?
What about the loss of visual functionality due to loss of dynamic GUI in
PC/Notes? Is it acceptable? (scale from 1-10, 10 = mostlyfine)
7. Visualization Level (Level 3)
Do you think support for multimedia visualization is important for integrated
management in your organization, and why? (Enumerate and describe)
8. Group Communication Support Level (Level 4)
Do you think support for mobility is important for integrated management in your
organization, and why? (Enumerate and describe)
Is mobile data communication expected to be more useful than cellular phones
and pagers in integrated management, and why? (Enumerate and describe)137
It may be noted that many of the questions are general and they allow experts to give opinion
in an unrestricted manner. It may also be noted that these questions are not complete for an
evaluation for a questionnaire-based survey. These questions form the basis for discussions
for an interview with experts and illustrate the evaluation stage of the methodology, CoMEN.
This section presents a summary of the feedback from experts.
7.5.2. Background of Experts
Because the heuristic evaluation is critically dependent on a few selected experts in this
area (management of enterprise networks), it is important to make sure that these selected
experts have had hands-on experience of designing integrated management systems and
processes in a business environment. These people need to be experienced in both the
technical and the management aspects in the enterprise.
We selected experts with more than 10 years of hands-on experience in the evolving
enterprise networks in each of the three business sectors. Each of them has had several years
of experience in the operations and management of corporate computer communication
networks. Each of them has also been a keen student of this fast changing technology of
distributed enterprise networking technology. However, there are major variations in the
organizational businesses and networking environment of their present employers. These are
summarized as follows.
7.5.2.1. Expert 1
This person works in a large telecommunication carrier as a specialist in the integrated

management center. He is primarily concerned with the data networking business of this fast
growing organization. He has previously worked on the planning and deployment of
computer communication networks in a Fortune 500 multinational corporate organization.
His present organization has a large network with more than 500 subnets, more than 10,000
nodes and interfaces, nearly 400 routers/intelligent hubs, and 225-X.25 packet switches. This
144
is a heterogeneous system with protocols, such as TCP/IP, DECNet/OSI, AppleTalk, and

Local Area Transport (LAT).
7.5.2.2. Expert 2
This person works in the organization providing networking services to Australian

universities. He is concerned with the planning and deployment of a state-of-the-art networking infrastructure to support the ever-growing demand for internet and related services in
various universities. Previously he was responsible for the operations and management of
the multisite, multiservices, multimedia communication network of one of the fastest
growing Australian universities. His university has approximately 100 subnets, 50 routers/switches (ATM, X.25), and 1,000 nodes and interfaces. This is a heterogeneous system
with protocols, such as TCP/IP, Novell NetWare, AppleTalk, OSI, and so on.
7.5.2.3. Expert 3
This person is the manager (Distributed System Software) in one of the largest Australian banks. His group is responsible for the planning, development, and deployment of a
networked software infrastructure in this multisite, multiservices, mission-critical enterprise
network. His group is responsible for the operating systemshetwork operating environment
of the bank, consisting of VAX, UNIX, AS400, NT, and Banyan VINES PC network
operating systems. The Banyan VINES environment is by far the largest of these environments with over 2,000 nodes.
7.5.3. Summary of Results

We present a summary of the comments of each of these experts with respect to various
levels of evaluation criteria and questions listed in section 7.2.
7.5.3.1. Enterprise Management (Level 1)
As expected, none of the experts had heard of any methodologies for integrated
management solutions. This is because there isnt any such methodology. All of them felt
that a methodology was necessary and that ours was a good proposal. None of them was
happy with existing integrated management systems because of the lack of integration in
existing management solutions. In addition, two of them felt that existing network management solutions did not interoperate with organizational business processes. All experts felt
that the cooperative management framework would be useful in view of the facility of
integration of various integrated management solutions in the organization. This would also
integrate with organizational business processes.
Whereas Expert 1 was looking for the integration of network simulation and a welldeveloped base, Expert 2 wanted more clear integration with organizational infrastructure
planning, such as building plans. Each of the experts felt that these scenarios were appropriate
in his organization and that he faced similar problems. Expert 1 felt that there could be many
more scenarios related to operations, whereas Expert 2 felt some scenarios highlighting the
planning process would be useful. However, all of them felt that the given scenarios captured
the essence of the problems. Whereas Expert 1 felt that no amount of cost was too much
considering the benefits in the telecom sector, Expert 2 felt that there was a serious problem
in getting such schemes approved in the higher education sector.
7.5.3.2.
145
Management Platforms, Application, and Human User Levels (Level 2)
At the platform level, Expert 1 uses a number of management platforms, such as HP

OpenView, and Expert 2 has just started using Cabletron Spectrum.
Regarding the application level, each of them felt that the demonstrated help desk was
general and captured all relevant business processes in his organization. Expert 1 gave a
rating of 9; Expert 2 gave a rating of 8 for Change Management in a scale of 1 to 10, with
10 being the highest. For Problem Management all experts gave 10 points in a scale of 1 to
10. Regarding the human user level, all experts felt that there was a severe shortage of skilled
personnel in the area of enterprise network management. Expert 2 suggested better training
and more sophisticated help-desk systems for low-skilled operation. All of them felt that
group cooperation is important in this environment. They also felt that such cooperation is
required within and across organizations. Each of them felt that the help-desk human roles
in his organization could be captured in the given prototype using Term Maps, a data
dictionary implemented in the prototype as a Notes database.
7.5.3.3.
Groupware Support, Usability, and Visualization Levels (Level 3)
None of the experts used any groupware tools for integrated management. However,
Expert 2 mentioned Novell GroupWise being used in the university for specific uses of higher
management computing applications, and Expert 1 thought that Lotus Notes was being used
in his organization in business applications.
At the usability level, none of them felt any difficulty in using Notes-based manager
interface. All of them felt that the alphanumeric/tabular display of PC/Notes (that could be
offered on mobile terminals) was good enough for integrated management.
Regarding the visualization level, none of them had any experience in using multimedia
for integrated management. Hence, they felt they could not answer this question well.
However, they felt it was worth trying.
7.5.3.4.
Group Communication Support Level (Level 4)
All of the experts felt that it was necessary to support the mobility of a manager in
enterprise networks. None of the experts was sure about the benefits of mobile data
communication over mobile voice/pager in view of the lack of experience with mobile data
tools.
7.5.3.5.
Additional Information from Expert 2
This organization has about 20 people handling the help-desk and related functions.
Although most of them are at a low skill level (Level 1 and 2), there are a few highly skilled
people called data network administrators (Level 3 and 4) who handle the job of planning
and troubleshooting major technical problems/changes. Australian universities have been
sharing the cost of network services on a simple basis in the past due to a heavy subsidization
by the federal government. This is likely to change soon. Consequently, Accounting Management will become increasingly important. In this university, a new node comes up every
3 days and a new subnet is installed every 15 days, according to a study conducted in 1995.
This organization finds it difficult to justify such a long-term investment in integrated
management. For example, as part of asset management plan, it was estimated that cable
routing information would take 18 man-months to enter in a computerized system.
146
7.5.3.6.
Additional information from Expert 3
This organization has a number of help desks for different services/networks, employing
about 50 people. Presently they have vendor-specific network management for different
types of networks, such as IBM and NetMaster, Banyan Vines, PC LAN Manager, and so
on. Presently 90% of the network/service problems are reported by users. Only 10% of
problems are proactively detected by network management systems. This is mainly due to
the legacy of heterogeneous systems of different technologies. The organization has decided
to go in for HP OpenView after a political fight between two influential groups supporting
Hp and IBM NetView/6000, respectively. It was, however, difficult to justify such a
long-term investment.
Although change management is handled seriously in this organization through a
high-power change management committee, often it is not clear which type of changes
should be referred to this committee. For example, is adding a printer a change? (If it is a
simple hardware addition, it is not, but if it involves changes in printer queue management
software, it is).
This bank suffers an average service outage of several hours every year due to network
failure. Presently the management of the EFTPOS/ATM network is different from that for
other networks (e.g., HQ network, branch network, etc.) in the bank. This organization is
planning to outsource a major network service and its management. Table 7.3 summarizes
the response from experts to the questions in the evaluation framework.
In summary, this evaluation shows that a management framework integrating existing
integrated management platforms with groupware may solve many of the problems in the
present-day cooperative management environment. There is no standard methodology for
the development of management solutions. However, this cooperative management methodology may provide the desired seamless integration between organizational management
processes and integrated management in an enterprise.
Some of these results are largely corroborated by some recently published work in this
area. Sachs146 reported the results of a study conducted in the integrated management
trouble-ticketing environment in NYNEX USA, and in a large telecommunication provider.
This shows that a higher level of automation may not necessarily improve the overall
productivity of an organizational team, and it involves a number of important human issues
that may not be evident to an application developer. Orlikowski122 reported the results of a
study conducted by a team of organizational researchers from MIT, regarding a large U.S.
corporation and the effect of groupware technology in the area of customer support activities.
It shows some local organizational changes (at the workgroup level) necessary for the
successful application of groupware in a large business organization.

This chapter has discussed a framework for the evaluation of cooperative management
systems for enterprise networks. There has been an identification of some major parameters
that are likely to be required in the specification and evaluation of future integrated
management systems. A template for the structured description of these parameters followed
this. The usage of this template was illustrated using parameters that are likely to be important
from the group cooperation perspective of enterprise management systems.
Chapter 7.
Evaluation
147
This study shows that it is not possible to formulate a simple quantitative index for the
evaluation of enterprise integrated management systems. However, it may be possible to state
and evaluate an integrated management system specification more objectively than in the
past, using the proposed templates. More research is needed to arrive at a commonly accepted
evaluation specification for an enterprise management system.
Finally, this chapter presented an evaluation of the new design and methodology for the
cooperative management of enterprise networks. Heuristic evaluation involved a contextual
interview of three experts in enterprise management. The results of this evaluation suggest
that CSCW features would be useful in future integrated management systems. Because
experts from different types of enterprise networks presented similar views on this subject,
one can conclude that the basic assumptions were correct, and the overall solution is on the
right track. However, a more comprehensive evaluation requires more detailed implementation of all features of the cooperative management framework.
8
Conclusions and Future Challenges
This book has examined the problem of the development of enterprise management applications integrated with organizational business processes. It has involved an investigation of
evolving network, systems and service management standards/frameworks, and CSCW
models and processes. The initial motivation was to explore new people-centered techniques
for solving problems of enterprise network management. The concepts have been illustrated
through the development of CoMEN.
This methodology was illustrated with the help-desk-based trouble-ticketing application
environment of a large telecommunication service provider. This led to a generic cooperative
management design, which was partially implemented using Lotus Notes groupware and the
Cabletron Spectrum management platform. This work has provided a case-study evaluation
of CoMEN and a design framework for enterprise management.
Chapter 1 discussed the background and motivation for this work with reference to some
recent work. This led to the identification of three major parts of the book:
Part A: Integrated Management Application Development Problem
Part B: Development of a New Methodology for Cooperative Management
Part C: Application of this Methodology to a Real Enterprise Network
The following sections have covered each part in turn and have summarized the contents.
8.1. PART A: INTEGRATED MANAGEMENT PROBLEM

Modern enterprise networks are going through rapid changes due to the evolving nature of
the information network technology and its application in enterprises. Although recent developments have led to the solution to the initial problem ofcollecting management information from
networked elements, there are now too many variables to report on network and systems
management. This necessitates potent management applications to filter and present management
information to users that are consistent with events and relevant contexts. Researchers are
workingin thisarea with the latest techniques from communication technologies, OO software,
and AI, with limited success so far. This led to the realization that a new approach may provide
the desired strategies for the development of management applications.
149
150
The major outcome from this chapter were the identification of a generic framework for
existing management solutions and relevant standards and narrowing down the problem area
to management applications requiring seamless integration with business processes. Further
research in this area will involve a study of the latest evolving telecommunication service
models and their applications in real organizations.
8.2. PART B: CSCW-BASED COOPERATIVE MANAGEMENT

This part of the book indicated that CSCW developments would be relevant for solving
the problem of providing the integration of organizational processes with integrated management. It seems that CSCW concepts would be useful at all stages of a cooperative
management life cycle. This was illustrated with the development of a formal methodology
for enterprise management (CoMEN), summarized as follows:
1. What should be the goals and objectives ofa CSCW-basedmanagement methodology?
To provide an enterprise-oriented view of technical management problems.
To develop usable, people-oriented solutions to enterprise management problems.
To provide seamless integration of organizational business processes with the
management of enterprise networks.
To develop an evaluation framework for cooperative management solutions.
These objectives drove much of the reasoning for the different aspects of the
methodology.
2. What concepts comprise the cooperative management model? CoMEN is based on
Checklands SSM for user-oriented design. It uses some ethnographic concepts to
study organizational processes in terms of human roles and their interactions. This
methodology uses simple activity-based graphic notations and tables to represent
the various role interactions and their support mechanisms. CSCW design and
implementation concepts, such as groupware and workflows, have been used to
illustrate the development of a cooperative management system.
3. What is the life-cycle model employed in the methodology? This methodology uses
the iterative waterfall process model with five major steps: requirements gathering,
analysis, design, implementation, and evaluation.
4. What is the process of cooperative management solution development? Firstly, one
needs to study the requirements in consultation with people in the organization
under study. Various human roles and their scope of work are identified. A recording
of role interactions in some representative scenarios follows. For each interaction
satisfaction level, cooperation tools and communication media details are recorded.
This is followed by an abstract CSCW-based modeling of various role interactions
to explain the difference in satisfaction levels amongst various interactions. CoMEN
uses the awareness model for this purpose.
The system design strives to arrive at a conceptual design based on required
awareness levels for roles at different interactions. At present, an awareness model
Chapter 8. Conclusions and Future Challenges
151
provides a qualitative requirement of group communication systems. Further development of this model may produce quantitative and formal design techniques. This
is followed by a workflow design of the process. This is implemented through a
groupware environment, such as Lotus Notes. Higher level design and implementation tools (encompassing CSCW in distributed computing environments) are
required for the realization of process-level designs.
Finally, this system is subjected to a heuristic evaluation by experts in this area
using a contextual interview based on the implementation.
5. What notation/representations should be made available to the modeler to provide
a concise, comprehensible, and practical means of expressing a cooperative management model? In this book CoMEN has used a number of different notations
appropriate for different stages of the process. For example:
The initial big picture of the system is represented through an informal rich
picture.
The interactions of roles in different scenarios are represented with activity flow
graphs.
The support for different interactions are represented through an interaction table.
Awareness-based design specification uses a matrix of awareness levels for
differentroles/interactions.
Workflow design uses Action Workflow methodology.
Although this book has used only the previously mentioned notations, CoMEN allows the
use of various other techniques, such as UML for object design, CORBA IDL for distributed
object interfaces, and ASN. 1 for managed object specification. More research is needed to
develop standard notations for the specification of CSCW systems, independent of workflow
engines, distributed computing environment, and the underlying network technology.
8.3. PART C: APPLICATION OF CoMEN

This part has further illustrated the CSCW-based development approach through an actual
application of CoMEN in a real organization for the development of a cooperative management
application. A help-desk-basedtrouble-ticketing environmentin atelecommunicationcompany
was chosen for this purpose. This has been shown as per the following steps:
1. Gathering and analysis of data from a real business environment. It has been possible
to capture some major gaps in the cooperative management support in enterprise
management by using role-interaction analysis of this methodology. A new CSCW
model based on awareness levels appeared to help in the abstraction of the details,
as required to enhance the external validity of the findings.
2. Design of cooperative management systems for enterprise networks. This step
involved the design of a generic cooperative management system according to the
Design stage of CoMEN. The previously mentioned awareness level requirements
152
were translated to qualitative group communication requirements and an overall

cooperative management framework. A generic cooperative management system
based on help-desk was implemented using Lotus Notes and Cabletron Spectrum.
3. CSCW system evaluation. This stage of the book also illustrated some CSCW-based
system evaluation techniques. In this stage the previously mentioned cooperative
management system was subjected to a heuristic evaluation using a contextual
interview of experts in this field. It may be noted that this evaluation is only to
illustrate the methodology. Hence, this is not intended to be an exposition of rigorous
evaluation, as may be required in an industrial environment.
8.4. FUTURE CHALLENGES

This book has presented a new approach to the management of enterprise networks and
services. The CSCW-based cooperative management methodology offers a fresh new
approach to the solution of problems in integrated management. This lays a strong foundation
for the integration of organizational business processes with integrated management. The
application of this methodology in a real organization has revealed the issues to be considered
for the development of effective CSCW-based cooperative management systems. The
prototype implementation showed the practicality of a CSCW-based cooperative management solution. Although this book has discussed cooperative management from the perspective of integrated management, the approach used in CoMEN is also applicable in a variety
of cooperative applications. 137
However, there is a need for further investigation in this area. Some of the unanswered
questions are as follows:
How effective are the cooperative management methodologies and frameworks in
real-life applications and installations? This will require more implementations and
evaluations of such systems.
How should one accurately define awareness levels in formal terms? This may need
inputs from other disciplines, such as neural networks.
How should one translate the required awareness levels to a formal CSCW design
(fuzzy logic?)?
How should one quantify the effectiveness of enterprise management systems with
respect to some new features, such as mobile/multimedia communications?
How should one formally specify management service requirements that can be
easily translated to groupware/workflow designs? Process-oriented tools are required
for this purpose.
More resources are required to study the effectiveness of additional group communication
mechanisms, such as wireless mobile data networks in the management of enterprise
networks. There is a need for substantial research in the standardization of evaluation criteria
for enterprise management. Finally, there is a need to cross-check these results with similar
studies in enterprise networks in different businesses and different countries.
Help-Desk-Based Groupware Design
As discussed in chapter 6 of this book, Notes application modules are organized into Notes
databases, around which various forms, views, and macros are defined to realize an
application. This appendix provides a description of various Notes databases and operations
supported on them for our generalized help-desk-based cooperative management system.
The databases are as follows:
Trouble-ticketing Database (TRBLTKT)
Change Management Database (CHNG)
Multiparty Discussion Database (TALK)
Technical Knowledge-base (KB)
HLP-DSK Term-Maps database (HLP-DSK)
whereas chapter 6 discusses the design of the trouble-ticketing database, this appendix
presents the complete design including all databases.
A.1. TROUBLE-TICKETING DATABASE (TBLTKT)

This is one of the five databases included in our trouble-ticketing application. The
database tracks each service a call from start to finish using three forms: call reports for
customer calls, and company profiles and caller profiles for names and addresses. A call
report can escalate a call, reassign a call to a technician in a different workgroup, and notify
that technician of his or her new assignment. It also allows NMC staff, business units staff,
specified customers, and authorized vendors to browse and create documents in the KB, the
CHNG, and the discussion database.
NMC operators use this database to log each call from a customer. NMC and business
unit managers use it to monitor the progress and effectiveness of various cooperative network
management functions, such as fault management and change management involving people
within the organization and those outside of it (e.g., customers, vendors, etc.).
This database (data structure in Fig. A.1) supports information on the following
categories: customer information, call information, and notifications. This database imple153
154
Figure A.1.
The data-structure for trouble-ticketing.
ments facilities (views, forms, and macros) for handling problem calls, entering user/organization information, and for taking various actions listed that follow.
Problem description & ID (caller)
Assign service type/category (interneve-mail)
Get statistics
Add action item (date, time)
Seventy level (high, low)
Assign to (skill group, person)
Escalation level (basic, complex)
Time taken
Enclose relevant documents
Test results (management information)
Customer contracts
It should be noted that this is only an illustrative implementation. Therefore, we do not claim
this to incorporate all variations of data structures that exist in todays troubIe-ticketing
systems for enterprise networks. For example, this implementation does not implement the
priority of a caller explicitly. This is assumed as part of the call priority here.
A.l .1. Customer Information
There is a need for defining and updating information related to customer organizations
and contact persons. A profile is a Notes document that stores information about a customer.
A database manager or customer service manager should complete most profiles before
trouble-ticketing users begin using the application, although specialists can also compose
Appendix A:
155
new profiles as they take calls. This application has two different kinds of profiles: company
profiles and caller profiles.
A company profile holds information such as the name and address of a company, the
primary contact person at the company, and notification lists of people who want to know
about serious problems reported by this company. A company profile allows us to create
notification lists containing people or groups who want to know when a call from this
company is escalated or assigned a severity level.
A caller profile holds information such as the name, title, phone number, and e-mail
address of a caller. A caller profile also contains four fields that hold additional information
useful to the customer service organization. Every caller profile must come from a company
profile because a caller profile inherits information from its related company profile. The
main view of the TRBLTKT categorizes call reports by the names of companies and callers.
A.1.2.
Call Information
A call report is a document that stores information about a single customer call made
to the support organization. An operator or technician enters this information and uses call
reports as home bases from which to work. For example, a technician can describe the
callers problem, research similar problems, keep track of the time spent on a problem,
escalate the call to a specialist, or submit the problem and its resolution as a technical note.
A call report inherits information from its related Caller Profile.
As shown in the Lotus Notes screen in Fig. A.2, a Call Report shows the complete history
of a customers problem. The screen incorporates a number of buttons, such as Escalate,
Reassign Call, Submit As, and Call Statistics. Research button allows research based
on access of management information from a platform, such as Spectrum. Call reports can
send e-mail messages that keep the help-desk organization and customers informed of
important changes in the status of calls. In addition, call reports can be submitted as service
change suggestions, change management problem reports, and technical notes that form a
valuable core of knowledge gleaned from customers.
A.1.2.1. About the Call History
Call history automatically keeps a history of one particular problem by logging each
contact between the customer service specialist and the caller, beginning with the initial
phone call. On a new call report, the call history is blank. Each time a technician edits the
call report, the application automatically pulls the new information from the action box
and logs it in the call history along with the authors name, the date, and the time.
What follows is a sample call history:
1: Bandu Jaywardene 03/04/98 06:10:51 PM
Told him I would investigate the problem and call back.
2: Bandu Jaywardene 03/04/98 06:15:24 PM
No one I spoke with seemed to know what to do. I think we need both an immediate,
interim solution and a long-term solution.
156
Figure A.2.
A call-report screen.
Escalated and reassigned to manufacturing group.

Each time one opens, saves, and closes a call report, the application logs the most recent
action with a sequential number (1,2, 3, and so on). If a call report is saved multiple times
without closing it, the application logs each new recent action with the same number. If
several actions in the call history are logged under the same number, it shows that these
actions were entered in one edit session.
When a user saves a call report, the application pulls the information from the action
box and logs it in the call history, described previously. It then clears this field so the field
is ready to accept new information. The call history uses this field to track the steps taken to
resolve a problem; problem details is used to describe the problem itself.
A.1.2.2.
About Actual Work Time
Actual work time keeps track of how much time is spent in resolving a call, in minutes.
One can edit this field directly or one can edit it using the stopwatch. To edit the actual work
time directly, one types in the number of minutes spent on the call. To edit the actual work
time with the stopwatch, clicking stop can stop the stopwatch. The application asks if the
user wants to add the elapsed time to the total work time. Usually one selects Yes.
Appendix A:
A.1.2.3.
157
Using the Stopwatch to Time Calls
Using an electronic stopwatch, the call report assists in keeping track of the time one
spends resolving a problem. The stopwatch is an optional feature; it need not be used if the
customer service organization doesnt track the time spent on calls. Each call report has its
own stopwatch. The status of the stopwatch-running, stopped, or paused-is displayed at
the bottom of a call report. The stopwatch can be controlled when the call report is in edit
mode. One can automatically add the amount of time elapsed on the stopwatch to the total
time worked or edit the time manually.
A.1.2.4. Call Statistics
The application keeps a log of time statistics for individual phone calls. A call statistics
document is associated with each call report. Call statistics documents provide information
such as the amount of time taken to open a call, the number of days the calls remained open,
the turnaround time, and the amount of time a customer service specialist spent working on
a call.
Call statistics provide information to help analyze the efficiency of the help-desk
organization. Each call report has a call statistics document associated with it. Call statistics
log four different time measurements in days, hours, and minutes. Time to enter indicates
how long it took the specialist to enter the call into the TRBLTKT. The application measures
time to enter from the time the call first reached the help-desk organization to the time a
specialist entered the call report into the TRBLTKT.
Days-open indicates how long the call has remained open. It is measured from the time
a specialist entered the call report into the TRBLTKT until today. If the call is closed,
days-open indicates how long it took the customer service organization to solve the callers
problem. The application measures days-open from the time the call reached the organization
until the time a specialist closed the call (the same as turnaround time that follows).
Turnaround time indicates how long it took the help-desk organization to solve the
callers problem. The application measures turnaround time from the time the call reached
the customer support organization until the time a technician closed the call. If the call is
still open, turnaround time is unavailable.
Actual work time indicates how much time a specialist spent resolving the callers
problem. The specialist enters this time on the call report form. He or she can use the
stopwatch to help log this time.
A.1.3.
Notifications
A notification is intended for database managers who need to define notification lists in
the HLP-DSK and the TRBLTKT, as well as customer service specialists who want to
understand how they work. A notification is a memo that the application automatically sends
whenever a call from this company is assigned a certain severity level or is escalated. An
application can automatically send notifications to certain people whenever there is a specific
change in the status of a document. The notification describes the change in the document
and provides a doclink to it.
The people who receive notifications when a specific change occurs make up a
notification list. The organization defines which people are included in notification lists.
158
People and groups on a notification list receive notifications only after the changed document
is saved.
A severity level notification list is used to define lists of people or groups who want to
receive notification when a call from this company is assigned a specific severity level. An
escalation notification list is used to define lists of people or groups who want to be notified
when a call from this company is escalated to a specific level.
The following events in the TRBLTKT trigger a notification.
A.1.3.1. Reassignment
When one reassigns a call from a call report, the specialist who now owns the call
receives a notification. This happens automatically. It is not necessary to define a notification
list individually for each notification.
A.1.3.2. Escalation
When a call is escalated (assigned to a specialist with a specific proficiency level), the
following people receive notifications:
The specialist who now owns the call, if this has changed. This happens automatically.
Anyone in the notification list (from this customer) for calls escalated to a certain
level. Sales people who work with a certain account, for example, may want to know
about complex problems the customer has reported. One defines a company-specific
notification list for each escalation level in the company profile.
Anyone in the notification list (from any customer) for calls escalated to a certain
level. A customer service manager, for example, may want to receive notification
about all high-severity calls. One can define a notification list for each severity level
in the HLP-DSK.
The two notification lists are separate. If the database manager edits one of the notification
lists (either in the company profile or the HLP-DSK), the other notification list remains
unchanged. If a person is in both of the notification lists, he or she will receive only one
notification.
A.1 .3.3. Notification Lists
When a severity level is assigned to a call (a decision on how severely the problem
impacts the customer), the following people receive notifications:
Anyone in the notification list (from this customer) for calls assigned a certain
severity level. Sales people who work with a certain account, for example, may want
to know about critical or disabling problems the customer has reported. One defines
a company-specific notification list for each severity level in the company profile.
Anyone in the notification list (from any company) for calls assigned a certain
severity level. A customer service manager, for example, may want to receive
notification about all high-severity calls. A notification list for each severity level is
defined in the HLP-DSK.
Appendix A:
159
The two notification lists are separate. If the database manager edits one of the notification
lists (either in the company profile or the HLP-DSK), the other notification list remains
unchanged. If a person is in both of the notification lists, he or she will receive only one
notification.
A.2. CHANGE MANAGEMENT DATABASE (CHNG)

The Change Management database (CHNG) is one of the five databases included in our
trouble-ticketing application. It stores and categorizes the changes undertaken. A change
management report document describes an activity related to change (plans, problems, etc.).
Change management problems can be escalated and reassigned; users can also assign a
severity level to a change management problem. A change management problem can inherit
information from a call report (including a doclink to the original report in the help-desk
database) or can be submitted independently.
NMC and change managers can use this database to identify change related information
and track progress in responding to them. Authorized users can submit change-related
information to this database from within the help-desk database. They can also use the
database to research possible reasons for a callers problem. Business managers, affected
customers, and support staff can browse this database for change information or can submit
their own change-related information.
The CHNG (the data structure in Fig. A.3) captures all information related to planning,
installation, and provisioning of various services in a distributed environment. This incorporates facilities for entering and modifying service/equipment changes. A change can be
initiated either by the customer or by any concerned person in the service organization, such
as business managers, technicians, and so on. The system can handle various problems
related to a change, such as the following:
Problem description ID (caller)
Severity level (high, low)
Assign service type/category
Get statistics
Figure A.3. The data structure for change management.
160
Add action description (date, time)

Timetaken
Escalate
Reassign owner
Enclose relevant documents
Customer suggestions
Expert comments
Technical specification
A.2.1. Change Management Problems
The change management problems database stores and categorizes the problem reports
submitted by customer service specialists. Product managers can use it to track their progress
in responding to change management design problems. In order to make this database generic
to a wide range of industries, sometimes this database is called a Product Design Database
because the process semantics of product design is similar to the change management part
in integrated network management.
Many of the features in Change Management are the same as in trouble-ticketing. The
difference is that the change management problems databases features concern servicechange-related problems instead of customer calls on existing services.
The product fields hold three pieces of information: service is the name of the product
about which the customer is calling, the service group is the group of related products about
which the customer is calling, and categories are areas of the product about which the
customer is concerned.
A.2.2.
Change Management Notifications
When a severity level is assigned to a problem in the change management problems

database, anyone on the change management problems notification list receives a notification. The people responsible for responding to design problems, for example, should be on
the list. This notification list is defined in the HLP-DSK.
A report designed in Notes is shown in the screen in Fig. A.4. This is designed to show
all the details regarding a product design/change management problem. Because both
problem management and change management are based on the help-desk-based troubleticketing business model, the screens for these applications are similar.
Once the change management problem report is saved, it is officially logged in the
change management problems database. One can then close the problem, reassign it, escalate
it, and/or submit the report to the knowledge base.
A.2.3. About the Problem History
The problem history automatically keeps a history of one particular problem by logging
each action taken to resolve the problem. In a new change management problem report, the
problem history is blank. Each time a technician edits the change management problem
Appendix A: Help-Desk-Based
Groupware Design
161
Figure A.4. The change management screen.
report, the application automatically pulls the new information from the action box and
logs it in the problem history along with the authors name, the date, and the time. What
follows is a sample problem history:
Bandu Jaywardene Nov. 25, 1997 10:30AM Tested remote connectivity-OK. Link
not working yet. Call escalated to expert-John Miller
Each time one opens, saves, and closes a change management problem report, the
application logs the most recent action with a sequential number (1,2,3, etc.). If the change
management problem report is saved multiple times without closing it, the application logs
each new recent action with the same number: This shows that these actions were entered in
one editing session.
The action box describes the most recent action taken to resolve the callers problem.
This field appears only when one edits a change management problem report. The latest
action taken is typed.
When the change management problem report is saved, the application pulls the
information from the action box and logs it in the problem history, described previously. It
then clears this field so that it will be ready to accept new information. The problem history
uses this field to track the steps taken to resolve a problem.
Cooperative Management ofEnterprise Networks
162
A.2.3.1. About Actual Work Time
Actual work time keeps track of how much time is spent in resolving a call, in minutes.
This field can be edited directly or manually by using a stopwatch.
A.2.3.2.
Researching a Problem
One can browse existing documents in the TRBLTKT, the knowledge base, or the change
management problems database while working on resolving a problem. One can do this right
from a change management problem report. The application opens the database and the views
selected.
A.2.3.3.
Reassigning a Problem
When a new change problem report is created, the problem is automatically assigned to
the person creating the report. Reassigning a problem gives a different group and technician
responsibility for the problems resolution. It does not change the escalation level of the
problem. One can reassign a problem at any time-to a specific person within the work
group, or to the groups default person. The organizational guidelines can be followed when
deciding to reassign a problem.
The application sends a memo to the new owner of the change management problem
report, notifying him or her of the assignment. One can verify the reassignment by choosing
View-Open Problems-By Owner in the database. Scrolling to the new owners name will
find the change problem report listed below it.
A.2.3.4. Escalating a Problem
Escalating a problem gives a different person with the required skill level in the product
group responsibility for the problem. Escalation takes place within a workgroup. Again, one
can follow the organizations guidelines when deciding to escalate a problem. No sophisticated mathematical models are used here. These may be linked to the knowledge base
through Notes macros (not implemented in this version).
When a problem is escalated, the application searches for those people who meet the
following requirements, based on information in the problem report:
People working with the group of products.
People with the required level of expertise in the product group. Expertise level
correlates with escalation level, so if a call is escalated to Level 2, the application
searches for designers of Level 2 expertise.
Technicians belonging to the appropriate workgroup. If the change problem report
is new (unsaved), the application searches for technicians who belong to the products
default workgroup. Otherwise, the application searches for technicians who belong
to the workgroup that currently owns the change problem report.
When a change problem report is escalated, it logs the escalation level, the date, and the time, as
seen in the following example. Scrolling to the bottom of the change problem report allows us
tosee the escalation history. Escalation levels may look different on the organizations reports.
Escalation Level: Closed
Date Basic: 03/14/94
Appendix A:
163
Date Complex: 03/14/94

Call Closed: 03/14/94 03:30 PM
Escalation Levels and Reassignment
If a problem is reassigned to a different group, the new owner may adjust the escalation level
to reflect the calls status within the new group. For example, a call may have been escalated
twice before being reassigned to the service department. The service department may decide
to return the call to a lower escalation level using the Escalate/Close button.
A.2.4. Submittinga Change Management Problem Report to the Knowledge Base
Technical notes and technical rules are documents in the knowledge base. A technical
note contains free-form product information. A technical rule also contains product information, but it presents a standard solution to a well-defined problem. When a technical note
or a technical rule is submitted, its considered a draft until approved by the appropriate
person. Technicians can use approved notes and rules as research aids while they work to
solve customer problems. Organizations have guidelines about when to submit a problem as
a technical note or a Technical Rule.
A.2.5. Viewing Change Management Problem Reports
One can view change management problem reports several different ways:
The All Problems views show both open (unresolved) and closed (resolved) problems.
Problems are organized by feature category or by product type.
The Closed Problems views organize closed problems according to the originating
date, the closed date, the technician, the product, or the product group. Each view
calculates the average turnaround time (time spent resolving the problem) for the
problems in each category.
The My Open Problems view shows each technician only the problems that are
assigned to him or to her.
The Open Problems views organize open problems according to the date, the feature
category, the escalation level, the owner, the problem number, the product, or the
severity level. Several of these views also calculate the percentage of calls that
concern a particular product, product group, or feature category.
A.2.6. Problem Statistics
The application keeps a log of time statistics for individual problems. A statistics
document is associated with each change management problem report. Statistics documents
provide information such as the amount of time taken to open a problem, the number of days
the problem remained open, the turnaround time, and the amount of time a technician spent
working on a problem.
164
Once a change management problem report has been saved, one can look at the
originators (often the callers) address, phone number, fax number, and e-mail address right
on the document.
To find the originators address press and hold the mouse button over the Originator
Information icon in the top left comer of the report. A pop-up containing the originator
information appears.
If a specialist submitted a change management problem report from the TRBLTKT, one
may want to see how the problem originated and how the specialist resolved it. This
information is available from the original call report.
A.3. MULTIPARTY DISCUSSION DATABASE (TALK)

The multiparty discussion database (TALK) is one of the five databases included in the
trouble-ticketing application. The database stores and categorizes the discussions related to
various trouble-tickets.
The database contains two kinds of documents: suggestions and responses to suggestions. Suggestions describe the suggestion and contain a Prioritize Idea button that allows
managers to manage suggestions effectively. The suggestion document also lets users track
which suggestions arise from complaints, and it has an acknowledgment letter check box
that generates a letter addressed to the customer. A suggestion can inherit information from
a call report (including a doclink to the original call report in the HLPDSK) or it can be
submitted independently. The response to suggestion form lets users post responses to
suggestions, making this database a forum for discussion.
This database allows free-form discussion on various threads by all concerned. Discussions can be developed either by initial calls or by responses to previous notes. There is a
workflow mechanism to bring these discussions to logical conclusions by authorized persons
in the organization. There are special workflows to automatically generate a trouble-ticket
in case discussion turns into a complaint from a customer. The Talk data structure is shown
in Fig. A.5. The contents are as follows:
Description & date
Submitted by
Figure A.5.
Multiparty discussion data structure.
Appendix A:
165
Figure A.6. The screen for the multiparty discussion database.
Service type, ID, category

Competitor
Suggestion status
Is this a complaint (macros to generate lT)
Possible test sites
Implementation strategy
Figure A.6 shows the screen containing the information in a TALK database. Change
management teams can use this database to discuss various changes, to prioritize the
suggestions, and to track responsiveness to them. Technicians can submit suggestions to this
database from within the help-desk database. They can also use the database to research
planned changes. Users can also browse this database for customer feedback or can submit
their own suggestions.
A.4. THE TECHNICAL KNOWLEDGE BASE

The Knowledge Base (KB) is one of the five databases included in our Lotus Notes
trouble-ticketing application. This database is a repository of product and how-to infor-
166
Figure A.7. A user interface for the knowledge base.
mation that technicians use to resolve customer problems. Other employees can use it
whenever they have a question about a product.
Figure A.7 shows the screen for user interface to the KB database. The KB has two
forms: technical notes and technical rules.
Technical notes contain free-form product information on a variety of topics; technical rules describe a common product problem and a prescribed solution.
A draft copy of the technical rule is shown in Fig. A.7. Both documents can inherit
information from a call report (including a doclink to the original call report in the
trouble-ticketing database) or can be submitted independently.
Technical notes and rules can be either drafts (not yet approved) or approved and can
be either public or private. The database has built-in workflow capabilities that notify
a document approver whenever draft documents need his or her attention. The
approver designates whether a document is public or private.
Experts and technicians can browse the KB for information that might help them solve a
problem. Specialists can submit technical notes or rules to this database from within the
TRBLTKT. Occasional users can search for product information in the KB or can contribute
Appendix A:
Figure A.8.
167
The knowledge base data structure.
documents of their own. Customerscan access the public documentsin this database through
Phone Notes.
A.4.1.
Database Structure
This database (the data structure shown in Fig. A.8) provides facilities to generate and
moderate technical information into authorized technical notes and technical rules to be
stored in the KB for consultation by all concerned when required. One can attach various
relevant test and results with these documents. These attachments can be notes, tables, and
so on from Notes or from external systems, such as SPECTRUM. Contents/reports related
to the KB are as follows:
Description
Submitted by (date)
Servicetype
Problem nature
Solution/discussion
Approved by (date)
Enclose relevant information
Discussions
Test results
Management information
References
A.4.2. Knowledge Base Notifications
When a draft of a technical note or rule is submitted to the KB, anyone on the technical
note approval notification list receives a notification. The people responsible for approving
168
the content of KB documents, for example, should be on the list. This notification list is
defined in the HLP-DSK.
A.5. HELP-DESK TERM-MAPS DATABASE (HLP-DSK)

This database holds the key to customization of the help-desk system. The HLP-DSK
defines labels and keywords used by other databases. The HLP-DSK acts as a data dictionary.
Figure A.9 shows the screen for the interface to the HLP-DSK. This database contains
two kinds of documents: term-maps database and keyword definitions. The database manager uses term-maps database to define the labels that appear on forms. The database manager
uses keyword definitions to define the keywords that customer service specialists use when
filling out forms. Every time a user fills out a keyword field, the HLP-DSK supplies a list of
keywords from which the user can choose. Keyword definitions also define the attributes of
the service organization, such as the qualifications of each support specialist and the
supervisor of each workgroup. A keyword definition form designed in Lotus Notes is as
shown in Fig. A.9.
Figure A.9.
A user interface for the term-maps database.
Appendix A:
169
The database manager must set up the HLP-DSK before the service staff can use the
application and must maintain it afterwards. A Notes administrator, a customer service
manager, and one or more data entry workers may assist the database manager. Operations
people should not need to use this database. When a user opens a call report, for example,
the TRBLTKT asks the HLP-DSK to look up the labels and the keywords that it needs.
The HLP-DSK can contain three kinds of labels: system terms, company terms, and
custom terms.
System terms: If the applications labels are not customized, the application databases use the system terms that are defined with the application. In the example,
severity level is a system term.
Company terms: Company term labels prompt the user for the same information
as a system term, just using a different word. For example, crisis level is a company
term that is a synonym for severity level.
Custom terms: Custom terms and their related keywords may be used to hold
specialized information that is important to the organization.
There are ten system terms in the HLP-DSK (organized as follows according to the customer
service forms on which they appear) that may be written over with custom terms.
A.5.1.
Forms
The HLP-DSK provides customization facilities through four types of forms:

The call report form has two fields; Problem Field 1 and Problem Field 2.
The caller profile form has four fields; Caller Field 1, Caller Field 2, Caller Field 3,
and Caller Field 4.
The company profile form has two fields; Company Field 1 and Company Field 2.
The change management problem form has two fields; Problem Field 1 and Problem
Field 2.
A.5.2. Defining labels
Labels are defined by editing a term-map document in the HLP-DSK. This database
contains 22 labels. Twelve of these are for defining company terms; ten of them are for
defining custom terms. Each term map contains several labels that are related to one another.
For example, all the labels having to do with severity levels are grouped together on the
severity level term map.
A.5.3.
Keywords
The HLP-DSK holds two kinds of keywords: base keywords and regular keywords. Base
keywords are used in more than one field in the application, hence these keywords are defined
first. The term maps use regular keywords in only one field.
170
A.5.3.1.
How a Base Keyword Works
A base keyword allows the HLP-DSK to successfully match keywords that appear in
different places. Suppose a customer service specialist decides to reassign a call to a person
in a different workgroup. The specialist clicks the Reassign Call button on the call report.
The customer service application looks up the workgroup keywords (different departments
at the company) in the HLP-DSK.
The specialist selects a workgroup, Customer Service, to take the call. The HLP-DSK
then performs another lookup, this time to find specialists in the workgroup Customer
Service. Because the workgroup keywords have been defined once and then have been
reused consistently, the HLP-DSK can successfully match specialists with their correct
workgroups. The example that follows shows specialists who work in customer service, as
displayed in the TRBLTKT.
Work Group Keyword
Specialist
ISDN
Paul Sheahan
Firewalls
Jim Wiley
A.5.3.2. Designer Keyword Definition
This provides a workgroup name in the specialist keyword definition default work.
Given a specific workgroup, one can look up the people (technicians or specialists) who
belong to that workgroup, defined using the level number in the escalation level keyword
definition.
A.5.3.3. Technician Keyword Definition
This keyword defines level numbers for technicians with different types of skills.
Given a specific escalation level, one can look up people who have corresponding skill
levels.
A.5.3.4. Defining Keywords
A keyword is defined by creating a keyword definition document in the HLP-DSK. Each

keyword definition belongs to a term map. To create a keyword definition, the related term
map is opened and clicked. Each keyword definition defines several keywords that are related
to one another. Just as all the labels having to do with severity levels are grouped together
on the severity level term map, so are all the keywords related to a specific severity level
grouped together on a seventy level keyword definition. Together, these keywords define
that severity level for the application.
A.5.4. Guidelines for Completing the HLP-DSK
The following guidelines may be used while planning and implementing an organizations HLP-DSK:
Appendix A : Help-Desk-Based Groupware Design
171
1. Brainstorm with the worksheet. Print the existing term maps and use them as a
worksheet. Edit any labels and brainstorm for the keywords that need to be
associated with these labels. Write the labels and keywords in the columns provided.
2. Editing the HLP-DSK is optional. Creating keyword definitions is required. If one
doesnt edit any of the HLP-DSK, the application will successfully use the system
terms. If no keyword definitions are created, the application will not work.
3. Solicit feedback. Once a preliminary worksheet is completed, solicit feedback on it
from the customer service specialists and the managers who will be active users of
the application.
4. The HLP-DSK and keyword definitions contain related sets of labels and keywords.
The HLP-DSK uses each term map and keyword definition as a record of related
attributes. For example, the specialist keyword definition for someone named
Colleen Griffiths contains her name, ID number, workgroup, proficiency level, and
area of product expertise. Without all of this information, the HLP-DSK cant
properly assign a call to her. This needs to be borne in mind when reusing base
keywords as well, for example, one can choose the base workgroup, level, and
product group name keywords that reflect Colleens actual workgroup, proficiency
level, and area of product expertise.
5. Create the base keywords (and their labels) first. The base keywords table earlier in
this section shows each base keyword, where it is defined, and where it is reused.
Once the HLP-DSK worksheet is completed, the following needs to be done in
order:
a. Editing the HLP-DSK for the base keywords (left column in the table) and
saving the changes.
b. Creating the keyword definitions for the base keywords (left column). Opening
the related term map and clicking Add Keyword does this.
c. Editing the Term-Maps database for the reused base keywords (right column in
the table) and saving the changes,
d. Creating the keyword definitions for the reused base keywords (right column).
Opening the related term map and clicking Add Keyword does this.
6. Define custom terms (and their keywords) last. Because the application databases
dont rely on custom terms to function, one can be flexible with them. A HLP-DSK
can be built without any custom terms to get it working. Then one can go back to
define the custom terms and keywords.
A.5.5. Checklist for a Healthy HLP-DSK
When the customer service application cant find the information it needs in the
HLP-DSK, it gives an error message. The error message tells the user which document to
create or correct in the HLP-DSK. To ensure that customer service specialists do not
172
encounter errors, the HLP-DSK is tested thoroughly before implementing the help-desk
application,
A.5.6. Accessing the HLP-DSK
Once the HLP-DSK is set up, tested, and corrected for any problems, the Notes
administrator needs to define Access Control Lists (ACLs) for the HLP-DSK and the other
application databases.
We have produced the design synopsis of all the Notes modules in this design. They
provide a full description of all designs of forms, views, and macros used in the system.
However, they are not reproduced here for the sake of brevity. Interested readers may contact
the author directly at p.ray@uws.edu.au for further details.
List of Acronyms
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
4th Generation Language

Automatic Call Distributor
Association of Computing Machinery
Artificial Intelligence
Application Programming Interface
As Soon As Possible
American Standard Code for Information Interchange
Abstract Syntax Notation One (language)
Asynchronous Transfer Mode
Bit Error Rates
Business Management Layer
Business Process Reengineering
Computer-Aided Software Engineering
Component Interface
Common Information Model
Connection Less (protocol)
Command Line Interface
Computer Mediated Communication
Common Management Information Protocol (OSI)
Common Management Information Service Element (OSI)
co
Connection Oriented
CoMEN Cooperative management Methodology for Enterprise Networks
CORBA Common Object Request Broker Architecture (OMG)
CPU
Central Processing Unit
CSCW Computer-Supported Cooperative Work
CSLN
Client/Server Layer Network inter-domain reference point
CTI
Computer Telephone Integration
DAI
Distributed Artificial Intelligence
DBMS
DataBase Management System
DCM
Data Communications Machine (SPECTRUM)
DCOM Distributed Component Object Model
DCN
Data Communication Network (TMN)
DDE
Dynamic Data Exchange
4GL
ACD
ACM
AI
API
ASAP
ASCII
ASN.l
ATM
BER
BML
BPR
CASE
CI
CIM
CL
CLI
CMC
CMIP
CMISE
173
174
34.
35.
36.
37.
38.
39.
40.
41.
DPE
DMI
DMTF
DOMS
EFTPOS
EML
ER
FCAPS
42.
43.
44.
45.
46.
47.
48.
49.
50.
5 1.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
FDDI
GDMO
GDSS
GRM
GSS
GUI
HAD
HCI
HMMP
HTTP
HUFIT
IDL
IEEE
IETF
IMA
IMF
IN
INA
IS
ISDN
IS0
IT
ITU
JMAPI
LAN
LAT
LLC
MAN
MBR
MD
MIB
MIF
MIS
MO
NCCE
NE
NMC
Distributed Processing Environment

Desktop Management Information
Desktop Management Task Force
Distributed Object Management System
Electronic Funds Transfer at Point Of Sale
Element Management Layer (TMN)
Entity Relationship
Fault, Configuration, Accounting, Performance, Security Management
Fiber Distributed Data Interchange
Guidelines for the Definition of Managed Objects
Group Decision Support System
Generalized Relationship Model (OSI)
Group Support System
Graphical User Interface
Heterogeneous, Autonomous, and Distributed system
Human-ComputerInterface
HyperMedia Management Protocol
HyperText Transfer Protocol (Internet)
Human Factors In Information Technology
Interface Definition Language (CORBA)
Institute of Electrical and Electronics Engineering
Internet Engineering Task Force
Intelligent Management Agents
Integrated Management Framework
Intelligent Networks
Information Networking Architecture (Bellcore)
Information Systems
Integrated Service Digital Network
International Standards Organization
Information Technology
International TelecommunicationsUnion
Java Management API
Local Area Network
Local Area Transport
Logical Link Control
Metropolitan Area Network
Model-Based Reasoning
Mediation Device (TMN)
Management Information Base
Management Information Format
Management Information System
Managed Objects
Native Computer and Communication Environment
Network Element
Network Management Center
Chapter Appendix 6.
79. NMF
80. NML
81. NOC
82. NTU
83. OA
84. ODP
85. OLE
86. OMA
87. OMG
88. OMT
89. OO
90. ORB
91. OSF
92. OSI
93. OSTA
94. OSS
95. PC
96. PCE
97. POTS
98. QoS
99. RBOC
100. RFC
101. RM
102. RMON
103. RPC
104. SCSI
105. SDH
106. SDLC
107. SIGCHI
108. SML
109. SNA
110. SNMP
111. SPIRIT
List of Acronyms
175
Network Management Forum

Network Management Layer (TMN)
Network Operations Center
Network Termination Unit
OfficeAutomation
Open Distributed Processing
Object Linking and Embedding
Object Management Architecture (OMG)
Object Management Group
Object Modeling Technology (Rumbaugh's)
Object-Oriented
Object Request Broker
Open SoftwareFoundation
Open Systems Interconnection (standards)
Open Systems Task Analysis
Operation Support System
Personal Computer
Process Centered Environment
Plain Old Telephone System
Quality of Service
Regional Bell Operating Company
Request For Comments
Reference Model
Remote Monitoring (MIB)
Remote Procedure Call
Small Computer Systems Interface
SynchronousDigital Hierarchy
Systems Development Life Cycle
Special Interest Group on Computer-Human Interaction
Service Management Layer (TMN)
SystemsNetwork Architecture
Simple Network Management Protocol (Internet)
Service Provider's Integrated Requirements for Information Technology
112. SPX
Sequenced Packet Exchange
113. SQL
Structured Query Language
114. SSADM Structured Systems Analysis and Design Methodology
Soft Systems Methodology
115. SSM
Tool Command Language
116. TCL
Total Cost of Ownership
117. TCO
Transmission Control Protocol
118. TCP
119. TINA
TelecommunicationInformation Networking Architecture
120. TMN
Telecommunication Managed Network
Transaction Processing
121. TP
122. TQM
Total Quality Monitoring
123. UDP
User Datagram Protocol
176
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
UI
UML
VGA
VNM
WAN
WAPI
WBEM
WIMP
WISE
WMC
WSF
WWW
XOM
User Interface
Unified Modeling Language
Video Graphics Adapter
Virtual Network Machine (SPECTRUM)
Wide Area Network
WorkflowAPI
Web-Based Enterprise Management
Windows, Icons, Menus, and Pointers
Workflow-based Internet Services
Workflow Management Coalition
Work-Station Function (TMN)
World Wide Web
X/Open Object Management protocol
Bibliography
1. Abeck, S., and Mayerl, C. Modeling IT operations to derive provider accepted management tools, Paper
accepted for the IFIP/IEEE International Symposium for Integrated Management (IM99).
2. Action Technologies Inc, USA. Action Workflow, Available: http://www.actiontech.com/action/.
3. Adensamer, R. J. A process-centric approach to enterprise transformation, IFIP/IEEE Nehvork Operations
and Management Symposium (NOMS96, Kyoto Japan, April 1996).
4. Avison, D., and Fitzgerald, G. Information systems development: Methodologies, techniques and tools
(2nd ed., McGraw-Hill, Berkshire, UK 1995).
5. Avison, D., Lau, E, Myers, M., and Nielsen, P. Action research, Communications oftheACM42( 1) (January
1999).
6. Bapat, S. Object-oriented networks: Models for network architecture, operations and management (Prentice-Hall, 1995).
7. Benford, S., Bowers, J., Fahlen, L. E., Marian J., and Rodden, T. Supporting cooperative work in virtual
environments; The Computer Journal 37(8) (Oxford University Press, UK 1994), pp. 653-668.
8. Benedek, E. The human-centered interface: IBM Research 1&2 (1998), pp. 28-32.
9. Bentley, R., Hortsmann, T., Sikkel, K., and Trevor, J. Supporting collaborative information sharing with
WWW: The BSCW shared workspace system, Fourth International WWW Conference (Boston, December
1995).
10. Blasko, K. Operations process planning: A systems approach, Journal of Network and System Management 1(2) (June 1993), pp. 107-122.
11. Bolling, S., and Xiao, D. Throwing off the shackles of a legacy system, IEEE Computer 31(6) (June 1998),
pp. 104-106.
12. Boloix, G., and Robillard, P. N. A software system evaluation framework, IEEE Computer 28(12)
(December 1995), pp. 17-26.
13. Bowen, D. M. Work group research: Past strategies and future opportunities, IEEE Transactions on
Engineering Management (February 1995).
14. Bruggemann, H. EUROSCOM. Does R&D in DOT and Middleware meet business requirements?
Proceedings of the Joint EURESCOM/COST 248 Workshop (Heidelberg, October 1997).
15. Koegel Buford, J. F. (Contributing editor). Multimedia system. In Middleware system services architecture
(pp. 222-244,Addison-Wesley, ACM Press, New York, USA 1994).
16. Business Week International Edition, Cover story: Software revolution-The
web changes everything
(December 4, 1995), pp. 34-39.
17. Butler, K., Esposito, C., and Hebron, R. Connecting the design of software to the design of work,
Communications ofthe ACM 42(1) (January 1999), pp. 38-46.
18. Cabletron Inc. USA. SPECTRUM 3.0 catalog. Available: http://www.ctron.com/Catalog/Net-ManagemenUSpectrum.html(l996).
19. CACI Corporation. CACI Simulation Products. Available: http://www.cacias1.com/ (April 1999).
20. Carlsen, S., Krogstie, J., Solvberg, A,, and Lindland, O. I. Evaluating flexible workflow systems. Available:
http://www.actiontech.com.
177
178
Bibliography
21. Carlsen, S. Fleksibel arbeidsflyt, DnDpresentation. Available: http://www.informatics.sintef.no/informatics/4030/4031 (March 1997).

22. Checkland, P., and Scholes, J. Soft system methodologies in action (John Wiley and Sons, Chichester, 1990).
23. Chen, H., Nunamaker, J., Orwig, R., and Titkova, O. Information visualization for collaborative computing,
IEEE Computer 31(8) (August 1998), pp. 75-82.
24. Coleman, D. (Ed.), Groupware: collaborative strategies for corporate LANs and intranets (Prentice-Hall,
NJ, USA 1997).
25. Compaq Linkworks. LinkWorks FAQ, documentation and presentations. Available: http://www.digital.com:
8O/.i/info/linkworks/ (March, 1999).
26. CSCW Research at Center for Tele-Information (CTI) Technical University of Denmark. Available:
http://www.cti.dtu.dk/CSCW/ (July 6, 1999).
27. Consens, M., and Hasan, M. Z. Supporting network management through declaratively specified data
visualizations, Third International Symposium on Integrated Network Management (ISINM93, San
Francisco, CA April 1993).
28. Covaci, S., Marchisio, L., and Milham, D. Troubleticketing X interfaces for international private leased
data circuits and international freephone service, Proceedings of IEEE/IFIP Network Operations and
Management Symposium (NOMS98, New Orleans, LA February 1998).
29. Czamecki, P., Jajszczyk, A., and Wilkosz, M. Comparison criteria for GDMO-based network management
information models: A step towards the integration of management systems, Journal ofNetwork and System
Management (JNSM) 4(1) (March 1996), pp. 49-70.
30. Daneshgarh, F., and Ray, P. Cooperative management based on awareness modeling, Eighth IFIP/IEEE
International Workshop on Distributed System Operations andManagement (DSOM97, Sydney, Australia
October 1997).
31. Daneshgar, F., and Ray, P. Towards a general theory of cooperative management, Submitted for publication
(October 1998). Available: http://sistm.webunsw.edu.au/peopldpradeep/#pub.
32. DataTrends Publications, Inc. Systems & network management report, 4th Qtr. 1997. Available:
http://www.systems-management.com/ (1999).
33. Davies, N., Blair, G. S., Cherverstt, K., and Friday, A. Supporting collaborative applications in a heterogeneous mobile environment, Internal Report No. MPG-94-18(Computing Department, Lancaster University, Lancaster U.K., 1994).
34. Denning, P., Hieb, M. R., and Menasce, D. A. Workflow module, Workflow Tutorial, Centerfor the New
Engineer (CNE) (George Mason University, Virginia, 1995). Available: http://cne.gmu.edu/moduledworkflow/index.html.
35. Desprats, T., Marty, J. L., and Barrere E Interaction modeling for structuring cooperative management
architectures, Fifth IFIP/IEEE International Workshop on Distributed Systems Operations andManagement
(Toulouse France, October 1994).
36. Dev, R. Managing the enterprise network: Command and control, Cabletron Systems Inc. (March 1993).
37. Ding, J. Three-dimensional multiresolution video compression strategy for using human visual characteristics, Proceedings of the IEEE International Communications Conference (ICC97, Montreal Canada,
June 1997).
38. Disabato, M. Key technologies for integrated network management, Third International Symposium on
Integrated Network Management (ISINM93, San Francisco, CA, April 1993).
39. Dix, A,, Finlay, J., Abowd G., and Beale, R. Human-computerinteraction evaluation techniques (pp.
363-400), (Prentice Hall, Hertfordshire, U.K., 1993).
40. Dourish, P., and Bellotti, V. Awareness and coordination in shared workspace, Proceedings of ACM
Conference on Computer Supported Cooperative Work (CSCW92, Toronto, Canada, November 1992).
41. Duff, J., Hunter, J. D., and Matthews, D. C. Process management: The future of integrated management
systems, Third International Symposium on Integrated Network Management (ISINM93, San Francisco,
CA, April 1993).
42. Dutta, S., Van Wassenhove, L. N., and Kulandaiswamy, S. European software management practices,
Communications of the ACM41(6) (June 1998). pp. 77-86.
43. Eckerson, W. Case study: The role of IS in reengineering, Open Information Systems 9(2) (February 1994).
44. Edwards, J. M. Development ofan object-oriented methodology and its application to a wastewater resources
problem. Unpublished Doctoral thesis (School of Information Systems, University of New South Wales,
1992).
Bibliography
179
45. Enterprise Management Center Summit 95. Shootout scenarios (Five most important management application scenarios addressed by vendor demos in Summit95, San Francisco, CA, October 1995).
46. EURESCOM. Advanced CSCW tools for telecommuting (ACT): Configuration used for the trials on
telecommuting and evaluation criteria, Deliverable 1, Vol. I & 2, Project P714, (pp. 15-21) (pp. 6-24)
(December 1997).
47. EURESCOM. Troubleticketing and provisioning for international private leased data circuits and international freephone service, PIR 2. l: Harmonized requirements for troubleticketing, Project P612 (March
1997).
48. Evans, C. D., Meek, B. L., and Walker, R. S. (Eds.), User needs in information technology standards
(Buttenvorth-Heinemann, U.K., 1993).
49. Fuchs, L., Pankoke-Babatz, U., and Prinz, W. Supporting cooperating awareness with local event mechanisms: The groupdesk system, Proceedings of the Fourth European Conference on Computer-Supported
Cooperative Work (Stockholm, Sweden, September 1995).
50. Gay, G., and Lentini, M. Use of communication resources in a networked collaborative design environment,
Online Journal of Computer-Mediated Communication 1(1) (1995).
51. Georgakopoulos, D., Homick, M., and Sheth, A. An overview of workflow management From process
modeling to workflow automation infrastructure, Distributed and Parallel Databases, 3 (pp. 119-153,
Kluwer Academic Publishers, the Netherlands, 1995).
52. Ghetie, I. G. Networks and systems management: Platforms analysis and evaluation (Kluwer Academic
Publishers, MA, USA, 1997).
53. Godart, C., Pemn, O., and Skaf, H. Coo: A workflow operator to improve cooperative modeling,
Proceedings of the Ninth International Workshop on Research Issues in Data Engineering: Information
Technologiesfor Virtual Enterprises (Sydney, Australia, March 1999).
54. Goyal, S. Knowledge technologies for evolving networks, Second International Symposium on Integrated
Network Management (ISINM91 Washington D.C., April 1991).
55. Graphics, Visualization and Usability Research Center (GVU Center), Georgia Technological University,
Georgia, CSCW home page. Available: http://www,gvu.gatech.edulgvulcscw/ (February 1999).
56. Greenbaum, J., and Kyng, M. (Eds.), Design at work: Cooperative design of computer systems (pp. 75-85,
Lawrence Erlbaum Associates, Hillsdale, NJ, USA, 1991).
57. Grudin, J. Computer supported cooperative work: History and focus, IEEE Computer Magazine 27(5)
(May 1994), pp. 19-26.
58. Grudin, J. Groupware and social dynamics: Eight challenges for developers, Communications of the ACM,
37(1) (January 1994) pp. 92-105.
59. Guido, B., Roberto, G., Tria, P., and Bisio, R. Work force management (WFM) issues, Proceedings of the
IEE/IFIP Network Operations and Management Symposium (NOMS98, New Orleans, LA, February
1998).
60. Gutwin, C., Roseman, M., and Greenberg, S. A usability study of awareness widgets in a shared workspace
groupware system, Proceedings of the International ACM Conference on Computer Supported Cooperative
Work (CSCW96)(Cambridge, MA, November 1996).
61. Gwynne, P. Wired for life, IBM Research (1&2) (1998), pp. 18-24.
62. Hamada, T., Kamata, H., and Hogg, S. An overview of TINA management architecture, Journal ofNetwork
and Systems Management 5(4) (December 1997), pp. 41 1-436.
63. Harris, G., and Taylor, S. Creating a new process model to support participation and improve coordination,
Center for Quality in Management Journal 6(3) (winter 1997).
64. Hawryszkiewycz, I. Designing the networked enterprise (Artech House, Boston, USA, 1997).
65. Hawryszkiewycz, I. Electronic workspace. Available: http:/flinus.socs.uts.EDU.AU/-igorh/cscw/tools/design/eplace htm
66. Hegering, H., Abeck, S., and Wies, R. A corporate operations framework for network service management,
IEEE Communications Magazine 34(1) (January 1996), pp. 62-69.
67. Hegering, H., Neumair, B., and Gutschmidt, M. Cooperative computing and integrated systems management: A critical comparison of architectural approaches, Journal of Network andSystem Management 2(3)
(September 1994), pp. 283-316.
68. Herman, J. Integrated network management, Tutorial presented at the Third International Symposium on
Integrated Network Management (ISINM93, San Francisco, CA, May 1993).
180
Bibliography
69. Herman, J. Suns solstice: A turning point in enterprise management, Distributed Computing Monitor 10(5)
(May 1995).
70. Hewlett Packard Inc., USA. HP Open View. Available: http://www.openview.hp.com/ (1999).
71. Holtzblatt, K., and Jones, S. Conducting and analyzing a contextual interview, Readings in human-computer
interaction: Towards the year 2000 (2nd ed., Morgan Kaufmann Publishers Inc., San Francisco, CA, 1995).
72. Hong, J. W., Kong, J., Yun, T., Kim, J., Park, J., and Baek, J. Web-based intranet services and network
management, IEEE Communications 35(10) (October 1997).
73. Hallows, R. Service Management in Computing and Telecommunications Artech House, Boston 1995, pp.
57-81.
74. Host Resources MIB, Internet Report For Comments (RFC), Internet Egy. Task Force Document 1993.
75. Hudson, S. E., and Smith, I. Techniques for addressing fundamental privacy and disruption tradeoffs in
awareness support systems, Proceedings of the International Conference ACM Computer Supported
Cooperative Work Conference C6CW96 (Cambridge, MA, November 1996).
76. Hung, Y. C. Dynamic hypermedia presentations: A model and its implementation, Proceedings of the IEEE
International Communications Conference (ICC97, Montreal, Canada, June 1997).
77. Hunvicz, M. Intelligent management agents; Distributed Computing Monitor 10(7) (July 1995).
78. IBM Networking Software Products. Available: http://www.raleigh.ibrn.com/netsoft.html (July 1996).
79. IETF SWAP Working Group. Available: http://www.ics.uci.edu/-ietfswap/ (March 1999).
80. Iishii, H. Message-driven groupware design based on an office procedure model, Journal of Information
Processing (1990).
81. Imielinski, T., and Badrinath, B. R. Wireless mobile computing: Challenges in data management,
Communications of the ACM (October 1994), pp. 19-27.
82. International Telecommunications Union (ITU-T). TMN Roadmap. Available: http://www.itu.int/TMN/
(1997).
83. ISO 10746-X.Reference model for open distributedprocessing (RM-ODP)Parts 1, 2, 3, and 4 (1995).
84. ISO/IEC JTC1/SC 21/WG 4,OSI systems management tutorial (May 1992).
85. ISO JTC1.21.57.UITU-T Q19/7 & 427 CD. QoS-basic framework (Interim Meeting Output, Toronto
Canada, January 1995).
86. ITU-T Recommendation X.790, Trouble management function for ITU-T applications. Available:
http://www.itu.int/plweb-cgi/fastweb?getdoc+viewl+itudoc+5727+1++X.790 (November 1995).
87. Jarzabek, S., and Hwang, R. The case for user-centered CASE tools;" Communications of the ACM 41(8)
(August 1998), pp. 93-99.
88. Johnson, D. NOC internal integrated trouble ticket system functional specification wishlist, Internet RFC
1297 (January 1992).
89. Jones, C. Software change management, IEEE Computer (February 1996), pp. 80-82.
90. Jordan, B. Ethnographic workplace studies and CSCW, Proceedings ofthe 12th Interdisciplinary Workshop
on Informutics and Psychology (Shaerding, Austria, June 1993).
91. Judd, C. M., Smith, E. R., and Kidder, L. H. Research methods in social relations (Holt, Rienhart and Winston
Inc, 6th edition, Fort Worth, USA, 1991).
92. Kahani, M., and Beadle, H. W. P. Immersive and non-immersive virtual reality techniques applied to
telecommunication network management, The Fifth IFIP/IEEE International Symposium on Integrated
Nerwork Management (IM97, San Diego, CA, May 1997).
93. Keller, A. Service-based management: Using CORBA as a middleware for intelligent agents, Seventh
IFIP/IEEE International Workshop on Distributed Systems Operations and Management (DSOM96,
LAquila, Italy, October 1996).
94. Kling, R. Organizational analysis and organizational informatics in computer science, Draft reportfor the
Encyclopedia of Computer Science (April 1994).
95. Koulopoulos, T. The evolution and future of workflow, Delphi Consulting Group white paper. Available:
http://www.delphi.com/pubs/96pubs.html (1997).
96. Larman, C. Applying UML and patterns: An introduction to object-oriented analysis and design (PrenticeHall, Upper Saddle River, NJ, USA 1998).
97. Laudon, K., and Laudon, J. Management informution systems: Organization and technology (Prentice-Hall,
Upper Saddle River, NJ, USA 1998).
98. van Leeuwen, J. (ed.), Handbook of theoretical Computer science, part A: Algorithms & complexity (pp.
527-612,Elsevier Science Publishers, Amsterdam, Holland, 1990).
Bibliography
181
99. Leinwand, A,, and Conroy, K. E Network management: A practical perspective, (2nd ed. Addison-Wesley,
MA, USA 1996).
100. Lewis, L. A fuzzy logic representation of knowledge for detecting/correcting network performance
deficiencies, In I. T. Frisch, M. Malek, and S. S. Panwar, (eds.) Network management and control, Vol. 2
(Plenum Press, USA 1994).
101. Lewis, L. Managing computer networks: A case-based reasoning approach (pp. 126-163,Artech House,
Boston, USA 1995).
102. Lotus Development Corporation. Application developers reference, Lotus Notes Release 3 (1993).
103. Lupu, E. C., and Sloman, M. Towards arole-basedframeworkfordistributed systems management, Journal
of Network and Systems Management 5(1) (March 1997), pp. 5-30.
104. Malone, T. W., Crowston, K., Lee, J., Pentland, B., Dellarocas, C., Wyner, G., Quimby, J., Osbome, C., and
Bemstein, A. Tools for inventing organizations: Toward a handbook of organizational processes (Center for
Coordination Science, Massachusetts Institute of Technology, Cambridge, MA). Available:
http://ccs,mit.edu/CCSWP198 (June 1997).
105. Megadanz, T., and Eckardt, T. Mobile software agents: A new paradigm for telecommunications management, Proceedings of IEEE/IFIP International Network Operations and Management Symposium
(NOMS96, IEEE Press, 1996).
106. Meyer, K., Betser, J., Nagard, E., Persinger, D., Wang, S., Maltese, R., and Sunshine, C. An architecture
driven comparison of network management systems, Third International Symposium on Integrated Network
Management (ISINM 93, April 1993).
107. Meyer, K., Persinger, D., and Phelps, R. Network management station performance metrics, IFIP/IEEE
Network Operations and Management Symposium (NOMS94, New Orleans, LA 1994).
108. Morinaga, N., Nakagawa, M., and Kohno, R. New concepts and technologies for achieving highly reliable
and high-capacity multimedia wireless communication systems, IEEE Communications 35(1) (January
1997), pp. 34-41.
109. Nardi, B. A., Miller, J. R., and Wright, D. J. Collaborative, programmable intelligent agents, Communications of the ACM 41(3) (March 1998), pp. 96-104.
110. Nicol, J. R., Wilkes, C. T., and Manola, F. A. Object orientation in heterogenous distributed computing
systems, IEEE Computer Magazine 26(6) (June 1993), pp. 57-67.
111. Nielsen, H., Ousland, A. R., and Roella, A. UsabiIity testing of CSCW applications and retrieval services:
Results from EURESCOM Project P605-JUPITAR: Proceedings of the Joint EURESCOMKOST 248
Workshop on Future Telecommunication User (Heidelberg, October 1997).
112. Nielsen, J. Noncommand user interfaces, Communications of the ACM 36(4) (April 1993), pp. 82-99
113. Network Management Forum (NMF). A service management business process model (1995). Technical
report from NMF, now known as Telemanagement forum. www.tmforum.org
114. Network management Forum (NMF). OMNIPoint integration architecture (Forum TR114, 1995).
115. Network Management Forum (NMF). Service providers integrated requirementsfor information technology
(SPIRT). Available: http://www.nmf.org/books,htm#spirit (January 1996).
116. Network Management Forum (NMF). Solution and component sets. Available: http://www.nmf.org/sets.htm
(1997).
117. Network management server (NMS). Available: http:Nnetman.cit.buffalo.edu/ (1998).
118. Nynex Corporation USA. Building networks: New York Telephone rethinks work to regain lost customers,
Scientific American (November 1992).
119. Object Management Group. The common object request broker: Architecture and specification. Available:
http://www.omg.org.
120. Oliveira, R., and Labetoulle, J. Intelligent agents: A new management style, Seventh IFIP/IEEE International Workshop on Distributed Systems Operations and Management (DSOM96) (LAquila, Italy, October
1996).
121. Olle, T. W., Hagelstein, J., Macdonald, I. G., Rolland, C., Sol, H. G., Assche, E V., and Verrijn-Stuart, A. A.
Information systems methodologies: A framework for understanding (pp. 26-42,Addison-Wesley, Workingham, England; Reading, MA, USA 1991).
122. Orlikowski, W. J. Learning from NOTES: Organizational issues in groupware implementation, Proceedings of the Conference on Computer Supported Cooperative Work (CSCW92, Toronto, Canada, November
1992).
182
Bibliography
123. Pavlou, G. From protocol-based to distributed object-based management architectures, EighthIFIP/EEE

International Workshop on DistributedSystems Operations andManagement (DSOM97), Sydney, Australia
October 1997.
124. Pham, A., and Karmouch, A. Mobile software agents, IEEE Communications 36(7) (July 1998), pp.
26-37,.
125. Piccinelli, G. Distributed process management: A federative architecture, Ninth IFIP/IEEE International
Workshop on Distributed Systems Operations and Management (DSOM98, University of Delaware,
Delaware, October 1998).
126. Pinsonneault, A., and Kreemer, K. L. The impact of technological support on groups: An assessment of the
empitical research, In R. M. Baecker (Ed.), Readings in groupware and CSCW assisting hum-hum
collaboration (pp. 754-771 Morgan Kaufmann Publishers, 1993).
127. Pontailler, C. TMN and new network architectures, IEEE Communications 31(4) (April 1993), pp. 84-91.
128. Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S., and Carey, T. Human-computer interaction
(Addison-Wesley, Workingham, England; Reading, MA; Menlo Park, CA, 1994).
129. Project WISE. Workflow based Internet SErvices (Swiss Federal Institute of Technology (ETH), Switzerland).
Available:
http://www.inf.ethz.ch/depaNnent/lSliks/
(October
1999).
130. Prozeller, P. TINA and the software infrastructure of the telecom network of the future, Journal ofNetwork
and Systems Management 5(3) (December 1997), pp. 393-410.
131. Ramaswamy, R. Design and management ofservice processes (Adison-Wesley, Reading, MA; Menlo Park,
CA; NY, Don Mills; Ontario; Workingham, England, 1996).
132. Ray, P. Integrated management in a heterogenous environment (Unpublished masters Thesis, University of
Technology, Sydney, Australia, 1994).
133. Ray, P., and Fry, M. Integrated management in a mobile environment: A TINA perspective, Proceedings
of the International Conference TINA95 (Melbourne, Australia, February 1995).
134. Ray, P. Cooperative management of enterprise networks (Unpublished doctoral dissertation, University of
Technology, Sydney, Australia, July 1996).
135. Ray, P. Integrated management of enterptise networks: A group cooperation perspective, IEICE Transactions on Communications E80-B(6) (June 1997).
136. Ray, P. A new methodology for the development of CSCW systems, IFIP International Conference on
Systems Implementation (SI2000, Berlin Germany, February 1998).
137. Ray, P. Evaluation methodology for network management systems, IEEE/IFP Network Operutions and
Management Symposium (NOMS98, New Orleans, LA, February, 1998).
138. Ray, P., Loge, C., Gay, V., and Fry, M. Cooperative network management from ODP viewpoints, IFIP
Conference for Upper Layer Protocol Architectures and Applications (ULPAA). Available:
http://www.cit.nepean.uws.edu.au/-pradeep (1995).
139. Redlich, J., Suzuki, M., and Weinstein, S. Distributed object technology for networking, IEEE Communications 36(10) (October 1998), pp. 100-111.
140. Rodden, T. Populating the application: A model of awareness for cooperative applications, Proceedings
of the International Conference ACM (CSCW96, Cambridge, MA, November 1996).
141. Rodden, T. Computer supported cooperative work. Available: http://www.comp.lancs.ac.uWcomputing/users/tam/MSC-Slides/msc1/index.htm (1997).
142. Rose, M. T. The simple book (Prentice Hall, Englewood Cliffs, NJ, USA 1991).
143. Rubin, H., and Natarajan, N. A distributed software architecture for telecommunication networks, IEEE
Network (January/February 1994).
144. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. Object oriented modeling and design
(Prentice Hall, NJ, USA 1991).
145. Rymer, J. R. Network and systems management road map, Distributed Computing Monitor 9(11)
(September 1995), pp. 3-25.
146. Sachs, P. Transforming work: Collaboration, learning, and design, Communications of the ACM 38(9)
(September 1995).
147. SAP AG. SAP at a glance. Available: http://www.sap.com (October 1996).
148. Sconwalder, J., and Toet, M. Management of World Wide Web, EighthIFIP/EEE International Workshop
on Distributed Systems Operations and Munugement (DSOM97, Sydney, Australia, October 1997).
Bibliography
183
149. Sheth, A., Kochut, K., Palaniswami, D., Zheng, K., Worah, D., Das, S., and Lin, D. METEOR2: Designer/builder and web (Large Scale Distributed Information System Laboratory, University of Georgia,
Athens, Georgia March 1997).
150. Shevenell, M. Applications management: The great inoperability war, Network World 12 (March 13,1995).
151. Shrewsbury, J. K. An introduction to TMN, Journal of Network and Systems Management (JNSM) 3(1)
(March 1995).
152. Sloman, M. (Ed.), Network and distributed systems management (Addison-Wesley, Workingham, England;
Reading, MA, USA 1994).
153. Spaniol, O., Fashbender, A., Hoff, S., Kaltwasser, J., and Kassubek, J. Impacts of mobility on telecommunication and data communication networks, IEEE Personal Communications Magazine 2(5) (October
1995), pp. 20-33.
154. Staffware PLC. Staffware white papers. Available: http://www.staffware.comlhome/whitepapers (March
1999).
155. Stallings, W. SNME SNMPv2, andCMIP-the practical guide to network management standards (AddisonWesley, Reading, MA, USA 1993).
156. Stallings, W. SNME SNMPv2, and RMON-Thepractical guide to network management standards (Addison-Wesley, Reading, MA, USA 1996).
157. Sturm, R. Application MIBs: Taming the software beast, Data Communications on the Web: Case Studies.
Available: http://www.data.com/index.html (December 1995).
158. Suchman, L. A. Plans and situated actions: The problem of human machine communication (Cambridge
University Press, Cambridge, NY, USA 1991).
159. SunSoft Solstice Products. Solstice intranet management products. Available: http://www.sun.com/solstice/telecom/ (March 1999).
160. Support Solution Pty. Ltd. Quantum series help-desk user guide (1992).
161. Telecommunications Information Networking Architecture Consortium (TINA-C). TINA business model
and reference points, Version 4.0 (May 1997).
162. Teng, J. T. C., Jeong, S. R., and Grover, V. Profiling successful reengineering projects, Communications
of the ACM41(6) (June 1998), pp. 96-102.
163. Thompson, P. Web-based enterprise management architecture, IEEE Communications Magazine (March
1998).
164. Tivoli Systems Inc. Managing business systems. Available: http://www.tivoli.com/o-products/html/body_products.html#bus sys (July 1998).
165. Tribe Inc. New WebManagetechnologyprovides networkmanagement via the World Wide Web. Available:
http://tl2.tribe.com/ (1995).
166. De Troy, 0. M. E, and Leune, C. J. WSDM: A user centered design method for web sites, Computer
Networks and ISDN Systems 30 (June 1-7,April 1998), pp. 85-94.
167. Umar, A. Object-oriented client/server internet environments (Prentice-Hall, NJ, USA 1997).
168. Valta, R., and Jager, R. Deploying group communication techniques in network management, Third
International Symposium on Integrated Network Management (ISINM III, San Francisco, CA, April 1993).
169. Wade, V., Lewis, D., Donnelly, W., Ranc, D., Karatzas, N., and Rao, S. Design and development of service
management systems in an open service market, In Paulo T. de Sousa (Ed.), The ACTS/NiChains guidelines
for the intemperability of broadband networks (Baltzer Science Publishers, 1998).
170. Walters, R. Computer-mediated communications: Multimedia applications (Artech House, London, UK
1995).
171. Weiser, M. Some computer science issues in ubiquitous computing, Communications of the ACM 36(7)
(July 1993), pp. 75-84.
172. Wies, R. Policies in integrated network and systems management (Unpublished doctoral dissertation,
Department of Computer Science, University of Munich, Germany, June 1995).
173. Willets, K. J., and Adams, E. K. Managing a broadband environment: You cant buck the market, IEEE
Communications 34(12) (December 1996), pp. 108-113.
174. Winograd, T., and Flores, E Understanding computers and cognition: A new foundation for design
(Addison-Wesley, New York, 1987).
175. Workflow Management Coalition. The workflow reference model (Specification Document Number TCOO1003, November 1994).
184
Bibliography
176. Workflow Management Coalition. Workflow and internet: Catalysts for radical change. Available:
http://www.wfmc.org (June 1998).
177. Workflow Management Coalition. Available: http://www.aiim.org/wfmc/mainframe.htm (March 1999).
178. Young, P. HELP! I need somebody, Network World (May 1996).
Index
Action workflow, 61-62,102-110

action workflow loop, 62
of generic cooperative mgmt, 108
of knowledge-base, 110
of multiparty discussion, 109
of troubleticketing, 108
Agent,
autonomous, 28,30, 102, 107, 108
in conceptual mgmt model, 8, 12,22,23,50
intelligent, 11,22,23,25,35,41, 110, 122
mobile, 31, 40
AI. see Artificial intelligence.
AL.see Awareness level.
Analysis, 80-96
CoMEN scenario, 4,60,71,112
co-operation, 94,98, 100, 102
cooperative management, 65-99
interaction analysis, 80, 83-87
Application design,
of CSCW, 105-110
Application/services management, 6,7, 12, 14, 17,
21.40, 149
Artifacts, 29,53-55,57,67,72-74
Artificial intelligence(A1). 22, 24, 27, 31, 33, 41, 50,
120,127, 128, 149
Asynchronous Transfer Mode (ATM), 30, 144,146
Audibility, 81
Automation, 2,3, 32, 33, 39,42,49, 50, 105, 107, 146
Awareness/Awareness level(AL),4,29,31,54-56,
104,105,111-115,
60,66,69,80,87-99,102,
120, 121, 130, 150
BML. see Business Management Layer
Business model,
TINA, 16
Help-desk, 3-4, 105-106,
Business Process Reengineering (BPR), 2
Business/enterprise management layer (BML) of
TMN, 4, 14,16, 17
185
Change management, 68,69,72,75, 83,92,94,97,

98, 106, 107, 115,139, 142, 145, 146
Checklist evaluation, 136-140
Client-server, 2,6, 9, 16, 50,73, 118, 120, 123
CMIP, see Common Management Information
Protocol.
Collaborative, 28,29, 32, 35,53, 55, 69,74, 80-83,
99,104
CoMEN. see Cooperative Management Methodology
for Enterprise Networks.
Common Management Information Protocol(CMIP),
8, 10, 12-14,44,50, 129
Computational infrastructure, 6.43,
Computational viewpoint of ODP, 13, 112
Computer supported cooperative work(CSCW), 27-46
benefits of, 31 -32
application design, 105-111
evolution, 32-34
methodologies, 51
platform considerations, 120
scenarios of a CSCW system, 74-78,87-97
Computer telephone integration (CTI), 30-31
Cooperation analysis 80 87-96
Cooperative management, 87, 97-99
Analysis, 65-99
Design of, 101-124
Architectural Design Of, 112-118
Environment, 115
Requirements, 1 16
Framework, 117
Cooperative management methodology, 47-50
problem domain, 48
CSCW methodologies, 51
Cooperative Management Methodology for
Enterprise Networks(CoMEN), 1, 2,4
Advantages of, 63
evaluation criteria, 127-130
models of, 52-56
186
Cooperative Management Methodology for

Enterprise Networks(CoMEN) (continued)
notations, 59-61
process Of, 56-59
Copresence, 81
CORBA,10,11,13-15,17-20,24,25,36,44,
48-50,59,102,111,117-120,123,129,151
Cotemporality, 81
Distributed computing systems, 1,
Element management layer(EML) of TMN, 14,17
Email,5-6,23,35,39-41,67-72,82,89,97-98,
104-105,110-111,121-122,130,136,
Engineering view point, 13-14
Enterprise analysis, 60,66,72, 80, 86
Enterprise networking, 1,36, 124,125, 143,
Enterprise viewpoint of ODP, 13,20,
Ethnographic, 66-67,80,150
Evaluation criteria of integrated management
systems, 127-135
application level, 129-130
human user level, 130
instrumentation level, 128-129
platform level, 129
for Enterprise Management, 130
Evaluation methodology, 125-127
Evaluation steps of CoMEN, 134-136
checklist evaluation, 136-141
heuristic evaluation, 141-146
Fault management, 8, 12,68-69,72,98, 105, 115,
123,130
Focus, 80
Groupware,20,21,27,28,34-3a,46-47,53,59,
97-98,101,103,105,111, 114-123,130,131,
142,145-146
HCI. see human computer interaction
Helpdesk, 3,4, 10, 12,14,21,28,31-32,40,46,52,
65,68-78,81-97,101,105-111-115,
149
119-121,123,125,141-143,145-146~
Heuristic evaluation, 3,4,59, 125,126,136, 141-146
Human computer interaction (HCI), 30,31,58,80,
126,127, 130
IETF. see internet engineering task force
IMA. see intelligent management agent
Information infrastructure, 6,20,21
Information systems methodologies, 1,4,58
Information view point of ODP, 13, 18
Integrated management, 2,21
Concepts, 6-10
evaluation criteria of, 127-130
evaluation framework, 133-135

framework of, 8
instrumentation, 8-9
platforms, 8-9
applications, 9-11
standards, 12-18
Integrated Service Digital Network (ISDN), 71-72
Intelligent management agent(MA), 22
Interaction analysis, 66,83-86,151
Internet engineering task force(IETF), 7.9.12
Internet,
8-10,12,14,18,20,30,43-45,81-82,117,
128-129
Interpretive evaluation, 126
Java management API(JMAPI), 23
Knowledge-base(KB), 10,20,82, 84,92,95,98,
105-107,109-111,123
workflow, 110
Local area network(LAN), 8, 12
Managed objects, 7-8,12-13,18,49,151
Management Information base(MIB), 7-8,12,18,23,
44,82,103,105-106,118,123,127-129
Management information systems(MIS), 12,48
Management infrastructure, 6, 13,25,32, 128
Management model, 7-8,13, 16, 116-117, 130,
150-15 1
Management policies, 22,24-25
Management protocol, 7, 8, 12, 18.50,
Methodologies, 1,3,38,42,46,47-49,51,54,58,
63,65-66,112,
CSCW, 51-52
Evaluation, 125-127
Information systems, 1,4,58,
Integrated management, 48, 141, 144
MIB. see management information base
MIS. see management information systems
Multiparty discussion workflow, 109
Network management, 2-149 21-25, 289 33p49,
69-72,86,98,125,128,142,144-146,149
Network Management Centre (NMC), 70-77.87-96,
136-137
Network management layer(NML) of TMN, 14, 17
Nimbus, 80
Notations,25,43,47,48,51,54,66,80,84,
COMEN, 59-62
Object-Oriented (OO), 1-2, 10-13, 17, 23,25,
29-30,35-36,48-49,52-53,58-59,63,
101-102,104-105,116-120,149
187
Index
Open distributed processing(ODP)/RM-ODP, 5, 10,
14,19-20,49,59,75,102-103,111-112,
129-130
ISO ODP, 13-14
Operation support systems (OSS), 33
OS1 management, 5-6,8,12-19
Participative, 52, 126
Plain Old Telephone Service (POTS), 82-85,
Predictive evaluation, 126
Problem management, 21,67,69,98, 105-107,145
Process management, 20-21,25
Prototype/ Promtyping environment, 2,-% 57,59,66,
96,101-102,119-121,124-126,136,141,
145,152
Quality of Service (QoS),45,99-100, 127, 133
Questionnaire, 66, 126-127, 130, 141-143
Repository/repositones, 52-53,55, 57-58, 60, 67,
80-87,89-93, 97-99,104-105, 112-1 13-1 15,
120-121,130,136-141
Response time, 125, 127, 129-130,134
Rich picture, 55,60,66, 151
Reviewability, 81
Revisability,81
Roles, 13, 15-17,21-22, 34-39,42-43,52-55,
69-72.80-96,105-115,127,136-143
Change Manager, 70,74-79,89-96
External Expert, 70,74-79,89-96
In-house Expert, 70,74-79,89-96
NMC Manager, 70,74-79,89-96
Operator, 70,74-79, 89-96
NMWest Technician, 70,74-79,89-96
User, 7 1,74-79,89-96
Satisfaction Level(SL), 55,65, 80, 84,87, 88-89,96,
101, 150-151
Scenarios,23,51-58,65-66-73,80,83-85,87-89,
96-99,123,125-127,136-144,151
scenario1, 74-75,89-91
scenario2,75-76,91-94
scenario3,76-77,94-95
scenario4,77-78,95-96
scenario5,78-79,96
Sequentiality, 81
Service management / Service Management Layer
(SML) of TMN, 1-4,6-7,12,14, 17,20-22,
25,40-42, 149
Simple network management protocol (SNMP), 5,
7-10,12-13,18-20,22-25,44,50,72-73,
117-118, 123, 128-129
Simultaneity, 81
Specifications workflow of,
cooperative management, 108
knowledge base(KB), 110

Multiparty discussion (TALK), 109
Trouble-ticketing (TT), 108
Standards for Integrated Management,
Comparison, 18
DMTF DMVCIM, 18
Internet SNMP, 12
ISO/ITU OS1management, 12
ISO ODP, 13-14
ITU Telecommunications
Management Network(TMN), 14
TINA, 14-17
Systems Management, 1,2,6-7, 12-13, 18-22,34,
39,45,48,68,109-110,127-129,
149
Technology view point of ODP, 13
Telecommunications Information Networking
Architecture consortium (TINA), 3-58, 10,
13-18,20-22.25-27,129
Business reference model, 17
comparison ofTINA & TMN, 16
software architecture of, 15
Telecommunications Management Network (TMN),
3-5,10,14,17,18-20,23-25,130,141
Troubleticketing (m), 9-10,13-14,20,32,37-38,
40-41,45-46,65-66,69-72
ODP computational view point of, 11 1-112
workflow of, 108
User interfaces (UI), 23-24, 117-120, 124
Visibility,81
Visualization, 23-25,87,96-97,116-117,120,
127-128-130,134,141-143,145
Voice mail, 82,
Web-Based Enterprise Management (WBEM), 23
workflow management, 53-54
Workflows, 39-46,105-111
Adhoc, 40
Document centric, 41
KnowIedge-based,41
Mail centric, 41
Object-based, 41
Process centric, 41
Transactiona-based, 40
Telecommunication service management, 39-40
Workflow classification, 40-42
Workflow management, 42-43
Workflow Management Coalition (WfMC), 42-45
Workflow reference model, 43-45
Workgroup collaboration, 34-35
World Wide Web Oyww), 23-24,29-31,71-74,
116-120

(Springer) Cooperative Management of Enterprise Networks

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

(Springer) Cooperative Management of Enterprise Networks

Uploaded by

Copyright:

Available Formats

Cooperative Management of

NETWORK AND SYSTEMS MANAGEMENT

BASIC CONCEPTS FOR MANAGING TELECOMMUNICATIONS

Kluwer Academic Publishers

2002 Kluwer Academic Publishers

Cooperative Management of Enterprise Networks

This page intentionally left blank

Integrated Management ofEnterprise Networks .

2.1. What Is Integrated Management? . . , . , . . . . . . . . . . . . . . . .

Cooperative Management of Enterprise Networks

2.6.4. Management Policies . . . . . . . . . . . . . . . . . . . . . .

Computer Supported Cooperative Work (CSCW)

3.1. What is CSCW? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1. Cooperative Management Methodology . . . . . . . . . . . . . . . . .

5. Cooperative Management Analysis

Cooperative Management of Enterprise Networks

5.3.4. Usefulness of the Awareness Model

6 . Design and Implementation of a Cooperative Management System

6.1. CoMEN Design Methodology . . . . . . . . . . . . . . . . . . . . . .

7.1. Evaluation Methodology . . . . . . . . . . . . . . . . . . . . . . . . .

7.5.2. Background of Experts . . . . . . . . . . . . . . . . . . . . . .

Conclusions and Future Challenges

Part A: Integrated Management Problem . . . . . . . . . . . . . . . . .

A . 1. Trouble-Ticketing Database (TBLTKT) . . . . . . . . . . . . . . . . . . 153

Cooperative Management of Enterprise Networks

A . 2 . 4 . Submitting a Change Management Problem Report to the

This page intentionally left blank

Cooperative Management of Enterprise Networks

1.2. BACKGROUND AND MOTIVATION

1.3. RELATED WORK

of telecommunication service management processes based on international standards for

1.4. ORGANIZATION OF THE BOOK

Cooperative Management of Enterprise Networks

Chapter 4 illustrates CSCW concepts through the development of CoMEN, based on

Cooperative Management of Enterprise Networks

2.1. WHAT IS INTEGRATED MANAGEMENT?

Integrated Management of Enterprise Networks

Figure 2.1. The information infrastructure.

management, and services management. For example, a stockbroker may be performing

Cooperative Management of Enterprise Networks

Conceptual management model.

Integrated Management of Enterprise Networks

Integrated management framework.

Cooperative Management of Enterprise Networks

2.3. MANAGEMENT APPLICATIONS

Integrated Management of Enterprise Networks

Functional model of enterprise network management.

Cooperative Management of Enterprise Networks

2.4. INTEGRATED MANAGEMENT STANDARDS

Although some of these standards are being implemented by some telecommunications

ISO/ITU OSI Management

Integrated Management of Enterprise Networks

Cooperative Management of Enterprise Networks

ITU Telecommunications Management Network (TMN)

A TMN is a network to provide surveillance and control of another telecommunication

Integrated Management of Enterprise Networks

Figure 2.5. TINA software architecture.

Cooperative Management of Enterprise Networks

Network management standards in IMF.

Integrated Management of Enterprise Networks

TINA business reference model.

Computational: this dimension is concerned with the management of various aspects

Business Management Layer