International Conference on Automonic Computing
Automating ITSM Incident Management Process
Rajeev Gupta K Hima Prasad
IBM Research Lab, Delhi IBM Research Lab, Delhi
grajeev@in.ibm.com hkaranam@in.ibm.com
Abstract
Service desks are used by customers to report IT
issues in enterprise systems. Most of these service
requests are resolved by level-1 persons (service desk
attendants) by providing information/quick-fix
solutions to customers. For each service request, level-
1 personnel identify important keywords and see if the
incoming request is similar to any historic incident.
Otherwise, an incident ticket is created and, with other
related information, forwarded to incident's subject
matter expert (SME). Incident management process is
used for managing the life cycle of all incidents. An
organization spends lots of resources to keep its IT
resources incident free and, therefore, timely
resolution of incoming incident is required to attain
that objective. Currently, the incident management
process is largely manual, error prone and time
consuming. In this paper, we use information
integration techniques and machine learning to
automate various processes in the incident
management workflow. We give a method for
correlating the incoming incident with configuration
items (CIs) stored in Configuration management
database (CMDB). Such a correlation can be used for
correctly routing the incident to SMEs, incident
investigation and root cause analysis. In our
technique, we discover relevant CIs by exploiting the
structured and unstructured information available in
the incident ticket. We present efficient algorithm
which gives more than 70% improvement in accuracy
of identifying the failing component by efficiently
browsing relationships among CIs.
1. Introduction
Service Desk is a single point of contact (SPOC) for
the users who need help for running their IT systems.
Service desk is managed by a level-1(L1) person.
Customers contact the service desk for various
purposes such as information, configuration change,
problem being faced by the customer, etc. Customers
978-0-7695-3175-5/08 $25.00 © 2008 IEEE
DOI 10.1109/ICAC.2008.22
Mukesh Mohania
IBM Research Lab, Delhi
mkmukesh@in.ibm.com
can report problems using various methods such as
web based, e-mail or telephone. The L1 person tries to
satisfy the customer requests as much as possible to
facilitate the restoration of normal operational service
with minimal business impact on the customer. Usually
a database of historic incidents and their corresponding
resolutions are maintained at the service desk. The L1
person uses keyword search to see if the service
request can be resolved using any of the previously
reported incidents. If the incident can not be resolved,
an artifact of the incoming request is created in the
form of an incident ticket which initiates the chain of
various IT system management (ITSM) processes such
as incident management, problem management,
configuration management, change management and
release management. Directly or indirectly, all these
processes start with the incident management process.
The incident management process provides most
immediate and visible gains to service quality and cost
reduction. Then the problem management process is
used to find the root cause of incident(s) so that similar
incidents can be avoided in the future. To alleviate the
root cause one or more of change/ configuration/
release management processes are involved.
As part of the incident management process, an
incident ticket is created and the ticket along with the
relevant information is forwarded to a level-2 (L2)
person who is subject matter expert (SME) for the
incident. Then the SME tries to resolve the incident
through her expertise. This whole process of incident
resolution is largely manual; thus it is time consuming
and error prone. This paper is aimed at improving the
incident management process so that it can be more
automated thus reducing the incident processing time.
An incident ticket contains information about the
customer and problem reported by her. Problem related
information may include system which is facing the
problem, severity of it, natural language description of
the problem, etc. In this paper we use both structured
and unstructured information to help in identifying the
possible failing component. Next, we describe the
ITSM incident management process in detail.
141
 Incident Duplicate Incident
