EMBEDDED SUPPORT SERVICES FOR WEB APPLICATIONS DELIVERED THROUGH

Dep. of Computer Science Institute for System Architecture, Computer Networks Group

Master Thesis

EMBEDDED SUPPORT SERVICES FORWEB APPLICATIONS DELIVEREDTHROUGH THE CLOUD

Xiaolong GouMat.-Nr.: 3735572

Supervised by:

Prof. Dr. rer. nat. habil. Dr. h. c. Alexander SchillAdvised by:

Dr.-Ing. Josef SpillnerDipl.-Wirt.-Inf. Tobias Julius NeubertSubmitted on 23. September 2013

TECH N ISCH.EUNIVERSITATDRESDENfatrlttit tnformatik, lnstitut fur Systemarchitektur, Lehrstuhl Rechlelnglze

AUFGABENSTELLUNG FUR DI E MASTERARBEIT

Name, Gou; Xiaol

FoischunEsgebiet: Service and Cloud Forschungspt"ojekt: FlexCloudComputing

as

il\-

Vera ntwortl i cher Fl'ochsc hu I le hrer: Prof. Dr. rer. nat. habil. Dr. h. c.Alexander Sch,ill

Thema: Embedded Support Services tor Web Appllcatlons oellvereothrough the Cloud

ZIELSTELLUNG

Software delivered on demand as a service from the Cloud provides benefits to

users who only need lnternet access and a service frontend such as a web browser.products of this type like SAP Cloud solutions are advantageous for customers,

especially smaller enterprises, to reduce costs and implementation time and effort.

Customers only pay forthe usage of the software depending on the demand.

lntegrated support functionalities play an essential role for Cloud products,

especially for the provisioning of interactive applications. lh"y are. essential

because this scheme of hosting software transfers the cost of software maintenance

and management from the service consumers to the providers. As a result'

efficienly providing the service in this mass market is vital for vendor success'

Embedded support in software life cycle management focuses on the above

mentioned business goals. lt provides tools for users to report software problems at

any point in usage time directly from the software application's Ul. lt also provides

tools for tracking and resolving software issues. From a service science perspective,

support services are bundled along with the domain-specific application services'

SAp Business ByDesign is an on-demand enterprise software product with well-

developed ämbedded support. The graphical user interface is currently

implemented with a proprietary web browser plug-in which does not guarantee

good coverage on mobile devices. To reach as many users as possible, on-deman-d-

iervice vendors have to leverage the advantages of HTMLS, which is broadly

available both on mobile devices as well aS on traditional front ends.

This master thesis will investigate techn.ical solutions to meet requirements of

embedded support especially in web based applicationt *itf' a usei interface based

on JavaScript. Reference to the existing functions in ByDesign will be taken' lt will

also describe and compare implementations of functionalities based on the results

of the investigation. Key aspects will be efficient and.user-friendly means for context

data (like user OS, browser type, etc.) collection, the user-supp:'t interaction, as

well as söftware problem solution search. On top of this practical work, the thesis

will also suggest methods to measure and analyse the contribution of the

implementations to an effective and efficient support process.

Services for Web Applications delivered

SCHWERPUN KTE

I Analysis and comparison of, efibedded suppor:t services in cornmercial'SaaS,resu lting i n a reusa ble Su pport'a,5;a,Service, defi niti on

o Concept for embedded support services with dynamic web interfaöes, consistentUl design with existing approaches, and multi-application 5urpport ,based on

' loose:coupling and tight integr:ation

. lmplementation as a web application conforming to HTML5 and JavaScript to

ensure compatibility with web browsers on mobile platforms

. Scherne for systematic measur:bment of sup$ort,effectivity'and efficiency

u n te rs ch ri tt a eS v eira ntw o rtl i ch e n H o c h sc h u I I e h re rs

Prof. Dr. rer. nat. habil. Dr. h, c. Alexander Schill

CONFIRMATION

I confirm that I independently prepared the thesis and that I used only the references andauxiliary means indicated in the thesis.

Dresden, 23. September 2013

v

ACKNOWLEDGEMENTS

I would like to first thank Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill for giving me theopportunity to write this thesis in his research group.

I would like to thank a lot my advisor Dr.-Ing. Josef Spillner for his continuous support andsteering my work during the past months. His openness, patience, commitment and efforts arecrucial for me getting to this point.

Many Thanks to Dr. Tilmann Haeberle from SAP AG who accepted me again as a studentemployee and provided me resources and channels to conduct my research and implement myprototype in the industry.

I would like to thank my internship mentor and thesis advisor Mr. Tobias Julius Neubert fromSAP AG who showed me the way to reach my thesis targets with precise planning, strictexecution, agile adjustments and retrospective inspections. His help and friendliness made thepast months real pleasant memory.

I would like also to thank Mrs. Martina Keller, Dr. Bettina Gaa-Frost and Mrs. Alda Dollani fromthe cloud supportability team, Mr. Uwe Schlenker, Dr. Ralph Radermacher, Mrs. Beatrice Pasch,Mr. Juergen Heiss, Mrs. Rosamund Armstrong, Mr. Hans Gradl, Mr. Uwe Wieditz, Mrs. NidhiAggarwal, Mr. Lars Riecke, Mr. Robert Gaida, Mr. Markus Melchinger, Mr. Forrest Zhang, Mr.Steen Tirkov, Mr. Sascha Zankel, and Mr. Prasanth Rajan from various SAP organizations globallyfor accepting my interviews and giving precious feedback to my work.

Special thanks are given to my family, my girlfriend Wenqian Wang and my friend Deborah AnnHoward for inspiring me to study in Germany, and most importantly simply for how you are. Youare the reason that I’ve never thought about giving up.

vii

ABSTRACT

Integrated support functionalities (Embedded support) play an essential role for cloudsoftware products in reducing the operational cost of the software service providers andimproving overall user experience of the software service consumers. The current embeddedsupport services based on ticket systems have made it possible for the end users to reportsoftware issues at any time and anywhere (UI components) in the products conveniently. Thecurrent embedded support services have drawbacks such as low first response time, poorquality of the created tickets (such as essential information to solve the issue, misleadingdescription, etc.), low efficiency of communication between problem reporters and peoplesolving the issues, and lack of interaction means.

This thesis addresses the above mentioned problems by suggesting a new support servicedelivery model complementary to the existing ticket systems and implementing a softwareprototype based on the eXtensible Messaging and Presence Protocol. Unlike the many thirdparty chatting products on the market which are functionally chat-centric, the implementedprototype provides access to different types of predefined context information thanks to itsnature of being embedded in the product itself. Therefore the thesis implementation is fullycontext-centric and delivered to the users as part of the whole embedded support services ofthe cloud product.

The thesis also provides results from experiments and questionnaires to demonstrate theeffects and potential of the prototype. It shows that the prototype implements the embeddedsupport services with desired features and in good quality. According to the stakeholders’views, the suggested embedded support services will improve the overall process of handlingsoftware issues in SaaS organizations.

ix

CONTENTS

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Definition of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5 Description of Remaining Chapters . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Goal Setting 9

2.1 Review of Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Software Support Model and Software Support Services . . . . . . . . . . 9

2.1.2 Software Bug Report(Ticket) Quality and Coefficients . . . . . . . . . . . . . 11

2.1.3 Internet Instant Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.4 Internet Instant Messaging (IIM) Protocols Comparison . . . . . . . . . . . 14

2.1.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Field Study: State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 Embedded Support in Enterprise SaaS . . . . . . . . . . . . . . . . . . . . . 16

2.2.2 Enterprise SaaS Support Structure . . . . . . . . . . . . . . . . . . . . . . . 16

xi

2.2.3 Live Support Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.4 Compare and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Goals and Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.1 Goal: Live Chat for Fast First Response . . . . . . . . . . . . . . . . . . . . 21

2.3.2 Goal: Templates for Efficient Communication . . . . . . . . . . . . . . . . . 22

2.3.3 Goal: On-line Diagnose with Live Chat . . . . . . . . . . . . . . . . . . . . . 23

2.3.4 Goal: Live Chat - Solution Search Integration . . . . . . . . . . . . . . . . . 23

2.3.5 Goal: Chat Assistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Embedded Support Services Concept and Design 25

3.1 Concept Precap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Embedded Support Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4 Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5 Structural Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.5.1 XMPP Client-Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . 32

3.5.2 JavaScript XMPP Client Structural Architecture . . . . . . . . . . . . . . . . 32

3.6 Process Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.7 Graphical User Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Implementation 41

4.1 Development Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1.1 Programming Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1.2 XMPP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.3 Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

xii Contents

4.1.4 Implementation Baseline (existing feature to be adapted and reused) . . . . 42

4.1.5 Packages Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2 Bundling of Embedded Support Services . . . . . . . . . . . . . . . . . . . . . . . 44

4.3 Basic Chatting Service: Connection Management, Message and Contact Handling 45

4.3.1 Connection Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3.2 Contact/Roster Management . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3.3 Message Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.4 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.5 Web-based Collaboration Service for Embedded Support . . . . . . . . . . . . . . 49

4.5.1 Screen Sharing through XMPP . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.5.2 DOM Elements Highlighting through XMPP . . . . . . . . . . . . . . . . . . 53

4.5.3 Dynamic Templates Fetching . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.6 Access to Holistic Context Information Service . . . . . . . . . . . . . . . . . . . . 55

4.6.1 Link to holistic collection of context information . . . . . . . . . . . . . . . . 55

4.6.2 HTML Page Annotation in IIM for Embedded Support . . . . . . . . . . . . 55

4.7 Human IT-supported Support Service . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.8 Business User Transfer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.9 Support User Assisted Ticket Creation Service . . . . . . . . . . . . . . . . . . . . 59

4.10 Collection of Chat History as Context Information Service . . . . . . . . . . . . . . 60

4.11 Automatic Chat Assistance Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5 Evaluation 65

5.1 Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2 Evaluation Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2.1 Design of Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2.2 Design of Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Contents xiii

5.2.3 Testing Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.2.4 Thesis Prototype Testing Set-up . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3 Results from questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3.1 Respondents Job Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3.2 Assessment of Features Coverage . . . . . . . . . . . . . . . . . . . . . . . 70

5.3.3 Assessment of Provided Context Information Quality . . . . . . . . . . . . 70

5.3.4 Estimated Influence on Tickets . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.3.5 Estimated Influence on Customer Satisfaction . . . . . . . . . . . . . . . . 72

5.3.6 Estimated Influence on SaaS Provider Cost . . . . . . . . . . . . . . . . . . 73

5.3.7 Expectation of Support User created Ticket . . . . . . . . . . . . . . . . . . 73

5.4 Results from tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.4.1 XMPP Screen-sharing Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.4.2 XMPP Screen-sharing Performance . . . . . . . . . . . . . . . . . . . . . . 75

5.4.3 Screen-sharing Performance compared with Citrix and Adobe products . . 76

5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6 Conclusion and Future Work 79

6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.2 Answered Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

A Acronyms 85

B Evaluation Questionnaire 87

C Screen-sharing Evaluation Results 93

xiv Contents

LIST OF TABLES

2.1 Important bug report description items . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Support Offering in non-ERP software market overview . . . . . . . . . . . . . . . 20

2.3 Support service in Enterprise Resource Planning SaaS market overview . . . . . . 21

3.1 Provided Functions of Chat as Embedded Support Services . . . . . . . . . . . . . 26

3.2 User Stories for Business User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3 User Stories for Support User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1 Stanza Extensions and Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1 Goals Features Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2 Hardware Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3 Software Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

C.1 Screen-sharing Performance Measurement . . . . . . . . . . . . . . . . . . . . . . 93

C.2 Screen-sharing Latency Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 94

C.3 HTML tags with counts (shared screen) . . . . . . . . . . . . . . . . . . . . . . . . 95

C.4 HTML tags with counts (displayed screen) . . . . . . . . . . . . . . . . . . . . . . . 96

xv

xvi List of Tables

LIST OF FIGURES

1.1 SaaS support ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Lifecycle of a Bugzilla Bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Software bug report and its related entities in FLOSS . . . . . . . . . . . . . . . . 15

2.3 Access in to support service in SaaS . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Filling in information while user creates a ticket . . . . . . . . . . . . . . . . . . . . 18

2.5 Software Issue Handling Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.6 Software bug report and its related entities in Enterprise Resource Planning SaaS 22

3.1 Ticket quality improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 New User Roles: Business User, Support User . . . . . . . . . . . . . . . . . . . . 28

3.3 Logical Architecture Support User . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.4 Logical Architecture Business User . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5 XMPP client-server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.6 JavaScript XMPP Client Structural Architecture . . . . . . . . . . . . . . . . . . . . 33

3.7 UI Controller Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.8 Connection and Messaging Manager Component . . . . . . . . . . . . . . . . . . . 34

3.9 Initial Start-up Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

xvii

3.10 Screen-sharing and DOM Element Indication . . . . . . . . . . . . . . . . . . . . . 37

3.11 Incident reporting and content proposal . . . . . . . . . . . . . . . . . . . . . . . . 38

3.12 Business User UI Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.13 Support User GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 Implementation Baseline with Added Functions . . . . . . . . . . . . . . . . . . . . 43

4.2 Package Diagram of Thesis Implementation . . . . . . . . . . . . . . . . . . . . . . 44

4.3 Object diagram depicting ConnectionManager . . . . . . . . . . . . . . . . . . . . 47

4.4 Integrated Live Support in Embedded Support Services . . . . . . . . . . . . . . . 49

4.5 Implemented Business User GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.6 Support User GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.7 Context Providers Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.8 Screen Sharing Results Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.9 State Chart: find indicated UI element . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.10 Screen Sharing Results Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.11 Captured UI Component Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.12 Adaptation to JavaScript Screen-shot Tool(JSST) . . . . . . . . . . . . . . . . . . . 56

4.13 HTML page annotation before holistic collection of context information . . . . . . 56

4.14 Captured UI Component Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.15 Solution search with automatic search terms extraction . . . . . . . . . . . . . . . 58

4.16 Business User Transfer Service UI . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.17 Support User Assisted Ticket Creation Service . . . . . . . . . . . . . . . . . . . . 60

4.18 Design of Bot for Automatic Chat Assistance . . . . . . . . . . . . . . . . . . . . . 62

4.19 Automatic chat assistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.1 Test Set-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.2 Respondents Job Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

xviii List of Figures

5.3 importance of chat features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.4 Estimation of Ticket Avoidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.5 Estimated Influence on Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.6 Vote for influence on customer satisfaction . . . . . . . . . . . . . . . . . . . . . . 72

5.7 Influence on Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.8 Percentage of Tickets that Should Be Created by Support User After Chat . . . . . 74

5.9 Comparison of HTML tags and their appearances . . . . . . . . . . . . . . . . . . . 74

5.10 Difference of HTML tags appearances (Group 1) . . . . . . . . . . . . . . . . . . . 75

5.11 Screen-sharing Performance measured by milliseconds . . . . . . . . . . . . . . . 75

5.12 Screen-sharing Performance relative to network transfer time . . . . . . . . . . . . 76

5.13 Screen-sharing Performance compared with Citrix GoTo Assist and Adobe Connect 77

List of Figures xix

xx List of Figures

1 INTRODUCTION

This chapter starts with illustrating the context in which the thesis work addresses the targetissues. After defining the context, the chapter lays out the target issues and goals of theresearch, continued by an overview of the structure of the whole work.

1.1 BACKGROUND

When a user of a software product is hindered from getting his/her expected softwarefunctionality from the product, there might be different reasons. To categorize the variousreasons, it is reasonable to first confine types of software that are addressed with this thesis. Ifwe constrain the scope of software to interactive web-based applications delivered through thecloud, the reasons of above mentioned user’s issues fall into three categories.

