Cooperative Management of Enterprise Networks (Network and Systems Management)

Cooperative Management of Enterprise Networks NETWORK AND SYSTEMS MANAGEMENT Series Editor: Manu Malek LucentTechnol...

Author: Pradeep Kumar Ray

30 downloads 780 Views 1MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

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.


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


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

.,,.......,.....................

1

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

X


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



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 today’s 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

2


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

3

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.

4


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

Today’s 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 provider’s 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

6


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

7

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 stockbroker’s 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 Today’s 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

8


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.


9

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 Group’s (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 ISO’s 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 today’s 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 can’t 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 today’s 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 people’s 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 user’s 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 user’s 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 individual’ssuccess 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 person’s 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 customer’s 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 user’s 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

I

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

3.6. CHAPTER SUMMARY 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 system’s 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

Cooperative Management of Enterprise Networks •

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

S

Customers

S

M

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

N

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 Rumbaugh’s 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.

4.8. CHAPTER SUMMARY 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 analyst’s 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 people’s 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.

Cooperative Management Analysis

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 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 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 Role U2 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 Role A). 4. The help-desk operator contacts users who have ordered provisioning and informs NMC (Role A Role U). 5. The NMC technician contacts users to find the need (Role B Role U).

76


Figure 5.3.

Process diagram of Scenario 2.

6. The NMC technician consults an expert if required (Role B 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 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 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 Role D). *6. An NMC expert discusses security with U2 (Role D Role U2). 7. The NOC security expert (U2) and the originator (U1) discuss (Role U2 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 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 Role Gb). *2. The NMC manager finalizes the solution in consultation with the expert (Role E Role D). *3a. The NMC expert consults with a vendors expert (Role D Role Gv). 3b. The NMC expert and an NMC technician discuss implementation (Role D 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 Role U1).

14. The NMC expert requests special monitoring action from a NMC technician (Role D 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 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 one’s 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 one’s 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. ( 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 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 &

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

3

C2

3

C2

2

C2 (video conference) C5

None

C2 (POTS)

0

C6, C2, C3

System design should prevent this

C5,C2 C5

8 3

C2

Automatic change impact notification

,

T2, T7 T8-Change mgmt syst. T2,T5

8

T2,T5

T3

C5,C3,C2 (POTS) Cl,C3,C2 (POTS) C5

T8

C5

0

T8 T5 None

C5 C5 C1, C3, C2 (POTS)

8 9 0

None

C2(POTS)

3

Automatic change impact notification Automatic change impact notification Automatic change impact notification No ack. from users

4 2

0

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 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 Role U2 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 organization’s 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)

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 provider’s 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 other’s 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 other’s framework, but configuration needs) none about other user’s 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.

3

3

3

2

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 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 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 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. The low level of user satisfaction can be partly attributed to the lack of required 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 initiator’s name so that users can remind the person.

Chapter 5.

93




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).

0

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).

0

0

0

0

0

0

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 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 The low level of user satisfaction can be partly attributed to the lack of required awareness support. There are other factors described as follows: Most of the problems are


User Scenario, Interaction

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

4

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 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 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 The low level of user satisfaction can be partly attributed to the lack of required 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


Awareness Required Awareness Supported

User Satisfaction Level

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).

0

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).

0

Remarks In this case, lack of awareness has created a potentially dangerous situation for the organization.

0

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 today’s 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.

5.5. CHAPTER SUMMARY 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 today’s 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. Spectrum’s 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.

6.9. CHAPTER SUMMARY 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 user’s 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 member’s 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 value with values “true” or “false”; list



Enumerative

List

Enumerative

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

9

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

Cooperative Management of Enterprise Networks •

•

• • • •

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 isn’t 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.

7.6. CHAPTER SUMMARY 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 Checkland’s 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 today’s 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 caller’s 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 customer’s 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 author’s 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 doesn’t 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 caller’s 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 caller’s 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 caller’s 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 caller’s 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 database’s 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 author’s 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 caller’s 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 problem’s 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 group’s 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 owner’s 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 organization’s 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 product’s 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 organization’s 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 call’s 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, it’s 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 originator’s (often the caller’s) address, phone number, fax number, and e-mail address right on the document. To find the originator’s 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 application’s 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 organization’s 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 doesn’t 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 can’t 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 Colleen’s 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 don’t 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 can’t 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 [email protected] 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 (NOMS’96, 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 (ISINM’93, 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 (NOMS’98, 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 (DSOM’97, 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 (ICC’97, Montreal Canada, June 1997). 38. Disabato, M. “Key technologies for integrated network management,” Third International Symposium on Integrated Network Management (ISINM’93, 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 (CSCW’92, 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 (ISINM’93, 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 Summit’95, 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 (ISINM’91 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 (NOMS’98, 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 (CSCW’96)(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 (ISINM’93, San Francisco, CA, May 1993).

180

Bibliography

69. Herman, J. “Sun’s 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 C6CW’96 (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 (IM’97, 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 (DSOM’96, L’Aquila, 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 developer’s 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 (NOMS’96, 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 (NOMS’94, 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 provider’s 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 (DSOM’96) (L‘Aquila, 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 (CSCW’92, 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 (DSOM’97), 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 (DSOM’98, 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 TINA’95 (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 (NOMS’98, 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 (CSCW’96, 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 (DSOM’97, 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 “WebManage”technologyprovides 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 can’t 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

Cooperative Management of Enterprise Networks (Network and Systems Management)

Cooperative Management of Enterprise Networks (Network and Systems Management)

Cooperative Management of Enterprise Networks (Network and Systems Management)

Principles of Computer Systems and Network Management

Web Services in the Enterprise: Concepts, Standards, Solutions, and Management (Network and Systems Management)

Web Services in the Enterprise: Concepts, Standards, Solutions, and Management (Network and Systems Management)

Web Services in the Enterprise: Concepts, Standards, Solutions, and Management (Network and Systems Management)

Service level management for enterprise networks

Cisco - Network Management within Campus Networks

Workflow Management: Models, Methods, and Systems (Cooperative Information Systems)

Workflow Management: Models, Methods, and Systems (Cooperative Information Systems)

Networks: Design and Management

Networks Design and Management

Management Accounting in Enterprise Resource Planning Systems

Network Management Fundamentals

Technology Systems and Management

Advances in Network Management

Network Management SNMP (excerpts)

Management of Multimedia Networks and Services

Management of Multimedia Networks and Services

Management of Multimedia Networks and Services

Management, Control, and Evolution of IP Networks

Cooperative Systems

Human Systems Management: Integrating Knowledge, Management and Systems

Enterprise Information Systems Design, Implementation and Management: Organizational Applications

Next Generation Telecommunications Networks, Services, and Management (IEEE Press Series on Network Management)

Cooperative Cellular Wireless Networks

Alfresco Enterprise Content Management Implementation

Trends in Enterprise Knowledge Management

Knowledge management: systems and processes

Cooperative Management of Enterprise Networks (Network and Systems Management)