detection search classification
Figure 1: Incident Management Workflow
2. Incident management process
The aim of the incident management process is quickly
resolving incidents that affect the normal running of an
organization’s IT services. An incident is an intimation
of some error or failure of some component in IT
systems. Figure 1 shows the incident management
workflow which can be used for resolving an incident.
In a typical service desk, incident is either reported by
the customer or automatically generated by system
monitoring/event generation system. Customer report
incidents by describing the system condition using
natural language text whereas automatically generated
incidents only have structured data specifying system
and event-class [17]. In this paper we are considering
customer reported incidents only. For such incidents,
L1 person does a quick “keyword based search” from a
database of historic incidents. If any matching incident
is found, its solution may be used to resolve the
incoming incident. If the L1 person can not provide
any resolution, an incident record is created. This
incident record is classified for various purposes such
as assigning priority based on urgency and impact,
selecting the appropriate SME, etc. Then failing
component is identified by manually associating
hardware or software components (configuration
items) responsible for the incident. Information about
these configuration items (CIs) is maintained in a
Configuration management database (CMDB) which is
also used by other ITSM processes as an underlying
data storage framework. L1 person uses keyword
search along with human intelligence to guess the
possibly responsible CIs. Then the incident ticket is
forwarded to L2 support to diagnose the problem in the
selected CI. For diagnosis the CI is monitored and
various probes [14] may be used. If the identified CI is
wrong ticket is bounced back and forth between L1 and
L2 support. If any code change is required external
support (L3) is contacted. After resolving the problem
customer is informed and incident ticket is closed. In
this paper we propose techniques to automate and
improve various stages of the incident management
workflow. Next we describe our approach with the
help of an example and outline our contributions.
2.1 Contributions
Identifying failing Diagnosis Repair &
component recovery
We explain our contributions with the help of an
example. Let us assume that customer has called and
describes the problem as:
Example1: “I tried launching inventory application
on server avalanche.server.net from 10.10.10.70. I get
an error saying that database transaction failed."
First, we automatically identify relevant keywords
which can be used to search CMDB and identify
possible failing CI. Presently simple keyword search is
used to do this operation. Using actual service desk
data we prove that simple keyword search may not be
sufficient to search the actual failing component. When
customer describes the system problem, (s)he describes
only her or his perception of the problem. Thus,
problem description may partially or not at all mention
the possible failing component explicitly. We use the
incident description and CMDB data to get the context
of the search and identify the failing component. For
identifying the incident context, incident classification
plays a key role as we describe towards the end of the
paper. Using performance results over the actual
customer data we show that accuracy of search can be
improved by more than 70% using our approach. By
our proposed automations, we help the service desk by:
• By improving the “duplicate search” step we help
reduce the number of incident tickets. By
associating CI and intelligently selected keywords
with historic incidents we improve recall of the
“duplicate search” step.
• By automatically associating responsible CIs, we
help in reducing the number of incident tickets
being forwarded (rightly or wrongly) to SMEs. As
SMEs are costly to get and maintain, this will help
in reducing operational costs.
• We implemented a rule based request router which
uses various attributes of incident ticket, including
associated CI, to automatically route the ticket to
most appropriate SME.
• Using the importance (or role) of the selected CIs,
the service personnel can assign priority to the
incident. For example, if the selected CI is a
machine on which billing application is installed,
and then higher priority can be given compared to
the case where selected CI is the backup software.
142
 The rest of the paper is organized as follows. In relationships. To find the database on which billing
Section 3, we give details of data model of the application is running one needs to traverse depth=2.
configuration management database. We use object
data model and relationship between objects for CMDB have one other kind of relationships of
performing context oriented search. Steps to implicit types. These implicit relationships are part of
automatically identify keywords from incident the CMDB data model. Figure 3 shows an example of
description are presented in Section 4. Searching implicit relationship where a Unix Computer is sub-
CMDB for keywords along with desired relationships category of Computer and Operating System is a child
is presented in Section 5. Implementation details and of that. These explicit and implicit relationships can be
performance results showing effectiveness of our used to know the details of all the linux machines in the
technique are presented in Section 6. Related work is enterprise such as which machine they are installed-on,
presented in Section 7. The paper concludes in Section what software’s are running on them, etc. When an L1
8. person searches the CMDB, she mainly considers CIs
without bothering about relationships. Usually CMDB
is searched using keywords extracted from the incident
Billing
Application
description. All CIs having attributes values matching
deployed-on with those keywords are returned as keyword search
results. If L1 person is not satisfied by the results
Apache
Web Server WebSphere she/he searches again and/or explores CIs related to
depends-on
Application returned CIs in a very ad-hoc manner. This whole
Server 5.2
process is largely manual heavily dependent on skills
runs-on Oracle transactiona of L1 persons making it unreliable and costly. For a
Database runs-on l- given incident, we propose a method to search CMDB,
runs-on DB2 considering both CIs and relationships, so that failing
Aix Machine Database component can be identified with more accuracy and
hpux1
minimal human intervention. First step of our
runs-on
Aix Machine automated architecture is identifying important
hpux2
keywords from incident which is explained next.
Aix Machine
hpux3