• The first category is natural reasons, such as electricity outage, natural disasters at user’sside, hardware system failure, and so on. Though these issues can be tackled byfault-tolerant enhancements such as redundancy, in most cases these enhancements arehardware related, thus are transparent to software users and even software providers.

• The second category is low level service-related errors such as network failures, whichmay lead to inaccessibility to the software functions. As software (or software service)provider, these errors can be sometimes detected, however to correct them is theresponsibility of service providers.

• The third category is software related reasons. Either the user is not familiar with thesoftware, not well trained to find the functionality; or the software behaves abnormally; orthe functionality demanded by the user is not implemented. These three problems arereferred to as "software issues". Modern software providers often use technical means totry to detect these situations when they occur, to provide users support to report softwareissues, and to provide users solutions for these problems.

1

In the following sections and chapters, this report takes care of issues of interactive web-basedapplications delivered through the cloud, taken Enterprise Resource Planning cloud solutions asexamples and implementing platforms. Unless otherwise presented, the term "software" will beused specifically to indicate interactive web-based applications delivered through the cloud;given these three reason categories above, it is reasonable to focus on tackling software issuesas the software producer.

Software issues happened at the user’s side negatively impacts the user experience directly.If software defects are not solved by the producer, certain issues may happen repeatedly andaffect more users. In a business context, there are also direct business impacts of the softwareissues. When this software is purchased with a guaranteed quality of service, as mostenterprise applications do adhere, the user needs support from the vendor to resolve the issue.Enterprise Resource Planning solutions are nowadays deployed on cloud to reach morecustomers; they are good objects to study given that many of their features are intensivelyinteractive. Enterprise Resource Planning software is designed in a way to cover users at anytime at any place on any device. No matter the user is a postman who delivers parcels andcollects electronic signatures, or is a salesman who always flies and is always on the way, or isan office employee who use different PC platforms, they can always access the service via theInternet. There is a fundamental difference in case of SaaS, compared with traditionalon-premise solutions. Under the current popular pricing policies of SaaS products, customers donot pay for maintenance[Cus10]. Of course different levels of service are usually available forcustomers to choose from and pay for, but it is still true that under the service agreement, theSaaS vendor is solo responsible for cost of issue resolution, thus the following formula alwaysholds:

Cdirect = N ∗ C (1.1)

Cdirect stands for direct cost of total software issues, N for total number of software issues. AndC for average cost of each software issue reported to the vendor side. Assume that not allsoftware issues are resolved with user satisfaction, additional indirect costs will yield ascustomers decide to switch vendor or simply stop renewing contract. Complaints regarding badsupport have already emerged in social networks, this bad reputation also falls into the categoryof indirect costs of software issues. Since the indirect costs are almost impossible to measurebut necessary to consider, it is defined on coarse granularity, simply as Cindirect . So far we havethe equation for costs of software issues C:

C = N ∗ C + Cindirect (1.2)

. Without going too deep to the influencing factors to C and N, we know that the longer theperiod to resolve a software issue is, the higher Cdirect would be. And user satisfaction is closelyrelated with Cindirect . Maintenance costs are generally responsible for 40% to 80% of totalsoftware costs and maintenance is probably the most important life cycle phase [Gla01]."Enhancement is responsible for roughly 60% of software maintenance cost. Error correction isroughly 17 percent."[Gla01]. Conclusion can be drawn that efficient and effective support is vitalfor success of enterprise SaaS.

2 Chapter 1 Introduction

Figure 1.1: SaaS support ecosystem

However, when the user creates a software issue report, it is the support engineer’s job tounderstand the type and content of the issue, find out exactly what has happened and either fixa software bug or instruct the user right actions. Figure 1.1 is derived from a typical SaaSEnterprise Resource Planning product to show different parties involved in a software issueresolution process. In figure 1.1, internal scenario describes that software issues can bereported by the software testers and developers; in contrast to the customer scenario wheretickets (software issue reports) are filed by the customers, either end users or theiradministrators. The figure shows different parties involved in a issue resolving process whichpartly depends on the experience of the support engineer but more importantly, on theinformation the support engineer can get about the issue. When the support engineer canreproduce the software issue with important context information like user OS, browserinformation, active UI component, invoked server module, then it is easier to solve the issues,the less this information is present, the more difficult it is, thus the higher C is and more likelythe higher Cindirect will be. There are already many tools in the market to trace software issuewith simple descriptions and communication records by predefined work flow, which only startswith a description written after the issue occurred outside of the user system. Much of usefulcontext information is lost in this way. Some other embedded support functions only works incertain browser runtime, which limit the reusability, portability, thus limit also the covered userdevices.

Besides the contribution of maintenance cost reduction, embedded support also is muchused in today’s software development and test phases. At the time a developer or a testerdetects a malfunction of the software; he simply clicks a button in the tested product and files areport about exactly the software issue with exact related context information. Later on, thedefect part will be taken care of by the responsible development team, with all the informationcollected at the scene. This whole procedure will reoccur at high frequency each developmentiteration, in each sprint, and in each release, until the software matures. By shortening software

1.1 Background 3

bug fixation time, embedded support helps also to make the product mature earlier, thus morecompetitive on the market.

Given the status quo above, it is clear that the cost of software issues resolution mustevaluated in depth. Because the target software is interactive web applications, new featuresbased on modern Web technologies like JavaScript, the dominant front-end script language, andHTML5 must enable SaaS vendors to resolve software issues in a more timely manner, withless cost for a single issue C, and preferably in the end, with a smaller N fraction by accelerationof software maturation.

1.2 MOTIVATION

According to the research on topics with embedded support concept which is done in theacademia, it is found that most of the existing research focus on maintenance of software , andthose researches are quite general without focus on SaaS. As a very important and widelyadopted technological solution for cloud business software maintenance, embedded support isnot given the deserved formal concept establishment. Also, there is no structured analysis ofthe purpose and challenges of embedded support in the field according to research results ofthe thesis.

Given the huge share of maintenance cost in the total software TCO (Total Cost ofOwnership), and the fact that support is an indispensable part in the maintenance workflow ofmodern SaaS solutions, the thesis will make efforts to establish the support concept, investigatethe role and effects of support. Focusing on the embedded support paradigm, the thesis willalso challenge the traditional technological methods to tackle the issue of effective support.

1.3 OBJECTIVES

The major objective for this thesis is to find the critical path in software issue resolution in thelifecycle of enterprise SaaS solutions; and shorten the length of this critical path with mostmodern concept of embedded support. At the end of this thesis, the following questions shouldbe studied and answered:

• What are the key factors influencing the monetary cost and resolution time of a softwareissue?

• Which technologies can be utilized to reduce this cost and time consumption? Are theabove mentioned potential technological solutions feasible? This question will beanswered by prototype building, design and implementation should be described.

• How can a measurement of improved user experience and reduced cost be established?

• What is the estimated or measured contribution of the technological solutions?


1.4 DEFINITION OF TERMS

Service: The definition of "Service" is taken from OASIS SOA reference model. "A service is amechanism to enable access to one or more capabilities, where the access is providedusing a prescribed interface and is exercised consistent with constraints and policies asspecified by the service description. A service is provided by an entity - the serviceprovider for use by others, but the eventual consumers of the service may not be knownto the service provider and may demonstrate uses of the service beyond the scopeoriginally conceived by the provider". [MLM+06]

ERP: The acronym ERP stands for Enterprise Resource Planning systems. These systemsintegrate internal and external management of information across an entire organizationembracing finance/accounting, manufacturing, sales and service, customer relationshipmanagement, etc.[Wik]

Cloud Computing: "Cloud computing refers to both the applications delivered as servicesover the Internet and the hardware and systems software in the data centers that providethose services". [AFG+10]

Everything as a Service (XaaS): According to recent study[BFB+11], cloud computing systemis now delivering everything as a service. To put it more concretely, three common XaaSexamples are: IaaS, PaaS, and SaaS. IaaS stands for "Infrastructure as a Service", whereinfrastructure means technologies for servers, storage, networking and IT management.PaaS stands for "Platform as a service", which means the technologies to share cloudinfrastructure to provide service platforms. The third example is:

Software as a Service (SaaS) : According to the definition of "cloud computing"[AFG+10]the applications delivered as services have been long called "Software as a Service", orSaaS1. In this thesis Software as a Service refers also to only the software that is deliveredto the end users in the form of a service which is accessed over the Internet[AFG+10].Another often used synonym to SaaS is "Hosted Software" 2.

Software Support and/vs. Software Maintenance: In software engineering,

Software Maintenance[ISO06] refers to three kinds of software modifications, namely"adaptive maintenance", "corrective maintenance", and "emergency maintenance". All ofthem define modification of a software product after delivery. Purpose of modification iseither correction or enhancement[ISO06]. It is very important to notice that in the 2006ISO standard, "pre-delivery activities include planning for post-delivery operations,supportability, and logistics determination". [ISO06] However, modifications pre-deliveryare not included in the maintenance process.

Software Support: While software maintenance focuses on change of software in onelife cycle process, software support is defined closely related with the usage of thesoftware. Because software usage happens before delivery inevitably for testing reasons,thus support covers a longer time than one life cycle process. Also, the usage of thesoftware can yield problems which do not necessarily results in a software change,therefore educating and instructing software users are also inherently a support task.

1SaaS is also called "On-demand Software" in many business naming paradigms.2The name of "Hosted Software" comes from the paradigm that software vendor hosts the software itself, customers

and users do not store, install, or maintain the software and its databases.

1.4 Definition of Terms 5

There are two major differences between Software Support and Software Maintenance.Firstly on the time scope, maintenance only refers to modifications after the softwaredelivery. Secondly, the subject of maintenance is developers, the object is the softwareitself, however, objects of the support can also be the users from users of the software,and therefore subject of support can be dedicated "support employee", whose job is toconsult, educate the software users.

Software Supportability: In this thesis, software supportability is defined as the ease of asoftware product to be supported in order to: correct a software bug; improve onperformance; extend functionality; or to educate the user how to use the product.

Incident: A user reported software issue.

Embedded Support: The term embedded support is not to be confused with generalembedded systems. "Embedded" describes the way how the support services areintegrated into the software product. When the user can directly access support servicesfrom the business product, then the service is "embedded". In other words, in contrast tomany existing IT support systems which standalone from the product, embedded supportis part of the product itself.

Context Information: "Context is any information that can be used to characterize thesituation of an entity. An entity is a person, place, or object that is considered relevant tothe interaction between a user and an application, including the user and applicationsthemselves."[ADB+99] Regarding software support, important context informationincludes information which is extractable either from the state of the client systemautomatically, or from human user’s input when a software issue happens. Thisinformation will be transferred to the support system and be used for incident diagnostics.

1.5 DESCRIPTION OF REMAINING CHAPTERS

Chapter 2 (Goal Setting) depicts the role of software support in enterprise SaaS solutions. Itshows results from the review of literature and study in the industry. This part will go into detailto find where exactly support cost happens. This chapter also introduces up-to-date researchresults and technologies which are leveraged to solve software support issues. The findings actas benchmarks for comparison in later chapters. In the end of the chapter, clear goals should beset up from technological aspects, which will guide the following chapters in the thesis.

Chapter 3 (Concept and Design) The concept section will propose a solution to meet theobjectives of this thesis and list the software requirements of the solution. The Design sectiondescribes design of solutions in more details. Different design considerations are listed andweighed. The reasons of design decision are clarified. In the end of the chapter, the selectedtechnologies should be clear, risks and potentials of the design choice should be explicit.

Chapter 4 (Implementation) The Implementation chapter answers the "How" question. Thischapter describes the implementation by listing important data structure and algorithms. It also


explains how design goals are achieved in detail, some important code will appear for sake ofconciseness.

Chapter 5 (Evaluation) presents key effect indicators for the implementation. It describeswhat should be measured and how to measure. It shows the measurement results andanalyses the effect of measurement.

Chapter 6 (Conclusion and Future Work) summarizes the problem settings of the thesis,reviews the approaches adopted in the thesis and emphasizes the important findings, achievedresults. This chapter will also provide the unanswered questions left in the field of study.

1.5 Description of Remaining Chapters 7

2 GOAL SETTING

2.1 REVIEW OF LITERATURE

There is literature describing the complexity and cost of software support. Regarding popularsoftware support models which define user roles and system behaviour, author of this report didnot find systematic study in the academia. However, documentations of mature open sourcesoftware issue tracking systems provide some insight into these models. In this section, thethesis conducts a thorough research into these research papers. The target is to discover theimpact of software support and the known technological solutions to reduce the negativeimpacts. The existing challenges in software support are deduced from this literature review. Inthe discussion part, contributions of the studied literature are listed and compared; a solutionproposal which uses the literature findings is set up.

2.1.1 Software Support Model and Software Support Services

"Bugzilla is a Web-based general-purpose bug-tracker and testing tool originally developed andused by the Mozilla project, and licensed under the Mozilla Public License."[Wik13] According toBugzilla’s official site, it is defined as a "Defect Tracking System" which allows "individual orgroups of developers to keep track of outstanding bugs in their product effectively"1. "The lifecycle, also known as work flow, of a bug is currently hardcoded into Bugzilla."2 Figure 2.1 showsthe life cycle of a Bugzilla bug. From figure 2.1, this report extracts the following four roles inBugzilla’s bug life cycle:

• User: bug reporter, whose reported bug needs to be confirmed or voted to be taken careof.

• Developer: processor of the bug report. Developer is also responsible for assigning bugreports to development.

1http://www.bugzilla.org/about/2http://www.bugzilla.org/docs/3.0/html/lifecycle.html

9

• Development: development of software products which use BugZilla.

• QA (Quality Assurance3): the mozilla.com QA organization is divided into teams focusedon Mozilla product areas or technologies.4

Some major differences of the Bugzilla support model compared with support models inbusiness SaaS products described in later sections are:

• There is no service level agreement between each interacting roles.

• Bugzilla supports only software defects, general user questions are not target ofanswering.

• In Bugzilla, only approved bug reports instead of all of them are dealt with.

• Bugzilla does not have explicit software issue escalation.

• Fixes generated in bugzilla are and only are confirmed by the QA team.

Gartner IT Glossary5 defines software support services as "generally technical support orbreak/fix services that are delivered for specific software products. These services includerevenue derived from long-term technical-support contracts or pay-as-you-go, incident-basedsupport. Software support services typically include remote troubleshooting capabilities,installation assistance and basic usability assistance. Remote troubleshooting capabilities maybe delivered via telephone and online communication media or without human assistancethrough automated means that reside on the customer’s device or are available on the Web".

Niessink [NVV00] performed a case study to investigate software maintenance as services ina large organization which provides Dutch social security system. The report divides the supportservices tasks into two processes. The first process is helpdesk management process; thesecond is the problem management process. "The implementation of these processes has beenbased on the Information Technology Infrastructure Library (ITIL). The ITIL process HelpdeskManagement is used to guarantee the continuity of services, while the ITIL process ProblemManagement is used to improve the level of service in the future. So, Helpdesk Managementdeals with incidents, whereas Problem Management is concerned with solving the problemsthat cause these incidents"[NVV00]. "It is found that classification of the incidents was oftenimpossible because free text description of the incident was too vague. In the cases were aclassification was possible, 30% of the new classifications differed from the existingclassification. Of the 30,000 incidents in the helpdesk database, 56% was not classified at all."At the end of the case study, the author claimed it "necessary to first implement a clear andconsistent registration of the incidents that occur during service delivery, before attempting toimprove the problem management process."[NVV00].

3https://wiki.mozilla.org/QA/whois4https://wiki.mozilla.org/QA5http://www.gartner.com/it-glossary/software-support-services/

