An Optumis White Paper

www.optumis.com

A Paradigm for Integrated IT Systems Management

Sanjay Raina

December, 2010
 Contents Introduction
IT Systems Management tools and technologies
Introduction 2 continue to be crucial to efficient delivery of IT
Problem Statement 2 services. The IT landscape is evolving all the time
Current Practice 3 and there are increasing demands placed on the
Optumis Concerto 4
management of IT. Systems Management tools
have failed to keep pace with these
Implementation 8
developments and often fail to deliver the
Business Benefits 13 potential value as promised by the vendors. The
Summary 13 main reason behind this is that IT Systems
References 13 Management tends to be disjointed and silo
based. This white paper presents a holistic
approach to IT Systems and Service
Management. The approach advocates a
declarative, data-driven framework for specifying
management structures and policy. This
combined with the notion of abstraction of
management data results in a integrated
paradigm that allows stakeholders to make
effective decisions about the complex IT
infrastructure and applications in a coherent and
consistent way.

Problem Statement
Today businesses rely heavily on IT to keep the
revenue streams flowing and to run the day to
day back office functions. It is therefore more
critical than ever that the tools and technologies
that manage the IT infrastructure are effective in
delivering high levels of availability and
productivity whilst keeping the costs down.

The Systems Management tools in use today

