December, 2010

www.optumis.com

A Paradigm for Integrated IT Systems Management

Sanjay Raina

An Optumis White Paper

Copyright ©Optumis Ltd. www.optumis.com

Contents Introduction 2

Problem Statement 2

Current Practice 3

Optumis Concerto 4

Implementation 8

Business Benefits 13

Summary 13

References 13

Introduction IT Systems Management tools and technologies

continue to be crucial to efficient delivery of IT

services. The IT landscape is evolving all the time

and there are increasing demands placed on the

management of IT. Systems Management tools

have failed to keep pace with these

developments and often fail to deliver the

potential value as promised by the vendors. The

main reason behind this is that IT Systems

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

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

DataTCP

Header

TCP DataIP

Header

Frame dataFrame

Header

Application

Transport

Internet

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

program. These take the form of local

storage (registers or stack) in

conventional machines. In the EMAM

these operands are typically alert

data, incident records, change records

etc.

• Reference data is used by the

workflow component. This is usually

general purpose storage in a

conventional machine where the

results of computation are stored. In

the EMAM, the reference data is

typically operational configuration

data stored in a

configuration/operational data store.

State-machine Workflows

A program in the EMAM is expressed in the

form of a workflow of state machines. The

control of the program propagates through

state machines, with one state machine

triggering another. The programming of the

EMAM takes place by specifying the sequence

in which these state machines are triggered.

The program is specified declaratively, in the

form of a database table or an XML based

markup. Table 1 below shows a sample

workflow specification.

TABLE 1. STATE TRANSITION TABLE

State Machine

Current State

Event Condition

Next State

Next State Machine

Monitor Idle Check Checking Monitor

Monitor Checking Breach Alerted Monitor

Monitor Checking NotBreached Idle Monitor

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

product [9]. The fragment below shows a XAML

representation of a state machine.

<StateMachineWorkflowActivity

x:Class="EMAMWorkflow.Monitor"

Name="Monitor"

InitialStateName="Idle"

xmlns="http://schemas.microsoft.com/winfx/200

6/xaml/workflow"

xmlns:x="http://schemas.microsoft.com/winfx/2

006/xaml">

<StateActivity x:Name="Idle">

<EventDrivenActivity

x:Name="CheckThreshold">

<HandleExternalEventActivity

x:Name="HandleCheckThreshold"

EventName="Check">

</HandleExternalEventActivity>

<CodeActivity

x:Name="DoCheckCode"

ExecuteCode="DoCheckCode_ExecuteCode">

</CodeActivity>

<SetStateActivity

x:Name="SetChecking"

TargetStateName="Checking">

</SetStateActivity>

</EventDrivenActivity>

</StateActivity>

…………

</StateMachineWorkflowActivity>

The above XAML code can be loaded directly into

Microsoft Workflow Foundation to appear as in

Fig. 6 below.

FIGURE 6. XAML BASED WORKFLOW IN MICROSOFT

WORKFLOW FOUNDATION

Operands

Management data that is processed by state

machines comes in various types. Examples

include:

• Alert

• Incident

• Change record

• Service request

• Provisioning

As the state machine workflow progresses,

the operands are transformed into more

specific and more relevant management

information.

Reference data

In addition to the operands, the state

machines also use more permanent,

reference data. Such data may include IT

Service Management data in a CMDB or more

transient data in another operational data

store. The operational management data

store contains the declarative data previously

mentioned and meta data that may be

mapped on, directly or indirectly, to tool

specific data as shown in Figure 7 below.

FIGURE 7. OPERATIONS MANAGEMENT DATA BEING

TRANSLATED TO TOOL SPECIFIC DATA

Scenario 1: Fault detection and

resolution

The following scenario describes a fault being

detected by the monitoring system, a problem

ticket being cut and then the problem

remediated following a change management

procedure. Each step corresponds to a state

machine and describes the operation performed

along with the operand and the reference data

used.

Table 2 below outlines the sequence of state

machines that constitute this scenario, followed

by the description of activities performed in each

step. Note that the activities within each

workflow may be automated or manual.

TABLE 2. STATE MACHINE WORKFLOW FOR FAULT

DETECTION AND RESOLUTION

State Machine Operand Ref Data

Detect fault Alert Thresholds, Alert history

Normalize Alert Normalization map

Correlate Alert Alert history

Enrichment Alert CMDB, OMDB

Problem ticket Alert, Problem Ticket

Alert Ticket mapping

Escalate Problem notification Escalation table

Notification Problem Ticket, Page, Email, SMS

Notification data, Call tree

Change Request Change Ticket CMDB

Update Monitoring

Close Change, Problem Tickets

Problem, Change Tickets

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

escalation data in a table such as below.

TABLE 5. ESCALATION TABLE

Priority P1 P2 P3 P4

Level of Impact

High, Critical, Fatal

Production severely impacted

Degraded operations

Minimal impact

2 hrs First response

4 hrs Work around

First response

24 hrs Mgmt notification

Work around

First response

48 hrs Mgmt notification

Work around

First response

1 wk Resolution Mgmt notif Work around

2 wks Resolution

3 wks Resolution

Release Resolution

Notification

Based on a calling tree and calendar

information the problem ticket can generate

notifications.

Create Change Ticket

Once the right personnel have been notified

and the resolution identified, a change record

is created to perform the change. In our

example here, the change involves a change

to the monitoring thresholds as it was

deemed to be a spurious alert. The change

request follows the change management

process, including appropriate reviews,

approvals and assignment of change

implementers.

Update monitoring threshold

Once the change has been approved and

implementer notified, the monitoring

threshold is updated in the database. Note

that no change has been made to the

monitoring tool or any rule sets, and such a

change can be performed by a non-specialist

since it is a simple data change.

Close change, incident and alert

The final step in this sequence is to mark the

Change as implemented and close the Incident.

The workflow will automatically close or clear the

alert in the monitoring tools.

Scenario 2: VM server provisioning

This scenario depicts another common situation

of requesting and provisioning a virtual server. As

with the previous scenario, the management

solution consists of a series of state machines.

The state machine workflow is outlined in Table 6

below with the associated operand and reference

data.

TABLE 6. STATE MACHINE WORKFLOW FOR VM SERVER

PROVISIONING

State Machine Operand Ref Data

Create Request Service Request

Check Service Catalog

Service Request CMDB, Service Catalog

Check capacity Service Request CMDB

Create Change Request

Service Request, Change Ticket

CMDB

Provision VM Change Ticket CMDB

Close Change, Service Request

Change Ticket, Service Request

Create request

A Service Request is created manually by a

requester. As before, the request is turned into a

standardized form so as to make its processing

easier. This state machine workflow routes the

request to individuals in the organization for

action, alerts the manager as necessary when the

current owner does not respond to the request,

and escalates or transfers the request to the next

level of support. At this stage only a few fields

such as request number and request owner are

populated in the service request.

Supplement information from Service

Catalog This step looks up the Service Catalog to fill in the

details about the servers. This step is comparable

to the Enrichment step in the previous scenario.

Additional attributes include response deadline,

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