10 Chapter 2 Goal Setting

Figure 2.1: Lifecycle of a Bugzilla Bug

2.1.2 Software Bug Report(Ticket) Quality and Coefficients

One research report[VM09] conducted under QualiPSo6 project made suggestions forimproving FLOSS(Free Licensed Open Source software) software quality. The recommendation6 is "Continuous Project Improvement", the report suggested that software project improvementopportunities include bug reports and recurrent support request. This report also suggestsadoption and implementation of requests/suggestions from users/ integrators and developersfor both software product and process.

One angle from which to know how long it takes at service vendor’s side to resolve a userreported software issue is to look at how many times the ticket gets reassigned to different

6The goal of the QualiPSo integrated project is to define and implement technologies, procedures and policies toleverage the Open Source Software (OSS) development current practices to sound and well recognized and establishedindustrial operations.[Qua09]

2.1 Review of Literature 11

people inside the vendor system. Bug fixing is more complex in big systems, when locating thecapable and responsible personnel for a software bug itself demands efforts and skill. Oneresearch [GZNM11] describing software bug report reassignments in Microsoft7 Windows Vistashowed that there are five main causes of bug reassignments in the Windows Vista project.They are "Finding the root cause", "Determining ownership", "Poor bug report quality", "Hard todetermine proper fix", and "Workload balancing" [GZNM11]. The study also shows it takes longerto close a ticket when reassignment increases. Cites from Microsoft employees say that "Themost important factor in multiple reassigning in my experience is unclear bug reports" and "If abug report cites only basic symptoms (such as ’crash’) and has little or no information hinting atcause (such as call stack), then triage is very difficult and a bug can end up being bouncedaround". The lack of context information harms software issue resolution.

Hooimeijer and Weimer [HW07] produced a model for software bug report quality aimed atreducing cost of bug report triage. The study used public bug reports from the Mozilla Firefoxproject8. This work also suggests features that should be emphasized when composing bugreports. Five major model features are "Self-Reported Severity" (severity of the software issuegiven by the issue reporter), "Readability Measures", "Daily Load", "Submitter Reputation", and"Change over time". "Priority changes" in the studied project is infrequent and considered to benegligible, therefore elided from the model features. The work used lifetime as a proxy for thecost of triaging. Major findings from this work which relates with the thesis topic are:

• Analysis of the models shows that "early" attachment count and comment count mattermost, where comment in the study comes from "anyone", which is understood as users ofthe bug tracking forum. The presence of an attachment often means "expensive" bugreports. Attachment count has a negative coefficient to the cost, whereas comment counthas a positive one. It is suggested by the author that this is because bugs that receivemore user attention get fixed faster or important bugs have a great deal of user attention.

• Easier-to-read descriptions correlate with a short bug report lifetime.

• Patch count, escalations and de-escalations were not found to be consistently significantfor various models.

Bettenburg[BJS+08]investigates quality of bug reports from the perspective of developers.Survey which involves both developers and bug reporters is conducted. 156 developerresponses from APACHE; ECLIPSE, and MOZILLA projects and 310 bug reporters’ responsesfrom the same projects were responding to the survey. To these two surveyed groups, twocategories of questionnaires are presented, namely the "Contents of bug reports" and "Problemswith bug reports". Consistency checks are performed to the received questionnaire andimportance of the choice items is calculated as the percentage of the time selected asimportant for the developer on the base of overall used times:

Importance(i) =ND1,D2(i)ND1(i)

(2.1)

7http://www.microsoft.com/en-us/default.aspx8http://www.mozilla.org/projects/firefox/


[BJS+08]. 9 Important findings from the research are:

• "Step to reproduce" is the most important items for developers, after which follow "stacktraces", "test cases", and "observed behavior".

• "Screenshot" is also important, but often only for GUI errors.

• Surprisingly, "expected behavior", "code examples", "summary", "version", "operatingsystem", "product", and "hardware" are considered important with only lower importance.

• Most provided items are (in frequency-descending order) "steps to reproduce", "observedbehavior", "expected behavior".

• Only few reporters used "stack traces", "code examples" or "test cases" to the bug reports.

• The most difficult to report items are (in difficulty-ascending order) "component", "stacktraces" "code examples", "step to reproduce", and "test cases".

• Spearman correlation10 between what developers use and what reporters provide is 0.321,a very low correlation.

• Spearman correlation between what developers consider important and what reportersprovide is -0.035, a huge gap.

• Report providers know what information developers need. So ignorance is not the reasonthe information is not provided. An exception happens on item "Screenshot", whereSpearman correlation is 0.839.

• Incomplete information was by far the most commonly encountered problem bydevelopers. Other common problems include errors in "step to reproduce" and "testcases"; "bug duplicates" and "incorrect version numbers, observed and expected behavior".Another challenging issue is the language fluency of the reporter.

• Developers are not impacted too much from bug duplicates.

• Bug reports containing stack traces get fixed sooner(APACHE/MOZILLA/ECLIPSE); Bugreports that are easier to read have lower lifetimes (APACHE/MOZILLA/ECLIPSE);Including code examples into bug reports increased the chance of fixation (MOZILLA).

2.1.3 Internet Instant Messaging

A study of internet instant messaging and chat protocols[JNO+06] provides insights intotechnical aspects of chat protocols which are adopted by three major business internet chatproducts. Of the three studied products, namely AOL Instant Messenger, Microsoft Messenger,and Yahoo! Messenger, major features and functions are explored. Different underlying systemarchitectures are depicted. They all adopted client-server architecture however with differentsystem architecture: symmetric and asymmetric. Other technical aspects like sessiondistribution, user authentication, data transfer are discussed and compared. At the end, SIMPLEand XMPP as IETF11 standardized protocols are compared.

9To be concise, for definition of question D1 and D2, please refer to the research [BJS+08]10http://en.wikipedia.org/wiki/Spearman’s_ rank_ correlation_ coefficient11Internet Engineering Task Force

2.1 Review of Literature 13

2.1.4 Internet Instant Messaging (IIM) Protocols Comparison

The Internet Relay Chat and Extensible Messaging and Presence Protocol are two popularopen standards for internet instant messaging applications.

• Internet Relay Chat is a text-based protocol, with the simplest client being any socketprogram capable of connecting to the server. [OR]

• Extensible Messaging and Presence Protocol (XMPP) is an application profile of theExtensible Markup Language (XML) that enables the near-real-time exchange of structuredyet extensible data between any two or more network entities.[SA] It is an opentechnology for real-time communication, which powers a wide range of applicationsincluding instant messaging, presence, multi-party chat, voice and video calls,collaboration, lightweight middleware, content syndication, and generalized routing of XMLdata.[xmp13]

Both standards mentioned above adopt client-server architecture. The messaging networks areboth federated, meaning that chat clients exchange messages with each other via server routing.

2.1.5 Discussion

This report cares about existing software support models and bug report studies in theacademia because they address the issue of software issue handling based on reporting, whichis also adopted as support methods by SaaS Enterprise Resource Planning vendors. And it isassumed that the cost of support is directly impacted by the quality of the software issuereports that are sent to the vendors. Figure 2.2 is derived from the above mentioned publicresearches conducted in open source on-premise software projects. It is an Entity-Relationshipdiagram which shows the main attributes composing a typical software bug report withnecessary attributes. This figure also shows the importance of Ticket as the communicationchannel between bug reporter (end user) and bug fixer (developer). Whether or not the issuedescription conveys correct information about the software bug has a direct impact on the timeconsumption of software issue diagnostics. From the above mentioned studies, we can see thatbug report (ticket) quality has a significant impact on the communication efficiency of developersand bug reporters. The gap between the user-offered and the developer-needed information ishuge.

There is information which is very important for the software provider to fix a software issue.However in many cases this information is either not described or not given at all. There is alsoevidence showing the positive correlation between a bug report’s quality and the time it saves toresolve a reported software issue. Fortunately, the studies mentioned above have discoveredmany categories of information which should be provided to the engineer who makes efforts totry to triage and fix software defects. Combining the findings, Table 2.1 shows the informationthat should be correctly provided to support organization in the software issue reports. It isreasonable to deduce that if there are dedicated tools to enforce these information requirementsfrom the software bug reporters, the quality of bug reports will be improved significantly.


Figure 2.2: Software bug report and its related entities in FLOSS(Free licensed open sourcesoftware)

The adoption of internet instant messaging by large Web application providers like Google andFacebook has provided mature technology for online communication. When properlycustomized for Enterprise Resource Planning SaaS support, on-line chat has potential to beadopted as a tool for embedded support. Such a tool can provide users instant access tosupport service with a very short first response time, thus provide better user experience.On-line chat has also many other potentials regarding fast data transfer, user friendliness and itsadvantage over phone. These advantages will be further discussed in the thesis. The strength ofXMPP over IRC is its XML data format. This thesis can leverage its built-in XML engine anddefine extensions to allow features more than text messaging.

The studied literature did not provide methods to prevent the users from reporting issues.Three possible explanations for this are: the objects of the studies are software bug reports,which do not include user’s service requests for answering "How to" questions, so preventingusers reporting an software issue is not a goal; the studied software, especially Mozilla Firefox,have narrower uses cases in comparison with highly complicated solutions like cloud EnterpriseResource Planning, so users of such software do not have a high intention to ask for help to usethe software; Eclipse users studies are in most cases developers, who are already supposed tobe familiar with various channels on the Internet to seek for their questions.

2.2 FIELD STUDY: STATE OF THE ART

To get an overview of how support is handled in the industry, the thesis investigates majorcloud Enterprise Resource Planning providers in the markets. It is found that all vendors in thefield supply their customers with support. So that further field study is described focusing onthe following aspects: business models for the support service; adoption of embedded support;and adoption of real-time live support. This field study should inspire on cutting-edgetechnologies the thesis software implementation shall leverage. Also, the solution proposed by

2.2 Field Study: State of the Art 15

Table 2.1: Important bug report description items

Name Often

missing

Often

incomplete

often

misleading

hard to

provide

steps toreproduce

No Yes Yes Yes

stacktraces

Yes Yes No Yes

testcases

Yes Yes Yes Yes

observedbehaviour

No Yes No No

screenshot Yes Yes (e.g. more screenshots areneeded, but only one is pro-vided)

No No

expectedbehaviour

No Yes No No

component Yes Yes No Yes

reporterlanguagefluency

Yes - - -

the thesis should be compared with and measured against these existing technologies. Toillustrate some concepts in SaaS embedded support, this report takes SAP’s cloud offerings asexample, screenshots are taken in one of the SAP’s cloud ERP products.

2.2.1 Embedded Support in Enterprise SaaS

Nearly all solutions provide on-line case submission systems for support. These systemstracks the whole life cycle of software issue reports (tickets). Figure 2.3 shows a user interfacefrom where users can access support services provided by the SaaS vendor. Figure 2.4 depictsa user interface of users creating a ticket in an example product(SAP Business ByDesign).

2.2.2 Enterprise SaaS Support Structure

Software Issue Handling Chain It is definitely inefficient and a waste of resource to letdevelopers spend time talking with end users on support desk without restriction sincedevelopers should focus on development tasks; general user questions should be directed toproduct experts or support employees. Modern SaaS Enterprise Resource Planning deploysmultiple support levels in a chain as filters for general user reported issues. Figure 2.5 is derivedfrom this filter approach and shows a typical structure of different support levels. This data flowdiagram depicts the software issue report’s processors in the service sequence. The CustomerEnd User is the sender of a software issue report. The Customer Administrator is anexperienced user in his organization. Traditionally, the end user cannot contact the administrator,such a one way communication paradigm is kept during the life time of a software issue report.Therefore, a chain of data flow is formed. In Figure 2.5, Direct Support is the party at the SaaSvendor who speaks the user’s language and translates the software issue report into a language


Figure 2.3: Access in to support service in SaaS

that is understood globally in the chain, such as English. Expert Support has more advancedproduct knowledge; it begins to handle the issue once direct support forwards the supportservice request to it. When expert support investigates and believes the issue is a software bug,it will send the report to Development Support, who will check the issue and fix the softwarebug if it exists.

The reason behind this design is that most SaaS vendors decide to reduce cost by lettingdevelopment support focus on only software defects, and lower support levels should filter outother kinds of software issues. The drawback of this chain can be seen from Figure 2.5, thatonce a software issue report is created, each processor only contacts with its neighbors. Whenthe quality of issue report is low, it will happen that the communication loops for many roundsinside the chain before the right responsible party is found. The higher the software issueescalates, the more costly it is to require additional information from the software issue reporterbecause more levels of support will be involved into the communication.

2.2.3 Live Support Adoption

Big software providers such as Redhat and Amazon have different support offerings for theirproducts. By studying these support offerings, we can check if they leverage also live support.In case yes, this report tries to find out which technologies are now used to enable the livesupport. Table 2.2 lists the major findings from the market study in non-ERP software supportofferings. It reveals a tiered support model as the support services are offered in different levelsand charged accordingly.


Figure 2.4: Filling in information while user creates a ticket

Drilling down onto Enterprise Resource Planning SaaS support services, this report revealsthat most Enterprise Resource Planning SaaS vendors have to bring down the communicationbarrier between their support department and the users is live communication, which enablesthe so-called "real-time" support. This kind of real-time support in most cases indicates a directphone call. In this sub-section, a research on this live support service offering is presented. Thisthesis takes examples from the market leaders in Enterprise Resource Planning SaaS products,and studies if and in case yes, what service channels are used by the vendors. Table 2.3 showsan overview of support service levels provided by the examined solutions and the existence ofremote live support.

The thesis takes a closer look at how these SaaS vendors provide live support:

• Salesforce.com As the one of the market leaders in CRM12 field worldwide in the year of2012, Salesforce.com13 generated a revenue of $2.5 Billion14. The company offers itsproducts with 3 levels of customer support, from the second of which 24/7 phone supportis available. All three levels enable user to use traditional built-in issue reportfunctionalities. However, live chat is not available.

• SuccessFactors As a very strong cloud HCM15 solution provider rated by Gartner16,SuccessFactors’17 cloud offering provides users "Live chat for real-time answers to simplequestions"18.

12Customer Relationship Management13http://www.salesforce.com14http://www.salesforce.com/company/investor/financials.jsp15Human Capital Management16http://www.gartner.com/17http://www.successfactors.com18http://www.successfactors.com/en/_us/solutions/support.html


Figure 2.5: Software Issue Handling Chain

• ORACLE CRM Ondemand19, NET SUITE20, Workday21, and Sugar CRM22 From the publicresearch and company public websites, the thesis found that they render different supportoptions. For example, Oracle CRM Ondemand provides phone support service to logservice request during normal business hours; Net Suite provides a similar service on 24/7base. However, there is no evidence to show these company are providing or preparing toprovide remote on-line chatting.

2.2.4 Compare and Analysis

The thesis found only one adoption of on-line chat into support service among all studiedmarket players. Yet the use of the chat tool is only for answering users’ "simple questions".Therefore, it is reasonable to assume that there is until today no product on the market, whichuse chat functionality to provide on-line real time problem diagnose.

19http://www.oracle.com/us/products/applications/crmondemand/index.html20http://www.netsuite.com/portal/services/support/comparison.shtml21http://www.workday.com/services/support.php22http://support.sugarcrm.com


Table 2.2: Support Offering in non-ERP software market overview

Solution Support

levels

Live

support

from

Live

support

form

Fastest

first

response

Bug

tracking

system

usage

Online

knowledge

base

Redhat Linux 3 levels Level 2 phone 1 hour Y Y

CanonicalUbuntuDesktopManagement