have their origins in the days of distributed, client
server technology. Since then the IT landscape
has undergone considerable evolution to N-tier,
Service Oriented Application architectures and
more recently towards Cloud based utility
computing delivery models. However, IT Systems
Management tools and practices have not kept
pace and there have not been corresponding
improvements in Systems Management
Copyright ©Optumis Ltd. www.optumis.com
technologies. While the management tools
were adequate in the distributed computing
era of twenty years ago, today's
infrastructure is considerably more complex
and more dynamic.
The Systems Management tools marketplace
is dominated by the Big Four vendors, each
with an arsenal of products [1][2][3][4] aimed
to cover the entire Enterprise Management
space and purported to solve the challenging
problems of end to end Systems
Management. In practice, however, these
tools fail to deliver the promised value and
have proved to be difficult and costly to
implement and integrate. Often, tools from
the same vendor have poor integration
capabilities and the only thing they share with
each other is the brand name!
When it comes to deploying Enterprise
Management tools, typically organizations
implement these as silo functions [7]
managed by several specialized teams. There
may be separate monitoring teams for
servers, applications and databases. Other
teams might be responsible for managing
desktops, network and security. Yet more
teams may be responsible for service desk
and operations functions. That there are so
many different teams performing IT
management functions is not a problem in
itself, but the fact that there is no coherent
framework or mechanism to orchestrate and
coordinate the activities of these disjointed
functions creates a number of problems.
Firstly, there is the problem of different
teams and tools using different proprietary
databases and data formats to store
management data, with the result that
integration although not impossible is
extremely laborious. Often, organizations
have to embark upon costly integration
projects to solve particular problems that span
multiple functional areas. Secondly, each team or
management function is driven by a narrow goal
of delivering their specific piece without any
investment of thought on how their piece
impacts other functions. Thirdly, the disjointed
approach prevents the fostering of higher level
abstractions that can create value simply by
cross-pollination of management information
from different sources. IT organizations spend a
disproportionate amount of time just to keep
things ticking over and fire fighting, leaving very
little resource to spend on adding value to their
service offering.
Current Practice
In the past, vendors have responded with more
tightly integrated Framework based products,
such as the older generation of IBM Tivoli [5]
and HP OpenView [3]. These products use an
underlying layer built out of technologies such as
CORBA to improve the integration capabilities.
The problem with such an approach is the lack of
flexibility and vendor lock-in that prevents the
use of best of breed tools. Consequently, the
Framework tools have nowadays lost favor and
most vendors now espouse a best of breed
approach.
More recently, organizations have sought to
make use of process frameworks such as ITIL [9]
to improve efficiencies. Such frameworks provide
the ability to organize people, processes and
technology so that IT management is optimized.
However, while some organizations have
benefited from the adoption of such practices,
the benefits have been limited because, in most
cases it is seen as an overlay of a governance
framework and doesn't fundamentally alter the
way various technical components of IT Systems
Management interact with each other. What is
required is a fundamental rethink of the
structure and organization of Enterprise
Management tools and techniques.
Optumis Concerto
The problems and challenges faced by IT
Systems Management are no different from
those faced in the past by other domains in
IT. The complexity of the resources to be
managed and the tools that manage them is
no different from the complexity of the
hardware and devices used in the platforms
for developing and running applications.
Likewise, the problem of interoperability
between Systems Management tools and
functions is no more severe than the problem
of communication in a distributed computing
environment.
We have taken some of the most common
techniques in computing that are in
widespread use and applied them to
Enterprise Management. The intent is to
develop holistic solutions by taking a broader
view of the Enterprise Management problem
rather than point solutions for specific
problems.
Enterprise Management as an
abstract machine
The principle of abstraction has long been
used in computing as well as other fields to
solve the problem of complexity. Operating
systems use abstraction to hide details of the
underlying hardware and provide a collection
of common interfaces and services that work
on a variety of hardware through the use of
device drivers. Compilers take abstraction
further by using an intermediate target
abstract machine (e.g. Java Virtual Machine).
An interpreter or assembler then converts the
intermediate code to machine language. As a
result, an application developer can build
increasingly rich applications without worrying
about the specifics and compatibility of
underlying hardware or software. Before the
advent of operating systems and compilers, life
was tough for the application developer, as
programming involved getting to grips with the
complexities and workings of the underlying
hardware and devices. Abstraction is also used in
network communication, where successive layers
of network protocols provide a more application
centric view of communicating endpoints than
offered by the underlying network components.
Without networking protocols, developing
internetworked applications would mean having
to know the details of all components of the
underlying network between two communication
endpoints - an impossible task.
Enterprise Management can benefit from
abstraction in the same way that application
development and network programming has. An
Enterprise Management Abstract Machine
(EMAM) allows higher level management
applications and tools to be built quickly, without
the intimate knowledge of the underlying
domain specific tools. Fig. 1 below shows layered
application and network stacks along with a
comparable Enterprise Management stack.
FIGURE 1. ENTERPRISE MANAGEMENT STACK COMPARED
WITH APPLICATION DEVELOPMENT AND NETWORK
PROTOCOL STACKS
Like the counterpart layers in the application and
network stacks, each layer in the Enterprise
Management stack supports the use of
constructs that use appropriate abstraction
mechanisms to ensure they are independent
of the specific characteristics of the layers
below.
The lowest layer consists of element
managers and can be compared to the device
driver layer in application and network stacks.
It constitutes agents that produce raw event
data from instrumented applications and
infrastructure components, as well as agents
that perform command and control of
managed resources. This layer abstracts the
specifics of element managers into common
constructs that offer a tool-agnostic view of
management data. For instance, one could
specify that a disk be monitored in abstract
terms as:
monitor(DISK, PctSpaceUsed, 95, Critical, 90,
Warning)
This construct is then translated by an
interpreter to tool specific instruction using
the API of the specific tool. Management
operations can now be specified in common
terms without worrying about the
representation in underlying tools. The tools
can now be replaced or augmented without
affecting the higher level applications – all
that is required is a change to the interpreter.
The same principle is applied to the
subsequent layers shown above. The next
layer provides an aggregated view of the
management data to applications. At this
layer, management data from multiple
element managers can be combined to
provide a more analytical interpretation of
the data. Note that the context is still
technology related. The next layer titled
Business Service Management consists of
abstraction that provides a business and
service centric view of management data. The
top most layer provides high level reports and
dashboard views as well as interfaces to data
marts, primarily for the consumption of business
analysts and senior management.
Cooperating state machines
Contemporary Systems Management tools are
programmed using policies and rules to model
the various activities within a management
function. Unlike data processing or determinate
programming, Enterprise Management is
essentially reactive in nature and is best
represented as an event-driven system. State
machines are an ideal way to implement complex
event driven functions and are characterized by a
collection of states and state transitions that
occur in response to events. State machines are
typically represented by a state transition
diagram as shown in Fig. 2 below.
FIGURE 2. A STATE TRANSITION DIAGRAM
Due to the large number of states and state
transitions, representing a complex end to end
Enterprise Management system as a single state
machine is an impossible task. In the past,
techniques such as State Charts [6] have been
developed to overcome the state explosion
problem. We have used the concept of
cooperating state machines. Each state machine
represents one Enterprise Management function
or process and they link together to form an end
to end model. Fig. 3 below shows a chain of state
machines representing the detection,
reporting and resolution of a fault.
FIGURE 3. COOPERATING STATE MACHINES
Data manipulation
Efficient manipulation of data is an important
aspect of any abstract or physical machine.
Operands are commonly used in an
instruction set (of abstract or real machine)
and allows instructions to perform operations
efficiently. Management data tends to be
passed around quite frequently amongst
various components in a Systems
Management solution and it is essential that
the data is optimally formatted and
structured. This is addressed by employing
two other concepts widely used in general
computing: normalization and encapsulation.
Normalization refers to the transformation of
the structure of the management data into a
canonical form. Without normalization,
considerable effort has to be expended in
interpreting the data emanating from various
management tools.
Encapsulation is most prominently used by
the TCP/IP protocol suite to provide
abstraction of network protocols and
services. As shown in Fig. 4 below, data
packets are encapsulated with headers at
each layer. The TCP layer adds a TCP/UDP
header to identify the source and destination
access point. The IP header adds routing
information and data link layer adds information
about the physical media. Each layer acts as a
provider of service that is consumed by the layer
above.
Data
Application
TCP
Data
Header Transport
IP
TCP Data
Header Internet
Frame
Header
Frame data Link
FIGURE 4. THE WELL KNOW NETWORK PROTOCOL STACK
A similar approach can be applied to Enterprise
Management data that is successively enriched
by layers in the stack. Each consuming layer
enriches the data further before providing it to
the next layer.
FIGURE 5. EVENT MANAGEMENT DATA BEING
SUCCESSIVELY ENRICHED
Enrichment involves filling in the missing
information into the normalized event format as
described above. The information can be
supplied by external information sources such as
the CMDB, an operational data store or the
Incident Management database.
The standardization and enrichment of
management data provides a number of benefits:
• Management Systems tend to generate
large volumes of data, much of which is
noise. This data needs to be aggregated
and correlated to pin-point the root
cause. Standardization of management
 data formats plays a crucial role in this