Figure 2: Typical enterprise architecture

3. Configuration management database

Effectiveness of the incident management process
depends on the speed and the accuracy of the process
to identify the failing component. That in turn is
closely aligned to the accuracy and design of the
configuration management database (CMDB). CMDB
stores configuration items which represent systems,
software’s and people in enterprise infrastructure.
Figure 2 shows a typical enterprise infrastructure
represented using configuration items and relationships
between them. Nodes shown are CIs stored in CMDB
and edges between them are explicit relationships
between CIs. Relationships are also stored in CMDB
as objects. For example, Oracle database is stored as Figure 3: Example CMDB data model
an object with its attributes like schema, table space
etc. Similarly, an Aix machine hpux2 is also stored
with its attributes like CPU type, memory etc. Another
relationship object is created with type runs-on whose 4. Identifying keywords
source-attribute is the oracle database object and
target-attribute is hpux2. Each edge shows depth=1 A typical incident record contains three types of
information: 1) Customer details such as name, contact

143
information, e-mail address, etc. 2) Ticket information
including status of the ticket, severity, system/
component related to the ticket, etc. 3) Problem
description giving client’s perception of the problem.
For identifying relevant keywords mainly problem
description is used. Customer and other ticket related
information are mainly used for determining scope of
the search in CMDB. For example, customer related
information can be used to search only a particular part
of CMDB belonging to that customer. Simple rule
engines can be created to process the structured
customer and ticket information but processing natural
language description of the problem using simple rules
is not possible. L1 person needs to understand the
problem to decide on the keywords to be used to search
CMDB. L1 person expects that these keywords will
result in the possible failing component for the given
incident ticket. In this section we describe a method of
automatically extracting relevant keywords from
incident description.
Incident tickets are usually managed using with
web-based interface. Thus first step of the incident
processing is to extract the incident description using
HTTP parser. As information entered in the incident
description may be unclean, we need to clean that
unstructured data. We used edit distance between
keywords and dictionary words to clean the incident
description. As one needs to search for keywords in CI
types (e.g. oracle database) and attribute values (e.g.
hpux3.ibm.com) of CIs; in an incident description (in
English language) only nouns or noun phrases need to
be extracted. Next step in identifying keywords is to
normalize the extracted nouns. For example a
computer name may be mentioned in its short form
(hpux3 for hpux3.in.ibm.com) thus, if required, we
identify such machine names and normalize them by
appending their domain names. Similarly it is possible
that all the attributes use IP addresses whereas incident
description has URL. Thus, we need to replace them
with commonly agreed format. To further improve the
search performance we annotate noun-phrases using
named-entity (NE) annotators [12] which annotates
keywords based on their types. By associating CI-types
with these keyword annotations, we limit the search
scope further. For example, if a particular keyword is
identified as software-name it need not be searched in
CIs of type ComputerSystem. A dictionary matcher can
be used to categorize keywords to classes such as
hardware and software using a dictionary of names.
Similarly, it can be used to identify WebSphere
application server as a single keyword.
144
5. Searching CMDB
All the keywords extracted as explained in the previous
section can be used to search the CMDB. But this
‘vanilla’ search is not likely to be efficient due to
following considerations:
™ Typical CMDB implementations are not
done with keyword search in mind.
Instead, CMDB is mainly used for
browsing from one object to its parent/
child or other related objects.
™ CMDB is largely implemented as object
oriented database [5]. Concept of keyword
search over object oriented database is not
well defined. Various questions such as
which attribute(s) to search, how to search
child objects, is it possible to index
objects, etc. need to be answered for
efficiently searching an object oriented
database.
™ While doing keyword search, relationships
are not taken into account. Keyword
search and relationship browsing need to
be integrated.
™ When a customer describes a problem it is
his/her perception of the problem which
may not include much information about
the actual failing component. Instead, it is
likely to have some information about
neighboring/dependent objects.
For efficiently and automatically locating failing
components we use indexing and object navigation
which are explained in next two sub-sections.
5.1 Making search efficient
For making CMDB search efficient we index all the
CMDB objects. Indexing CMDB objects is non-trivial
as we should be able to search not only with keywords
but also with relationships. For example, we should be
able to efficiently search all the Computer-Systems
which have Linux Enterprise Edition v3.1 as operating
system. Further, it should be possible to search for
relationships which are arbitrarily deep. We solve all
these issues by creating two indices over CMDB.
Aim of the keyword index is to identify objects
having a given keyword in the values of its attributes.
This index maps each keyword with a set of objects.
The keyword index has four columns: keyword, object-
id, object-desc and object-class. The object-desc
(object description) column is used to display name of
objects so that service personnel can identify and get
details of any of the displayed object. The object-class
column is used to indicate type of the object e.g.
Computer System, Database, Security certificate, etc.
To synchronize the index with the modifications in the
underlying CMDB, we poll the CMDB logs
periodically to get updates since last poll. All the
newly added/ deleted/ updated objects are reflected in
the index. Frequency of the index synchronizing
process should be decided based on number and
frequency of changes occurring in CMDB. Usually
CMDB is modified using resource discovery
mechanism [] which is done once a day. Thus, we
perform the synchronization once a day which
synchronizes keyword index as well as relationship
index which is explained next.
Relationship index is created to efficiently browse
over related objects. We use these relationships to
extract context of the incident search automatically.
For example, if incident describes two machines which
are not able to communicate, then possible failing
component may be the CI corresponding to a network-
link between them. As in keyword index, for creating
the relationship index also all configuration items are
obtained one-by-one and all its depth 1 relationships
are stored in the relationship index. For getting objects
related with higher depths, multiple invocations on the
relationship index can be done. Each relationship can
be defined by its source object, target object and
relationship type between them. Table 1 shows
example entries for the relationship index. In the
relationship index, oid-1 is the object-id of the object
we are parsing, oid-2 is the object-id of the related
object, relationship-type gives name of the
implicit/explicit relationship and direction is forward
(backward) if parsed CI is the source (target) CI of the
relationship. Both explicit as well as implicit (parent-
child) relationships are covered using the relationship
index.
Table 1: Example relationship index
oid-1 oid-2 relationship- direction
type
ab4569000 ph9067230 installed On forward
ph9067230 ab4569000 installed On backward
ab4569000 dc4587689 parent-child forward
dc4587689 ab4569000 parent-child backward
Keyword index and relationship index are used to
efficiently search the CMDB. In the next section, we
describe how relationship browsing can be done to
automatically obtain search context.
145
5.2 Limiting search results
Keyword search may result in lots of objects. We do
not want to overburden the service desk personnel by
showing lots of results. Further, search context is
captured by the objects represented by keywords as
well as their neighborhood objects; and one naïve way
is to get all the neighborhood objects of vanilla
keyword search results. Such an approach is also likely
to return lots of unnecessary objects which the service
desk personnel will have to examine. In general all the
CMDB objects can be related to each other thus we
need some way of limiting number of search results. In
general, search results can be limited by two ways:
1. Keyword search results are returned with their
corresponding TF-IDF [10] scores. In this case objects
with top-k relevance scores are shown to the service
desk personnel. She can select the failing component
from the list shown.
2. In this case a list of objects is shown so that ratio of
scores between bottom ranking object and that of top
ranking object is above a certain threshold. This
approach is motivated by the fact that if bottom rank
object has very low relevance score then it is better not
to show that to service desk personnel.
We combine the above two criteria to output
minimum results to the service desk personnel.
Configurable parameter nmax is used to indicate the
maximum number of results to be returned (top-k).
Another parameter  is used to indicate the lower
bound on the ratio of score of bottom ranked object
and the top-ranked object. Let the results returned by
the CMDB search have relevancy scores {c1, c2,... cn}
in descending order. Thus,
cn
n < n max and >γ (1)
c1
Actual number of objects returned by the keyword
search will be given by the more restrictive of
conditions given by Equation (1).
5.3 Getting search context
As mentioned previously, search context is obtained by
using neighborhood objects of directly mentioned
objects in the incident description. If there is no other
information then we can simply consider getting
neighbors of all the object resulted from vanilla
keyword search. This forms our base-line scheme.
5.3.1 Omni-directional search. As one object may be
related, directly or indirectly, to a large number of
objects, we can not access all the related objects. We
limit the object navigation up to a certain relationship-
depth (rd). E.g., rd=1 signifies only directly related
objects will be used for getting incident context, by
keeping rd =2 we get objects which are directly related
to the related objects (database to billing application in
Figure 2), etc. For getting all the related objects,
irrespective of depth, rd can be set to 0. Relevancy
score of neighborhood objects depends on the score of
the keyword search results to which they are related,
type of relationship and depth. Equation (2) is used to
get relevancy score of a related CI (RCI) which is
related to one keyword search CI (KSCI).
wi ( rel _ type )
RR = r × ∏ (2)
0≤i ≤ rd α
RR is the relevancy score of the related CI (RCI), r
is the relevancy score of the KSCI to which it is
related, w(rel_type) is the weight assigned to the type
of relationship, and rd is the relationship-depth
between the KSCI and its related RCI. Value of
w(rel_type) lies between 0 and 1, depending on the
type of relationship. We give more weight to parent-
child implicit relationship compared to explicit
relationships. Further, among explicit relationships
larger weight is given to a relationship type if any
problem in their target may lead to problem in source.
Configuration parameter α (> 1) makes sure that the
RR value of the RCI is less than the relevancy (TF-
IDF) score of its related KSCI. If an RCI is related to
more than one KSCI then its relevancy score is sum of
all its individual RR values. It should be noted that we
are only interested in neighboring objects having score
more than cn (otherwise it will not be part of results
shown to the service personnel). As one object may be
related to more than one object, we calculate scores of
all related objects having RR values more than cn/;
where  (>1) is a configuration parameter. Thus, an
RCI can be part of result only if:
wi ( rel _ type) cn
RR = ci × ∏ > (3)
0≤ i ≤ d α β
This gives us the bounds on the relationship weight
and depth to which relationships are to be explored.
These bounds reduce the navigation scope drastically,
thus improving search performance. As w(rel_type) [1
and ci [c1, from Equation (3):
c1 / α d > cn / β (4)
Thus, from Equations (1) and (4) we get,
log(β / γ )
d<
log(α )
Similarly, we can obtain the minimum weight of
the relationship to be explored using,
w( rel _ type) > α × γ / β (6)
Equations (5) and (6) can be used reduce the search
scope without any adverse impact on quality of results
presented to the service personnel. Typical values of
various parameters discussed in this section are given
in Table 2.
Table 2: Typical parameter values
Parameter-name Value
nmax 20
α 3
 3
 0.05
5.3.2 Super object search: This case is useful when
service desk personnel can guess the type of object
which may be responsible for the incoming incident. In
this case all child objects are considered as part of its
parent object. For example, if we want to find the
machine (Computer System) responsible for the
incident then we search for keyword is super object
consisting of Computer System object along with all its
children like Operating System, File System, etc. This
ensures that whole physical object is considered a
single logical object leading to better results. There are
two problems with this approach. First, how can we
automate the selection of object type – we answer this
question in Section 5.3.4. Second, we are only
considering relationships which are implicit in the data
model. Thus, results for this depend a lot on the data
model. We correct that in our next approach.
5.3.3 Directed search. In this case we want to include
both implicit as well as explicit relationship in a
manner which is more intelligent than the one
presented in Section 5.3.1. We do directed search by
using what we call search templates. This scheme is
useful when service desk personnel can identify the
type of object responsible for the incident along with
relationships which can be useful in getting the search
context. In general, a search template can be
represented as tree of CIs and relationships as shown in
Figure 4. Search templates are a subset of data model
including CMDB object types with implicit and
explicit relationships between them. Directed search
has following distinctive features:
o Keyword search using this template will
involve CMDB objects of types database
server, application server, Java server and
application.
(5) o All resultant objects of child type are
traversed using relationship specified on
edges to get their corresponding parent
objects. Thus, all the resultant objects of type
“Application” are traversed using “Deployed
on” relationship to get their corresponding
146
 “Application Server” objects. These objects
are further traversed using “Dependency”
relationship to get the corresponding
“Database Server” objects.
o Service desk person is presented with objects
of the root type, that is, “Database Server”.
o Relevancy score of each object is calculated
in the manner similar to the one described in
Section 5.3.1. Thus, a “Database Server”
object which is parent of lots of resultant child
objects (result of keyword search) will have
higher score.
Database Server
Dependency Dependency
Application Server Java Server
Deployed On
Application
Figure 4: Sample search template
For both super-object search and directed search
we are selectively using relationships to get the search
context. For super-object search only implicit
relationships are considered whereas for directed
search both implicit as well as explicit relationships
can be used. In both these cases it is important to
choose the correct search template/ super object.
Search template can be created with various object
types as root. Service desk personnel can select the
appropriate template by guessing the object type which
is most likely to be responsible for the incident. We
semi-automate this step through incident classification
as explained in the next section.
5.3.4 Incident classification. Incidents are normally
classified among pre-specified hierarchical classes.
The classification is used to assign priority to the
incident and to route the incident to the appropriate
service team. We automate the incident classification
which helps in selecting the appropriate search context
also. As different words are used to describe different
kinds of problems we used keywords and their
annotations as classification features. These features
are used for learning the class to which the failing
object is likely to belong. Support vector machine [16]
method was used to get the class for a given incident
description. Figure 5 gives significant keywords for
example root/super objects. A number of hierarchical
classes were created to classify the incidents and a rule
147
based mapping was used to select template(s) to be
used for a particular class. For example, for incidents
of class connectivity problems we can have template
for Computer Systems as root with its network
interfaces as non-root objects.
Computer hardware: wireless, key-board, mouse
Desktop problems: windows, software, word, hang
AppServer: websphere, servlet, jsp, page, application
Database: database, db, sql, db2, table, oracle
Networking: connection, ping, access, connectivity
Figure 5: Example features for various
classes of incidents
6. Implementation details and performance
evaluation
Our system was implemented as per the architecture
shown in Figure 6. Implementation details are
explained in [18]. Keyword extractor component is
implemented for identifying keywords and annotating
them. We use part-of-speech (POS) tagger to identify
noun-phrases from the given incident description.
Then, we use regular expression matcher to identify
certain kinds of attributes such as IP addresses and
URLs whereas synonym matcher is used to add
domain names with ambiguously specified machine
names. IBM's unstructured information management
framework (UIMA) [12] is used for annotating
keywords based on their object types such as
<hardware>, <software> etc. To implement keyword
and relationship indices we extended the openly
available Lucene [1] framework of document indexing.
An object has attributes of various types such as
integer, float, char, string etc.; besides other objects.
From keyword search point of view, only Strings (or
character arrays) are important as all the keywords are
usually stored as strings. Further, we assume that all
the object attributes can be accessed using public
methods (e.g. get*() methods in Java). Results of all
such methods are combined, using space separated
concatenation, to create a text document corresponding
to an object. These documents are fed to Lucene to
create the keyword index. Relationship index was
created by browsing all relationships of depth 1. The
keyword index and the relationship index were placed
on the server machine itself which makes index
synchronization task easier. Object navigation
templates were represented in XML format [18] for
super-object search as well as directed browsing.
 the help of subject matter experts (SMEs). For each
incident for a particular class a set of one or more
templates were obtained. Directed search was
performed with corresponding to each such
template and a union of results was presented to
service desk personnel.

Table 3: Problem ticket queues

Queue Id Problem type # tickets
LNWAT LAN Services 240
Figure 6: System architecture DSA LAN admin operations 495
AIXBK AIX backup and restore 26
CMDB server was running on 2GHz, 2GB dual UNIX Unix support for CA4B 59
processing machine with Red Hat Enterprise Linux as WMAIL Email support 27
operating system. Other components of the architecture NOTES Notes and other applications 7487
including the CMDB client were running on 2GHz RESWTG Web conferencing 12
1GB IBM T43P laptop with MS Windows as OS. All
the components were implemented in Java 1.4.2. For 6.1 Data Collection
performance comparison we use following schemes:
CMDB data consisted of 192,000 objects and more
• All: This is the naive keyword search where whole than 150,000 relationships among them in an IBM
of CMDB is searched for the given incident network. Various tickets are categorized (by the L1
without considering relationships between objects. person) using the location and type of problem.
Different queues are formed for different categories.
• CI type specific: In this case keyword search is For example, there are 16 queues for Watson location
performed only on CIs of given types. Specifically, for problem categories such as notes, network related,
we use two classes of CIs called hardware and etc. Location information can be used to decide the
software. The hardware class has Computer System CMDB server to be used whereas problem-type is used
(with its sub-objects) whereas software class has to select the template. Table 3 shows ticket queues
Database, Web Server, Application Server, and along with the number of tickets used in our
J2EE Application objects. These sets are experiments.
configurable.
6.2 Performance results
• Omni directional search: This scheme is explained
in Section 5.3.1. Maximum depth of navigation was We now present the accuracy and response time
configured to be 2. results for context oriented search enabled by object
navigation and CI type specific search. For each ticket,
• Super object search: This scheme is explained in responsible CI(s) were identified by subject matter
Section 5.3.2. In this case we considered super experts as ground truth. With each incident we show a
objects of types Computer System (including its configurable number of results (nmax=20) to the
child objects Operating System and File System), service desk personnel but to measure accuracy we
Business process (including applications), servers consider only top-k results among them. If actual CI
etc. (ground truth) is part of that top-k set, we assume the
results to be accurate. Service desk personnel select the
• Directed search: In this case directed navigation is resultant CI (or CIs) which can be used to show details
done as per Section 5.3.3 with different templates of those CIs and their related CIs (all software’s
specified. We created 54 templates corresponding installed on the machine, network interfaces, etc.) for
to 120 classes of incidents. One to many mapping helping in the incident resolution.
between incident-class to template was created with

148

Figure 7: Accuracy of results for various
schemes
Figure 7 shows percentage accuracy for various
templates while varying the number of results
presented for k=1, 2, 3. Directed search with
appropriate template gives the best accuracy values
whereas naive keyword search performs worst. The
accuracy improves by limiting the search scope by
either limiting it to certain CI types or templates. We
get slight improvement by including child objects with
their parent objects but it is better if we consider
explicit relationships as well. Omni directional scheme
performs better than the super object scheme since it
explores all the related objects. Super object scheme
fails to return correct CI if it is not explicitly
mentioned in the incident description. Accuracy results
for bounds are not presented in Figure 7 as they are
same as the omni directional scheme.
For k=1, we get 84% accuracy for directional
scheme compared to 50% for a naive keyword search.
Thus our template based technique can be used for
automatically associating CIs without any filtering by
service desk personnel; but, in general, CI association
should be verified by the service desk personnel before
being used for any of the purpose mentioned in Section
2.1.
Figure 8 shows average number of server accesses
required for various schemes. As search response time
is dominated by the network and processing delays at
the server, average number of server access is
proportional to response time and CPU cycles required
for a ticket. These accesses are required for searching
over indexes and getting individual CIs to display. For
naive keyword search (scheme all) we need to access
maximum 20 (=nmax) objects whereas for other cases
we need to access other neighborhood objects as well.
We show number of accesses for omni-directional
search with and without bounds specified in Section
149
5.3.1 as given by legends OmniDir and Bounds
respectively. Number of accesses for the super-object
case is slightly higher than the directional-scheme as
former explores all the implicit relationships
irrespective of their importance. As can be seen from
Figure 8, we get better results, compared to the omni-
directional search, if we can correctly identify the
template to use. Omni-directional scheme not only
gives lesser accuracy but also has more response time
Figure 8: Number of CMDB accesses
(more accesses) compared to the directed search.
7. Related works
Importance of the incident management is underlined
by work in [8] where IT management of business
objectives (MBO) is done by mapping effect of various
system management processes on key performance
indicators (KPIs). A way of assessing impact of
incident management on business objectives is given in
[7]. By automating a big part of incident management
process, incident resolution can be done faster leading
to reduced impact on business objectives. There has
been lot of work in literature using database and data
mining technologies for helping service desk
personnel. Idea of using case-based reasoning by
matching incoming problem symptoms against a
historical database of symptoms (and their
corresponding solutions) is proposed in [6]. In [9]
authors use call stack matching to find the likely cause
of the crash and hang related problems. These
approaches try to find similarities in the problem report
information supplied by users without considering their
semantic meaning. In contrast, our approach finds the
possible failing components even if problem
description does not explicitly mention them. Our
technique uses integration of unstructured information
in the form of incident description with the structured
information in CMDB to generate context of the
incident and identify relevant CIs. In [11] authors have
proposed an algorithm for linking text document with
the relevant data stored in a relational repository. Their
algorithm is primarily based on identifying the
keywords from the text and searching the RDBMS
based on these keywords and predefined templates.
However, for incident management we need to
associate an incident with configuration items which
are stored as (Java) objects in CMDB. In this paper, we
extend the technology for the CIs stored in CMDB and
use it for service desk management.
8. Conclusions and future works
In this paper we presented a technique to identify
failing component by integrating text specified in the
problem ticket with structured data stored in CMDB
database along with incident classification. In our
system, improvement in incident management process
occurs due to three main reasons: automated
identification of keywords, search over CMDB using
search context, and limiting search scope using
directed navigation. We plan to extend the work for
autonomic computing and problem management. Our
work is also continuing towards identifying CIs
corresponding to system events. That work will be
useful in correlating system events with client reported
incidents.
9. References
[1] Apache Lucene: Full featured text search engine.
http://lucene.apache.org/java/docs/index.html.
[2] Java Beans.
http://java.sun.com/products/javabeans/docs/index.html.
[3] Reducing IT support costs through automated electronic
end-user support. http://www-935.ibm.com/services/us
/its/pdf/g510-3499-00.pdf.
[4] Using Java Reflection. http://java.sun.com/developer
/technicalArticles/ALT/Reflection.
[5] What do you need from a configuration management
database (CMDB)? www.bmc.com/USA/Corporate/
BSM/attachments/BMC CMDB wp en.pdf.
150
[6] T. Acorn and S. Walden. SMART: Support management
reasoning technology for Compaq customer service. In
Innovative Applications of Artificial Intelligence, Volume 4,
1992.
[7]
C. Bartolini and M. Salle. Business driven prioritization
of service incidents. DSOM, 2004.
[8] C. Bartolini, M. Salle, and D. Trastour. It service
management driven by business objectives: an application to
incident management. NOMS, 2006.
[9] M. Brodie, S. Ma, G. Lohman, T. Syeda-Mahmood,
L. Mignet, N. Modani, M. Wilding, J. Champlin, and P.
Sohn. Quickly Finding known software problems via
automated symptom matching. In Workshop on Integrating
Data Mining and Knowledge Management, 2005.
[10] S. Chakrabarti. Mining the Web. Discovering
Knowledge from Hypertext Data. Morgan Kaufmann
Publishers, 2002.
[11] V. Chakravarty, H. Gupta, P. Roy, and M. Mohania.
Efficiently linking text documents with relevant structured
information. In International conference on Very Large
Databases (VLDB), 2006.
[12] D. Ferrucci and A. Lally. Building an example
application with the unstructured information management
architecture. IBM Systems Journal, 43(3):433-455, 2004.
[13] T. Li, S. Zhu, and M. Ogihara. Mining patterns from
case base analysis. In Workshop on Integrating Data Mining
and Knowledge Management, 2001.
[14] I. Rish, M. Brodie, N. Odintsova, S. Ma, and G.
Grabarnik. Real-time problem determination in distributed
systems using active probing. In Proceedings of Network
Operations and Management Symposium, Seoul, Korea,
April 2004.
[15] S. Sarawagi. Automation in information extraction and
integration (tutorial). In VLDB, 2002.
[16] S.R. Gunn. Support vector machines for classification
and regression. Technical Report ISIS-1-98, Department of
Electronics and Computer Science, University of
Southampton, 1998
[17] IBM Tivoli Enterprise Console.
www.ibm.com/software/tivoli
[18] R. Gupta, K. H. Prasad and M. Mohania. Information
integration techniques to automate incident management.
(Short paper) NOMS 2008.