2 levels N/A N/A N/A N/A Y

CanonicalUbuntu ServerManagement

3 levels N/A N/A N/A N/A Y

CanonicalUbuntu CloudManagement

3 levels Level 1 phone N/A N/A N/A

Adobe products 8 levels Level 1 phone,onlinetext chat,adobeconnect

30 min Y Y

Amazon WebServices

4 levels Level 3 Phone,chat, livescreensharing,email

< 15 min Y Y

Figure 2.6 is derived from a typical support organizational layout from a well-known EnterpriseResource Planning SaaS vendor. It is a Entity-Relationship diagram which shows the mainattributes composing a typical software issue report. In comparison with Figure 2.2, we findsoftware support related tasks are much more complex within a Enterprise Resource PlanningSaaS product.

2.3 GOALS AND SUMMARY

The general goal of the thesis is to use technological means to cut operational cost at SaaSvendors’ side. For that purpose, attempts will be made to reduce the number of software issuereports which can be resolved without entering the different support levels. Once an softwareissue report is created, it will be tried that support engineers at different levels can use thethesis implementation to reduce the time it costs to resolve the software issue report.

For the mission mentioned above, the goals listed under focus on different aspects insoftware issue handling. These aspects are: to provide faster first response time; to improveuser-support communication quality; to empower support engineers with more contextinformation and to make support engineer quick access to knowledge data bases. Thesedifferent aspects are technologically intersected on the point of usage of on-line chatting.


Table 2.3: Support service in Enterprise Resource Planning SaaS market overview

Solution Number of

support

levels

Remote live

support from:

Remote live support

form

Salesforce.com 4 levels Level 2 24/7, Phone

Oracle CRM Ondemand 1 level Level 1 Business hour, phone

Net Suite 3 levels Level 2 24/7, phone

Workday notpublished

not published 24/7, published

Success Factors 3 levels Level 1(phone only)

24/7, phone, chat(from level 2)

Sugar CRM notpublished

not published not published

SAP Business ByDesign 3 levels Level 1 Business hour, phone

Detailed requirements are not described in this chapter; they will be described in the Design andImplementation chapter afterwards.

2.3.1 Goal: Live Chat for Fast First Response

From the field study, it is shown that first response time to user after a software issue takesplace is one of the key performance indicators of the support service quality of the SaaSsolution. The best guarantee found during the study is one hour, however this level of QoScomes with a higher price, therefore does not apply to all the customers and users. Also, thisone hour first response happens usually between user and support through built-in software bugtracking system, which is slow.

On-line chat can very well bridge this gap between users and support. When a user faces asoftware issue, he can simple ask for help by logging-in to the chat system. This request for chatwill be immediately visible at the support side. Such a request can be picked-up instantly whilethe responsible support personnel is available. Therefore, first response time is reduced.Implementation of such a live chat tool is a goal of this thesis.

To implement such an on-line chat system, it is important that the first response to user ishandled by support engineer who can understands the user’s language and has a generalknowledge about user’s product configuration.

2.3 Goals and Summary 21

Figure 2.6: Software bug report and its related entities in Enterprise Resource Planning SaaS

2.3.2 Goal: Templates for Efficient Communication

From the various research results presented in this thesis, and also from the interviewsconducted inside SAP’s support organization. It is clearly shown that the communication qualitylargely decides how long it takes to understand the user’s software issue. In most cases, thetype of issues encountered are closely related with the location when the issue happens. It istherefore important to enable the user to ask for help from support at every UI in the softwareproduct. However it is too costly to have a support engineer who chats on-line with the userwho knows every product and every business process.

Therefore, on-line chat should be able to provide the support engineers with communicationtemplates which are generated from the UI where the user requests the on-line chat. Besidesthese UI-specific communication templates, there should be also template questions whichcover highly-reused procedures related with software issue handling, such as asking the usersto describe his expected system behaviour and the output he gets.


2.3.3 Goal: On-line Diagnose with Live Chat

For support engineers who have the ability to resolve a software issue on-line during the chat.It is preferable that user context information can be supplied to assist the handling of softwareissue. Such context information should be pro-actively required from the customer user at thevery beginning of each chat session. Once the user agrees to render the context information,this information should either be transferred to the back-end system or directly to the chatterwho acts in the supporter role. In on-line chat module, either the information directly or a link tothis information should be supplied.

2.3.4 Goal: Live Chat - Solution Search Integration

The main reason why solution search should be done also by the support engineer rather thanonly the user is that often a solution file which is generated by the SaaS provider is written inprofessional languages, with company specific terminology. As a result, it is difficult to querysolution proposals with appropriate search terms and to understand the provided results.However these terms are assumed to be well known to support engineers.

Based on the idea of on-line chatting, while the support engineer is making efforts toinvestigate the software issue and helps the user to resolve these issues. It is important tomake the support employee convenient access to the knowledge storage of software issues.This storage can be either the product data base, forums, or solution case data base.

2.3.5 Goal: Chat Assistance

For Enterprise Resource Planning SaaS support via chatting, no chat bot should be directlyactivated to communicate with the customer user due to the low maturity of the bot’sintelligence, which would upset the users. However, bot can be deployed to help supportemployees for analyzing user input and perform assistance tasks such as template suggestionand solution search. Interface for bot should be provided in the thesis implementation for futurework.

2.4 SUMMARY

Chapter two described the general business demand which drives the modern softwaresupport technologies. Based on the research from academia, major challenges in software bugreporting handling are presented, key factors influencing the cost of handling user reportedsoftware bug are analyzed. The field study section conducted a research in the SaaS EnterpriseResource Planning market, finding out what kind of support services exist. Comparing theresults from the academic research and the existing support technologies, development goalsare set up at the end of the chapter. Through the implementation of the described software

2.4 Summary 23

solution, the purpose of improving user-support communication should be achieved, In the end,the operational cost of Enterprise Resource Planning SaaS should be deducted.


3 EMBEDDED SUPPORT SERVICESCONCEPT AND DESIGN

3.1 CONCEPT PRECAP

In the previous chapter, this report has introduced the issue escalation chain in dealing withuser reported software issues in a large organization. In figure 3.1a, we can review this chain.From the field study and research in academia, we have already known that poor quality ofsoftware issue reports is the reason why lots of communication overhead exists in the supportorganization. These communication rounds are represented in figure 3.1a as the red circles.The bold red arch indicates the creation of a ticket, which is the start of the communication ofpoor quality in case the ticket is created by the customer administrator. In case the ticket iscreated by the end user, then the dashed bold red arch indicates this starting point. With serviceconfiguration, chat has the potential to be placed inside the customer organization so thatcustomer end user can access the service.

Therefore, a concept of "Chat" is introduced in figure 3.1b, shown as the "Chat" node in thedata flow diagram. It is intended that from the services provided by "Chat", the software issuehandling chain will be shortened in time. The service of chat should serve different purposes todifferent kinds of service consumers, which will be illustrated in section 3.2.

3.2 EMBEDDED SUPPORT SERVICES

From figure 3.1, it can be seen that both users from SaaS provider and users from customerneed services that provide "Chat". The current Embedded Support functionalities have to bere-bundled into the application service with completely new delivery channels. Such newembedded support services are consisted of many services delivered to both sides in the

25

(a) Software Issue Handling Chain before improve-ment

(b) Software Issue Handling Chain with "Chat" em-bedded support services

Figure 3.1: Ticket quality improvement

interaction between support organization and the customer. The main functions the embeddedsupport services provides to users are depicted in table 3.1. Here some of these are explainedmore explicitly for sake of clarity:

Table 3.1: Provided Functions of Chat as Embedded Support Services

id Object Function

F1 SaaS vendor ticket quality enforcement toolF2 SaaS vendor support employee assistance toolF3 SaaS vendor support service request concurrent handling enablerF4 SaaS vendor support service request redirect toolF5 SaaS vendor on-line user issue diagnostic toolF6 SaaS vendor ticket number reduction toolF7 SaaS vendor user education toolF8 SaaS user fast support response channelF9 SaaS user remote assistance toolF10 SaaS user SaaS product learning channelF11 SaaS user SaaS product knowledge storageF12 SaaS user/vendor user experience improvementF13 SaaS user/vendor coordination tool in web

• F1: ticket quality enforcement tool Instead of allowing users create incidents freely withinaccurate, incomplete, even misleading information. The "chatter" will request theimportant information pro-actively during chatting. Ticket will only be created at the end ofeach chatting instance, with data that are manually or automatically selected by thechatting support employee. Thus, ticket quality should improve.

• F2: support employee assistance tool Modern SaaS comes in a way of highly complicatedand integrated services. To train support employees who chat with the user to be productexpert is too expensive to be realistic. Automatic chatting assistance should be provided tosupport chat users. This assistance service should provide templates which adapt to each

26 Chapter 3 Embedded Support Services Concept and Design

individual software issue context. It should also be possible that each support employeecreates his own chat templates.

• F3: support service request concurrent handling enabler Traditional help desk approach ofphone call has the restriction that one support employee can only address one user at onetime. The concept of "Chatter" should empower support employees to serve multipleusers simultaneously. This can be done by opening multiple chat windows.

• F4: support service request redirect tool There should be at least one support employeeon-line who chats with the users who request the chat service. When there are multiplesupport employees on-line, they should have the ability to redirect a user chat request toother support employees for reasons of different expertise or load balancing.

• F5: on-line user issue diagnostic tool There are already existing tools for diagnostics ofuser reported software issues. However, the access to these tools traditionally onlyhappens from reviewing a user ticket. When support employee or developer uses suchdiagnostic tool and finds it necessary to ask for clarification or complement, new circles ofcommunication in the software issue escalation chain take place. Thus, these tools shouldbe accessed at the "chatting time" before tickets are created. More importantly, contextinformation regarding a software issue should be collected for diagnostics automatically ator before "chatting time".

• F6: ticket number reduction tool Based on the assumption that every ticket takesexamining time at least on one level at SaaS vendor side in the escalation chain. It ispreferred that easy-to-answer questions are directly answered during a chat instead ofafter entering ticket handling process.

• F11: SaaS product knowledge storage Within the same customer organization,administrator user deals directly with the software issues reported by the normal end user.When the root cause of a software issue is software defect, or the product went live ashort time before, many software issues will be met by different end users. When oneissue solution is suggested during a chat, at least administrator user should be able tostore the chat instance. Later on when other users meet the same software issue, theadministrator can then directly forward the chat history as solution proposal.

• F13: coordination tool in web Support employees at SaaS vendor’s side use many technicalterms in their language. However end users are in most of cases unaware of such terms.This creates a communication gap during issue description and a coordination obstacleafterwards in trouble shooting. Thus, a tool should be provided to improve the coordinationcapability. One idea is to let both parties access a shared HTML page and annotate it.

There are two user roles established in the software requirement document of thesis,depicted by figure 3.2 The first user role is Business User, which refers to a user who requestscustomer support service via on-line chatting, this role replaces the "End User" and"Administrator User" roles depicted in figure 1.1. The second user role is Support User, whichrefers to either an employee from SaaS vendor or an experienced user from the customerorganization who accepts the Business User’s service requests and handles the software issueduring chatting.

3.2 Embedded Support Services 27

Figure 3.2: New User Roles in Support Ecosystem: Business User, Support User

The two roles, "Business User" and "Support User" roles, are subjects to chat service. Theprototype which is to be implemented should leave it open for configuration of user rolesmapping. An example mapping into the business roles is given: the Business User can either bean end user of SaaS, or a key user (business administrator) at the customer’s side; while theSupport User can be either a support engineer in the different levels of support organization atSaaS vendor’s side, or a developer who handles a potential software defect and establishes achat session with the software issue reporter.

3.3 REQUIREMENT

Functional requirements are described in the form of user stories. Table 3.2 lists thefunctional requirements from the Business User’s point of view; table 3.3 Support User’s.

Several important non-functional requirements are:

• NFR1: Platform Independence. Implemented solution should be compatible with thelargely adopted SaaS end user devices. The execution environment should be available onboth desktop computers and mobile devices.

• NFR2: Scalability. Implemented solution should be scalable so that increasing number ofSaaS users would not dramatically harm the system’s availability or performance.

• NFR3: Conformance of Graphical User Interface(GUI) Design. Implemented in a productiveSaaS product, the solution should not break the overall GUI design principles, themes,etc...

• NFR4: Security. As an on-line interaction service, the solution interface should providebasic security mechanisms to prevent message flooding and script injection.


Table 3.2: Functional Requirements for Business User

3.4 LOGICAL ARCHITECTURE

The logical architecture is shown in two separate parts from the perspective of Support Userand Business User. Logical architectures which are depicted by figure 3.3 and figure 3.4 reflectsthe functional requirements collected in the previous sections.

From figure 3.3 and figure 3.4, the major components of the thesis implementation can bederived, they are:

• Connection and Messaging Manager

• Roster Manager

• Context Information Provider

• Coordination Manager

• Chatting Helper

• Hint-providing Bot

3.4 Logical Architecture 29

Table 3.3: Functional Requirements for Support User

• Knowledge Database Searcher

• Conversation Templates Provider

• HTML Page Annotator

• Backend Communicator

Connection and Messaging Manager is responsible for connection establishment andcommunication with the chat server. This logical module provides interface to higher levelmodules to send and receive messages of different types.

• Roster Manager is responsible for maintaining the roster of support user. It is the rostermanager’s job to establish the correlation between messages and the conversationpartners. This module also maps other data such as context information to its owner in theroster.

• Context Information Provider encapsulates the functionalities to provide contextinformation from a business user to his chat partner, namely the support user. Someexamples of the context information are: business user identity, product configuration, thescreen at which the business user experiences a software issue and starts to chat, contextinformation that can be collected by existing incident reporting functions, etc..

• Coordination Manager manages web-based on-line coordination operations. Suchoperations may include screen synchronization and user instruction.


Figure 3.3: Logical Architecture Support User

Figure 3.4: Logical Architecture Business User

• Chatting Helper improves the quality of communication in chat by providing support useraccess to knowledge base according to the current chatting context. This module helps toimprove the efficiency of support users by giving him templates for chatting and bots forconversation hints. It uses Hint-providing Bot, Knowledge Database Searcher, andConversation Templates Provider.

• HTML Page Annotator is responsible for annotating the HTML page that will be collectedas context information.

• Backend Communicator is responsible for persisting data, either user specific or issuespecific, over each chatting session.

3.4 Logical Architecture 31

3.5 STRUCTURAL ARCHITECTURE

This section introduces the structural architecture of the thesis implementation. It begins withan overview to the XMPP client-server architecture. Since the thesis implementation mainlyfocuses on the client part, this section will also take a closer look into the components designedin the JavaScript Client.

3.5.1 XMPP Client-Server Architecture

Figure 3.5: XMPP client-server Architecture

The XMPP network has many servers and clients, plus the servers are interconnected in asingle-hop network[SAST09]. Figure 3.5 is derived from the single-hop network, the blue line isthe message route when XMPP Client 01 on XMPP Server 1 sends a message to XMPP Client04 on XMPP Server 2. To implement the functionality for live support integrated into embeddedsupport services for SaaS, the thesis assumes that XMPP servers are built as part of IaaS in thecloud infrastructure; therefore the functionalities of the thesis can be seen as an XMPP clientimplementation. For development and testing, a free XMPP server called Openfire1 is deployed,which includes also built-in data bases which persist user information.

3.5.2 JavaScript XMPP Client Structural Architecture

Graph 3.6 depicts the components at XMPP JavaScript client, at XMPP Server and at thebackend of the supported SaaS. A layered structure which respects MVC pattern is applied. Eachlayer is explained in detail in this subsection.