regard. The standardized format
makes matching of events efficient.
The rules for duplicate detection and
suppression become simplified.
Detection and prevention of event
storms is also simplified. It is also
possible to apply more granular rules,
e.g. one can put very specific alerts
from a particular resource or from a
whole datacenter into maintenance.
• Due to the added context information
available, it is easier to perform
business impact management.
Enrichment of management data
enables more accurate and automated
processing of events within a
management system. New, service
impacting events can be generated
based on location or service
information from the CMDB or
Incident information from the Incident
database.
• Management data often traverses a
number of boundaries when various
functions are performed. The
information conveyed by the data is
often interpreted by a multitude of
systems and personnel. It helps a
great deal if the information being
passed around is consistently
structured.
Declarative, data-driven
programming
Most programs are written in an imperative
paradigm where the developer instructs the
computer how to get a certain task done. In
declarative programming, on the other hand,
the developer simply states what is to be
achieved, and leaves it up to the system to
get the job done. XML and related markup
languages are examples of the declarative
paradigm. Specialized configuration files can also
be considered declarative, and even though they
are not programming languages, they do enable
computation based on what rather than how.
Another example of a declarative language is
Prolog where programs are specified as facts and
rules in a knowledge base. An inference engine
then attempts to find solutions based on the
rules and facts.
Enterprise Management tools are generally
programmed in an imperative manner using
proprietary rule bases and databases. When
implementing Enterprise Management solutions,
a significant amount of effort is spent on
encoding the control flow, i.e. specifying how
particular tasks are to be accomplished. We
advocate a declarative approach where the
emphasis is on what rather than the how. So,
rather than specifying how to monitor a disk in a
particular tool, using tool specific data structures,
we can specify the monitoring parameters in an
abstract form, as shown below.
<DiskThresh>
<Hostname>Ferrari</Hostname>
<Diskname>C:</Diskname>
<PctUsedWarn>90</PctUsedWarn>
<PctUsedCrit>95</PctUsedCrit>
</DiskThresh>
A driver component then takes this abstract
notation and converts it into tool specific
instructions. The declarative approach can be
applied right across the board. The fragment
below shows how an alert matching a certain
criteria can be specified to be routed to a
resolver group.
<IncidentProfile>
<hostname> Ferrari </hostname>
<resource> DISK </resource>
 <threshname> PctUsed
</threshname>
<threshop> LessThan </threshop>
<threshval> 95 </threshval>
<resolver_group>GTI_GB_WENG</tick
etqueue>
<priority>P2</priority>
<scim>Server OS, EMEA Intel</scim>
</IncidentProfile>
Similarly, the fragment below shows how an
alert matching a certain criteria can be
specified to be suppressed during a
maintenance window.
<MaintenanceMode>
<hostname> Ferrari </hostname>
<resource> DISK </resource>
<threshname> PctUsed
</threshname>
<thre shop> LessThan </threshop>
<threshval> 95 </threshval>
<suppressstart>
3-Aug-2010 11:00:00
</suppressstart>
<suppressend>
27-Dec-2010 12:00:00
</suppressend>
<suppressday>Sunday</suppressday>
<suppresshour>05:00--
11:00</suppresshour>
</MaintenanceMode>
This has a major advantage in that the policies
and rules for management have to be
specified just once. The underlying tools can
be replaced at any time without having to
rewrite the policies and rules for the new
tool. Integration to various tools is done via
SOAP/WSDL or tool specific APIs.
Another advantage is that the management
data in declarative form is easier to
understand and you don’t need specialists in the
different tools to manage and maintain the
management data. The data can be managed by
a wider section of the IT service delivery
organization rather than just the specialists.
Finally, there is the advantage that all data can
now be made available to personnel, based on
their role, for configuration and reporting
purpose. A user can update monitoring,
maintenance windows, enrichment data, Incident
resolver group information, notifications
calendar and calling tree, all in one place.
Implementation
Although the Enterprise Management Abstract
Machine covers a wide range of functions, its
implementation is expected to be a veneer of
software that runs on top of existing tools and
systems. We do not intend to reinvent well
established functions of Systems Management
and most of the heavy lifting is expected to be
done by existing tools and systems. This section
describes how the key aspects described in the
previous section can be realized. Two scenarios
are outlined to demonstrate the use of the
concepts discussed.
In common with other abstract (and indeed
physical) machines, the operation of EMAM is
characterized by:
• A workflow component that executes the
logic of the computation being
performed. This may take the form of a
program of instructions compiled and
then processed by a CPU or, in the case of
an operating system a sequence of
processes being scheduled from a work
queue. In the case of EMAM, program
execution takes the form of a sequence of
state machines.
 • Operands used by the instructions in a product [9]. The fragment below shows a XAML
program. These take the form of local representation of a state machine.
storage (registers or stack) in
conventional machines. In the EMAM <StateMachineWorkflowActivity
these operands are typically alert x:Class="EMAMWorkflow.Monitor"
data, incident records, change records Name="Monitor"
etc. InitialStateName="Idle"
• Reference data is used by the xmlns="http://schemas.microsoft.com/winfx/200
workflow component. This is usually 6/xaml/workflow"
general purpose storage in a xmlns:x="http://schemas.microsoft.com/winfx/2
conventional machine where the 006/xaml">
results of computation are stored. In <StateActivity x:Name="Idle">
the EMAM, the reference data is <EventDrivenActivity
typically operational configuration x:Name="CheckThreshold">
data stored in a <HandleExternalEventActivity
configuration/operational data store. x:Name="HandleCheckThreshold"
EventName="Check">
</HandleExternalEventActivity>
State-machine Workflows <CodeActivity
A program in the EMAM is expressed in the x:Name="DoCheckCode"
form of a workflow of state machines. The
control of the program propagates through ExecuteCode="DoCheckCode_ExecuteCode">
state machines, with one state machine </CodeActivity>
triggering another. The programming of the <SetStateActivity
EMAM takes place by specifying the sequence x:Name="SetChecking"
in which these state machines are triggered. TargetStateName="Checking">
The program is specified declaratively, in the </SetStateActivity>
form of a database table or an XML based </EventDrivenActivity>
markup. Table 1 below shows a sample </StateActivity>
workflow specification. …………
</StateMachineWorkflowActivity>
TABLE 1. STATE TRANSITION TABLE
State Current Event Next Next State
Machine State Condition State Machine The above XAML code can be loaded directly into
Monitor Idle Check Checking Monitor
Monitor Checking Breach Alerted Monitor
Microsoft Workflow Foundation to appear as in
Monitor Checking NotBreached Idle Monitor Fig. 6 below.
Monitor Alerted DupDetected Duplicate Monitor
Monitor Alerted Not Dup Unique Normalized
Monitor Duplicate Drop Idle Monitor
Normalize " " " "
" " " " "

The above specification can be represented in

an XML markup such as XAML. XAML is used
by the Microsoft Workflow foundation
 FIGURE 7. OPERATIONS MANAGEMENT DATA BEING