1http://www.igniterealtime.org/projects/openfire/


Figure 3.6: Structural Architecture

3.5S

tructuralArchitecture

33

View is a layer responsible for all user interface related operations. Figure 3.7 depicts thiscomposite component. The "DOM Operator" component is responsible for CRUD operations ofDOM elements in the HTML5 page. "UI Modifier" component encapsulates logical UI operations,therefore it consumes the "DOM Operator". The separated UI components provide flexibility.

Figure 3.7: UI Controller Component

Model layer is responsible for data operation and bottom layer chat messaging.

• Connection and Messaging Manager utilizes the "Strophe"2 library which provides XMPPclient-server communication for JavaScript. The Connection and Messaging Manager isalso a composite component depicted by figure 3.8 where "Message Extender" providesfunctionality to extend message types, so that "Presence and Message Manager" is ableto not only send chat content in text but also send and interpret other content types likeHTML stream for screen-sharing, coordination parameters and customized messageswhich trigger certain chat client actions like request of sharing context information orstarting incident reporting.

Figure 3.8: Connection and Messaging Manager Component

• Backend Communicator takes care of calling the Application Server to persist and fetchuser-specific data such as templates and chat history. This component uses remotecommunication interface to call back-end function, for example SAP’s "Remote FunctionCall".

Controller layer encapsulates the major application logic that covers the functionalrequirements of the implementation. As a layer sitting between View and Model, the Controllerlayer components separate UI specific logics and the lower data and messaging models. Bysuch a MVC structure, both extensibility and modifiability are enhanced.

2http://strophe.im/


• Context Analyzer is responsible for requesting and collecting context information. Thecomponent consumes "Connection and Messaging Manager" for transferring the requestsand context data. The actions in the component are triggered by events from the UI.Context analysis operations such as screen-sharing also depend on the "UI Controller".Some of the context information is provided by existing functionalities from the backend,therefore the given component also depends on "Backend communicator" for accessingthat context information.

• Coordination Manager is responsible for web-based real time interaction happeningbetween chat users. This component also depends on UI Controller to render coordinationpage elements and the "Connection and Messaging Manager" to perform requiredmessaging.

• Template Manager is responsible for template related operations. Since user specifictemplates need to be persisted, the given component consumes the "BackendCommunicator" to manipulate stored templates. Also, this component depends on the UIto render the templates.

• Chat/Presence Manager is the basic component for taking user inputs from the UI andrender chat responses. The component also manages presence switches and statuschange handling. Similar to "Template Manager", the given component have dependencyon "UI Controller" and "Connection and Messaging Manager".

• Roster Manager is the component which operate the rosters (buddy lists) of a chat user.The given component requests rosters (buddy lists) and manages member (buddy)specific data such as test message, shared screen, and context data. Similarly, the givencomponent has dependency on "UI Controller" and "Connection and Messaging Manager".

• Solution Search Controller is the component which helps the support user to find solutiondocuments or workaround descriptions in the knowledge database. Therefore, the givencomponent has dependency on "UI Controller" and "Backend Communicator".

• Bot is the component which suggests chat content to the support user. Suggestion istriggered on business user input. The given component has dependency on "UI Controller"and "Connection and Messaging Manager".

3.6 PROCESS ARCHITECTURE

This section describes the chat system behaviour from the process point of view. Theprocesses selected illustrate the components’ and the users’ behaviour including normal textchat, screen-sharing and coordination, requesting additional information, and assisted incidentcreation.

Start up: Figure 3.9 depicts the process of chat from the moment when it is started in theHTML client to the initial screen is created. If the user is a support user, the components whichare responsible for user specific templates and roster management are also created. Detailedinteraction between the components is shown in the figure.

3.6 Process Architecture 35

Figure 3.9: Initial Start-up Process

Screen sharing and real time coordination: Figure 3.10 shows an example of messagesequences between the support user’s and the business user’s chat client. To get a sharedscreen, support user needs to first request sharing from business user. If the business useragrees so, HTML page will be encoded into string and transmitted via chat to the support user.Secondly, the referenced "<image>" elements in business user’s HTML pages will be encodedinto Base64 strings and also transmitted. When support user client receives a HTML pagemessage or an image message, the page or the image will be displayed.

The support user client then registers handlers for double click events of each DOM element inthe shared page. The handler will trigger a message sending which contains the nearest parentof the DOM element clicked which has an "ID". Business user client receives this "indication"message and gets the indicated element’s ID for displaying. This way, support user can show apage element for coordination easily without verbal description.

Support user suggested and assisted incident creation: Figure 3.11 depicts messagesequences between the support user’s and the business user’s chat client when the supportuser suggests the business user to report the software issue as incident. The request alsoincludes that the content of the incident will be proposed by the support user for sake ofdescription quality and accuracy. As a result, upon the agreement of business user, the chatclient initiates an incident editing UI for the support user. When the support user finishesediting, this proposed incident will be transmitted and filled into the UI of incident reporting, alsobased on business user’s consent. Starting incident reporting at business user’s side is also endof chatting.


Figure 3.10: Screen-sharing and DOM Element Indication

3.7 GRAPHICAL USER INTERFACE DESIGN

This section introduces the design of the implementation focusing on the user interface.During the user interface (UI) design, this report implementation adopts the method ofuser-centered design (UCD) process. The design focuses on the core needs of the two types ofusers specified in the software requirements.

For business users, the UI should be functionally complete, which means business user canreact to various action requests required by the support engineer, such as agreement overcontext data sharing; page annotation; basic chat input and output. The UI for business usershould also be very simple. The reason is that live support services are accessed by thebusiness user when a software issue happened and the business user is seeking support, if thisservices again fails to be easy-to-use(user-friendly), then the overall user experience of the SaaSproduct will be considerably damaged. Therefore, a simple UI with reactive extensions isdesigned.

3.7 Graphical User Interface Design 37