TRANSLATED TO TOOL SPECIFIC DATA

Scenario 1: Fault detection and

resolution
FIGURE 6. XAML BASED WORKFLOW IN MICROSOFT The following scenario describes a fault being
WORKFLOW FOUNDATION
detected by the monitoring system, a problem
Operands ticket being cut and then the problem
Management data that is processed by state remediated following a change management
machines comes in various types. Examples procedure. Each step corresponds to a state
include: machine and describes the operation performed
• Alert along with the operand and the reference data
• Incident used.
• Change record
Table 2 below outlines the sequence of state
• Service request
machines that constitute this scenario, followed
• Provisioning
by the description of activities performed in each
As the state machine workflow progresses,
step. Note that the activities within each
the operands are transformed into more
workflow may be automated or manual.
specific and more relevant management
information. TABLE 2. STATE MACHINE WORKFLOW FOR FAULT
DETECTION AND RESOLUTION
Reference data State Machine Operand Ref Data
Detect fault Alert Thresholds, Alert
In addition to the operands, the state history
machines also use more permanent, Normalize Alert Normalization map
Correlate Alert Alert history
reference data. Such data may include IT Enrichment Alert CMDB, OMDB
Service Management data in a CMDB or more Problem ticket Alert, Problem Alert Ticket mapping
Ticket
transient data in another operational data Escalate Problem notification Escalation table
store. The operational management data Notification Problem Ticket, Notification data,
Page, Email, SMS Call tree
store contains the declarative data previously Change Request Change Ticket CMDB
mentioned and meta data that may be Update Monitoring
Close Change, Problem, Change
mapped on, directly or indirectly, to tool Problem Tickets Tickets
specific data as shown in Figure 7 below.
 Detect fault
A monitoring tool samples metrics from a
resource and compares against the thresholds
table. An alert is generated if a threshold
condition is breached. Thresholds are
specified in a database and may be made
available synchronously within the tool, for
instance via configuration file or
programmatically through tool specific APIs.
The generated event follows a tool specific
format. The figure below shows fields from an
event generated by an agent and those from
an SNMP trap, both depicting the same fault.
FIGURE 8. TOOL SPECIFIC ALERT FIELDS
Normalize
In this step, the event fields are normalized
into a canonical form. The idea is that no
matter what tool or method is used to detect
the fault, its representation is the same, in an
abstract form and not dependent on the
underlying tool. Table 3 below shows alert
data in normalized form
TABLE 3. NORMALIZED ALERT DATA
The fields can now be used consistently to
perform matching and analytics at various
levels. These fields serve as a key in matching
against the different types of management
data.
Correlation and root cause analysis
In this step, alerts are consolidated and root
cause determined. Existing alerts are searched to
determine if this is a repeat symptom of an
underlying problem. Lookup tables are used to
perform correlation. Fields defined previously are
used to perform the match against the lookup
tables. Also, maintenance windows may be
consulted at this stage using the same matching
criteria and the alert dropped if the matched
resource is under maintenance.
Enrichment
In this step, additional fields are added to the
alert. These fields can be technology related to
assist operations or business related to add
business context. Table 4 below shows the
location and service fields enriched.
TABLE 4. ENRICHED ALERT DATA
Create Problem Ticket
Based on the mapping table, and using the alert
data, a new problem ticket is created. The
problem ticket follows a standard form just like
the alert, to ensure consistency. Whether an
alert was generated automatically as above or
the ticket created manually by a Service Desk
operator, the representation should be the same.
The problem ticket now forms the basis for
tracking the alert and is used when performing
escalation etc.
Escalation
Escalation is a core function of the Incident
Management process. The escalation function
can be performed on the problem ticket using The final step in this sequence is to mark the
escalation data in a table such as below. Change as implemented and close the Incident.
The workflow will automatically close or clear the
TABLE 5. ESCALATION TABLE alert in the monitoring tools.
Priority P1 P2 P3 P4
Level of High, Production Degraded Minimal
Impact Critical, severely operations impact
Scenario 2: VM server provisioning
Fatal impacted
2 hrs First
This scenario depicts another common situation
response of requesting and provisioning a virtual server. As
4 hrs Work First
around response with the previous scenario, the management
24 hrs Mgmt Work First solution consists of a series of state machines.
notification around response
48 hrs Mgmt Work First The state machine workflow is outlined in Table 6
notification around response below with the associated operand and reference
1 wk Resolution Mgmt notif Work
around data.
2 wks Resolution
3 wks Resolution
TABLE 6. STATE MACHINE WORKFLOW FOR VM SERVER
Release Resolution
PROVISIONING
State Machine Operand Ref Data
Notification Create Request Service Request
Based on a calling tree and calendar Check Service Service Request CMDB, Service
Catalog Catalog
information the problem ticket can generate Check capacity Service Request CMDB
notifications. Create Change Service Request, CMDB
Request Change Ticket
Provision VM Change Ticket CMDB
Create Change Ticket Close Change, Change Ticket,
Service Request Service Request
Once the right personnel have been notified
and the resolution identified, a change record Create request
is created to perform the change. In our A Service Request is created manually by a
example here, the change involves a change requester. As before, the request is turned into a
to the monitoring thresholds as it was standardized form so as to make its processing
deemed to be a spurious alert. The change easier. This state machine workflow routes the
request follows the change management request to individuals in the organization for
process, including appropriate reviews, action, alerts the manager as necessary when the
approvals and assignment of change current owner does not respond to the request,
implementers. and escalates or transfers the request to the next
level of support. At this stage only a few fields
Update monitoring threshold
such as request number and request owner are
Once the change has been approved and
populated in the service request.
implementer notified, the monitoring
threshold is updated in the database. Note Supplement information from Service
that no change has been made to the Catalog
monitoring tool or any rule sets, and such a This step looks up the Service Catalog to fill in the
change can be performed by a non-specialist details about the servers. This step is comparable
since it is a simple data change. to the Enrichment step in the previous scenario.
Additional attributes include response deadline,
Close change, incident and alert server asset data etc.

Check capacity
Once the service request is sufficiently
qualified, the next step checks there is
adequate capacity on the physical
infrastructure. Checks are performed to
determine CPU, Memory and Storage capacity
and appropriate personnel notified, if
necessary.
Create and manage Change Ticket
Once the right personnel have been notified
and the checks performed, a Change Ticket is
created to perform the change.
Provision VM
This is essentially a manual step, in which the
implementer creates the Virtual Machine.
Close change and service request
The final step in this sequence is to mark the
Change as implemented and close the
corresponding Service Request.
Business Benefits
The integrated approach to Enterprise
Systems Management provides a number of
key related benefits to the business.
• The solution enables optimal use of
technology and human resources to
deliver significant cost reduction in
managing IT systems.
• Standardisation and systematic reuse
of processes and procedures leads to
increased automation and efficient
practice.
• The solution significantly improves
productivity, allowing support staff to
improve service delivery and add
value rather than constantly fire
fighting.
Summary
The approach described in this white paper is
based on ideas and principles widely used in
general computing to overcome the problem of
complexity and inter-operability. The approach
results in a more holistic solution to the problem
of Enterprise Management. A concept of
Enterprise Management Abstract Machine is
presented that utilizes state machine workflows
and declarative, data-driven programming to
decouple management procedures and data
from the underlying tools. Such an approach
results in a federated management model that
enables optimal use of people, processes and
technology. Management applications and
processes can be implemented quickly and
efficiently, without getting bogged down by the
mechanics of the tools.
References
[1] BMC Patrol, http://www.bmc.com/products/product-
listing/ProactiveNet-Performance-Management.html
[2] CA, http://www.ca.com/us/products.aspx
[3] HP OpenView Operations,
https://h10078.www1.hp.com/cda/hpms/display/main/hpms_h
ome.jsp?zn=bto&cp=1_4011_100
[4] IBM Tivoli, http://www.ibm.com/software/tivoli
[5] IBM, Tivoli Management Framework, http://www-
01.ibm.com/software/tivoli/products/mgt-framework
[6] D.Harel. Statecharts: a visual formalism for complex systems.
Science of Computer Programming 8:231-274. North-
Holland 1987.
[7] Macehiter Ward-Dutton, The New Face of IT Service
Management, 2007.
[8] Microsoft System Center Operations Manager,
http://www.microsoft.com/systemcenter/en/us/operations-
manager.aspx
[9] Microsoft Windows Workflow Foundation,
http://msdn.microsoft.com/en-
us/library/ms735921(VS.90).aspx
[10] Office of Government Commerce: Best Management
Practice, IT Service Management, http://www.best-
management-practice.com/IT-Service-Management-ITIL