Figure 3.11: [Incident reporting and content proposal

Figure 3.12 is conceptual design of the graphical user interface for the business user. Theupper part of the chat window is the display of on-going conversation. The middle part is acontrol bar which is only filled with controls when the functions are available. The lower part ismainly the input field. The traffic light at the bottom of the chat window shows the presencestatus of the business user. A submit button is supplied for mobile devices with no physicalkeyboard as an alternative to the "Enter" key in the virtual software keyboard. Buttons in theoutput area are triggered in GUI by messages (input request) sent from the support user. TheGUI in this case controls access to such functions therefore business user does not need toperform any manual search. The figure also shows extended controls for annotation of HTMLpage, such extension controls are added to the control bar when the business user isconducting related operations and removed once the operations finish. As a result, the GUI forbusiness user is simplistic and functionally complete.

For support users, the GUI design focuses on the tasks of support derived from the softwarerequirements. Figure 3.13 is the conceptual design of the support user’s GUI. This GUI consistsof mainly 3 parts. The first part is the elements on the left, which include chat partner’s(business user’s) master information, the shared context information link, the roster of othersupport users and incoming chat service requests. The middle part of the GUI is a compositionof chat and other controls, such as buttons and select lists. The third part of the support user’sGUI is a representation of chat partner’s screen, which is requested for sharing pro-actively bythe support user.

The process of UCD is iterative, new features should be integrated to the GUI with minimumefforts even when new requirements arrive. This is easier for business user’s case since new


Figure 3.12: Business User UI Concept

reaction options do not affect the general layout of UI and control bar can be cleared toinstantiate new controls very easily. For support users, the UI is adjusted each time newfeatures are implemented. Given the design that the right part of the UI for screen sharingshould be viewed in full screen mode, one strategy adopted to cope with this complexity is tore-use and do changes only on the right part of the UI, keeping the left and middle part stable.

Figure 3.13: Support User GUI

3.8 SUMMARY

This chapter introduced the solution proposal of embedded support services deliveredthrough Internet instant messaging. It explained the benefits and concept of this solution

3.8 Summary 39

proposal. Section 3.1 introduced the change of support work flow in case embedded supportservices of chat is introduced as a solution plan and the benefits this change can bring. Section3.2 explained the functions of the intended services to its two kinds of service consumers. Insection 3.3, software requirements were laid out. In section 3.4, logical structures which wereset up to cover the functional requirements were explained. Section 3.5 breaks the system intocomponents. Section 3.6 depicts both examples of components interaction and interactionbetween chat users in sequence diagrams. Section 3.7 introduces implemented UI design,implementation language and environment.


4 IMPLEMENTATION

This chapter introduces how each component specified in the previous chapter isimplemented. First, selected technologies are talked about, then code examples are given whennecessary for key implementations. Diagrams are shown to describe the directory hierarchiesand objects’ relationships. In the end, this chapter is also briefly summarized.

4.1 DEVELOPMENT PLATFORMS

The prototype is going to be built in a JavaScript HTML client of a SaaS ERP product.Important development conditions are given in the following subsections.

4.1.1 Programming Language

The thesis implementation is programmed in JavaScript1, which is the client side scriptprogramming language supported by nearly all major web browsers2. Thesis implementationuses the mandatory name spaces to load JavaScript code and follows conventions in order to beconsistent with the general coding style. A JavaScript library is used for implementation:

Strophe.js "Strophe.js is an XMPP library for JavaScript. Its primary purpose is to enableweb-based, real-time XMPP applications that run in any browser."3 The thesis useStrophe.js to build and extend messages of different types to communicate with theServer.

1https://developer.mozilla.org/enUS/docs/Web/JavaScript?redirectlocale=enUS&redirectslug=JavaScript2http://en.wikipedia.org/wiki/Comparison_of_web_browsers3http://strophe.im/strophejs/

41

4.1.2 XMPP Server

For the thesis implementation, the selected XMPP Server is Openfire. "Openfire is a real timecollaboration (RTC) server licensed under the Open Source Apache license."4 Chat user andgroup data are stored in the XMPP Server. For the prototype implementation, the XMPP serveris deployed on a PC in the SAP Intranet, development environment and the JavaScript client isrun on another machine.

4.1.3 Development Environment

The thesis implementation is built in a HTML5 client of an Enterprise Resource Planning SaaSproduct. Therefore naming conventions and script loading syntax are regulated by a proprietaryJavaScript library.

Eclipse5 is the IDE used for the implementation. Git6 is the distributed version control toolused. Maven7 is used for project management. Google Chrome8 is the browser used fordevelopment and testing.

4.1.4 Implementation Baseline (existing feature to be adapted and reused)

To enable chatting with context information, it is necessary to consume the context data thatis already collected by the embedded support features. Figure 4.1 gives a holistic view of allthose context providers. However only some of the existing JavaScript code will be consumed,which will be explained in later sections. The thesis implementation also changes some of theexisting features for new features’ requirements. The added functions are listed in the objectsthat it belongs to.

This existing framework was designed for providing embedded support services in a formvisible to the end user as "Reporting an incident". To get a more detailed overview of the existinginfrastructure, they are now explained coarsely:

• DiagnosticsManager is a facade, which handles the phases and the overall contextcollection. This is the central entry point for embedded support, not only for contextcollection.

• ContextCollectionManager is a singleton class which handles the context collection onclient side (context collection happens on both server and client sides). Here the contextprovider can be registered and executed.

4http://www.igniterealtime.org/projects/openfire/5http://www.eclipse.org/6http://git-scm.com/7http://maven.apache.org/8Version 27.0.1453.116 m

42 Chapter 4 Implementation

• ReportIncidentFloorplan is a UI factory that creates a new window that enables user toinput incident facts.

• Context Providers is a package which contains all the "context providers". A contextprovider collects certain context information, either from frontend or application backend.Examples of context information are: exceptions, images on user screen, values in inputfields, etc.

• Context Collection Phases is a package which contains abstraction of different phasesduring which context providers are called. The context providers are not executed alltogether because certain context information can only be collected at certain points intime distributed between client and server.

• Miscellaneous is an abstract representation of other JavaScript files that provide assistingfeatures for context collection, they are not to be directly consumed by chat.

Figure 4.1: Implementation Baseline with Added Functions

4.1.5 Packages Overview

This part will present how the different functions of the prototype are implemented. Eachdifferent aspect of functions is grossly represented by a package which contains theimplementation JavaScript files.

Overview of the packages is given by figure 4.2. Code in each of the packages will beexplained in more detailed manner in later parts of the chapter.

4.1 Development Platforms 43

Figure 4.2: Package Diagram of Thesis Implementation

4.2 BUNDLING OF EMBEDDED SUPPORT SERVICES

This report suggests two approaches to provide live support services to business users. Thefirst approach is the reactive approach: currently, the embedded support services are accessedby the user from a static position in the GUI, regardless of which product component the useruses or which work center the user is currently working on. By providing an access point at thesame place, user can access live support services in conformance with other embedded supportservices. The second approach is the proactive approach: users who are performing a certaincategories of actions are suggested automatically to use live-support service, for example whenthe user is searching for a solution document too long without rating a helpful result, or whenthe user is answering a ticket which has already been sent back for detailed information.

Though the motivations behind the two approaches are quite different, the implementationsfor both are rather similar. For conciseness, the implementation in the thesis provides only thereactive approach. The "Get help by on-line chatting" link is the service access point for businessuser. Through the "Log-in as support chatter" link, support user can use the service.


4.3 BASIC CHATTING SERVICE: CONNECTION MANAGEMENT,MESSAGE AND CONTACT HANDLING

This section introduces implementation of the functionalities regarding basic chatting servicesincluding connection management, text messaging and contact(roster) handling.

4.3.1 Connection Management

ConnectionManager.js is a singleton which is responsible for maintaining connection to the"Openfire" XMPP server from the browser, shown in listing 4.1(For conciseness, functions areonly shown with their signatures whenever possible). The prototype also specifies defaultautomatic reconnection on server timeout as long as chat is not closed by the user.

1 sap.client.embsup.xtoc.connection.ConnectionManager.prototype.connect = function(

bIsReconnect)

2

3 sap.client.embsup.xtoc.connection.ConnectionManager.prototype.getOffline = function()

Listing 4.1: Connect and disconnect functions

It is also responsible for dispatching message of different types (extension) to their handlers.Listing 4.2 shows the calling in function "connect" which registers the function "on_indicator" tohandle any message of type "xtocIndicator", which are those that indicate an HTML element tohighlight sent by the support user:

1 that.connection.addHandler(that.on_indicator, null, "message","xtocIndicator");

Listing 4.2: Registering handlers for messages

To have a holistic overview on the implemented message extensions and their handlers, a list ofmessage and handler mapping is provided in table 4.1

4.3.2 Contact/Roster Management

There is no need to let a business user see his roster. But for support user, it is better toencapsulate data like chat history and user master information. The "ContactsManager" is asingleton which maintains lists including the support users and the business users that aretaken over in chat by the support user. In JavaScript, there is no formal definition of a class,therefore an object diagram figure 4.3 is used to represent the relationship of the relatedJavaScript objects in runtime, at a moment when there are 2 contact objects created. Thecreation of contact objects are triggered by function "on_roster", is explained in the MessageExtension subsection. Major functions of the objects in figure 4.3 are explained in detail:

• ConnectionManager A singleton object which requests roster and registers handlers forroster entry stanzas sent back from the server.


Table 4.1: Stanza Extensions and Handlers

Message Type Handler Name Handler Explanation

chat on_message show plain text chatpresence on_presence react on presence changesxtocIncidentPrepareRequest on_Request dispatch to function to request business

user if to allow incident preparationxtocSSKeyRequestMessage on_Request dispatch to function to request business

user if to allow send solution search keysfrom system messages

xtocNewSUSuggest on_Request dispatch to function to request businessuser if to accept a chat transfer

xtocSSKeyRequestException on_Request dispatch to function to request businessuser if to allow send solution search keysfrom system exception

xtocIndicator on_indicator add highlight effects to indicated HTML el-ements

xtocRemoteControl on_remoteControl trigger click event in business user’s UIwhen an element is clicked in the remotecontrol mode by support user

xtocIframeImage on_iframeImage replace image URL with Base64 strings,show images

xtocIncidentPrepareRequest on_Request ask business user if support user can sug-gest incident inputs for him/her

xtocIncidentRequestAgree on_prepRqtAgr start incident preparationxtocScreenRequest on_Request request a screen sharing from business

userxtocContextCollectionLinkRequest

on_Request request business user to render a link toholistic context information collection

xtocRequestReject on_reject show user rejectionxtocNewSUSuggestReject on_reject show user rejection of chat transferxtocIncidentFact on_incidentFact stop chat and start incident reportingxtocPCIRequestAgree on_pCIAgree notice support user that business user has

started annotating the screen and prepar-ing context information link

xtocNewSUSuggestAccept on_TransferAgree notice support user that business user ac-cepts chat transfer

xtocJSSTCancel on_jSSTCancel notice support user that business usercancelled sending context information link

xtocJSSTSent on_jSSTSent notice support user that business usersend context information link with anno-tated HTML page

xtocReportIncidentChatOver on_ChatOver notice support user that business userstopped chatting and begins incident re-porting

xtocBrwoser on_Browser request browser type and version frombusiness user

xtocSSMsgKeys on_MsgKeys display and use solution search suggestedkeys

xtocHTMLStream on_HTMLStream display HTML page in an IframextocTransferDetails on_TransferDetails display chat history and context collection

link to the next responsible support userin case chat is transferred


• StanzaExtender A factory singleton which instantiates extended message types.Extensions specified are shown in the next subsection in detail.

• ConnectionParams A singleton which supplies connection parameters like server address,port number, initial user name(JID) and initial chat partner name(JID).

• ContactsManager A singleton which maintains contacts in different lists and managesrosters.

• Contact Each roster member is represented in the JavaScript chat client as a Contactobject. It encapsulates data like name and contact information, user type and referencesto UI elements belonging to the contact such as sub-window for multi-chat.

• Message Objects which contain the content, the associated contact, and time stamp of atext chat message.

Figure 4.3: Object diagram depicting ConnectionManager

4.3.3 Message Extension

1 <message to='[email protected]'

2 type='chat'

3 xmlns='jabber:client'>

4 <body>

5 Hallo World

6 </body>

7 </message>

Listing 4.3: A normal message stanza

In XMPP protocol, the data that is exchanged is in XML. There are three kinds of XMLelements defined in the default XMPP namespace, each of which is called a


"Stanza"(<message/>, <presence/>, or <iq/> elements9). "XMPP stanzas make up the core partof the protocol"[Mof10]. To realize features that are beyond text chatting, extending the dataformat is necessary. Listing 4.3 shows a default stanza in XML which is exchanged to"[email protected]" to the server the "type" attribute specifies that this message stanza is asimple text chat message. The extensions to XML data can be either made on attribute level oron element level. The prototype defines the following function shown in listing 4.4 in the"StanzaExtender" to extend XML on both levels:

1 sap.client.embsup.xtoc.connection.StanzaExtender.prototype.extendMessageStanza = function(

2 sNewTag, sTextValue, sType, oMsg)

Listing 4.4: Extending Message Stanza

With this function, it is possible to define stanza for special purposes. For example it is possibleto create a "prepare incident request" to the business user by calling

1 var oMsg = sap.client.embsup.xtoc.connection.StanzaExtender

2 .getInstance().extendMessageStanza("Request",

3 "Y/N", "xtocIncidentPrepareRequest");

A message which has the type attribute value "xtocIncidentPrepareRequest" is then created, andit contains a child element "Request", whose value is "Y/N". Listing 4.5 shows the producedmessage in detail. The business user side code can determine how it handles this requestflexibly.

1 <message xmlns='jabber:client'

2 to='[email protected]'

3 type='xtocIncidentPrepareRequest'

4 from='[email protected]/495eec99'>

5 <Request>

6 Y/N

7 </Request>

8 </message>

Listing 4.5: An extended message stanza

4.4 USER INTERFACE

Figure 4.4 shows two links to access chat service in the help center in an EnterpriseResource Planning SaaS product. Business user can click on the link "Get help by on-linechatting" to start chatting. The implemented business user GUI is shown in figure group 4.5.Figure 4.6 shows the support user’s GUI, implemented according to the design which isdescribed subsection 3.7.

9According to XMPP standard(http://xmpp.org/rfcs/rfc3920.html#stanzas), the definition of XML Stanza is an XMLstanza is a discrete semantic unit of structured information that is sent from one entity to another over an XML stream.An XML stanza exists at the direct child level of the root <stream/> element and is said to be well-balanced if it matchesthe production content of [XML]"


Figure 4.4: Integrated Live Support in Embedded Support Services

4.5 WEB-BASED COLLABORATION SERVICE FOR EMBEDDEDSUPPORT

Three major features are implemented for web-based collaboration between support user andbusiness user. The support user can require HTML screen sharing, highlight a selected DOMelement and refresh UI specific templates by requesting a unique identifier for current UI forcurrent business user. The three features are explained separately in this section.

4.5.1 Screen Sharing through XMPP

Instead of taking and transferring an image format picture such as PNG, the prototypetransfers the target HTML page together with CSS and displays the HTML page in an "<iframe>"tag in the support user’s UI. This approach lowers the programming efforts and also bringsadvantages, for example text on initial page can be copied in the transmitted page. Thismentioned step is done with the extended message stanza of type "xtocHTMLStream". The nextstep is to replace the entire source URLs of "<image>" tags to correctly display the images onthe target page. This step is done with the extended message stanza of type "xtocIframeImage".

The function which provide the original HTML stream and the function which extractsreferenced image into Base64 strings are existing features which locate in the"embsup/contextproviders" package, the thesis reuses many of the context providers as datasources. However the results returned by those "context providers" are not directly consumableby chat client, as they are initially designed to transfer JSON ( (JavaScript Object Notation)10 data

10http://www.json.org/

4.5 Web-based Collaboration Service for Embedded Support 49

(a) Business User GUI(without additional con-trols)

(b) Business User GUI(with additional con-trols)

Figure 4.5: Implemented Business User GUI

to the ABAP backend. Therefore in controller objects which call the context providers,adaptation is performed and results are used to initiate specialized extended message stanzas.

Figure 4.7 depicts how the context provider facade "ContextInformationProvider" consumesthese existing supportability functionalities. On one hand, it creates directly context providerslike "HtmlStreamProvider", "ContextImageProvider", and "MessagesProvider" because thesecontext information can be collected lazily, which means the context information is eitherdurably available for collection, or the context information is buffered for collection. On the otherhand, "ContextInformationProvider" also calls "ContextCollectionManager" to get a list of contextproviders which are only created under certain situations, such as "ExceptionContextProvider"."ExceptionContextProvider" is instantiated only when unhandled exceptions occur and these aredisplayed to the user. As a result, "ContextInformationProvider" needs to store these transientcontext information for later consumption.


Figure 4.6: Support User GUI

Figure 4.7: Facade for Context Collection


(a) "Session Time Out" exception window (b) Shared "Session Time Out" Exception Window

(c) UI with Donut Chart (d) Shared Screen for UI with Donut Chart

Figure 4.8: Screen Sharing Results Examples

52C

hapter4

Implem

entation

Figure 3.10 shows the sequence diagram of this process. Figure group 4.8 shows the effectsof screen sharing on randomly picked UI in the cloud product. Figure 4.8b and figure 4.8d arethe support user’s view on the transferred page, figure 4.8a and figure 4.8c are the originalpage where business user starts chat on and transferred to the support user. The DOMelements that form chat window are removed in the transferred HTML stream so that in figure4.8b and figure 4.8d, the business user chat window is not shown. An interesting point is thatthe scroll bars available on the shared HTML page are also available for scrolling, since thewhole page is transmitted.

4.5.2 DOM Elements Highlighting through XMPP

It is necessary to let support user indicate a screen area in order to quickly and convenientlyinstruct actions to the business user. When HTML stream is used for re-constructing thebusiness user page, there is loss of accuracy due to difference of browsers or screen settings. Itis therefore not feasible to directly transfer the coordinates of the indicated UI elements. Thesedifferences can be noticed also in figure group 4.8, the scroll bars have different size and lookdifferent for example. A special message stanza is extended for the purpose of accurateindication of DOM elements.

Figure 4.9: State Chart: find indicated UI element

After the screen sharing happens, support user would have a copy of the page displayed in an"<iframe>" tag. Figure 4.9 shows the recursive approach how element is selected for theindication. On each of the DOM elements, double click event handlers are registered. In thehandler, it is checked if the DOM element has an ID recursively along the event bubblingsequence. Then the ID of the clicked element or in case it does not have an ID, its nearestparent node is sent to the business user. There the ID is extracted to find its owner element.


And special visual effects are added to the indicated element. In this way, regardless of theinaccuracy of screen-sharing, the DOM elements indication is always targeting at the element ofwhich the ID matches.

Results of the double clicked elements highlighting can be seen in figure group 4.10, wherehighlighting effects on different HTML tags are shown. The rectangles which indicate thehighlighted elements are given a "blinking" effect, whose color is switching rapidly betweenyellow and red.

(a) Highlighted "Work center view"(yellow) (b) Highlighted input field(red)

(c) Highlighted Table Header(yellow) (d) Highlighted Link(red)

Figure 4.10: Screen Sharing Results Examples

4.5.3 Dynamic Templates Fetching

To use communication templates effectively, the templates should be context specific. Tosimplify the problem, templates can be UI specific. Therefore fetching the UI specific templatesin chat can be broken into two steps. First step is getting the keys of the UI; second step usingthe keys to query the templates from database. Since the second step involves mostly backendfunctions that have to be implemented in the server and there is currently no business data(templates) available. It is more practical and also technically meaningful to simulate the secondstep by using experimental templates in the JavaScript chat client. For the same reason, theimplemented "BackendCommunicator" contains only functions with mock-up data instead offunctionalities that fully consumes server side services.

In the environment UI framework of the SaaS product. UI components are identified in alayered structure of different granularities. The "Work Center" is the highest level, under which


exist multiple different "Work Center Views"; under each view the "CurrentWindowID" uniquelyidentifies the current UI component the business user is working on. The thesis implementationextracts all three of the IDs and let support user choose which to use for fetching templates.Figure 4.11 shows the results of UI key extracting in a window that enables support user to usethe captured UI component keys to search for related templates.

Figure 4.11: Captured UI Component Keys

4.6 ACCESS TO HOLISTIC CONTEXT INFORMATION SERVICE

Though the thesis implementation empowers chatting with many important contextinformation that can be collected by pre-defined context providers. There is still much contextinformation that is relevant for deeper analysis. To fully leverage the existing context collectinginfrastructure in the SaaS product, it is implemented that support user can require business userto trigger a holistic context collection and the context is persisted on the server, therefore it isavailable for immediate and later analysis.

4.6.1 Link to holistic collection of context information

Support user can view all possible context information with support tools in a structured waywith this link to the holistic context information collection. Figure 4.1 shows the modified"DiagnosticsManager" has a new function which is called "createIncidentSilentlyWithJSST". Thisfunction implements the triggering of the above mentioned context collection.

4.6.2 HTML Page Annotation in IIM for Embedded Support

To make it easier for business user to describe a software problem, especially those that arerelated with UI, the thesis implementation lets him annotate the HTML page. An existing HTMLpage annotation tool "JSSTManager" is reused for the purpose. The annotated page is latertransferred into the dummy incident created, which is mentioned in the previous subsection.

There is an adaptation that is done in the chat client in order to use the existing"JSSTManager". The reason is "JSSTManager" copies the entire HTML page contents into an<iframe>, and annotations are done on top of the <iframe>. So that a copy of the original pagecontent can be modified in the <iframe> without worrying about destroying the original page.This process would also copy the current chat window, which is not desired. Therefore there aretwo alternatives to solve this issue: one is to temporarily remove the chat window; the other

4.6 Access to Holistic Context Information Service 55

Figure 4.12: Adaptation to JavaScript Screen-shot Tool (JSST)

being temporarily set the "display" attribute to "none". For sake of minimal size of the resultedtransferred HTML stream, the thesis implementation temporarily remove chat window till theentire page is copied and the <iframe> is rendered. Figure 4.12 shows this process as concept.Figure 4.13 shows the integrated page annotation in chat client.

Figure 4.13: HTML page annotation before holistic collection of context information

4.7 HUMAN IT-SUPPORTED SUPPORT SERVICE

When support user tries to resolve the business user’s software issue, in many cases thesupport user has to refer to the internal knowledge base. For the thesis implementation’sproduct, access to two of the search engines is provided for the support user directly in the chat


client. According to the context information support user can get from the thesisimplementation, he can already search for many key words (search terms). Furthermore, it isimplemented that the chat client is able to automatically extract some search terms. The thesisimplementation uses two types of search terms, namely the exception information and thesystem message information.

Figure 4.14 shows how the two types of context information can help support user quicklyfind existing solution documents in order to reply to business user efficiently and effectively. Infigure 4.14 the business user chat client extracts the error messages and the exceptioninformation (hash keys) by calling the responsible context providers, shown in figure 4.7. Theextracted information will be transferred to support user. On the support user’s client, theinformation will be displayed in a structural way thus support user can choose what touse/combine to have the best search terms. Figure 4.14 also shows the association betweenthe internal tickets and software issues. If the business user’s software issue (software issue 3’in figure 4.14 ) has the same error messages or same exception as an already solved softwareissue (software issue 3 in figure 4.14 ), then it is highly possible that the solution or workaroundspecified in the ticket (internal ticket 3 in figure 4.14 ) which addresses this already archivedissue also applies to the newly encountered software issue. Additionally, by using exceptionhash key or error message text, the ticket will be searched and found.

Figure 4.14: Captured UI Component Keys

The thesis implementation uses an <iframe> to integrate the search engine for the last stepof using automatic extracted search terms, an example where business user’s exceptioninformation being transferred for solution search is shown in figure group 4.15, where figure4.15a shows the exception happened in business user’s application and figure 4.15b shows theextracted hash keys and the integrated search engines.

In this way, an "Human IT-supported Support Service" is implemented.

4.7 Human IT-supported Support Service 57

(a) Business user experiences an exception

(b) Support user searches for solution documents with extracted exception hash key )

Figure 4.15: Solution search with automatic search terms extraction


4.8 BUSINESS USER TRANSFER SERVICE

When a support user discovers that the business user encounters an issue which the supportuser cannot solve, a business user transfer service is provided so that the support user canassign the chat session to his on-line colleagues.

Together with the chat transfer, the message history and the latest link to holistic contextinformation collection is also transferred to the new support user to avoid redundant repeatingconversations.

Figure 4.16: Business User Transfer Service UI

Figure 4.16 shows the UI where the support user just received an chat transfer from hiscolleague "Michael Schultze", before any conversation with the transferred business user"Business-User", he can already see the history chat conversation and access the link to holisticcontext information without asking the business user for that again.

4.9 SUPPORT USER ASSISTED TICKET CREATION SERVICE

To improve the ticket handling process, it is important that the ticket is created with gooddescription. When the end users (business users) cannot always deliver this, it is better to let a

4.8 Business User Transfer Service 59

support user who has already chatted with the business user to create a ticket for the businessuser. This support user assisted ticket creation service is especially important given the fact thatnot all software issues can be solved during a chat session, for example a newly discoveredsoftware bug.

(a) Support User suggests ticket contents (b) Business User starts ticket reporting

Figure 4.17: Support User Assisted Ticket Creation Service

The this implementation provides such a service by rendering a UI shown in figure 4.17a tothe support user where he can input subject, description, and also priority for the issue. A chathistory view field is supplied for support user to review the chat session. These inputs are thensent to the business user. Upon agreement, the business user can use the suggest contents toreport an incident, shown in figure 4.17b, note that the suggested contents including subject,description and priority are pre-filled into their fields. Business user is free to modify thesesuggested inputs.

4.10 COLLECTION OF CHAT HISTORY AS CONTEXT INFORMATIONSERVICE

In case a ticket is created after using chat services, the chat history should be persisted in theticket because it may contain useful information. Therefore the thesis prototype implemented aservice for collection of chat history as context information and defined the class"ChatHistoryCntProvider", in which chat messages are stored and upon ticket creation, sent as


part of the ticket. Persisted chat history is stored as XML data in the backend. Listing 4.6 showsan example from the loaded ticket, only two "record" elements are kept to be concise.

1 <?xml version="1.0"?>

2 <spr:ContentCollection xmlns:spr="http://www.sap.com/spr">

3 <spr:Content ContextId="A97BC22D7E019842C39853998AFC0BC4" Sanity="OK" Size="1317">

4 <ChatRecords>

5 <Record>

6 <from>[email protected]/725832d9</from>

7 <to>[email protected]</to>

8 <content>Do you want to let me access your browser information?</content>

9 <time>10:46:04 AM</time>

10 </Record>

11 <Record>

12 <from>[email protected]</from>

13 <to>[email protected]</to>

14 <content>hi</content>

15 <time>10:52:50 AM</time>

16 </Record>

17 ...

18 ...

19 </ChatRecords>

20 </spr:Content>

21 </spr:ContentCollection>

Listing 4.6: Persisted Chat History

4.11 AUTOMATIC CHAT ASSISTANCE SERVICE

The purpose of implementing a chat bot 11 is to provide a service to the support user toquickly respond to a business user in chat. Since user experience is a major concern for thethesis implementation, bot is only used to propose response to the support user instead ofdirectly "talking" to the business user.

The designed chat bot can be seen from figure 4.18. The thesis only implements theconversation interface of the chat bot and uses simple template questions to simulate aresponse generated by modules which processes business user inputs and query for answers.For the conversation interface part, the thesis implementation falls into the category of"Responder Bots" [GXWW11], which means that the bot’s output are triggered by certain orevery human user input. Figure 4.19a shows the chat bot’s suggestion upon an business user(named "Thomas Mueller") input. Figure 4.19b shows that support user accepts the suggestionso that the text is automatically copied for further editing.

11Bots are "automated programs, that is, programs that do not require a human operator. A chat bot is a program thatinteracts with a chat service to automate tasks for a human"[GXWW11]

4.11 Automatic Chat Assistance Service 61

Figure 4.18: Design of Bot for Automatic Chat Assistance

In this way, a service which provides automatic chat assistance to the support user isimplemented, the objective of quickly replying to multiple business user is further realized.

4.12 SUMMARY

The given chapter explained the thesis implementation from its lower level XMPP protocolstanza extensions and dependencies on existing infrastructure to examples of implementationof the context-information-rich chat. Diagrams are given both to demonstrate the workingprinciples of the implementation and to show the results of some implementation details. Somelines of key codes are also briefly listed in order for the user to grasp the details.

• section 4.1 explained the development environment of the prototype implementation,declared the technologies, and depicted system dependencies.

From a service point of view,

• section 4.2 showed how chat support service is bundled into the environment SaaS;

• section 4.3 showed how chatting service is implemented with messaging basics androster handling;


(a) Bot suggests reply to the support user

(b) Support user accepts the suggestion by clickingon the blue area. Suggested content is then copiedto the input area.

Figure 4.19: Automatic chat assistance

• section 4.5 showed how web based-collaboration as a service is implemented, includingservices like screen sharing, DOM elements highlight, and dynamic templates fetching;

• section 4.6 showed how a service to access holistic collection of all pre-defined contextinformation is designed and realized through chat with a link to the context information andintegration of HTML page annotation functionality;

• section 4.7 shows the implementation of solution search in chat which delivers the humanIT-supported support service;

• section 4.8 shows the implementation of business user transfer service, which helps thesupport user to find the right colleague for the given software issue.

• section 4.9 shows the implementation of support user assisted ticket creation service,which would improve the ticket quality before tickets enter the handling process.

• section 4.10 shows the implementation of collection of chat history as context informationservice, which persists the chat messages once software issue is not solved and a ticket iscreated.

• section 4.11 showed the implementation of a bot interface and the design of high levelbot modules, which together renders service of automatic chat assistance.

4.12 Summary 63

5 EVALUATION

5.1 EVALUATION CRITERIA

In chapter 2 "Goal Setting", the general goal was defined to cut operational cost at SaaSvendor’s side and to improve customer satisfaction. The following functional expectations wereset for this thesis:

• live chat for fast first response, thus for better customer satisfaction

• templates for efficient communication

• on-line diagnose with live chat

• live chat - solution search integration

• Chat assistance

For each of the goals, several services are implemented. As a recap, they are listed brieflynow in table 5.1.

Table 5.1: Goals Features Mapping

Goals Main features implemented

live chat for fast first response Multi-user text chat;templates for efficient communication Three types of templates(General Template; UI-

specific templates; My Templates)on-line diagnose with live chat Link to holistic context data collection

support user-assisted incident creationlive chat - solution search integration Integration with two major support search engines

Automatic search term extractionChat assistance Bot interface to support user;

65

To evaluate if the thesis implementation fulfills the general goal, it would require deploymentof the prototype in productive business systems for a long term assessment with real customerinteraction. It is not feasible to fully simulate this in the manageable time scope of the thesis.Therefore the effects of the implemented thesis prototype are measured in interviewquestionnaire, answered by support and development employees in SAP’s cloud organizations.

The different types of context information which are made available for real-time consumptionin the thesis prototype are based on XMPP protocol. To measure the performance of XMPPprotocol transmitting the context information, especially larger data like big CSS(cascading stylesheet) strings and images in Base64 formats, several features are measured on their accuracyand timing performance such as screen-sharing based on HTML.

Positive and negative values for the measured attributes are given in the questionnaire indifferent degrees, therefore the evaluation has a clear criteria if the impacts of the prototype arecontributions or not, and if yes, how much.

5.2 EVALUATION DESIGN

This section will introduce why and how the evaluation is designed in its way in two parts,namely the test evaluation and the questionnaire evaluation. Questionnaire distributed can befound in appendix B, only the contents which illustrate the reason and design of thequestionnaire will be discussed in the related subsection (subsection 5.2.2).

5.2.1 Design of Tests

Goals of the tests are to measure concrete performance of the thesis implementation indifferent dimensions of features in detail, these measurement objectives are:

• Screen-sharing Accuracy

Screen-sharing based on HTML reconstructs the business user’s page in the supportuser’s screen. Different to screen-sharing based on screenshots, this approach can showsupport user each DOM element and their values without losing quality by imageencoding. So texts on the page can be copied, links can be examined, IDs of the DOMelements can be retrieved. To measure the screen-sharing’s accuracy, it is vital to test if allHTML tags which are relevant for display are correctly copied and reconstructed.

For evaluation, these meta data are collected from both business user and support user byJavaScript code instrumentation. A comparison between the shared HTML page and thedisplayed shared screen is done in this chapter. Original data can be found in appendix C.

• XMPP Screen-sharing Performance

66 Chapter 5 Evaluation

Among all the context information that is structurally displayable in the chat prototype, theshared screen consumes by far the most band-width. Therefore by measuring theperformance of screen-sharing, the performance aspect of the prototype can bereasonably estimated.

This measurement objective is reached through several key indicators, namely the "HTMLPage Collection Time", the "HTML Images String Collection Time", the "Page Display Time",and the "HTML Page Transfer Time".

• Screen-sharing Performance compared with Stand-alone Screen-sharing Tools

The screen-sharing functionality of the thesis prototype is based on HTML transmission. Itis necessary to compare the end-to-end latency of this approach with general approachwhich is based on screen-shot(image format) data transmission. This report selects twopopular tools in the market to compare this performance, namely the Citrix GoTo Assist 1

and the Adobe Connect 2.

For the Adobe and Citrix products tests, videos which are SAP Business ByDesign livedemos are played in full screen in the shared screen to simulate product usage scenario inpractice, a timer page is opened on top of the video so that screen shots can be madecontaining both the shared screen and the displayed shared screen with timers. Bysubtracting the two time stamps, latency can be calculated.

5.2.2 Design of Questionnaire

The goal of the evaluation questionnaire is to measure

• how the thesis implementation realizes the functional requirements

• the potential of the prototype suggested embedded support services, their use cases andestimated contributions

So the questionnaire is distributed to voluntary respondents from the SAP cloud organizations.

The questionnaire should ask the following general categories of questions:

• What chat services are important for different stages in ticket handling? Does theevaluated solution implement these services to be helpful?

• How well does the evaluated prototype compare to other means of live support and otherchat products?

• How will the evaluated prototype influence the workloads of support organization andSaaS provider overall?

• How will the evaluated prototype influence user satisfaction?

• Does the evaluated prototype show promising use cases for support?1http://www.netviewer.com/en/products/gotoassist/2http://www.adobe.com/products/adobeconnect.html

5.2 Evaluation Design 67

Respondents are required to specify their job responsibilities and the average number ofweekly software problem reports (tickets) they process. The questionnaire then focuses oncomparison between the respondents’ expectation of chat tool features that are helpful forsupport and the realized features of the thesis implementation. Questions are also given to seehow often respondents feel the need to directly contact the software issue reporter. After whichthe respondents are asked to answer in which senses the implemented prototype can be betteror complementary to a phone call. Respondents then face the question about what are theadvantages and disadvantages of the evaluated prototype compared to existing chat solutionbased on HTML. In the end, respondents should tell their estimation of the evaluatedprototype’s influence on cost of SaaS provider and user satisfaction.

5.2.3 Testing Environment

For test evaluation, the test environment is given:

• Hardware environment is listed in table 5.2

Table 5.2: Hardware Environment

PC Model CPU RAM

Lenovo Thankpad T510 Intel Core i5 (2.53GHz, 2.53GHz) 4,00GB

• Software environment is listed in table 5.3

Table 5.3: Software Environment

Operating System Browser

MS Windows 7 Enterprise, 64-bit Google Chrome (Version 29.0.1547.57 m)

5.2.4 Thesis Prototype Testing Set-up

Figure 5.1: Test Set-up


Figure 5.1 depicts the test set-up used in evaluation. It is shown that chat clients are run onthe same Laptop in different browser taps. XMPP server is installed on a remote server. Testclients and server are connected by the internet.

5.3 RESULTS FROM QUESTIONNAIRE

After live-demo to the respondents, they are asked to fill in the questionnaire (given inappendix B). Missing results to single questions are not included in the calculation and analysisin this chapter, however the sent back questionnaires with incomplete answers are notexcluded. In total eleven questionnaires were returned.

5.3.1 Respondents Job Distribution

Figure 5.2 depicts the distribution of job responsibilities among the interviewed respondents.It shows that the questionnaire interview covers employees involved in various phases ofsoftware issue handling processes including support and development. Respondents alsoinclude support managers, and employees from other cross-over organisations that are stakeholders to software issue handling for SAP’s cloud offerings.

Figure 5.2: Respondents Job Responsibilities

Some of the organizations are specific to SAP, therefore not introduced in previous chapters,now they are described briefly:

• Support Management

Respondents in this group are managers for employees in Expert support and directsupport, they are also experienced employees with support professions.

• Support Innovations

Respondents in this group define support processes which are delivered to the customersfrom the support organization.

• Quality Management

Respondents in this group set quality KPIs for products, define and measure teststrategies, manage test systems.

5.3 Results from questionnaire 69

• Knowledge Management

Respondents in this group write product documentations, make roll-out materials andmanage terminologies used.

5.3.2 Assessment of Features Coverage

Figure 5.3 shows the average importance of chat features wanted by the respondents inorder to understand and solve software issue in chat separately. It shows that all the listedfeatures have gained a rated importance over 3, where 5 is the highest importance (5 is labelledas "Very Important" in the questionnaire, whereas 1 labelled as "Not important"). Since only onerespondent mentioned "Chat History Persistence" in the questionnaire and rated it onlyimportant for understanding software issue, this measured feature does not have importance forissue solving (value is zero).

Figure 5.3: importance of chat features

5.3.3 Assessment of Provided Context Information Quality

To rate the quality of the prototype services implementation, respondents are asked to givetheir ratings of quality of each implemented feature of the prototype(S) (5, which stands for "VeryGood" is highest possible score; 1 is lowest for "Very Poor") and the their best expected qualityof such feature in any possible chat tool(E) (5, which stands for "Very Good" is highest possiblescore; 1 is lowest for "Very Poor"). Therefore, the thesis calculates the score by dividing theexpected quality with the rated quality, from which the average value(Score ) can be calculatedusing equation 5.1 out of respondents replies, given there were (n) respondents. Results areshown in figure 5.4. Those answers are higher than 1.0 were treated as 1.0 in the results, whichhappen when thesis implementation quality exceeds the expectation of the respondents.


Score =Σ( S

E )

n(5.1)

.

Figure 5.4: Estimation of Ticket Avoidance

From figure 5.4, it can be seen that all of the evaluated features reach a score over 0,85 fromthe respondents’ point of view. Solution Search and bot for support user have relatively lowerscores. To explain this, the reason why bot gets a lower score is probably its lack of intelligence.Some respondents gave also the feedback that the solution search can be better integrated ifthe searching step is automatically performed.

5.3.4 Estimated Influence on Tickets

Given the assumption that on average tickets that are solved more quickly have higher quality(more complete/accurate description, more complete problem reproduction steps, etc) thanthose with lower quality. One question in the questionnaire is given to let respondents estimateinfluence on ticket resolving time if there would be enough well-trained support users and theprototype would be productized. Figure 5.5a shows this estimation from respondents afterprototype demo. All answering respondents claimed that tickets will be solved faster in aprevious question. The result shows that 30% of respondents believe that the prototypesolution, once productized, can contribute to a reduction of ticket resolving time to 51% to 70%,


(a) Estimation of Future Ticket Resolving Time (b) Estimation of Ticket Avoidance

Figure 5.5: Estimated Influence on Tickets

another 30% claimed a reduction of ticket resolving time to 31% to 50%. The otherrespondents were even more optimistic regarding this.

Given the assumption that there would be enough well-trained support users and theprototype would be productized, figure 5.5b shows the estimation of tickets that can beavoided. It shows that half of respondents expect a 31% to 50% reduction in ticket number.30% of all respondents expect a reduction of 11% to 30%.

5.3.5 Estimated Influence on Customer Satisfaction

Figure 5.6 shows the respondents’ estimation of the chat tool’s influence on the customersatisfaction. All respondents give positive estimations, 36% of them estimated a full customersatisfaction influence "+5". 64% of all respondents estimated satisfaction influence of "+3".

Figure 5.6: Vote for influence on customer satisfaction


5.3.6 Estimated Influence on SaaS Provider Cost

Respondents are asked in the questionnaire to give their estimates of the effects of chat toolon cost, of support departments alone (shown in figure 5.7a) and of the whole SaaS providerorganization (shown in figure 5.7b).

(a) Estimation of New Support Workload (b) Estimation of New SaaS Provider Workload

Figure 5.7: Influence on Workload

About estimation of new support workload, 55% of all respondents answered that supportload would be less. 18% of all respondents chose 91% to 110% of original work load; The other27% of all respondents think that support load would increase to 111% to 150%. Therespondents’ answers are not very unified regarding this estimation.

For the workload of entire SaaS organization, 60% of all respondents estimated reductioninstead of increase. 30% of all respondents claim that work load will reduce more than 50%.10% of all respondents say workload will remain more or less the same (91% to 110% oforiginal). The other 30% of all respondents answered that work load for whole SaaS organizationwill increase to 111% to 130%. Consensus opinion is not reached regarding this estimation.

5.3.7 Expectation of Support User created Ticket

Respondents are asked how many tickets should be created by support user after using chat.The answers are shown in figure 5.8. Only 12% of respondents answered that they want lessthan 10% of all tickets to be created by a support user. Half of all respondents said thispercentage should be 11% to 30%. A quarter of all respondents said this should be over 50%.In general, respondents expect that the support user inputs incorporated by the prototype canlead to better ticket quality.


Figure 5.8: Percentage of Tickets that Should Be Created by Support User After Chat

5.4 RESULTS FROM TESTS

This section introduces the results from evaluation. Original data collected in table form canbe found in appendix C. In each result subsection, brief analysis of the results will also be givenfor further illustration.

5.4.1 XMPP Screen-sharing Accuracy

Figure 5.9: Comparison of HTML tags and their appearances

To evaluate the accuracy, five groups of data are collected regarding HTML tags at random UIin the tested product. Figure 5.9 answers the question what tags exist in the shared page andhow many times these tags appear and these of the displayed screen. From this figure, it isshown that numbers of "<script>" and "<link>" tags are different in the shared screen.

Since tags like "<meta>", "<title>" and "<script>" do not affect display, tags like "<link>" and"<style>" are merged during HTML stream collection, they are excluded from the comparison.Figure 5.10 shows the mismatches between the other tags in the first group (HTML page) ofcollected data.


Figure 5.10: Difference of HTML tags appearances (Group 1)

It is shown from this result in figure 5.10 that the screen-sharing is accurate regardingnumber of HTML elements. Tests from other four groups showed the same result of nodifference regarding number of rendered HTML tags, so the diagrams for them are omitted inthis report to be concise.

5.4.2 XMPP Screen-sharing Performance

Figure 5.11: Screen-sharing Performance measured by milliseconds

To evaluate the screen-sharing performance, this report chooses five random UI and startsscreen-sharing from each of these UIs. In order to exclude network congestion spikes, for eachUI the screen-sharing is repeated for five times. Therefore 25 groups of data are collected.

From the results, it is shown that in most of the cases (24 out of 25), context collection of theHTML page and HTML images takes less than 100 milliseconds. In figure 5.11, all of the 25groups of data are depicted. It shows that the transfer time on the network is the mosttime-consuming among the four measured activities. In the test environment HTML pagetransfer takes on average 1127.56 milliseconds.

5.4 Results from tests 75

Figure 5.12: Screen-sharing Performance relative to network transfer time

Figure 5.12 maps the consumed time of the other three activities to the consumed time ofpage transfer, there it is shown that HTML image collection and HTML page collection havecurve that match each other’s changing tendency. Display algorithm also takes much more timethan collection of the context information. In the test environment, display of the shared HTMLpage takes on average 358,16 milliseconds.

5.4.3 Screen-sharing Performance compared with Citrix and Adobe

products

Data collected for the evaluation can be found in appendix C. Figure 5.13 shows the resultsof screen-sharing latency of randomly selected screens. Twenty five random samples are takenfor each product. This histogram shows that Adobe Connect performs the best during the test,whose 7 out of 25 latencies takes 300-350 milliseconds.

The average latency of Adobe and Citrix solutions are 509.12ms and 793.84ms, the thesisprototype has an average latency of 1560.36ms, which are grossly three times of the Adobelatency and two times of the Adobe latency.

Given that the average payload of each of the thesis shared screen is 723.2KB, which can becompressed to "ZIP" format and reaching a size of around 70KB and the results from 5.4.2which shows that network transmission is the dominating time consuming part, it can bereasonably assumed that with proper data compression in the future, the thesis prototype hasthe potential to reach better than average performance competing against these tools regardingscreen-sharing speed.


Figure 5.13: Screen-sharing Performance compared with Citrix GoTo Assist and Adobe Connect

5.5 SUMMARY

This chapter gave an evaluation to the presented thesis software prototype. Section 5.1made a recap to the thesis goals and set the criteria of the evaluation. Section 5.2 described thereasons why and how the questionnaire interview and the tests are conducted in such a wayfrom practical point of view. Section 5.3 showed the results collected from questionnairerespondents and summarized these data. Section 5.4 delivered tests results of the prototyperegarding quality and performance, comparison results with existing tools were given.

The chapter showed the assessment from user point of view and revealed strengths andshort comings of the thesis implementation.

5.5 Summary 77

6 CONCLUSION AND FUTUREWORK

6.1 CONCLUSION

The presented work aimed at improving the software issue handling process in SaaSorganizations by providing additional embedded support services.

Findings from researches motivated a way to reach this goal by enforcing or improvingmissing and low quality context information in the tickets created in the traditional approach andby resolving software issues before they enter ticket systems. Results from the field studyshow that using Internet instant messaging to provide software issue context information is rarein practice but has a positive effect on customer satisfaction regarding software issues.However the studied SaaS product which uses this approach lacks the focus on collection andconsuming of the context information.

The thesis proposed an approach to leverage Internet instant messaging to bridge the gap. Onone hand, the proposed approach is a horizontal extension of current ticket system basedservices. On the other hand, the proposed approach helps to improve ticket quality in thepreliminary ticket creation phase of the traditional approach. Built in HTML client of SAP’s SaaSERP frontend, two major types of services of the intended work were accomplished: theservices that enable multi-user chat between support user and business user, and the servicesthat are context information centric which assist the software issue handling.

• Chapter 1 introduced the background information of the thesis targeted problems and gavethe motivation to address thesis objectives.

• Chapter 2 reviewed literature in researches that address the thesis targeted problems andinvestigated adopted industry solutions. From the research study a gap between the

79

existing software support offering and the necessary support service of goodquality wasfound. In the field study conducted in both general software markets and specifically SaaSERP markets showed that Internet instant messaging was used as a delivery channel ofsupport services, however with limited functionalities with a very low popularity.

The idea of providing embedded support services in form of Internet instant messaging tobridge the gap and improve the whole SaaS support process was derived. Concrete goalsof combining instant messaging and software issue context information were set.

• Chapter 3 revealed in detail the proposed software solution on conceptual level.Furthermore, software user roles in the proposed solution were created, softwarerequirements were established. Structures of the solution were described, keyinteractions between structural components were depicted, service access and userinterface were designed on the level of concepts.

• Chapter 4 showed the dependencies of thesis prototype and the developmentenvironment. The chapter then explained the implementation of the prototype separatedin subsections, each of which represents an implementation of a type of embeddedsupport service.

• Chapter 5 gave the design of evaluation for the thesis implementation. The solution wasmeasured to show the quality of the implementation and also contribution as a softwareprototype, namely how this prototype can express the potential of the concept ofdelivering embedded support service in the thesis proposed way.

6.2 ANSWERED QUESTIONS

• What problem exist in the support organizations of software providers, especially SaaSvendors?

This work investigated software issue handling process in SaaS organizations anddiscovered short comings of current embedded support services which are ticket centric.The current approach fails to deliver end users fast response upon software issues. Also,when tickets are handled in the SaaS vendor’s typical tiered support levels, it is often foundthat the poor quality of the tickets lead to much communication overhead and cost inresolving process.

• How do researches and industry tackle these issues?

Research work in the area indicated the important types of information that are relevant forsoftware issue resolving. Quality gaps are proven by researches. In the industry,telephone support is much adopted. In contrast, instant messaging is adopted to providefast first response, however without ability to deliver arbitrary context information, which isvital for issue resolving.

• How can these findings from researches and industry practice be combined and reachsynergy?

The thesis suggested a new model of embedded support services by combining Internetinstant messaging and context data collection. A software prototype was built to prove theconcept. The prototype shows that using Internet instant messaging can efficiently deliver

80 Chapter 6 Conclusion and Future Work

many types of context information. Evaluation based on interview questionnaire andperformance analysis shows that:

– The prototype provided the desired embedded support services that are needed byusers from support and development organizations from the studied SaaS provider.

– The quality of the implementation satisfies these users.

– Estimation given by the respondents predicts reduction in both ticket number andticket resolving time.

– The questionnaire evaluation also reveals positive influence of the delivered serviceson customer users.

Therefore, the general goal of cutting support cost in SaaS providers is achieved by thiswork. Additionally, by predicting a very positive influence on customer satisfaction byinterviewees, and since support services are important for SaaS products’ contractrenewal, additional economic benefits for SaaS provider are introduced.

6.3 FUTURE WORK

The prototype developed shows already promising use cases. However there are manyaspects of future work regarding more detailed evaluation and functional extensions.

• Automatic chat assistance for support user

By bundling UI elements from where chat is requested and the support user’s answers ina database. Some more services can be provided to support user that he/she gets thosesolutions which apply to the current screen to business user from other support users,once the chat is launched and the UI Ids are traced.

Such services can also be provided by the model established in the thesis prototype,through the chat bot. Artificial intelligence can be implemented for this purpose to furtherassist the support users.

• Evaluation on ticket quality improvement

Once the prototype is productized, it is meaningful to measure the tickets created withoutusing chat and ones with a chat session before. The tickets should be measured on theirtypes of addressed issue, quality (according to existing models), solution rate, and solutiontime.

• Performance Improvements for Screen-sharing

Performance improvements for screen sharing can be achieved by adopting morecomplicated algorithms like delta transmission for HTML pages or data compression.Once the performance allows, chat should provide page refresh service which allowsautomatic page updates in smaller time intervals.

6.3 Future Work 81

82 Chapter 6 Conclusion and Future Work

BIBLIOGRAPHY

[ADB+99] Gregory D Abowd, Anind K Dey, Peter J Brown, Nigel Davies, Mark Smith, and PeteSteggles. Towards a better understanding of context and context-awareness. InHandheld and ubiquitous computing, pages 304–307. Springer, 1999.

[AFG+10] Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz,Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, and MateiZaharia. A view of cloud computing. Commun. ACM, 53(4):50–58, April 2010.

[BFB+11] P. Banerjee, R. Friedrich, C. Bash, P. Goldsack, B.A. Huberman, J. Manley, C. Patel,P. Ranganathan, and A. Veitch. Everything as a service: Powering the newinformation economy. Computer, 44(3):36–43, 2011.

[BJS+08] Nicolas Bettenburg, Sascha Just, Adrian Schröter, Cathrin Weiss, Rahul Premraj, andThomas Zimmermann. What makes a good bug report? In Proceedings of the 16thACM SIGSOFT International Symposium on Foundations of software engineering,SIGSOFT ’08/FSE-16, pages 308–318, New York, NY, USA, 2008. ACM.

[Cus10] Michael Cusumano. Cloud computing and saas as new computing platforms.Commun. ACM, 53(4):27–29, April 2010.

[Gla01] R.L. Glass. Frequently forgotten fundamental facts about software engineering.Software, IEEE, 18(3):112–111, 2001.

[GXWW11] Steven Gianvecchio, Mengjun Xie, Zhenyu Wu, and Haining Wang. Humans andbots in internet chat: measurement, analysis, and automated classification.IEEE/ACM Trans. Netw., 19(5):1557–1571, October 2011.

[GZNM11] Philip J. Guo, Thomas Zimmermann, Nachiappan Nagappan, and Brendan Murphy."not my bug!" and other reasons for software bug report reassignments. InProceedings of the ACM 2011 conference on Computer supported cooperativework, CSCW ’11, pages 395–404, New York, NY, USA, 2011. ACM.

[HW07] Pieter Hooimeijer and Westley Weimer. Modeling bug report quality. In Proceedingsof the twenty-second IEEE/ACM international conference on Automated softwareengineering, ASE ’07, pages 34–43, New York, NY, USA, 2007. ACM.

Bibliography 83

[ISO06] ISO/IEC 14764:2006 software engineering – software life cycle processes –maintenance. Technical report, 2006.

[JNO+06] R.B. Jennings, E.M. Nahum, D.P. Olshefski, D. Saha, Zon-Yin Shae, and C. Waters. Astudy of internet instant messaging and chat protocols. Network, IEEE, 20(4):16–21,2006.

[MLM+06] Matthew MacKenzie, Ken Laskey, Francis McCabe, Peter Brown, and RebekahMetz. Reference model for service oriented architecture 1.0. Technical Reportwd-soa-rm-cd1, OASIS, February 2006.

[Mof10] Jack Moffitt. Professional XMPP programming with JavaScript and jQuery. Wiley.com, 2010.

[NVV00] Frank Niessink and Hans Van Vliet. Software maintenance from a serviceperspective. Journal of Software Maintenance, 12(2):103–120, 2000.

[OR] J Oikarinen and D Reed. Rfc 1459: Internet relay chat protocol, may 1993. Status:EXPERIMENTAL.

[Qua09] Qualipso consortium. qualipso - quality platform for open source software., 2009.

[SA] P Saint-Andre. Rfc 6120: Extensible messaging and presence protocol (xmpp): Core(2011). URL http://tools. ietf. org/html/rfc6120 [2011-08-28].

[SAST09] Peter Saint-Andre, Kevin Smith, and Remko Tronçon. XMPP: The Definitive Guide:Building Real-Time Applications with Jabber Technologies. O’Reilly Media, 2009.

[VM09] Jose Carlos Maldonado Viviane Malheiros, Erika Höhn. Qualipso project: Qualityrecommendations for floss development processes. 2009.

[Wik] Wikipedia. Enterprise resource planning.

[Wik13] Wikipedia. Bugzilla, 2013.

[xmp13] Xmpp, 2013.

84 Bibliography

A ACRONYMS

CRUD Create, Read, Update and Delete

CRM Customer Relationship Management

CSS Cascading Style Sheet

DOM Document Object Model

ERP Enterprise Resource Planning

FLOSS Free Licensed Open Source software

GUI Graphical User Interface

HCM Human Capital Management

HTML Hypertext Markup Language

IDE Integrated Development Environment

IIM Internet Instant Messaging

ITIL Information Technology Infrastructure Library

JSON JavaScript Object Notation

JSST JavaScript Screenshot Tool

KPI Key Performance Indicator

MVC Model View Controller

OS Operating System

SaaS Software as a Service

SOA Service Oriented Architecture

QoS Quality of Service

85

TCO Total Cost of Ownership

UCD User Centric Design

UI User Interface

XML Extensible Markup Language

XMPP Extensible Messaging and Presence Protocol

86 Appendix A Acronyms

B EVALUATION QUESTIONNAIRE

87

88 Appendix B Evaluation Questionnaire

C SCREEN-SHARING EVALUATIONRESULTS

Table C.1: Screen-sharing Performance Measurement

93

Table C.2: Screen-sharing Latency Comparison

94 Appendix C Screen-sharing Evaluation Results

Table C.3: HTML tags with counts (shared screen)

95

Table C.4: HTML tags with counts (displayed screen)

96 Appendix C Screen-sharing Evaluation Results

EMBEDDED SUPPORT SERVICES FOR WEB APPLICATIONS DELIVERED THROUGH

Documents

Transcript of EMBEDDED SUPPORT SERVICES FOR WEB APPLICATIONS DELIVERED THROUGH