IT GOVERNANCE & MANAGEMENT

IT SERVICE MANAGEMENT
ADDITIONAL MATERIAL

Claude Doom
KU Leuven

1
This text presents supplementary course material in addition to the book THE IT
MANAGEMENT ESSENTIALS – DELIVERING BUSINESS VALUE, published by ASP Editions.

© 2018 Claude Doom

All rights reserved. No parts of this book may be reproduced or transmitted in any
form or by any means, electronic, mechanical, photocopying, recording, or other-
wise, without the prior written permission of the author.

2
CONTENTS

3 A FRAMEWORK FOR IT MANAGEMENT 5

3.5. THE CONCERNS .........................................................................................................................5
13 IT MANAGEMENT 7
13.3 IT MANAGEMENT STANDARDS AND FRAMEWORKS ...............................................................7
13.3.1 ITIL 7
13.3.2 ISO/IEC 20000 12
13.3.3 IT4IT 14
13.3.4 COBIT 18
13.3.5 CMMI-SVC 19

14 SERVICES DELIVERY MANAGEMENT 23

14.2.1 THE CUSTOMER SERVICE REQUEST 23
14.2 CUSTOMER SERVICE REQUEST HANDLING ............................................................................24
14.4 ECONOMIES OF SCALE ...........................................................................................................25
14.5 MOORE’S LAW AND DECREASING COSTS ..............................................................................28
15 FINANCIAL MANAGEMENT 31
6.4 IT PROJECT COST-BENEFIT ANALYSIS .......................................................................................31
15.1 IT SERVICES COST CALCULATION ...........................................................................................31
2. THE IDENTIFICATION OF THE SERVICES 32
4. THE CONSOLIDATION OF THE PERSONNEL COSTS 33
5. THE TOTAL COST OF THE RESOURCES 35
6. THE ALLOCATION OF THE RESOURCES TO THE SERVICES 36
7. THE CALCULATION OF THE SERVICES UNIT PRICE 37

16 OPERATIONS MANAGEMENT 41
16.2 CHANGE HANDLING ...............................................................................................................41
16.3.2 EVENT HANDLING 43
16.3.3 INCIDENT HANDLING 44
16.3.4 PROBLEM HANDLING 45

17 QUALITY MANAGEMENT 47
17.1.2 TYPES OF SERVICE LEVELS 47
17.1.4 AVAILABILITY SERVICE LEVELS 48
17.1.5 CAPACITY/PERFORMANCE SERVICE LEVELS 55
17.1.6 ADMINISTRATION/SUPPORT SERVICE LEVELS 56

20 IT GOVERNANCE 59
20.1.1. ISO/IEC38500 59
20.1.2. COBIT 62
20.3. IT SPENDING AND FUNDING .................................................................................................73
20.3.1. IT SPENDING 73
20.3.2. PORTFOLIO MANAGEMENT 75

3
 20.3.3. IT FUNDING 76

21 BUSINESS-IT ALIGNMENT 77
21.2.1. THE GENERIC FRAMEWORK FOR INFORMATION MANAGEMENT 80
21.2.2. THE ALIGNMENT MODEL OF WEILL EN BROADBENT 81
21.5.3. ARCHITECTURE MATURITY 84
21.7. MEASURING BUSINESS-IT ALIGNMENT ................................................................................85
21.7.1. THE LUFTMAN MODEL 85
21.7.2. THE COBIT BUSINESS AND IT GOALS 88

LITERATURE 89
INDEX 95

4
 3
A FRAMEWORK FOR IT MANAGEMENT

3.5. THE CONCERNS

The concerns relate the information systems, their management and their govern-
ance, to the stakeholders1. Concerns are worries and issues, important to the differ-
ent stakeholders, such as the users and the management, but also the developers
and the system engineers.
The concerns are different for different organizations and can be different for differ-
ent IT systems. It is important to identify the particular concerns that apply to a par-
ticular organization. It is also important to identify the particular concerns that ap-
ply to an information system early in its life cycle, preferentially in the first life cycle
phase (conception).
There are two broad categories of concerns:
1. The business concerns. These concerns are mainly related to the business.
Typical business concerns are:
• Products and services. How are the products and services of the organiza-
tion affected?
• Economic aspects, such as the cost of development and operations and the
quantitative benefits of the new system.
• Compliance. During all life cycle phases, the activities should be compliant
with laws and with external and internal regulations and guidelines.
2. The system concerns. These concerns are more related to the information sys-
tems. Typical system concerns are:
• Service levels. These are concerns about the quality of the information sys-
tems and the services built around them. Service levels are minimum qual-
ity requirements, imposed on information services and on information sys-
tems. There are three categories of service levels:
a. Availability and reliability service levels describe the availability of sys-
tems and services, i.e. the fraction of the total time the system or ser-
vice is operational and usable for the users (availability) and the total
time a service or system can operate without interruption (reliability).

1 see also the ISO/IEC 42010 standard (IEEE, 2007).

5
 b. Capacity and performance service levels describe the amount of pro-
cessing by systems and services (capacity) and the timely character of
the processing (performance).
c. Support and administration service levels describe the quality charac-
teristics of the support of the services and systems and of the associ-
ated administration.
• Usability. How easy is it to use, manage and support the information sys-
tems and the services that are based on them? Usability has several aspects:
• User friendliness: the system or service is easy to understand and to
use. This is usability towards the end user.
• Maintainability: the system is easy to install, to update, to configure, to
modify, etc. This is usability towards the engineering staff.
• Administration: the system is easy to administrate. This is usability to-
wards administration staff.
• Scalability: the system can easily be scaled up or down depending on
the (future) needs. This is usability towards the systems- and services
manager and planner.
• Security. The system and the services are secure. Security three basic com-
ponents: authentication (establishing identity), authorization (allowing
and denying access to services and resources), confidentiality (keeping in-
formation from unauthorized persons). Other aspects of security are a de-
rivatives of the basic components. Integrity (information and processes
cannot be altered without authorization) is a consequence of good author-
ization. Non-repudiation (you cannot deny authenticity) is a consequence
of advanced authentication.

6
 13
IT MANAGEMENT

13.3 IT MANAGEMENT STANDARDS AND FRAMEWORKS

There are several standards describing IT services management. The central frame-
work for IT services management is ITIL, mainly describing processes for IT services
management. ITIL is a best practices standard, not a normative standard. ITIL de-
scribes “the best way” to organize IT services management but does not demand
compliance or certification2.
ISO/IEC 20000 is an “official” normative standard for IT services management. In
practice, it describes a subset of ITIL in regulatory terms. ISO/IEC 20000 can serve
as a basis for certification and audit.
IT4IT is the newest of all IT service management standards. It considers IT manage-
ment from the viewpoint of supply chain and contains a reference architecture for
setting up IT services management in an organization.
COBIT is in principle a framework for IT governance, but COBIT describes a large
number of IT management processes: COBIT 5 contains 32 management processes
in addition to five governance processes. These processes partly overlap with ITIL
and ISO/IEC 20000.
CMMI-SVC is a general framework describing best practices for service delivery. It
is not limited to IT services but describes generic management processes for all
kinds of services.

13.3.1 ITIL
ITIL is a series of books, describing the best practices to organize and manage IT
services provision in an organization.3 It is a flexible framework that can be adapted
to several forms of IT services management. It may be used in large and in small
organizations. ITIL has become the de facto standard for IT services management:
more and more organizations require that their IT service providers work according
to ITIL.

2 The ITIL “certifications”, often encountered in the trade press, are certifications of ITIL professionals,
i.e. it certifies that a person is knowledgeable about ITIL and not that an organization is compliant to ITIL.
3 Office of Government Commerce (2007a), (2007b), (2007c), (2007d), (2007e)

7
The ITIL describes the “architecture” to set up an IT services organization. ITIL pro-
vides guidelines to organize and manage IT services provision. It describes what
should be done rather how things should be done.
The current version of ITIL, called ITIL 2011, was released in July 2011. It consists
of five books, each describing a part of the IT service provision. The books follow the
services life cycle, starting with the service strategy, to evolve through design and
roll-out into services operation. A separate book describes IT services quality man-
agement. Each ITIL book describes the goals of the phase and the basic concepts.
The most important part of each book is the description of the ITIL processes and
activities of the life cycle phase. The books also describe the roles and responsibili-
ties, the organizational structure and the methods, techniques and tools, used in the
processes and activities.
The five ITIL 2011 books and the processes they describe are:
1. Service strategy. This book describes how to develop a general strategy for IT
service provision. The provider should deliver added value to its customers and
should have an overall strategy to achieve this goal. This book describes the fun-
damental principles of the development of a strategy, the creation of a services
offering and the organization of the IT department. This ITIL book also discusses
a number of economic aspects of IT service provision.
The ITIL processes of this life cycle phase are:
• Service portfolio management. This process maximizes the value of the invest-
ment in IT services by governing and managing IT investments across the or-
ganization.
• Financial management. This process provides the necessary financial informa-
tion to manage the IT service delivery cost-effectively and to allocate the costs
of the IT services to the users.
• Demand management. In this process, IT services demand is balanced against
the available supply. This process predicts the future use of IT services as ac-
curately as possible.
• Business relationship management. The aims of this process is to ensure that
the service provider understands and meets the customer’s business require-
ments, that there is a good relationship between the provider and its custom-
ers and that the customers are satisfied with the provided IT services.
2. Service design. The second book describes aspects of the design of IT services:
general principles, the identification of the requirements, the services catalog
management and the service level management. It also describes how a service
with sufficient capacity, a high reliability and sufficient security should be de-
signed.

8
 The ITIL processes of this life cycle phase are:
• Service catalog management. The IT provider needs to develop and maintain a
catalog of all IT services. The catalog should describe the available services,
whether they depend on other services, and what services are being devel-
oped.
• Service level management. This process ensures that the relevant service levels
are agreed with the customers and enforced upon the IT provider. Service lev-
els are minimum quality requirements of the IT service provision (also see sec-
tion 0 on page 47). They are specified and agreed upon in service level agree-
ments. IT providers should monitor the performance of their IT service deliv-
ery to ensure that the minimum quality requirements, laid down in the service
agreements, are met.
• Capacity management. The purpose of this process is to deploy sufficient IT
resources in order to deliver the required IT services at the agreed service lev-
els.
• Availability management. This process ensures that the services are available
to the users. The level of availability (e.g. a percentage of the total time) is usu-
ally specified in service level agreements. The process includes the determina-
tion of the requirements, a risk assessment, an evaluation of the impact of fail-
ures, the design of infrastructure to resist component failures and an analysis
of the causes of failures.
• IT service continuity management. The purpose of this process is to support
business continuity in case of a disaster. A plan should be developed to restore
IT service delivery from another location in case of a disaster striking the or-
ganization. This plan should then be implemented and tested at regular inter-
vals. IT service continuity management should be part of the organization-
wide business continuity management process.
• Information security management. The purpose of this process is to define, im-
plement and manage IT security. It includes security risk assessment, the iden-
tification of security threats, the detection of incidents and the repair of even-
tual damage.
• Supplier management. This process aims at a proper management of the sup-
pliers, ensuring that they deliver products and services with the required qual-
ity.
• Design coordination. This process coordinates all design activities.
3. Service transition. This book contains guidelines on the roll-out of IT services. It
describes the activities, such as planning, change management and the infra-
structure and applications configuration management. This book also discusses
a number of management issues related to services roll-out, such as communica-
tion and internal organization.

9
 The ITIL processes of this life cycle phase are:
• Transition planning and support. This process ensures that new services are
rolled-out properly, according to a well-defined transition strategy and follow-
ing a transition plan.
• Change management. This process evaluates, plans and coordinates all changes
in the IT resources, such as installations of new hardware and software.
• Service asset and configuration management. This process ensures that basic
data and configuration data of all IT resources is kept in a central database,
called the configuration management system (CMS). This includes data on
hardware items, installed software, user accounts, applications, networks and
product and services documentation.
• Release and deployment management. This process supports the building, test-
ing and roll-out of the IT services. In this respect, a “release” is a new version
of an IT resource being developed, tested and deployed.
• Service validation and testing. This process ensures that newly developed ser-
vices or modifications of existing services are properly tested and validated
before being rolled-out.
• Change evaluation. This generic process verifies whether new of modified ser-
vices perform as required.
• Knowledge management. This process ensures that useful information is avail-
able to the people designing, implementing and managing IT services.
4. Service operation. The fourth book describes the daily operations of IT services.
It highlights the principles of proper IT operations and describes the major pro-
cesses and activities. The book also gives guidelines on the internal management
of IT resources: infrastructure monitoring, client, server and network manage-
ment, storage and database management and building and technical room man-
agement.
Of particular importance for the daily services operations is the service desk. The
service desk is not an ITIL process, but is an organizational unit, involved in sev-
eral of the ITIL service operation processes (see below).
The service desk is the central point of contact for all IT users. Users contact the
service desk to report incidents, to ask for information or to enter service re-
quests. Usually, a service desk may be contacted by phone, by e-mail or through
a web-interface, for example via the organization’s intranet. The service desk
may be located close to the users (a “local” service desk). Other organizations opt
for a centralized service desk, where all service calls are handled on one single
location. A service desk may also be virtual, where users call one single number
or e-mail to one single address, but where the staff is spread over several loca-
tions. This allows for a 24/7 service desk service, where the service desk may be

10
 contacted round-the-clock, 7 days a week. Some organizations integrate their
service desk into a call center or even outsource it to an external partner.
The ITIL processes of the service operation life cycle phase are:
• Event management. This process detects events, things that happen and that
are relevant for the IT services delivery. Examples of events are failing tele-
communications links, hard disks running out of space and users, logging on to
the network. The event management process also analyzes the detected events
and determines what action should be taken. Event management is intimately
connected to incident management (see below).
• Incident management. An incident is an unplanned (and undesired) interrup-
tion of an IT service or a significant reduction of the quality of an IT service.
Examples of incidents are failing disk drives, crashing applications and aborted
logon attempts. The incident management process identifies, diagnoses, inves-
tigates and solves incidents. The aim is to restore the proper operation of the
interrupted or degraded service as soon as possible.
• Request fulfillment. A service request is a demand from a user to obtain a par-
ticular IT service. The request fulfillment process handles all user requests,
from the receipt of the request to the fulfillment. Examples of service requests
are a demand for a new desktop PC, a request for access to an application or a
request to replenish the toner in a laser printer. Requests for information are
also handled by the request fulfillment process.
• Problem management. A problem is the underlying cause of one or more inci-
dents. For example, continual failures to save a file on a network drive may be
an indication of a shortage of network disk storage. The problem management
process aims at detecting, diagnosing and solving problems. A diagnosed prob-
lem may be solved (e.g. more network disk space is installed) or a workaround
may be implemented (e.g. users are asked to delete obsolete files).
• Access management. This process grants users the right to use a particular IT
service. Of course, access is only granted to authorized users. The process man-
ages all necessary activities, such as verifying user requests for access, granting
the authorized rights, monitoring the access rights and limiting or revoking the
rights whenever necessary.
5. Continual service improvement (CSI). The last ITIL book describes the principles
and processes to improve the IT services. It describes reporting, benchmarking
and quality control. Service improvement should be applied to all phases of the
service provision, from the strategy to the daily operations.
There is only one process in ITIL continual service improvement:
• 7-step improvement process. This process describes seven steps to measure and
improve the quality of the IT services delivery. The steps involve setting up a
plan, determining what the relevant quality parameters are, performing the

11
 actual quality measurements, analyzing and interpreting the measured data
and taking corrective actions.

13.3.2 ISO/IEC 20000

ISO/IEC 20000 is an official ISO standard for IT management. It describes the termi-
nology of IT management, the requirements for an IT services management system
and gives implementation guidelines and examples. The current version was pub-
lished in between 2009 and 20164.
The standard consists of nine parts:
• Part 1: Service management systems requirements. This part describes the com-
plete service management system, used by the services provider to deliver and
manage the services. It describes the requirements to “plan, establish, imple-
ment, operate, review, maintain and improve the SMS” 5. An overview of the
service management system, as specified in this part of the standard, is shown
in .
• Part 2: Guidance on the application of service management systems. This part
offers guidance and recommendations on the implementation of a service
management system.
• Part 3: Guidance on scope definition and applicability of ISO/IEC 20000-1. This
part offers guidance on the applicability of the standard and on the definition
of the scope of the service management system. It describes who is affected by
the standard, what technology is involved and how suppliers are involved in
the system.
• Part 4: Process reference model. This part describes the processes of the service
management system.
• Part 5: Exemplar implementation plan for ISO/IEC 20000-1. It gives an example
of how to implement a service management system according to the require-
ments from the first part of the standard. It describes a phased approach to the
implementation, including the development of a business case, a gap analysis
and implementation governance.
• Part 9: Guidance on the application of ISO/IEC 20000-1 to cloud services. This
part provides guidance for providers of cloud services. This includes the pro-
vision of infrastructure (IaaS,), platform (PaaS) and Software (SaaS) services.
It can be applied to private, public and hybrid cloud environments.
• Part 10: Concepts and terminology. This part explains the terminology of
ISO/IEC 20000.

4 ISO/IEC (2011) (2012) (2012) (2010) (2013) (2015) (2015) (2015) (2016)
5 ISO/IEC (2011)

12
 • Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and ser-
vice management frameworks: ITIL®. It describes the relationship between the
ISO/IEC standard and the ITIL best practices framework. It clarifies how ITIL
is used in accordance with ISO/IEC 20000. It is useful for IT departments, hav-
ing implemented ITIL and seeking ISO/IEC 20000 conformance.
• Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and ser-
vice management frameworks: CMMI-SVC. This part clarifies the relationship
between ISO/IEC 20000 and the CMMI-SVC (Capability Maturity Model Inte-
gration for Services) framework.
ISO/IEC 20000 and ITIL. ITIL is a framework for best practices. It recommends
how to organize and manage IT services. It is descriptive: as an organization, you
can follow the ITIL recommendations, and perhaps you should. However, you do not
have to follow ITIL. It is not a prescriptive standard. If you choose to implement
parts of ITIL and do something else for the rest, that’s perfectly fine.
A consequence of this is that ITIL is not really auditable or certifiable. No auditor or
reviewer has the right to declare that you are working in an ITIL “compliant way”,
simply because ITIL does not prescribe anything.
ISO/IEC 20000 is a prescriptive standard. It tells you what you must do in order to
be compliant with the standard. If you fail to implement everything the way it is de-
scribed in the standard, you are not compliant. In addition, ISO/IEC 20000 contains
strict requirements for compliance. These are auditable, so an auditor can use the
requirements to verify whether your organization is compliant or not.
Therefore, there is a fundamental difference between “ITIL certification” and
“ISO/IEC 20000 certification”. The first certification applies to individuals: they are
certified as being knowledgeable about ITIL, i.e. as being ITIL professionals, able to
implement ITIL in organizations. As argued above, an organization cannot become
“ITIL certified” for adopting the ITIL framework.
On the other hand, an organization can achieve ISO/IEC 20000 certification if it im-
plements its IT services processes in compliance with the ISO/IEC 20000 standard.
Such compliance would be ascertained by a certification organization after an audit.
ITIL is more elaborate than the ISO/IEC 20000 standard. The most general descrip-
tion of IT management is contained in the first part of the ISO/IEC 20000 standard
(Service management systems requirements). More details, and implementation
guidelines are given in the rest of the standard. Still more details are contained in
the ITIL books.
An organization implementing ITIL can easily become ISO/IEC 20000 certified, as
only minor changes in the processes are needed to be compliant with the ISO/IEC
standard.

13
 Figure 0.1. The IT Value
Chain of the IT4IT standard.

13.3.3 IT4IT
IT Value Chain. The IT value chain collects the activities to create IT services offer-
ing value to the business. It describes the basic operations of the IT department, in-
cluding activities such as planning, implementation and support.
The IT value chain is shown in Figure 0.1. It contains four primary IT value streams
and five supporting activities.
The value streams represent the capabilities and activities to manage the IT services
life cycle. Note that IT4IT does not describe processes, as e.g. ITIL does. Instead of
processes, the value streams are collections of so-called functional components and
of data objects. We discuss these in the IT4IT reference architecture (see section 0
below). The primary value streams are:
• Strategy to portfolio (S2P). This value streams supports activities for managing
the portfolio of IT services, such as demand management and forecasting. It
aims at establishing an IT portfolio, based on business priorities, at creating
visibility into the business and at tracking the services life cycle.
In this value stream, a conceptual service model is being developed. This model
represents the new or modified IT services. It only shows high-level architec-
tural elements. The conceptual model provides a bridge between the business
and IT and also provides the business context for the IT services.
The activities of this value stream include:
• Strategy: define objectives, align business and IT roadmaps, set up stand-
ards and policies.

14
 • Service portfolio: enterprise architecture, create service blueprint and
roadmap.
• Demand: consolidate demand, analyze priorities, create new demand.
• Selection: Business value, governance.
• Requirement to deploy (R2D). This value stream provides a framework for cre-
ating new services and modify existing services. it is complementary to devel-
opment methodologies such as Waterfall, Scrum or DevOps. This value stream
ensures that IT services meet business needs, that the IT services are predict-
able. It aims at standardizing service development and -delivery and aims at
building a culture of collaboration between IT development and IT operations.
In this value stream, the logical service model is being developed. It describes
the detailed requirements for the IT services, contained in the conceptual
model, and describes how the services are to be designed (the ‘system design’).
Typical activities of this value stream include:
• Plan & design: IT project planning, Logical services model, requirements
analysis, standards and policies.
• Develop: agile, iterative, linear, … development, version control, initial test-
ing.
• Test: functional-, performance- and security testing.
• Deploy: release planning, change- and configuration management.
• Request to fulfill (R2F). This value stream connects the users/customers with
the IT services they need. It supports the transition of the IT function to a ser-
vices broker model, where the IT department procures, aggregates and offers
services, obtained from different internal and external sources. The value
stream provides a services catalog, preferentially in self-service. It enhances
efficiency by aiming at standard changes and even automatic services fulfil-
ment. It supports tracing of services use and the implementation of service
charge-out.
Typical activities of this value stream are:
• Design & publish: define catalog items, set pricing, publish services.
• Subscribe: offer both self-service and personalized services, manage sub-
scriptions.
• Fulfil: handle fulfilments, automate deployment, integrate fulfilment with
change management and with asset and configuration management.
• Measure: measure services usage, (pro-forma) charge-out, cost calculation,
surveys and ratings.
• Detect to Correct (D2C). This value stream describes a number of operational
aspects of IT services management, such as monitoring and remediation. It in-
cludes event-, incident-, problem-, change- and configuration management. It
aims at the timely identification and prioritization of issues, understanding

15
 their business impact and linking events to incidents, incidents to problems
and problems to defects. It ensures the elaboration of an operating model (ca-
pabilities, processes) to handle the complexity of services delivery.
Activities include:
• Detect: see events and alarms from the IT infrastructure, trace relation-
ships between events, understand user issues.
• Diagnose: detect root causes, evaluate severity and business impact, esca-
late issues.
• Change: Define and approve change requests, perform problem and risk
analysis.
• Resolve: implement changes, verify recovery, close issues.
The supporting activities if the IT value chain are (see Figure 0.1):
• Governance risk & compliance.
• Sourcing & vendor.
• Intelligence & reporting.
• Finance & Assets.
• Resource & project.
IT4IT reference architecture. The IT4IT reference architecture supports the IT
value chain. It provides a standard and repeatable model for creating an IT services
management environment, based on a value chain operating model. In addition, it is
intended to guide suppliers of IT management products and services in the devel-
opment of their products and services.
The IT4IT reference architecture is defined at five levels of abstraction. The three
highest levels of abstraction (level 1: end-to-end overview, level 2: value stream doc-
umentation, and level 3: vendor-independent architecture) are independent of tech-
nology and vendors. The two lowest levels (level 4: vendor-specific refinement ar-
chitecture and level 5: solution architecture) are vendor- and technology dependent.
They are out of the scope of the IT4IT standard 6 and are controlled by IT service
management product- and service vendors.
The main concepts of the IT4IT reference architecture are:
• The value stream. A value stream is a collection of functional components. It
describes the key activities of one area of the IT value chain. The reference ar-
chitecture contains four value streams.
• The functional component. This is a piece of software in the IT4IT reference
architecture. A functional component has inputs and outputs which are data
objects. It is associated to a number of IT services management activities.

6 The IT4IT reference architecture only provides ‘exemplar guidance’ for these levels.

16
 • The data object. The data object contains the (structured) data, manipulated
by the functional components. Data objects evolve through a life cycle. Each
data object has a functional component that manages it
These concepts are related to each other:
• (Data object) relationship. This is a connection between two data objects.
• Data flow. The data flow describes the flow of information between func-
tional components.
• Integration. An integration is a particular type of data flow.
Three types of integration are defined:
1. System of record integration (SoR): cross-linking and life cycle manage-
ment of data objects. SoR integration links directly related data objects
whose life cycles are related, e.g. an event and an incident.
2. System of engagement integration (SoE): this enables humans and ma-
chines to interact and to take action on data objects.
3. System of insight integration (SoI)7: integration with the purpose of cre-
ating visibility, traceability and transparence, to capture services perfor-
mance measurements and to generate information and knowledge.
The combination of the concepts and the relationships leads to the IT4IT reference
architecture model (Figure 0.2). This model includes the four value streams and
shows a number of interrelated functional components and data objects in each
stream.
We recognize a number of well-known functional components in each value stream,
also appearing in other standards, such ITIL and COBIT:
• Strategy to portfolio.
• Enterprise architecture.
• Service portfolio component.
• Requirement to deploy.
• Requirement component.
• Service design component, Build component and Test component.
• Project component.
• Request to fulfill.
• Catalog composition component.
• Fulfillment execution component.
• Detect to correct.
• Event component, Incident component, Problem component.
• Change control component.

7 The current version of the standard (2.1) does not define any system of insight integrations.

17
Figure 0.2. TheIT4IT reference architecture model. Blue rectangles represent functional com-
ponents and circles represent data objects (purple: service backbone data objects, black: other
key data objects, gray: auxiliary data objects).

The standard then describes the objectives, the business value proposition, and the
key performance indicators per value stream. For each functional component, the
standard describes the purpose, the key data objects and attributes and the main
functions (i.e. activities).
IT4IT in the standards landscape. IT4IT intends to be a precise, prescriptive and
normative standard. It is unique in its supply chain approach to IT services manage-
ment. IT4IT is not a methodology, but rather a design template for an IT manage-
ment environment. It provides extra guidance for the implementation of IT manage-
ment, on top of the ITIL best practices and the COBIT control objectives. IT4IT is
model-driven, including a formal and consistent data model for managing all IT ser-
vices management data.
IT4IT aims at allowing IT services management support software developers to
standardize the software and data structures, needed to support IT services man-
agement. This would clean up the large diversity of IT management tools, supporting
more ‘vague’ standards such as (mainly) ITIL or COBIT.

13.3.4 COBIT
COBIT Process model. Figure 0.3 shows the COBIT management processes
COBIT and ITIL. COBIT is much broader than ITIL and is in the first place a frame-
work for IT governance. In this respect, COBIT emphasizes goal setting and control
rather than process description. One can consider COBIT as the more abstract “up-
per layer” of IT management and ITIL as the more specific “lower layer”, describing

18
Figure 0.3. The COBIT 5 process model.

the processes more in detail. Another way is to state that COBIT contains the “what”
and “why” and ITIL describes the “how” of IT services management.
Many of the COBIT processes are described in ITIL. Sometimes one COBIT process
corresponds to several ITIL processes and sometimes one ITIL process is described
in several COBIT processes. There are detailed maps of the correspondence between
the COBIT and ITIL processes8.

13.3.5 CMMI-SVC
CMMI is a set of best practices to improve processes. The best known aspect of CMMI
is the maturity model, which allows to determine the level of maturity at which a
process is implemented. CMMI has been applied for a long time to software devel-
opment.
CMMI-SVC9 is the application of CMMI to services provision processes. It describes
a number of generic processes for services provisioning and a capability- and ma-
turity model to measure these processes. A few of the CMMI-SVC processes are:
• Capacity and availability management, in order to ensure sufficient resources
and adequate services performance.
• Causal analysis and resolution. Analyze issues and improve process perfor-
mance.

8 ITGI (2008), (2008)

9 CMMI Product Team (2010)

19
 GOAL: Prepare for incident resolution and prevention
PRACTICES: Establish an approach to incident resolution and prevention
Establish an incident management system

GOAL: Identify, control, and address individual incidents

PRACTICES: Identify and record incidents
Analyze individual incident data
Resolve incidents
Monitor the status of incidents to closure
Communicate the status of incidents

GOAL: Analyze and address causes and impacts of selected incidents

PRACTICES Analyze selected incidents
Establish solutions to respond to future incidents
Establish and apply solutions to reduce incident occurrence

Figure 0.4. The specific goals and practices of the CMMI-SVC process Incident resolution and
prevention.

• Configuration management. Identify and control configuration of work prod-

ucts. Ensure configuration integrity and provide accurate configuration infor-
mation to developers, users and customers.
• Incident resolution and prevention. Resolve service incidents and prevent them.
This includes activities such as monitoring, identifying and analyzing incidents,
identifying causes, finding workarounds and communicating the status of inci-
dents.
• Service continuity. Establish and maintain plans to ensure the continuity of ser-
vices delivery, even when a major incident occurs.
• Services delivery. Deliver the services according to service agreements.
• Service system development. Design and develop systems to deliver services.
For each process, the CMMI-SVC document specifies the specific goals to reach and
the practices (i.e. ‘activities’), necessary to reach each goal. The document also lists
work products, e.g. documents to be produced. An example of the goals and the prac-
tices is shown in Figure 0.4.
CMMI-SVC measures both the capability level and the maturity level of processes.
The capability level considers a single process area while the maturity level consid-
ers the overall state of the processes. There are four capability levels and five ma-
turity levels.

20
The four capability levels are numbered from 0 to 3:
0: incomplete. The process is absent or only partly implemented. Some of the
specific process goals are not reached.
1: performed. The process realizes its specific goals. However, the process is not
institutionalized.
2: managed. A managed process is planned and executed according to a prede-
fined policy. It is monitored, controlled, reviewed and evaluated.
3: defined. This is a managed process that has a maintained process description.
A defined process is derived from an organization wide set of standard pro-
cesses. It is therefore more consistent than a managed process.
A maturity level consists of a set of practices that defines the organization’s overall
performance. It is considered as an evolutionary stage in the overall development
and improvement of organizational processes. Organizations should evolve from
one maturity level to the next.
There are five maturity levels:
1: initial. Processes10 are unstable and ad hoc. Success depends on the particular
people executing the particular instance of the process. Typical problems
with processes at maturity level 1 are overcommitment to results, non-exe-
cution in case of problems and difficulties to repeat successful process execu-
tions.
2: managed. Selected key processes are institutionalized. The service provider
closes agreements with the customers and manages contractual require-
ments. Configuration management and quality assurance are institutional-
ized. Work groups, processes, products and services are properly managed.
They are planned and sufficient resources are provided. People are assigned
responsibility and are trained. Process execution is periodically evaluated.
3: defined. Best practices such as service continuity and incident handling are
implemented. Services are validated to ensure they meet requirements. Pro-
cesses are rigorously defined and are described in standards, procedures and
methods. Consistent standard processes are established throughout the or-
ganization. From these processes, particular variants are derived to be imple-
mented in particular circumstances. Processes are managed proactively.
4: quantitatively managed. Process objectives and performance are measured
quantitatively. The objectives are based on customer, user and organization
requirements. Quality and performance are statistically defined and managed
accordingly. Process performance is predictable and consistent.

10 Note the plural: the maturity level considers the organization’s overall processes.

21
 5: optimizing. Quantitative methods are used to understand and manage varia-
tions in process performance and outcomes. There is a continuous focus on
process performance improvement through incremental and innovative pro-
cess- and technological improvements. Quality and performance objectives
are established and revised, reflecting changes in the business. Effects of im-
plemented process improvements are measured. Maturity level 5 is charac-
terized by the concern for continuous improvement.
The CMMI-SVC describes how to evolve from one capability level to the next and
from one maturity level to the next.

22
 14
SERVICES DELIVERY MANAGEMENT

14.2.1 THE CUSTOMER SERVICE REQUEST

Users have many needs. Sometimes they need a specific IT service, but in other
cases, they just need advice or they need something “small” like a memory upgrade
or a new mouse for the desktop PC. When the customer wants to obtain a service
from the IT department, a customer service request is issued. This request should
contain the following information:
• The identification of the requestor. The identification of the user requesting the
service. Usually, an identification is also required of the budget center absorb-
ing the cost of the service.
• The name of the requested service. The name is taken from the service catalog.
If the service has variants, the exact variant should be specified.
• The requested service volume. How many service units are needed?
• The requested service level. Services can be available at different service levels,
as described in the services catalog. In this case, it should be stated which ser-
vice level is desired.
• The desired date of the delivery of the service. When should the service be deliv-
ered (for one-time services such as an intervention) or when should the service
be activated (for permanent services such as application access)?
• An optional end date of the service provision. The delivery of permanent ser-
vices in principle continues indefinitely. The optional end data indicates that
the services delivery is only temporary and should end on the given date. For
example, access to an application can be requested for a user for a period of six
months, e.g. because the user is a temporary employee.
• Any existing IT services and systems involved. Sometimes services pertain to
other services or to specific IT systems. When a user request a memory up-
grade, a particular PC is involved. Some requests are for upgrades of existing
services, e.g. upgrading from occasional user to intensive user of an applica-
tion. In these cases, the particular service or system involved should be speci-
fied.
• Any relevant configuration data to approve and deliver the service. For example,
if access to applications for five users is requested, the identification of these

23
Figure 0.1. The request handling process.

five users should be given in order to verify that the users have the authoriza-
tion to access the application.
• Any particular remarks.
In many organizations, users can enter customer service requests through the intra-
net, where a form guides them through the process. Simple requests are usually ac-
cepted by phone or e-mail. All requests are initially received at the service desk,
where they are routed to the customer service request handling process.

14.2 CUSTOMER SERVICE REQUEST HANDLING 11

Figure 0.1 shows a flow chart of the customer service request handling process.

11In the ISO/IEC 20000 standard, this process is part of the process Incident management and request
fulfillment (ISO/IEC, 2010a). In ITIL the process is called request fulfillment. it is part of the services op-
eration life cycle phase (Office of Government Commerce, 2007d). In COBIT, the process is part of the
process DSS02: Manage service requests and incidents (ISACA, 2012b).

24
 14.4 ECONOMIES OF SCALE
An important issue in IT services planning is the realization of economies of scale.
This means that the cost of IT resources or IT services per unit lowers as more units
are being deployed. Economies of scale are a widely observed basic micro-economic
phenomenon, from retail (‘by a six-pack — cheaper’) to industry, where larger man-
ufacturing plants produce cheaper cars than small plants.
In IT services, economies of scale are a driving factor for centralized and larger IT
departments, and also for IT outsourcing. In outsourcing, the idea is to profit from
economies of scale at the IT services provider, who can bundle resources, leading to
a lower unit price.
In order to study economies of scale in IT resources, we need to know the relation
between the capacity of a resource (e.g. part of the infrastructure) and its cost, at
least qualitatively. There are several patterns of capacity – cost relationship, found
in IT resources (see Figure 0.2):
• Linear scaling. The cost is proportional to the capacity. For example: the cost
of a development team is proportional to the number of full-time equivalents,
as all developers have about the same cost.
• Linear scaling with upfront cost. The total cost consists of a fixed cost plus a
cost, proportional to the capacity. For example: large-capacity storage systems
feature a basic cabinet, containing the controller system and the host or SAN
connections, and a number of inexpensive disk units, inserted in the cabinet
according to the desired capacity. One needs to purchase the cabinet first,
which is the upfront cost. However, when disk units are added, the total cost
rises linearly, as all added disks come the same cost.
• Stepped cost. The cost remains fixed for a considerable12 capacity range. How-
ever, at certain critical values of the capacity, the cost rises substantially to a
higher level. An example is a network switch. It has a fixed cost, which remains
the same as long as ports are available. When an extra port beyond the capacity
of the switch is needed, a new switch needs to be purchased.
• Fixed cost13. The total cost is independent of the capacity. Some server software
comes at a fixed cost, independent of the server capacity or the usage 14.
• Grosch’s law. The total cost is proportional to the square root of the capacity.
This law was originally observed at the end of the 1940’s. It also held up for
mainframe servers in the 1950’s and early 1960’s. The law does not fit the data
for mainframe servers over the period 1963 – 1967. For modern computer in-
frastructures, Grosch’s law is one of the possible capacity-cost relationships. It

12 In fact, linear relationships are also stepped in practice, because they mostly involve the purchasing of
discrete parts of the resource at a discrete cost. However, if the ‘steps’ are small, e.g. compared to the cost
at full capacity, we consider the relationship as a ‘smooth’ linear function.
13 Theoretically, this is a special case of the stepped cost.
14 However, many software vendors prefer a pricing scheme following a linear trend or Grosch’s law.

25
Figure 0.2. Possible relationships between the capacity of IT resources and their total cost.

usually still holds at one given moment for comparable hardware models (e.g.
servers from one product line) with varying capacity. The law does not tend to
hold when strongly different products are compared. Sometimes, Grosch’s law
is observed ‘disguised’ as volume discounts, e.g. in software licenses or com-
modity hardware purchases.
Which particular pattern is applicable to a particular resource depends on the re-
source and on the resource vendor policy. For some resources, different patterns
are possible, depending on the supplier or on the client’s choice. Combinations of
the basic patterns are also possible: sometimes the cost rises linearly for smaller
capacity and follows Grosch’s law for larger capacities, when the vendor starts of-
fering volume discounts.
Before the advent of large-scale distributed computing infrastructure, such as PCs
and local servers, computing was dominated by central large-scale mainframe serv-
ers. The main cost of the computer infrastructure at that time was the central server
hardware. The capacity-cost relationship of these servers mainly (but not always)
followed Grosch’s law. Large data centers could realize economies of scale by imple-
menting higher-capacity mainframes, lowering the unit transaction cost.
This encouraged the implementation of large centralized IT departments, where all
computing for the entire organization was performed. In addition, smaller users
could profit from economies of scale by outsourcing their mainframe computing to
mainframe computing service providers.
Since the 1990s computing has been more distributed. The cost of infrastructure has
shifted from central mainframe hardware to distributed infrastructure such as PCs,
local servers and networking equipment. In addition, the share of hardware in the
total cost of ownership has decreased steadily, as most costs are now spent on soft-
ware and supporting services.

26
Figure 0.3. An example of Grosch’s law: the price of the different models of Kingston
USB sticks (vertical) as a function of the capacity (horizontal). The best fit power
curve is shown with the solid line. The square root best fit curve is shown with a
dashed line. Data: Coolblue.be, January 24, 2017.

Intuitively, one still expects that Grosch’s law holds, at least for a given moment and
for the hardware cost within one family of products. A computer server model with
twice the capacity of another model of the same series costs less than double. The
same is largely true for network switches and routers. However, these costs repre-
sent a smaller fraction of the total IT budget as forty years ago, so the total IT budget
hardly profits from these economies of scale.
For lower-capacity storage equipment (flash memory, single disks, e.g. in PCs and
small servers) Grosch’s law applies: the unit price drops for larger storage systems
(see example in Figure 0.3). This is not the case for high-capacity storage equipment,
which follows a linear relationship with an upfront cost.
The relation between ‘capacity’ of software and the total cost varies widely. In this
relationship, ‘capacity’ can have different meanings:
• For server software, capacity refers to a measure of the processing capacity
(MIPS, processor speed). For some servers (e.g. mainframe computers) the
manufacturer has its own capacity measuring system.
• For storage, capacity refers to storage capacity.
• Capacity may refer to volume, e.g. for client software licenses.

27
Figure 0.4. The evolution of computer performance from the beginning of the twen-
tieth century to 1998. The vertical axis gives the number of instructions per second
(log scale) that can be purchased for 1000 euros (2007 value). Data from Moravec
and Kurtzweil.

Software cost has a wide variety of relationships with capacity. Sometimes the rela-
tionship is linear, the cost being proportional to the capacity. Other software ven-
dors offer a fixed cost (‘site licensing’), a stepped cost or a linear cost that evolves
into Grosch’s law for large capacities (‘progressively larger discounts for large vol-
umes’).
Services usually follow the linear cost relationship, the total cost being proportional
to the consumption of services. Sometimes volume discounts are offered (Grosch’s
law). In more exceptional circumstances, fixed costing is used.

14.5 MOORE’S LAW AND DECREASING COSTS

The cost of computer processing has dropped spectacularly over the past decades.
This trend can be clearly demonstrated by considering the evolution of the pro-
cessing power that can be purchased for a given purchasing power (e.g. 1000 euros,
2007 value). This trend is shown in Figure 0.4 for computer systems up to 1998. Tis
figure shows that the computer power that could be purchased for increased faster
than exponential. Over the whole twentieth century, it increased by an average 35%
per year. However, starting from 1973 the yearly growth accelerated to a staggering
60% per year!

28
Figure 0.5. The evolution of the SPECINT2000 computer performance measure for processors,
introduced from 1985 to 2007. Figure: Fuller and Millett (eds.) Invalid source specified..

The performance growth was fueled by Moore’s law, stating that the number of tran-
sistors on a single chip doubles each 18 to 24 months. The growth in number of tran-
sistors translated into a comparable performance growth, while the cost of the com-
puter chip essentially remained the same.
Visionaries like Kurtzweil and Moravec assumed that this spectacular growth would
continue far into the 21st century. Extrapolating, they predicted that the processing
power of the human brain would be available in a commodity computer in the early
2020s. It was even envisioned that the human brain would live forever by being
downloaded into a computer system within a few decades.
The rising trend continued until 2004. At that time, the fast exponential growth was
interrupted. This is shown in Figure 0.5, where the SPECINT2000 computer proces-
sor performance measure of a number of processors is shown as a function of the
time of their introduction. This figure is not directly comparable to Figure 0.4, as it
shows rough computer performance, not performance for a given fixed price. How-
ever, the cost of a processor has remained largely constant over the past two dec-
ades, making Figure 0.5 a representative measure of performance trends.
Since 2004, the performance of computer processors has risen slower. The perfor-
mance has increased by 14% per year, the performance per unit cost by 38% per
year, in line with performance gains in the 1950s and 1960s. Before 2004, single
processors became faster and faster by increasing the clock rate of the processor,
combined with decreasing component size and an increasing number of transistors.

29
In 2004, the practical limit of the clock speed was reached at a few GHz. Increasing
clock speed requires a higher power density and power consumption. The power
consumption of a single chip had risen to tens of watts, approaching 100 watt. Such
a power consumption for a single chip makes it near to impossible to cool the chip
sufficiently to keep the temperature within working range.
Chip manufacturers changed their strategy from increasing clock speed of single
processors to putting several processors on a single chip: the so-called ‘multi-core’
chips. In this way, Moore’s law continues, as more components are being crammed
on a single chip. The nominal processing power of the chip also increases, as four
cores are nominally four times as fast as a single core. However, this scaling does not
hold in practice: using multiple cores in a single software process requires special
programming techniques. In a intensively multitasking environment, such as trans-
action processing, many different small processes are active, so they can easily be
spread over different processors. However, processor-intensive tasks need to be re-
programmed to use multicore processors efficiently. This is one of the major chal-
lenges of high-performance computing in the next years.

30
 15
FINANCIAL MANAGEMENT

6.4 IT PROJECT COST-BENEFIT ANALYSIS

The net present value of a project is given by the formula
𝑁
𝐶𝐹𝑛
𝑁𝑃𝑉 = ∑
(1 + 𝑖)𝑛
𝑛=0

where 𝐶𝐹𝑛 is the cash flow of year n and 𝑖 is the nominal interest rate15. In this
formula, the total number of cash flows is 𝑁 + 1.
The net present value can be calculated with or without taking into account
inflation. If inflation is not taken into account, the cash flows are called real
cash flows or current cash flows. In fact, all cash flows are then expressed in
current monetary value. In this case the nominal interest rate i is equal to the
real interest rate r. This rate includes the compensation for the use of capital
and an optional compensation for risk. Many companies use the cost of capi-
tal, corrected for inflation for the real interest rate.
If inflation is taken into account, the cash flows are called nominal cash flows
or money cash flows. They then correspond to actual amounts of money, val-
ued at the actual future year. In this case, the nominal interest rate i is a com-
position of the real interest rate r and the inflation rate h:
1 + 𝑖 = (1 + 𝑟)(1 + ℎ)
which, for small values of r and h, is approximately equivalent to:
𝑖 ≈ 𝑟 + ℎ.
In this case, the nominal interest rate is often set equal to the cost of capital
(including inflation), augmented with an optional compensation for risk.

15.1 IT SERVICES COST CALCULATION

In order to calculate the cost of IT services from the list of the cost items, we proceed
in seven steps:
1. The identification of the costs;

15Some formulae for the net present value start the sum at 𝑛 = 1. Microsoft Excel uses this definition of
the net present value in its built-in financial function NPV. In order to use Excel calculate the net present
value according to the formula, given here, one should calculate 𝐶𝐹0 + 𝑁𝑃𝑉(𝑖; 𝐶𝐹1 ; 𝐶𝐹2 ; … ; 𝐶𝐹𝑁 ).

31
 2. The identification of the services;
3. The identification of the resources;
4. The consolidation of the personnel costs;
5. The calculation of the cost of each resource;
6. The allocation of the resources to the services;
7. The calculation of the services unit price.

2. THE IDENTIFICATION OF THE SERVICES

The services, rendered by the IT department to its customers, are normally de-
scribed in the services catalog. This catalog gives a description and also gives a unit
of services consumption.
In order to come to a workable cost calculation, it may be necessary to group related
services. The basic idea is that the services cost is calculated for the total group of
related services. This avoids too much detail in the cost calculation. On the other
hand, the grouping allows us to create a cost difference between related services.
This difference may then be reflected in the pricing of the services.
Services may be related to each other and may be grouped for several reasons:
• They are the same service, but with another service level, e.g. a different avail-
ability or performance.
• They are the same service, but with a different capacity, e.g. a larger bandwidth
or more intensive use.
• They are different services, but with essentially the same final result, e.g. an
Ethernet and a Token Ring LAN connection.
• They are different services, but rendered by essentially the same resources, e.g.
programming and unit testing.
For example, two services like “a 100 Mbit/s LAN connection” and “a 1000 Mbit/s
LAN connection” are clearly two variants of the same service. The difference be-
tween them is the capacity of the service, 100 Mbit/s in the first service and 1000
Mbit/s in the second service. When we calculate the cost of LAN services, we may
consider both these service as one single service. Indeed, it is nearly impossible to
separate the cost of a LAN (a resource) into the fraction used by 100 Mbit/s connec-
tions and the fraction used by 1000 Mbit/s connections. Therefore, we consider
both services as one during the cost calculation exercise. Afterwards, we can split
the total cost of the LAN service into 100 Mbit/s and 1000 Mbit/s connections by
assigning a different weight factor to each service, e.g. by deciding that a 1000
Mbit/s LAN connection bears twice the cost of a 100 MBit/s connection.
In order to group services, it is necessary that all services in the group have the same
service unit. In the example above, the unit of both the 100 MBit/s and the 1000
Mbit/s connection is “connection  year”.

32
The IT department of Acme Inc. has defined three IT services: Figure 0.1. An example of
Office Environment. This includes a desktop computer with the definition of services,
a LAN connection, a full office software suite, file- and including groups.
print services, e-mail and Internet access.
The service unit is one computer  year.
Use of administrative software. This includes access to and
use of the full suite of administrative software, includ-
ing accounting, order processing, invoicing, HR man-
agement and inventory management.
This service has two variants:
A simple user, using only one of the applications.
An intensive user, using more than one application.
Application development. The development team delivers
services to the different divisions of Acme Inc.
The unit of service is one day of work. There are three
variants of this service:
1. one day of analysis,
one day of programming,
one day of testing.

By grouping services, we should finally obtain a list of services, whose cost we will
determine. This list is a compromise between ease of calculation (smaller number
of services, more groups) and detail (larger number of services, less groups). When
we consider too many services, too much detail is needed to calculate the cost of all
these services. This requires too many decisions when allocating costs and re-
sources, leading to cumbersome and even inaccurate cost calculations. When we use
too little services, we do not have enough detail in the cost calculation, leading to
inaccurate cost estimates.
An example of services, including some groups, is given in Figure 0.1.

4. THE CONSOLIDATION OF THE PERSONNEL COSTS

The costs for personnel are commonly composed of several different cost elements.
The personnel salaries are not the only costs. We should take into account all costs,
related to personnel, such as office space, office supplies and -equipment, company
cars, training, etc.

33
The IT department of Acme Inc. contains 15 staff members. There are two managers, four
support staff members, seven analyst-programmers and two staff members for the service
desk. We divide the staff into four groups: support, development, management and service
desk. The distribution of the personnel cost is shown in the table below.
Cost (Euro) Total Support Development Management Service desk
Number of persons 15 4 7 2 2
Compensation 772 950 191 690 335 460 150 980 94 820
Office space 42 240 11 264 19 712 5 632 5 632
Office equipment 7 440 1 984 3 472 992 992
Training 16 950 4 520 7 910 2 260 2 260
Internal IT 35 250 9 400 16 450 4 700 4 700
Total 874 830 218 858 383 004 164 564 108 404
Cost/person 58 322 54 715 54 715 82 282 54 202

The ICT Department of Acme Inc. contains three non-operational staff members: the two
managers and the development group coordinator. The costs of these three staff members
should be allocated to the groups of operational staff members. The development group co-
ordinator is allocated for 100% to the development group. The time use of the managers
shows that 0.9 person works for the support group, 0.6 person for the development group
and 0.5 person for the support group. The allocation and the average cost per operational
staff member for each group are shown in the table below.
Cost (Euro) Total Support Development Management Service desk
Total 874 830 218 858 383 004 164 564 108 404
Cost per person 58 322 54 715 54 715 82 282 54 202
Corrections:
Management
persons 0 0.9 0.6 –2.0 0.5
cost 0 74 054 49 369 –164 564 41 141
Total cost 874 830 292 912 432 373 0 149 545
Operational persons 12 4 6 0 2
Cost/oper. person 73 228 72 062 — 74 773

The average costs per operational staff member are to be used in the cost calculation exercise.

Figure 0.2. An example of the consolidation of the personnel cost.

Before we are able to assign the costs to the resources, we should structure the per-
sonnel costs and determine the total cost per operational staff member. An opera-
tional staff member is a staff member who may be assigned directly to one or more
resources. Examples of operational staff members are help desk staff, hardware en-
gineers and programmers. Managers and internal dispatchers are usually non-oper-
ational staff: they work for other staff members and are not directly assigned to re-
sources.

34
There are three options to calculate the total cost of operational staff:
1. We determine the total staff cost and simply divide this total cost by the num-
ber of operational staff members. This yields one single average cost per op-
erational staff member. However, this calculation method does not allow to
make a distinction between “cheap” and “expensive” staff members. During
the cost calculation exercise, we consider the total cost of all staff members as
one single cost item.
2. We determine the staff cost of each staff member separately. This requires
the assignment of all separate costs per separate staff member. Then the costs
of all non-operational staff members are assigned to the operational staff
members. During the cost calculation exercise, each staff member corre-
sponds to a separate cost item.
3. The staff is divided into groups of similar staff members and the average cost
of a staff member is determined per group. For instance, we may consider a
group of all analysts and programmers, a group with the support engineers,
a group containing the managers, a group with the complete service desk
staff, etc. We then determine the total cost per group. By dividing this cost by
the number of staff members in the group, we obtain the average cost per
staff member for the group. Then we assign the non-operational staff mem-
bers to the groups containing operational staff. During the cost calculation
exercise, we consider each group containing operational staff as one cost
item.
An example of the third option to consolidate the staff costs is given in Figure 0.2.
Once we have structured the personnel costs, we may assemble all cost elements. In
addition to the personnel costs, it contains all the other costs of the ICT services de-
partment. The list of the cost elements is the basis of the cost calculation. Therefore,
it should contain all the costs. When costs are left out, they will be hidden and will
artificially lower the cost of the resources and the costs of the ICT services.

5. THE TOTAL COST OF THE RESOURCES

When all cost items are allocated to resources, we can calculate the total cost of each
resource. This can be done by a simple matrix multiplication. Let there be N different
cost elements, indicated by the amounts 𝐶𝑖 (1 ≤ 𝑖 ≤ 𝑁). The total cost of all IT, 𝐶𝑡𝑜𝑡 ,
is given by the sum of all cost elements:
𝑁

𝐶𝑡𝑜𝑡 = ∑ 𝐶𝑖
𝑖=1

Let there be M different resources, their cost being represented by the amounts
𝑅𝑖 (1 ≤ 𝑖 ≤ 𝑀). The sum of the total cost of all resources, 𝑅𝑡𝑜𝑡 , is obviously equal to
the total cost 𝐶𝑡𝑜𝑡 :

35
 𝑀 𝑁

𝑅𝑡𝑜𝑡 = ∑ 𝑅𝑗 = 𝐶𝑡𝑜𝑡 = ∑ 𝐶𝑖
𝑗=1 𝑖=1

The fraction of each cost element i, allocated to a resource j, is given by 𝑎𝑖𝑗 , with 1 ≤
𝑖 ≤ 𝑁 and 1 ≤ 𝑗 ≤ 𝑀. It is clear that each cost element should be completely allo-
cated to resources, so we have:
𝑀

∑ 𝑎𝑖𝑗 = 1, 𝑓𝑜𝑟 𝑎𝑙𝑙 𝑖, 1 ≤ 𝑖 ≤ 𝑁

𝑗=1

The total cost of a resource j is equal to the sum of the cost contributions of all cost
items i:
𝑁

𝑅𝑗 = ∑ 𝐶𝑖 ∙ 𝑎𝑖𝑗 , for all j, 1 ≤ 𝑗 ≤ 𝑀

𝑖=1

If we consider the cost elements and the cost of the resources as row vectors:
𝐶 = [𝐶1 𝐶2 ⋯ 𝐶𝑁 ] and 𝑅 = [𝑅1 𝑅2 ⋯ 𝑅𝑀 ]
and if we consider 𝑎𝑖𝑗 as a matrix:
All allocations to resource j

𝑎11 𝑎12 ⋯ 𝑎1𝑗 ⋯ 𝑎1𝑀
𝑎21 𝑎22 ⋯ 𝑎2𝑗 ⋯ 𝑎2𝑀
⋮ ⋮ ⋮ ⋮
𝑎= 𝑎 𝑎𝑖2 ⋯ 𝑎𝑖𝑗 ⋯ 𝑎𝑖𝑀  All allocations of cost
𝑖1
element i
⋮ ⋮ ⋮ ⋮
[𝑎𝑁1 𝑎𝑁2 ⋯ 𝑎𝑁𝑗 ⋯ 𝑎𝑁𝑀 ]
we can express the calculation of the resources cost as a simple matrix multiplica-
tion:
𝑅 =𝐶∙𝑎
The matrix a is called the cost allocation matrix.

6. THE ALLOCATION OF THE RESOURCES TO THE SERVICES

The allocation of resources to services can also be represented by a matrix multipli-
cation. Let there be T different services. The cost of these services is 𝑆𝑘 (1 ≤ 𝑘 ≤ 𝑇).
The row vector, containing all the services costs, is:
𝑆 = [𝑆1 𝑆2 ⋯ 𝑆𝑇 ]
The fraction of a resource j, allocated to a service k, is given by 𝑏𝑗𝑘 , where 1 ≤ 𝑗 ≤ 𝑀
and 1 ≤ 𝑘 ≤ 𝑇. All these fractions may be written as one single matrix b, called the
resource allocation matrix:

36
 All allocations to service k

𝑏11 𝑏12 ⋯ 𝑏1𝑗 ⋯ 𝑏1𝑇
𝑏21 𝑏22 ⋯ 𝑏2𝑘 ⋯ 𝑏2𝑇
⋮ ⋮ ⋮ ⋮
𝑏=
𝑏𝑗1 𝑏𝑗2 ⋯ 𝑏𝑗𝑘 ⋯ 𝑏𝑗𝑇  All allocations of
resource j
⋮ ⋮ ⋮ ⋮
[𝑏𝑀1 𝑏𝑀2 ⋯ 𝑏𝑀𝑘 ⋯ 𝑏𝑀𝑇 ]
In this way, we can calculate the total cost of the services by a simple matrix multi-
plication:
𝑆 =𝑅∙𝑏
Finally, we can substitute the expression for R into the expression for S, in order to
calculate the services cost directly from the cost elements:
𝑆 =𝐶∙𝑎∙𝑏 =𝐶∙𝑐
where
𝑀

𝑐𝑖𝑘 = ∑ 𝑎𝑖𝑗 ∙ 𝑏𝑗𝑘

𝑗=1

This result is very important: it shows that the costs of the services (S) are linear
functions of the cost items C. The coefficients of these linear functions (𝑐𝑖𝑘 ) are de-
termined by the allocation of cost elements to resources and the allocation of re-
sources to services.

7. THE CALCULATION OF THE SERVICES UNIT PRICE

The cost calculation exercise, described in the previous section, yields the total cost
of each of the services. However, in order to set a pricing for the users, we need to
know the cost per unit of each service.
In principle, the cost per unit of a service is equal to the total cost, divided by the
number of units. In the case of a budget calculation (the standard cost), the number
of units is determined by the services forecast. In the case of an actual cost calcula-
tion, the number of units is the actual number of consumed service units.
When services have been grouped, the calculation is more complex. In this case, it
may be necessary to give different variants of one grouped service different weights.
For example, we may argue that a 1000 Mbit/s LAN connection bears twice the cost
of a 100 Mbit/s connection. In this case, we select one of the services as the basic
service. This basic service is then assigned a weight of one. We then assign weights
to the other variants of the service, relative to the basic service. In the example of
the LAN connections, the 100 Mbit/s connection is the basic service (weight 1) and
the 1000 Mbit/s connection gets a weight of 2.

37
The table below shows the services and the services variants of Acme Inc. The table also
shows the relative weight f, the number of units of each variant and the total number of basic
units per services variant.
Service Variant Weight Number of units Number of
basic units
Office environment Computer 1.0 423 423
Total 423
Administrative application Simple user 1.0 13 13
Intensive user 3.0 4 12
Total 25
Application development Analysis (day) 1.2 400 480
Programming (day) 1.0 400 400
Testing (day) 1.2 300 360
Total 1240

We can now calculate the cost per unit:

Service Total cost Number of Cost per basic
(Euro) basic units unit (Euro)
Office environment 907 718 423 2 146
Administrative application 319 499 25 12 780
Application development 483 100 1240 390

and the cost of each variant of each service:

Service Variant Weight Cost per basic
unit (Euro)
Office environment Computer 1.0 2.146
Administrative application Simple user 1.0 12.780
Intensive user 3.0 38.340
Application development Analysis (day) 1.2 468
Programming (day) 1.0 390
Testing (day) 1.2 468

Figure 0.3. An example of the calculation of the unit cost of IT services.

The number of basic units of a service is the sum of the numbers of the different
variants, multiplied by their weight. When a service k consists of 𝑇𝑘 variants, each
with a weight 𝑓𝑘𝑙 (1 ≤ 𝑙 ≤ 𝑇𝑘 ), the total number of basic units of the service k is
equal to
𝑇𝑘

𝑈𝑘 = ∑ 𝑓𝑘𝑙 ∙ 𝑁𝑘𝑙
𝑙=1

where 𝑁𝑘𝑙 is the number of forecasted or consumed units of the variant l of the ser-
vice k.
The cost of the service k per unit of service is then equal to

38
 (𝑈) 𝑆𝑘
𝑆𝑘 = ⁄𝑈
𝑘

and the unit cost of each variant l of the service k is given by

(𝑈) (𝑈) 𝑓𝑘𝑙 ∙ 𝑆𝑘
𝑆𝑘𝑙 = 𝑓𝑘𝑙 ∙ 𝑆𝑘 =
𝑈𝑘
An example of the calculation of unit costs is given in Figure 0.3.

39
40
 16
OPERATIONS MANAGEMENT

16.2 CHANGE HANDLING 16

A request for change should contain:
• The identification of the requestor.
• The type of change (standard, normal, urgent).
• The proposed priority (low, medium, high, urgent).
• The identification of the implicated resource item(s).
• A list of related changes (if any).
• The desired modifications to the resource item(s).
• A motivation of the change.
• Optionally: an estimate of the effort and the needed resources to implement
the change.
• Optionally: a proposed schedule for the implementation of the change.

16Change handling is called change management in ISO/IEC 20000 (ISO/IEC, 2010) and in ITIL (Office of
Government Commerce, 2007c) and “Manage changes” in COBIT (ISACA, 2012b).

41
Figure 0.1. The process flow of change handling. The grayed processes (labeled “per-
form change”) are performed by the technical staff. CAB stands for Change Advisory
Board.

The process flow for the handling of change requests is shown in Figure 0.1.

42
 Figure 0.2. The event handling
process.

16.3.2 EVENT HANDLING

A process flow of event handling is shown in Figure 0.2.

43
Figure 0.3. The incident handling process.

16.3.3 INCIDENT HANDLING

A process flow of incident handling is shown in Figure 0.3.

44
Figure 0.4. The problem handling process.

16.3.4 PROBLEM HANDLING

A process flow of problem handling is shown in Figure 0.4.

45
46
 17
QUALITY MANAGEMENT

17.1.2 TYPES OF SERVICE LEVELS

Some common service levels for different IT services are briefly described in Figure
0.1.

Service level Availability Capacity / Performance Administration

Service
Desktop services
Office environment Availability of PC Minimum local disk Delivery lead time
space Intervention time after
incident
File server storage File server availability Minimum available space Back-up frequency
Maximum access delay File restoration lead time
Printing Printer availability Minimum printing speed Intervention time
Network services
Network connection Connection availability Minimum throughput Lead time new connec-
tion
Intervention time
Internet access Access availability Minimum throughput Lead time to adjust con-
Maximum frequency se- figuration
curity breaches
E-mail E-mail server availa- Minimum throughput Lead time to activate ac-
bility messages count
Maximum number unde-
tected spam / viruses
Application services Application availability Transaction response Lead time activation new
time transaction
Minimum transac-
tions/hour

Figure 0.1. The definition of some common service levels.

47
 17.1.4 AVAILABILITY SERVICE LEVELS
One of the most important kinds of service level refers to availability of infrastruc-
ture, resources and services. Availability is the fraction of the time a piece of infra-
structure, a resource or a service can effectively be used. An IT resource or service
is in many cases a complex combination of underlying hardware, software and ser-
vices. The availability of a resource or service will therefore depend on the availa-
bility of each of the underlying components. If we want to know the availability of a
composed resource or service, we need to decompose it into its components and
calculate the availability from the availability of the components.
Availability of single components. First, we consider the availability of single com-
ponents like hardware or data connections. Such components are not normally de-
composed in smaller components.
We use two basic parameters to describe the availability of single components:
• The mean time between failures (MTBF)17. This is the mean time between the
startup of a component and the moment the component fails. This parameter
is sometimes referred to as the component reliability 18.
• The mean time to repair (MTTR). This is the mean time between the moment
the component fails and the moment the component is again operational.
The mean time between failures is an intrinsic property of the component. On the
other hand, the mean time to repair depends on intrinsic and external factors. For

Part MTBF Figure 0.2. The mean time between

failures (in hours) for some hard-
Components
ware components and systems. One
IDE hard disk 300 000 h
year is equal to 8766 hours.
SCSI high-quality disk 1 200 000 h
Floppy unit 30 000 h
CD-rom drive 70 000 h
Tape unit 250 000 h
PC power supply 400 000 h
Cooling fan 25 000 h
Mother board 100 000 h
Systems
“Normal” PC 25 000 h
Industrial PC 100 000 h
Mainframe 175 000 h
Matrix printer, laser printer 10 000 h
LAN switch 200 000 h
Router 60 000 h

17 Technically, this parameter should be called “main time to failure”, as, strictly speaking, it is not the
time between two subsequent failures, which is equal to MTBF + MTTR.
18 Office of Government Commerce (2007b)

48
 Figure 0.3. The “bathtub” curve
shows the error rate of a system
as a function of its age.

example, it may take ten minutes to restart a server. If however, no alert is given
when a server goes down, it may take much longer before the server is effectively
operational again after a failure, leading to a much larger MTTR than expected.
Mean times between failures have been determined for many different components,
ranging from electronic components like resistors and transistors to complete com-
puter systems. Figure 0.2 lists mean times between failures for some common com-
puter components. These times look very impressive: a “normal” disk has a mean
time between failure of 300 000 hours, corresponding to 34 years. However, this
does not mean that the average disk will last for 34 years without failing. The mean
time between failures is in fact a statistical parameter. A MTBF of 300 000 hours
means that in a group of 300 000 working disks, one disk per hour will fail on the
average. When we view the MTBF in this respect, the figures are less impressive. In
a group of 300 disks — the typical number of disks in the PC's in a mid-sized busi-
ness — one disk fails per 1000 hours (on the average). This corresponds to one disk
failing per six weeks, a frequency that is not negligible.
It is important to take into account that the mean time between failures of many
components depends on the component age. This dependence is usually expressed
by considering the risk function. This function gives the frequency of failures, , as a
function of the age of the component. The frequency is inversely proportional to the
mean time between failures:
𝜆 = 1⁄(𝑀𝑇𝐵𝐹 + 𝑀𝑇𝑇𝑅)

or, because MTTR is in most cases much smaller than MTBF:

𝜆 = 1⁄𝑀𝑇𝐵𝐹
The risk function often has the form of a bath tub, with two rising wings to the side,
and is therefore often called the “bathtub curve” (see Figure 0.3). It is well known
that systems fail when they are newly installed or when they are old. In the first case,
lack of experience and installation errors cause failures. In the latter case, wear is
the cause of failure. The mean times between failures, traditionally given,

49
correspond to the “bottom” of the curve: they correspond to the intrinsic failure rate,
without the initial installation problems or wear.
Mean times between failures for software are generally much smaller than for hard-
ware and much more variable. They are not easy to determine, because they depend
on many factors, such as the configuration of systems, the load and other software
on the same systems. To obtain information on mean times between failures of soft-
ware in particular situations, only historical data can be used. Many server systems
are able to run uninterrupted for several weeks, leading to mean times between fail-
ures of the order of one thousand hours. However, when regular scheduled mainte-
nance is taken into account, the mean time between failures of software may drasti-
cally increase. Well configured servers and databases that are restarted on a regular
basis tend not to fail during the operational period, leading to mean times between
failure — outside maintenance windows — of a million hours or more; excellent
values. At the other end, servers with software problems may not last more than a
few hours before failing.
The mean time to repair is largely related to the life cycle of an incident. The mean
time to repair consists of the following periods of time:
• The time to detect the failure.
• The time to diagnose the cause of the failure.
• The time to repair the failed system.
• The time to restore the service.
The availability of a component or system,  , is the fraction of the time the compo-
nent or system is operational. It is expressed in terms of the mean time between
failure and the mean time to repair:
𝑀𝑇𝐵𝐹
𝛽=
𝑀𝑇𝐵𝐹 + 𝑀𝑇𝑇𝑅
The quantity 1 –  is called the unavailability:
𝑀𝑇𝑇𝑅
1−𝛽 =
𝑀𝑇𝐵𝐹 + 𝑀𝑇𝑇𝑅
Most hardware has an availability close to 100%.
A typical hard disk with a mean time between failure of 300 000 hours may easily
be replaced within eight hours (MTTR = 8 h). This disk has an availability of
99.997%. A server with a MTBF of 1000 hours may be restarted within half an hour
(MTTR = 0.5 h) and has an availability of 99.98%).

50
 99% 1 hour per 4 days Figure 0.4. The MTBF and MTTR corresponding to an
99.9% 1 hour per 6 weeks availability of “two nines” to “five nines”.
99.99% 1 hour per 14 months
1 minute per week
99.999% 1 hour per 11 years
1 minute per 10 weeks

A standard reference to mean times between failures is the “two to five nines”, indi-
cating which MTBF and MTTR corresponds to availabilities of 99%, 99.9%, 99.99%
and 99.999% (see Figure 0.4). Relating this to the availability of a server system,
including hardware and software, we may conclude that:
• 99% availability is unacceptable for any server system.
• 99.9% may be reached with a well-configured server consisting of “simple”
server hardware.
• Reaching 99.99% availability is only possible with clustering of servers, i.e.
multiple server instances collaborating into one logical system.
• An availability of 99.999% can only be reached by deploying fault-tolerant sys-
tems, where all components are fully redundant and have a back-up that in-
stantly takes over when a component fails.
Availability of composite systems. Many ICT systems are composed of many com-
ponents. The availability of such a composite system is a function of the availability
of the components. Let us consider a system S, composed of n components 𝐶𝑖 , 1 ≤
𝑖 ≤ 𝑛. In order for the complete system to be available, áll components should be
available. The availability of the system S, 𝛽𝑆 , is the product of the availabilities of
the components (𝛽𝐶𝑖 ):
𝑛

𝛽𝑆 = ∏ 𝛽𝐶𝑖
𝑖=1

When the availability of all components is close to one (as we would reasonably ex-
pect), the total unavailability of the system is approximately equal to the sum of the
unavailabilities of the individual components:
𝑛

1 − 𝛽𝑆 ≅ ∑ 1 − 𝛽𝐶𝑖
𝑖=1

As an example, let us consider an IP data connection between two locations. The

availability of the overall connection depends on the availability of the actual data
link (provided by a telecoms company) and the availability of the router at both ends
of the link. The calculation of the availability of the IP data connection proceeds as
follows:

51
 Component Availability Unavailability
Router side 1 99.98% 0.02%
Data link 99.50% 0.50%
Router side 2 99.70% 0.30%
Total 99.20% 0.82%
The situation is different when we consider redundant components. In this case, the
overall system remains available as long as one of the components remains availa-
ble. In this case, the total unavailability of the overall system, 1 − 𝛽𝑆 , is the product
of the unavailabilities of all components:
𝑛

1 − 𝛽𝑆 = ∏ 1 − 𝛽𝐶𝑖
𝑖=1

As an example, we may consider a web site, containing three web servers, each ful-
filling incoming page requests. Each of the servers has an availability of 99.5%. The
total availability of the site is then equal to 1 − 0.0053 = 99.99999%.
Availability improvement techniques. There are several ways of improving the
availability of computer systems. The main idea in all these techniques is to limit or
even avoid single points of failure (SPsOF). Such a SPOF is a piece of equipment that
causes the complete system to malfunction or fail if it fails. In a ‘normal’ IT system,
all components are points of failure. The idea is to include redundant equipment into
the IT system, removing SPsOF from the system. In a fully redundant system, no
SPOFs are left. In practice, it is often quite difficult and expensive to implement an
IT system without SPsOF.
Two techniques that are used to improve the availability of servers are:
• Clustering. Instead of a single server, multiple servers are installed, sharing the
total workload. When one server fails, the workload is spread over the remain-
ing servers with a minimal interruption of the service.
• Virtualization. This technique decouples instances of the operating system
from instances of the hardware. In a ‘classical’ configuration, a single instance
of server hardware runs a single instance of the operating system. By using
virtualization, multiple instances of the operating system can run on multiple
instances of the server hardware. Virtualization is implemented on IBM main-
frames (Sysplex, LPAR, VM hypervisor) and on Intel platforms (VMWare soft-
ware).
Another domain where availability improvement techniques are widespread is disk
storage. In particular, the RAID technique (Redundant Array of Inexpensive/Inde-
pendent Disks) combines multiple disk units in order to improve the availability and
reliability of the combined system.

52
Figure 0.5. The principle of RAID.

The basic concept behind RAID is to introduce extra storage disks, containing redun-
dant information (see Figure 0.5). When a disk fails, its content can be restored from
the redundant information. In modern RAID systems, restoring data is possible
without performance degradation. The whole system is controlled by a specific disk
controller called a RAID controller.
There are several ways to organize RAID. The simplest way is RAID-1 or disk mirror-
ing. In this setting, all data is always written on two identical disks. When one disk
fails, its data can be recovered from the other disk. Usually disk mirroring is local,
i.e. both disks are installed in the same room or the same building. Such a setting
protects against failure of a disk but does not protect against disaster, where both
disks are destroyed, e.g. by a fire or a flood. It is possible to implement so-called
remote mirroring, where both disks are located in different buildings. The basic prin-
ciple is the same: a disk write operation is only confirmed by the disk controller
when the data is written on both disks. In order to guarantee sufficient performance,
the data connection to the second disk unit needs to be sufficiently fast. Usually, a
dark fiber19 connection is installed and the distance is limited to a few tens of kilo-
meters. In such a setting, one disk unit is installed near the server(s) and another
disk unit is installed in the remote location. In case of a disaster, striking only one of
the locations, all data can be recovered.

19This is a fiber connection without intervening switch, with one uninterrupted optical fiber from the
origin to the destination. Dark fiber is realized in practice by welding segments of fiber together. Installing
a dark fiber connection usually takes considerable earthworks.

53
Figure 0.6. The disk configuration in RAID-1 (disk mirroring, above) and RAID-5 (below). PABC is
the block containing the parity information of blocks A, B and C.

RAID-1 is simple but expensive, as it requires twice the net capacity of disk storage.
Therefore, other RAID schemes have been developed. One scheme that is widely
used is RAID-5. The scheme combines n+1 identical disks (e.g. 3+1) with a net ca-
pacity of n disks. RAID-5 combines striping with redundancy. Subsequent blocks of
data are written on subsequent disks in a round-robin fashion. For each physical
disk block location, one of the disks contains a so-called parity block, where redun-
dant data is written. The parity blocks are distributed over all n+1 disks in order to
avoid performance bottlenecks. The parity data is a combination of the data on the
same location on the other disks. For instance, each parity bit is an XOR of the bits
on the same location on the other disks.
When a disk fails, the data on the other disks (all data or data and a parity block)
allows for the recovery of the lost data.

54
In addition to specific availability-improving techniques for servers and storage,
there are a number of general measures that can be taken to improve the availability
of infrastructure in a data center.
First, the data center can be equipped with an uninterruptible power supply (UPS).
This protects (critical) equipment against power failure. An UPS installation usually
has two components: a battery and a generator. When power fails, the battery pro-
vides power to the (critical) equipment for a limited amount of time, usually 10 to
30 minutes. During this period, non-critical equipment (servers, printers, disk units,
networking equipment, etc.) can be shut down correctly (instead of crashing due to
a sudden power failure). During the same period of 10 to 30 minutes, the generator
can be started. If power is not restored when the batteries are exhausted, the gener-
ator starts supplying power to critical equipment for the whole period of the power
failure.
It is to be decided which equipment is critical (and keeps on functioning after a
power failure and exhaustion of the batteries) and which equipment is not critical
(and is shut down in case of power failure). Typically, servers, storage and network
equipment supporting daily operations are considered critical, while development,
testing, and redundant infrastructure is classified as non-critical.
Second, data centers can take measures for disaster recovery. A disaster is an event
that considerably disrupts operations in a data center. Examples are a fire or a flood.
To protect against disaster, many organizations have established a disaster recovery
site. This is a location, remote from the data center, where back-up equipment is
installed. The back-up equipment can be on-line and operating simultaneously with
the operational equipment (hot stand-by) or the equipment can be off-line or even
powered down (cold stand-by). In case of disaster, the equipment at the disaster
recovery site takes over immediately (hot stand-by) or is activated on the short term
(cold stand-by).
In order to properly manage disaster recovery, organizations elaborate a disaster
recovery plan, also called an IT continuity plan. Such a plan explicates what needs to
be done when disaster strikes and how the ‘normal’ situation can be restored.

17.1.5 CAPACITY/PERFORMANCE SERVICE LEVELS

These service levels define minimum levels of capacity or performance of a service
or a specific aspect of a service. A few examples of capacity/performance service
levels are:
• Minimum upload or download capacity of an internet connection. An internet
service provider promises that an internet connection has a minimum capacity

55
 for uploading (sending) data (e.g. 512 kb/s) and has a minimum capacity for
downloading (receiving) data (e.g. 3 Mb/s) 20.
• Minimum storage capacity. This service level typically applies to network stor-
age, where the user is guaranteed to have a minimum storage size available.
• Minimum processor capacity. This service level applies to IaaS and PaaS cloud
computing environment, where the cloud services provider guarantees pro-
cessor capacity.
• Printing speed: the minimum number of pages printed per minute.
• Response times: the time between the initiation of an operation and the com-
pletion. For end users, mainly transaction response times are relevant, i.e. re-
sponse times of transactions in applications. This is usually the time between
hitting the “Enter” or “OK” button on a screen and the display of the result of
the transaction on the screen. Examples are searches in databases, entering
data and performing calculations.
Response time service levels are formulated in two ways:
1. The target value is the average response time over a given period. For
example: “The average response time of SAP transactions over a period
of one month will be less than 3 seconds”. Such a response time is simple
to calculate but does not exclude a considerable number of instances
with larger response times.
2. A percentile for the response times. In this case, a percentile is given in
combination with a target value. For example: “95% of the SAP response
times will be lower than 3 seconds”. Such an approach can limit the num-
ber of outliers (larger than the target value); in this example outliers are
limited to 5%.

17.1.6 ADMINISTRATION/SUPPORT SERVICE LEVELS

These service levels describe the minimum quality requirements for administration
and support of service levels. Most of these service levels describe averages or per-
centiles of lead times for various support and administration activities. A few exam-
ples are:
• Maximum lead times for standard service request fulfilment. These are maxi-
mum times for the fulfilment of standard requests for service. Examples are
the lead times for creating a new user, for providing access to an application,
for the installation of a new desktop PC.

20Do not confuse these minimum capacities with the maximum throughput, which is a part of the service
description.

56
• Lead times for incidents and problems. These service levels describe maximum
lead times for actions on reported incidents. There are two kinds of lead times:
1. Lead time for starting an intervention. For example: “When incident is
reported, the handling of the incident will always start within 1 hour af-
ter reporting”.
2. Lead time for resolution of an incident. For example: “90% of all inci-
dents will be solved and closed within 4 days after reporting (measured
per month)”.

57
58
 20
IT GOVERNANCE

20.1.1. ISO/IEC38500
Vocabulary. First, the ISO/IEC 38500 standard establishes a vocabulary, defining
the most important concepts in IT governance. Three key concepts are:
• Corporate governance of IT: a system for direction and control of the current
and future use of IT. It includes the evaluation and direction of the use of IT
and monitoring to verify that goals are achieved. It includes strategy and poli-
cies for the use of IT.
• Use of IT: this includes the planning, design, development, deployment and op-
eration of IT and the demand management and supply of IT services.
• Human behavior: interactions between individuals and other elements of sys-
tems ensuring the wellbeing of humans and the proper performance of sys-
tems. His includes culture, needs and aspirations of people and of groups of
people.
The standard makes a difference between directors and managers:
• A Director is a member of senior management, typically responsible for gov-
ernance. It includes owners, board members and senior executives.
• Management is the system of controls and processes, established in order to
reach the governance objectives. Managers are those persons, exerting the
management.
Tasks. The standard prescribes that IT should be governed through three main
tasks (see Figure 0.1):
1. Evaluate. Directors should continually evaluate the current use and the future
needs of IT. This includes the evaluation of the strategy, of proposals and of sup-
plier arrangements. Directors should consider internal and external business
pressures, such as changes in technology and economic trends. They should also
consider the current and the future business needs, including business objectives
to be achieved. This evaluation should be a continuous process.
2. Direct. Directors should direct the implementation of plans and policies. The
plans should set the direction for investing in IT. The policies should enforce the
proper behavior in using IT. Directors should ensure that IT projects are
properly managed and encourage good IT governance. Directors should

59
 Figure 0.1. The ISO/IEC 38500
model for corporate govern-
ance of IT (ISO/IEC 2008).

establish a culture of proper governance of IT by demanding compliance to the

six principles of good IT governance.
3. Monitor. Directors should monitor the performance of IT and ensure that IT per-
formance is in accordance with the plans and with the business objectives, as
well as with regulations, legislation and contractual obligations.
An important governance principle is that the responsibility for some aspects of IT
can be delegated from directors to managers within the organization, but that ac-
countability for the effective, efficient and acceptable use of IT remains with the di-
rectors.
Guidelines. Finally, the standard combines the six principles with the three tasks in
a number of guidelines for proper IT governance:
1. Responsibility
• Evaluate. Directors should evaluate the competence of the staff, responsible for
IT decision making. These should be business managers, assisted by IT staff
understanding the business.
• Direct. Directors should direct the execution of plans and request that they re-
ceive the necessary information to meet their responsibilities and accountabil-
ity.
• Monitor. Directors should ensure that IT governance mechanisms are put in
place. They should monitor that staff being given responsibilities actually
acknowledges and understands these responsibilities. Also, directors should
monitor the performance of responsible staff involved in IT governance.

60
2. Strategy
• Evaluate. Directors should evaluate the current IT activities and new develop-
ments in IT in order to ensure that IT supports future business needs.
• Direct. Directors should solicit proposals for innovative use of IT. They should
direct the preparation and implementation of plans and policies in order to
ensure that the business benefits from new IT developments.
• Monitor. Directors should follow up on the progress of approved plans and pro-
posals. They should monitor the use of IT to ensure that benefits from IT are
actually realized.
3. Acquisition
• Evaluate. The options for realizing plans and proposals should be properly
evaluated, balancing risk and value.
• Direct. Directors should direct that the acquisition of IT resources is done
properly by preparing suitable documentation and by ensuring that the re-
quired capabilities are actually delivered.
• Monitor. Directors should verify that IT investments actually deliver the re-
quired capabilities. They should determine to what extent the business and its
suppliers have a common understanding of the IT acquisition.
4. Performance
• Evaluate. Directors should evaluate proposals aimed at supporting business
processes with sufficient It capacity and capabilities. Such proposals address
normal IT operations and take into account the risks of IT use. Directors should
evaluate the risks of interruption of continued business operations and the
risks to the integrity of information and IT assets. They should evaluate the
options to implement effective and timely decision taking practices. They
should regularly assess the effectiveness and performance of the IT govern-
ance system.
• Direct. Directors should allocate sufficient resources to IT, so It can meet the
requirements of the business according to agreements and within budget. Di-
rectors should direct staff to ensure that IT properly provides the business
with correct, up-to-date and secure data.
• Monitor. Directors should assess how effective IT supports the business. They
should monitor the priority setting of IT resources and budgets. They should
determine the extent to which policies are followed.
5. Conformance
• Evaluate. Directors should evaluate the extent of conformance to regulations,
legislation, contractual obligations, standards, internal policies and

61
 professional guidelines. They should evaluate the level of conformance to the
IT governance system.
• Direct. Directors should direct responsible staff to establish mechanisms to en-
force compliance. They should direct that policies should be established and
followed and that IT staff should behave in a professional and ethical way.
• Monitor. Directors should monitor compliance by establishing proper report-
ing and auditing. They should monitor IT activities to ensure that all relevant
obligations are met.
6. Human Behavior
• Evaluate. Directors should evaluate IT activities, ensuring the proper identifi-
cation and consideration of human behavior.
• Direct. Directors should direct that IT activities should be consistent with hu-
man behavior. They should direct that risks, opportunities, issues and con-
cerns are identified, reported and managed in accordance with established pol-
icies.
• Monitor. Directors should monitor IT activities to ensure that proper attention
is given to human behavior.
Benefits. The ISO/IEC 38500 standard states principles for the correct use of IT in
organizations. It also describes a model for the proper governance of IT. The stand-
ard should benefit organizations in two ways:
1. Conformance. IT governance, and the IXO/IEC 38500 standard in particular, as-
sist directors of organizations in assuring conformance with regulations, legisla-
tion and contractual obligations. Inadequate IT systems expose the organization
to risks of non-conformance. Examples include security and privacy regulations,
trade practices, intellectual property, environmental issues and safety regula-
tions. It is common in jurisdiction to hold directors responsible for non-conform-
ance to regulations and legislation. Only when effective governance e is put in
place can directors minimize the risks of non-conformance.
2. Performance. Proper governance of IT contributes to the performance of the or-
ganization. This is accomplished by establishing clear responsibilities and ac-
countability in the delivery of IT services, by aligning IT with the business, by
efficient allocation of IT resources, by establishing good practices, by reducing
costs and by realizing benefits.
Although the ISO/IEC 38500 standard is very concise (it is only 15 pages long) and
only describes general principles, it is an important standard, especially in combi-
nation with COBIT, describing IT governance in more.

20.1.2. COBIT
COBIT addresses specific needs in the overall governance of IT:

62
 Financial perspective
1. Provide a good return on investment of IT-related business investments. Be/ /
2. Manage IT related business risk. /Ri/
3. Improve corporate governance and transparency. Be/ /
Customer perspective
4. Improve customer orientation and service. Be/ /
5. Offer competitive products and services. Be/Ri/
6. Establish service continuity and availability. /Ri/
7. Create agility in responding to changing business requirements. Be/ /
8. Achieve cost optimization of service delivery. Be/ /Re
9. Obtain reliable and useful information for strategic decision making. Be/Ri/Re
Internal perspective
10. Improve and maintain business process functionality. Be/ /Re
11. Lower process costs; Be/ /Re
12. Provide compliance with external laws, regulations and contracts. /Ri/
13. Provide compliance with internal policies. /Ri/
14. Manage business change. Be/Ri/
15. Improve and maintain operational and staff productivity. Be/ /Re
Learning and growth perspective
16. Manage product and business innovation. Be/ /
17. Acquire and maintain skilled and motivated people. /Ri/Re

Figure 0.2. The COBIT 4.1 business (enterprise) goals (ISACA 2007). To the right, the relation-
ships with the stakeholder needs are given (COBIT 5, ISACA 2012): Be: benefits realization, Ri:
risk optimization, Re: resource optimization.

• Reconciling the diverging and conflicting stakeholders expectations in respect

to. Some stakeholders require short-term solutions, while others aim at long-
term stable and sustainable investments. Stakeholders demand involvement
and transparency.
• Addressing the dependency of the business on IT providers, both internal and
external. IT has become pervasive and is often an integral part of the business.
This means that IT can often not be considered as a separate issue. This also
affects the role of IT in the business and the role of the CIO. Achieve
• Achieve business value creation through effective and innovative use of IT.
• Ensure compliance with relevant laws, regulations, contractual agreements
and internal policies.
Meeting stakeholder needs. COBIT starts from the stakeholder drivers, influenc-
ing the stakeholder needs. Drivers include a number of external factors, such as the
market environment, industry sector changes, new technologies, regulations and
politics, and a number of internal factors, including corporate culture, the organiza-
tion and acceptable risks.

63
 1. Respond to business requirements in alignment with the business strategy.
2. Respond to governance requirements in line with board direction.
3. Ensure satisfaction of end users with service offerings and service levels.
4. Optimize the use of information.
5. Create IT agility.
6. Define how business functional and control requirements are translated in effective and effi-
cient automated solutions.
7. Acquire and maintain integrated and standardized application systems.
8. Acquire and maintain an integrated and standardized IT infrastructure.
9. Acquire and maintain IT skills that respond to the IT strategy.
10. Ensure mutual satisfaction of third-party relationships.
11. Ensure seamless integration of applications into business processes.
12. Ensure transparency and understanding of IT cost, benefits, strategy, policies and service
levels.
13. Ensure proper use and performance of the applications and technology solutions.
14. Account for and protect all IT assets.
15. Optimize the IT infrastructure, resources and capabilities.
16. Reduce solution and service delivery defects and rework.
17. Protect the achievement of IT objectives.
18. Establish clarity of business impact of risks to IT objectives and resources.
19. Ensure that critical and confidential information is withheld from those who should not have
access to it.
20. Ensure that automated business transactions and information exchanges can be trusted.
21. Ensure that IT services and infrastructure can properly resist and recover from failures due to
error, deliberate attack or disaster.
22. Ensure minimum business impact in the event of an IT service disruption or change.
23. Make sure that IT services are available as required.
24. Improve IT’s cost-efficiency and its contribution to business profitability.
25. Deliver projects on time and on budget, meeting quality standards.
26. Maintain the integrity of information and processing infrastructure.
27. Ensure IT compliance with laws, regulations and contracts.
28. Ensure that IT demonstrates cost-efficient service quality, continuous improvement and read-
iness for future change.

Figure 0.3. The COBIT 4.1 IT goals (ISACA 2007

The aim of COBIT is to translate the stakeholder needs in a series of specific and
actionable goa ls. This called the COBIT goals cascade.
The cascade starts from the stakeholder drivers, influencing the stakeholder needs.
These needs are:
• Benefits realization; IT should deliver benefits to the business and it is the
aim of IT governance to verifiably realize these benefits.
• Risk optimization; Risk and benefit should be properly balanced in taking
IT decisions.

64
Figure 0.4. The relationship between the enterprise goals 1 → 24
(number left of the arrow) and the IT goals (numbers to 2 → 2,14,17,18,19,20,21,22
the right of the arrows) according to COBIT 4.1. 3 → 2, 18
4 → 3, 23
• Resource optimization. Resources should
5 → 5, 24
be used optimally, balancing cost and per- 6 → 10, 16, 22, 23
formance. Resources include information, 7 → 1, 5, 25
services, infrastructure, applications, 8 → 7, 8, 10, 24
people, skills and competencies. 9 → 2, 4, 12, 20, 26
10 → 6, 7, 11
Next, these needs translate into 17 generic enter-
11 → 7, 8, 13, 15, 24
prise goals. The goals are grouped in four groups 12 → 2, 19, 20, 21, 22, 26, 27
corresponding to the four dimensions of the Bal- 13 → 2, 13
anced Scorecard. The 17 enterprise goals 21 are 14 → 1, 5, 6, 11, 28
shown in Figure 0.2, which also shows the rela- 15 → 7, 8, 11, 13
tionships with the stakeholder needs. An enter- 16 → 5, 25, 28
prise can select one or several of the goals as being 17 →9
the most important ones.
In a next step, 28 IT goals are defined. These are generic but specific goals for the IT
function in the enterprise. The goals are shown in Figure 0.3. The IT department
could select one or more of these goals as being the most important ones.
COBIT relates each of the enterprise goals to one or more IT goals. The relations
indicates that in order to realize a particular enterprise goals, each of the related IT
goals should be realized. The relationship between the enterprise goals and the IT
goals is shown in Figure 0.4. For instance, enterprise goal 5 (Offer competitive prod-
ucts and services) is realized by realizing IT goals 5 (Create IT agility) and 24 (Im-
prove IT’s cost-efficiency and its contribution to business profitability).
In a last step, COBIT 4.1 relates the IT goals to specific processes. The relations indi-
cate that the realization of a particular IT goal, a number of specific process goals
need to be realized. Or we can say that that the relationships indicate which pro-
cesses are important to realize each particular IT goal. In COBIT 5, the process goals
are replaced by the more general concept of enabler goals, enablers being principles,
policies and frameworks, processes (as in COBIT 4.1), organizational structures, cul-
ture, ethics and behavior and resources (information, services, infrastructure and
applications, and people, skills and competencies). This expresses the idea that the
realization of IT goals depends on more than just processes.
A summary of the relationship between the IT goals and the IT processes is shown
in Figure 0.5. Each of the mentioned IT management processes is described in detail
in the COBITstandard, including the process goals, metrics, activities, the process
inputs, outputs and RACI (responsible, accountable, consulted and informed roles).

The enterprise goals are taken from COBIT 4.1, where they are called business goals. The relationships
21

with the stakeholder needs are derived from COBIT 5.

65
 1. → Define a strategic IT plan; Define information architecture; Define the IT pro-
cesses, organization and relationships; Manage projects; Identify automated so-
lutions; Manage changes; Install and accredit solutions and changes; Define and
manage service levels; Manage performance and capacity; Monitor and evaluate
IT performance.
2. → Define a strategic IT plan; Define the IT processes, organization and relation-
ships; Manage projects; Monitor and evaluate IT performance; Provide IT gov-
ernance.
3. → Manage quality; Enable operation and use; Define and manage service levels;
Manage third-party services; Educate and train users; Manage service desk and
incidents; Manage problems; Manage operations.
4. → Define the information architecture; Manage data.
5. → Define the information architecture; Define the IT processes, organization and
relationships; Manage IT human resources; Acquire and maintain technology in-
frastructure.
6. → Identify automated solutions; Acquire and maintain application software; Man-
age changes.
7. → Determine technological direction; Acquire and maintain application software;
Procure IT resources.
8. → Acquire and maintain technology infrastructure; Procure IT resources.
9. → Manage IT human resources; Procure IT resources.
10. → Manage third-party services.
11. → Define the information architecture; Enable operations and use; Install and ac-
credit solutions and changes.
12. → Manage the IT investment; Communicate management aims and direction; Iden-
tify automated solutions; Acquire and maintain application software; Manage
changes; Monitor and evaluate IT performance; Provide IT governance.
13. → Communicate management aims and direction; Enable operation and use; Install
and accredit solutions and changes; Educate and train users; Manage service
desk and incidents.
14. → Assess and manage IT risks; Ensure systems security; Manage the configuration;
Manage the physical environment; Monitor and evaluate internal control.
15. → Determine technological direction; Acquire and maintain technology infrastruc-
ture; Manage performance and capacity; Educate and train users; Manage the
configuration.
16. → Manage quality; Enable operations and use; Manage changes; Install and accredit
solutions and changes; Manage problems.
17. → Assess and manage IT risk; Manage problems; Monitor and evaluate internal
control.
18. → Assess and manage IT risks.
19. → Communicate management aims and direction; Ensure system security; Manage
data; Manage the physical environment.
20. → Communicate management aims and direction; Install and accredit solutions
and changes; Ensure system security.

Figure 0.5. The relationship between the IT goals (number left of the arrow) and the IT pro-
cesses according to COBIT 4.1. Figure continues on next page

66
 21. → Communicate management aims and direction; Install and accredit solutions and
changes; Ensure continuous service; Ensure system security; Manage the physi-
cal environment; Manage operations. Monitor and evaluate internal control.
22. → Communicate management aims and direction; Manage changes; Ensure contin-
uous service; Manage the physical environment.
23. → Manage performance and capacity; Ensure continuous service; Manage service
desk and incidents; Manage operations.
24. → Manage the IT investment; Identify and allocate costs.
25. → Manage quality; Manage projects.
26. → Manage changes; Ensure systems security.
27. → Manage data; Monitor and evaluate internal control; Ensure compliance with ex-
ternal requirements; Provide IT governance.
28. → Manage the IT investment; Identify and allocate costs; Monitor and evaluate IT
performance; Provide IT governance.

Figure 0.5. (continued) The relationship between the IT goals (number left of the arrow) and
the IT processes according to COBIT 4.1.
The goals cascade allows managers to relate enterprise business goals to specific IT
goals and to determine which IT processes deserve the most attention. It tells both
IT managers and senior business managers what the priorities of IT should be, de-
pending on the strategic business priorities. This turns COBIT into a valuable tool
for business-IT alignment.
Covering the enterprise end-to-end. COBIT 5 addresses the governance of IT over
the whole enterprise. The governance of IT, proposed by COBIT, also integrated with
any governance framework for the whole enterprise. In addition, COBIT is complete:
it covers all processes necessary to manage information and the related technolo-
gies in enterprises. This implies that COBIT provides a holistic view on IT govern-
ance and management.
The overall COBIT approach to governance starts from the governance objectives,
which are the stakeholder needs: benefits realization, risk optimization and re-
source optimization. Next, COBIT defines the governance enablers and governance
scope:
• Governance enablers are the organizational resources that enable governance.
This includes frameworks, structures, processes and practices and the organi-
zation’s resources (see section 0 on page 68 for more details).
• The governance scope defines the scope of the governance system, i.e. the parts
of the organization implicated by governance.
Finally, COBIT defines the governance roles and responsibilities. The mutual rela-
tionship of the different roles involved in governance are shown in Figure 0.6. The
owners and stakeholders delegate IT governance to a governance body. This usually
is a committee consisting of a number of stakeholders, including senior manage-
ment, IT management, users and optionally customers and suppliers. However, the

67
Figure 0.6. The key roles in the COBIT governance framework.

owners and stakeholders retain accountability for governance. The governance

body sets out the governance direction and gives guidelines to the management of
the organization. The governance body monitors the management. Management
then instructs operations and aligns operations to the direction set by the govern-
ance body. Operations reports to management about its accomplishments.
Applying a single, integrated framework. COBIT is a single, complete and inte-
grated framework for IT governance. It does not need any other framework to be
implemented. COBIT 5 integrates several previous frameworks, including ValIT and
RiskIT.
The COBIT framework consists of the basic framework. It is completed by a number
of enabler guides, including the COBIT 5 Enabling processes document, describing
the COBIT processes and the COBIT 5 Enabling information document. In addition,
there are a number of COBIT 5 professional guides, describing the application of the
COBIT framework to specific domains. This includes the general COBIT 5 implemen-
tation guide, COBIT 5 for information security, COBIT 5 for assurance, and COBIT 5 for
risk.
Enabling a holistic approach. COBIT enablers are factors that determine whether
or not IT governance works. COBIT defines seven categories of enablers. These en-
ablers work together to implement IT governance. Each enabler needs input from
the others to be fully effective and delivers output that can be used by the other en-
ablers.
The seven categories of enablers are:
1. Principles, policies and frameworks. These are the means to convey the direction
and instructions of the governance body and the management to the operational
staff.
The principles are general in nature, limited in number and are stated in simple
language. They express the core values of the enterprise Policies provide more
detailed guidance on how to put principles in practice. Good policies achieve the

68
 Figure 0.7. The COBIT 5 infor-
mation cycle.

desired outcome, ensure efficient implementation of the underlying principle(s)

and are logical and acceptable to the concerned people.
The frameworks provide structure, guidance and tools to the implementation
and maintenance of IT governance. A good framework is comprehensive, cur-
rent, open and flexible.
Principles, policies and frameworks should be written down and should be ac-
cessible to all relevant stakeholders.
2. Processes. COBIT defines a process as: “a collection of practices influenced by the
enterprise’s policies and procedures that takes inputs from a number of sources,
manipulates the inputs and produces outputs”.
3. Organizational structures. This describes the structure of the enterprise, in par-
ticular the decision making structures. It includes general operating principles,
the membership of structures, their span of control (decision authority bounda-
ries), their level of authority (the decisions they can make), delegation of author-
ity and escalation procedures.
4. Culture, ethics, and behavior. This refers to the individual and collective behavior
in the enterprise.
Organizational ethics are determined by the values by which the enterprise
wants to live. Individual ethics are determined by individuals and are influenced
by factors such as religion, ethnic background, education, and personal experi-
ences.
Behavior is driven by ethics but also by objectives, ambitions and interpersonal
relationships. Of particular interest is behavior towards taking risks, towards

69
 following policies and towards negative outcomes. Desired behavior is stimu-
lated by creating awareness and communicating desired behavior. Rules and
norms provide guidance for implementing desired behavior.
5. Information (a resource). This includes all information, relevant for the enter-
prise, not only electronically stored information. Information can be structured
or unstructured and can be formal (e.g. a policy) or informal (most extreme ex-
ample: gossip).
Information is interpreted data, which is generated by business processes. It a
crucial step in the creation of useful knowledge and of value, which drives busi-
ness processes (see Figure 0.7).
6. Services, infrastructure, and applications (resources). This includes the infra-
structure and technology that provides the enterprise with IT services. Services
can be delivered by internal or by external providers.
7. People, skills, and competencies (resources). This is related to the people. People
should have the correct education and qualifications for their role(s). In addition,
experience and behavioral skills may be required.
Each enabler is associated to a number of stakeholders, internal or external. These
stakeholders have an interest in the particular enabler. For example, a process has
a responsible for its execution, who is a stakeholder.
Each enabler has a number of specific goals. The achievement of these goals pro-
vides value to the organization. Goals are defined in terms of expected outcomes (of
processes) or expected operation of the enabler (e.g. applications).
An enabler has a life cycle. The phases of the life cycle are:
• Plan (including conceptual design)
• Design
• Build, acquire, create and/or implement
• Use and operate
• Evaluate and monitor
• Update or dispose.
The life cycle applies to information, structures, processes, policies, applications and
infrastructure.
An enabler is subject to good practices. These practices describe the best way to
achieve the enabler goals. For some enablers, such as IT governance and manage-
ment processes, COBIT provides good practices.

70
Figure 0.8. The COBIT 5 process groups.

Separating governance from management. COBIT makes a clear distinction be-

tween governance and management. While governance is about stakeholder needs
and enterprise objectives, management consists of planning, building, running and
monitoring activities in line with governance directions.
COBIT defines and describes five governance processes and 32 management pro-
cesses. They are divided in five groups, show in Figure 0.8. The five governance pro-
cesses are consistent with the ISO/IEC 38500 standard 22. Each process contains ac-
tivities of evaluate, direct and monitor, the three main management activities of the
ISO/IEC 38500 standard.
The five COBIT 5 governance processes are23:
• EDM01: Ensure governance framework setting and maintenance. Define the re-
quirements for IT governance. Implement and maintain the necessary IT govern-
ance principles, practices, processes and structures. Define clear responsibilities
and authority.
This process includes three activities:
• Evaluate. Communicate with the stakeholders to understand their require-
ments and assess the current and future IT governance system.
• Direct. Provide guidance to the IT governance practices, processes and struc-
tures.
• Monitor. Assess the effectiveness and performance of the IT governance prac-
tices, processes and structures.
• EDM02: Ensure benefits delivery. Optimize the delivery of benefits from IT services,
IT assets and IT related investments.
This process includes three activities:

22 ISO/IEC (2008)
23 ISACA (2012b)

71
 • Evaluate. Continuously evaluate the portfolio of IT-enabled investments, ser-
vices and assets. Judge any changes in direction necessary to optimize value
delivery to the business.
• Direct. Direct the implementation of principles and practices aimed at deliver-
ing optimal value.
• Monitor. Monitor goals and metrics to determine whether the expected value
and benefits have been delivered. Identify issues and consider corrective ac-
tions.
• EDM03: Ensure risk optimization. Understand, articulate and communicate the en-
terprise’s risk appetite and tolerance. Ensure that IT-related risks are identified
and managed.
This process includes three activities:
• Evaluate. Continuously examine and judge risks related to the current and fu-
ture use of IT in the enterprise. Consider whether the current risk appetite is
correct.
• Direct.. Direct the implementation of risk management practices, ensuring that
actual risk does not exceed the predefined risk appetite.
• Monitor. Monitor goals and metrics of risk management processes.
• EDM04: Ensure resource optimization. Ensure that sufficient and suitable IT peo-
ple, processes and technology are in place to effectively and optimally support the
enterprise objectives.
This process includes three activities:
• Evaluate. Examine the current and future need for IT-related resources and the
options for their acquisition (possible sourcing strategies).
• Direct. Direct the implementation of resource management principles by as-
signing responsibilities and defining goals, metrics and principles.
• Monitor. Monitor the key goals and metrics of the resource management pro-
cesses. Handle deviations from goals.
• EDM05: Ensure stakeholder transparency. Ensure effective communication with
stakeholders
This process includes three activities:
• Evaluate. Examine the current and future needs and principles for stakeholder
communication and reporting. This includes mandatory (regulatory) stake-
holder communication and other communication.
• Direct. Ensure the implementation of effective stakeholder communication
practices, including mechanisms to ensure completeness and quality.
• Monitor. Monitor the effectiveness of stakeholder communication. Assess the
accuracy reliability and effectiveness of the communication. Ascertain that
stakeholder requirements are met.

72
 20.3. IT SPENDING AND FUNDING

20.3.1. IT SPENDING
An overage business spends 4.1% of its revenues or 7.7% of its total expenses on
IT24. In cost-focused IT organizations, IT spending as a fraction of the revenues or
expenses is 10% lower, in agility-focused organizations, it is 10 to 25% larger25.
There are also differences per sector26. In finance and insurance, IT spending is 7%
of the revenues and 14% of the expenses. This is because financial products such as
bank accounts and insurance contracts are highly “computerized” and are in fact “IT
products”. It also shows that in these sectors, IT is not a marginal cost. In the manu-
facturing business, IT spending is 2% of the expenses and in retail, IT spending
amounts to only 1% of the total expenses. In these sectors, IT is a marginal cost in
spite of considerable investments.
IT organizations spend IT money in four areas27:
• Infrastructure. This is the foundation of the IT systems. It usually includes net-
works, clients and servers, storage and printing, Internet access and basic of-
fice and communication applications (Office, e-mail, calendar)., Infrastructure
also frequently includes the implementation and management of central
server infrastructure (mainframes, application servers, storage).
The infrastructure should be sufficiently flexible and allow to build diverse ap-
plications on top of it. By using standards, it allows for the reduction of the total
cost of IT.
• Transactional systems. These systems support the automation of the opera-
tional and mostly repetitive business processes. The purpose is to make these
processes more efficient, less labor-intensive, and thus save costs. Typical
transaction systems include accounting, order processing, invoices, payments,
payroll, etc. ERP systems are typical examples of large-scale transactional sys-
tems.
• Informational systems. These systems provide information to support the busi-
ness tactics or strategy. Typical examples are business intelligence systems,
supporting marketing activities. By analyzing sales data, these systems can
yield information on customer behavior, on the effectiveness of marketing
campaigns, on profitability of products and stores, etc. The goals of informa-
tional systems is to increase control and to acquire useful information on the
organization’s operations.

24 Weill and Broadbent (1998)

25 Ibid.
26 Ibid.
27 Weill and Broadbent (1998)

73
Figure 0.9. IT spending patterns of organizations. The first two columns show the average pat-
terns as measured in 1998 and in 2004. The next three columns give the spending for organiza-
tions with different strategies. The next four columns give spending according to industry sec-
tor (I/S = Information and Services). The + symbols indicate top performers in each sector.
Data from Weill and Aral (2004) and Weill and Broadbent (1998).

• Strategic projects. These are investments to improve the strategic position of

the organization. They are usually made outside the operational systems and
aim at evaluating new technology, new systems or new services before they
are made operational on a large scale. Historic examples are the use of ATMs,
Internet banking and, more recently, mobile banking. Organizations should in-
vest in strategic projects in order to gain or to consolidate a competitive ad-
vantage.
Organizations spread their total IT budget over these four areas. The actual spend-
ing pattern is different from one organization to another. The average distribution
is to spend 54% of the budget on infrastructure, 13% on transactional systems, 20%
on informational systems and 13% on strategic projects 28.

28 Weill and Aral (2004)

74
Spending patterns are different according to the business strategy and according to
the organization’s sector. These differences are shown in Figure 0.9.
The data show that organizations spend roughly half of their IT budget on infra-
structure and another 10 to 15% on transactional systems. Cost-aware organiza-
tions spend less on infrastructure (42%) and considerably more on transaction sys-
tems (40%). Many of those organizations are industrial or manufacturing busi-
nesses, focusing on vertically integrated (little infrastructure) transaction systems
supporting highly standardized manufacturing activities and supply chain.

20.3.2. PORTFOLIO MANAGEMENT

The IT spending patterns provide a basis for IT portfolio management. The basic idea
is that the organization manages a portfolio of investments in information technol-
ogy. This portfolio contains running projects, but also planned projects, projects on
hold and ideas for new projects.
In portfolio, the investments are a considered as a cohesive set of projects, support-
ing the organization’s strategy and operations. The basic portfolio management task
consists of evaluating the mix of projects against the organization’s strategy and
needs and adjusting the projects to meet this mix.
The mix of projects in a portfolio can be classified according to the four areas where
IT departments spend money. This leads to four kinds of investments:
• Investments in infrastructure. These project implement basic infrastructure
such as networks, clients, servers, and storage.
• Investments in transaction systems. These investments set up the transactional
systems supporting the operational business activities.
• Investments in informational systems. This consists of the implementation of
business intelligence systems and management information systems.
• Strategic investments. These are usually projects that explore new technology,
new sales channels and marketing models (e.g. e-business, mobile devices, so-
cial media) or new IT related products and services.
The spread of investments over these four areas depends on the organization and
follow the spending patterns, discussed in the previous section. Cost-aware organi-
zations should invest more on transactional systems. Organizations focusing on agil-
ity should invest more in a (flexible) infrastructure. In addition, it seems obvious
that organizations where IT is of strategic importance and where IT yields a com-
petitive advantage invest more in strategic projects.
The management of the IT portfolio is a governance task. It should therefore be done
by the organization as a whole, not exclusively by IT.

75
 20.3.3. IT FUNDING
Where should the money that IT spends come from? This is the issue of IT funding.
Funding of IT can be done in two basic ways:
1. Charge-out: the users pay to the IT department for the IT services they use.
This ‘payment’ is an internal cost transfer for an internal IT department. It is
an actual expense for outsourced IT services.
2. Corporate overhead. It is considered as a general overhead cost for the organ-
ization.
Funding can be homogeneous, i.e. all IT funding is done the same way, or it can be
heterogeneous, where different areas are funded in a different way. Homogeneous
charge-out is appropriate when IT is a considerable cost for the organization and
when informational and strategic projects are a minor cost. This would be the case
for organizations where IT is important operationally but not of strategic value. Ho-
mogeneous funding through corporate overhead is recommended when IT is a mi-
nor cost for the organization, e.g. less than 2% of the total cost or less than 1% of the
turnover. In this case, it is not meaningful to calculate a detailed cost of IT and gran-
ularly charge it to the users.
Heterogeneous funding patterns are suitable for organizations with a substantial IT
cost and also needing informational systems and strategic projects. A possible het-
erogeneous funding pattern is:
• Infrastructure projects and expenses are funded by charge-out of basic ser-
vices such as network access, processing power, storage and printing. The
principle is that the infrastructure is paid for by its users. Infrastructure
users usually pay a stable fee for the infrastructure they use. Project costs
are spread over longer periods (e.g. by amortizing) and included in the fees.
• Transactional systems are funded by charging-out application services, i.e.
access and usage of applications. This means that the costs of the transac-
tional systems are covered by the users of these systems. The usage of the
systems is charged as a fee, sometimes based on transaction volumes. The
development or acquisition of the application software can be funded on a
project basis or can be spread over the life time of the system and included
in the fees (e.g. by amortizing the investments).
• Informational systems are funded on a project basis by their immediate us-
ers, usually the marketing department. The users pay the direct project
cost, without it being spread over the life time of the system.
• Strategic projects are funded out of corporate overhead. They aim at the
discovery and development of technology that benefits the whole company.

76
 21
BUSINESS-IT ALIGNMENT

What is business-IT alignment? The strategy of a business has a direct influence

on the use of information systems. For example, the role of information technology
in Internet businesses is quite important. It is fundamentally different from the role
of IT in small industrial companies. Internet companies critically depend on their
information systems. When they fail, the business fails. However, when information
systems are unavailable for a short time in a typical small industrial company, this
is a nuisance but not a disaster.
On the other hand, the opportunities, offered by information technology may pro-
vide valuable input to the business. New technological developments may open op-
portunities for new business, even for new business strategies. The Internet
prompted several companies to alter their business model, becoming aggressive us-
ers of the Internet for promotion and sales.
It is clear that businesses need to adjust their IT function to their business. This is
called business-IT alignment.
Henderson and Venkatraman29 were the first to emphasize the importance of busi-
ness-IT alignment. In their strategic alignment model, they argue that business-IT
alignment is based on two building blocks: a strategic fit between the external do-
main (the business environment) and the internal domain (the administrative struc-
tures) and a functional integration between the business and IT. The fit and integra-
tion lead to business-IT alignment.
A useful definition of business-IT alignment is30:
“the degree to which the IT mission, objectives, and plans support and are
supported by the business mission, objectives, and plans”.
This definition includes three aspects: mission, objectives and plans and considers
a two-way alignment (“support and are supported”) between the business and IT.
This definition emphasizes the integration at the strategic level, while the Strategic
Alignment Models also considers the operational level.
It is clear that business-IT alignment should not only be preoccupied with the stra-
tegic level.

29Henderson & Venkatraman (1993)

30Reigh & Benbasat, who call business-IT alignment “linkage between business and information technol-
ogy”.

77
Business-IT alignment may be considered as a state one wishes to achieve. We use
this context when referring to “business-IT alignment leads to competitive ad-
vantages for the company”31.
However, business-IT alignment is also the process of aligning the business and IT.
It may even be viewed as a continuous effort, where the value of the alignment is in
the execution of the process, not necessarily in the outcome. In this respect, it may
be called a “journey”32. Of course, the desired outcome of the business-IT alignment
process is a state of business-IT alignment.
The business-IT alignment process may be formal or informal. In the first case, there
is a formal process, seeking business-IT alignment. In the latter case, business-IT
alignment (as a state) is supposedly achieved without the implementation of busi-
ness-IT alignment as a process.
Sometimes, it is not explicitly define what business-IT alignment is, but only criteria
are given that point to business-IT alignment. In his model to measure business-IT
alignment, Luftman considers 38 criteria, divided into six categories. There is (per-
fect) business-IT alignment when the maturity of the organization in each of the cri-
teria categories is high. There is business-IT alignment when:
•
there is mature and integrated communication between the business and IT;
•
IT demonstrates value to the business;
•
there is proper governance of IT;
•
there is a partnership between the business and IT;
•
IT is able to provide flexible and customizable systems, supporting the busi-
ness;
• IT skills are at a high level.
Cumps33 defines an Business-IT score variable by considering five external determi-
nants. An organization has a (perfect) business-IT alignment if:

31 e.g. Reigh & Benbasat (1996), Kearns & Lederer (2000), Luftman (2003), Avison et al. (2004)
32 Ciborra (1991), Chan (2002).
33 Cumps (2007)

78
 …meeting customer …CRM systems
requirements…
…obtaining …business intelligence
management and knowledge
information… management systems
…is related to
The role …cost reduction the adoption …transactional and ERP
of IT in … and efficiency of systems
improvement… …
…enterprise …application integration
integration… systems
…product …product lifecycle
development… management systems

All correlations are positive. For example, a stronger role of IT in meeting customer
requirements should lead to a higher adoption of CRM systems. In this view, busi-
ness-IT alignment is mainly concerned with implementing the appropriate applica-
tions for a number of key business processes where IT may be important.
We can define business-IT alignment as:
“the proper governance of the IT function34 in accordance with the re-
quirements of the business and the proper use of IT capabilities in the
business”.
This definition reflects the bidirectional nature of business-IT alignment. It requires
that the business governs IT (business → IT) but also that IT capabilities are
properly integrated into the business (IT → business). Furthermore, it emphasizes
that business-IT alignment is an IT governance issue, i.e. it is concerned with the
way the organization as a whole manages and uses its IT function.
The definition allows us to consider business-IT alignment as a process (ensuring
proper governance of IT and ensuring that IT capabilities are properly used) and an
outcome (the state of proper governance and proper use of capabilities).
Because IT governance includes both strategy, projects and operational manage-
ment, business-IT alignment should naturally be concerned with all these aspects
and should therefore not be limited to strategic alignment.
A major issue in business-IT alignment (and also in the current definition) is the
meaning of “proper”. This issue is related to the question whether business-IT align-
ment leads to better business performance.

34 the IT function is the whole of IT systems, human resources and related efforts.

79
 Figure 0.1. The Generic
framework for information
management.

We can attach two meanings to the word “proper”, leading to a different interpreta-
tion of business-IT alignment:
“Proper” means that the outcome of the governance and use of capabilities is posi-
tive for the organization, e.g. it leads to better performance and higher profits. In
this context, a question like “Does business-IT alignment lead to better perfor-
mance?” is meaningless because business-IT alignment implies better business
performance by definition. However, studying the IT governance and the use of
IT capabilities in well performing organizations can show us what “proper”
means and how business-IT alignment should be implemented.
“Proper” means that the governance and the use of capabilities are organized ac-
cording to predefined rules and “best practices”. These rules are based on com-
mon sense and on empirical observations of best practices in organizations. In
this case, there is no assurance that business-IT alignment is beneficial for the
organization. However, in this context empirical studies can reveal whether the
adoption of the predefined rules and best practices (i.e. business-IT alignment)
is beneficial or not.
In this work, we will use the second meaning of “proper”. We will derive the prop-
erties of business-IT alignment a priori from the literature and from best practices
and use these rules to implement alignment.

21.2.1. THE GENERIC FRAMEWORK FOR INFORMATION MANAGEMENT

In several papers, Maes35 extended the Strategic Alignment Model to three layers
and nine “domains”. He split the internal domain of the Henderson and Venkatra-
man framework into a structural and an operational level. The IT domains were re-
named “Technology”. Between the business and IT domains, an intermediate

35 Maes (1999), Maes (2007).

80
 Figure 0.2. The alignment model of
Weill and Broadbent.

column was inserted, called “Information and Communication”, representing the

communication between the business domains and the technology domains. The re-
sult was the Generic Framework for Information Management (see ).
The additional middle horizontal layer represents the structural aspects of the or-
ganization, in particular the infrastructure and competences. Maes argued that busi-
ness-IT alignment is not only a strategic issue, but also a problem of structural (mid-
dle layer) and operational alignment. The structural level is primarily concerned
with architecture. The structural business domain focuses on business architecture
while the technological domain is concerned with the technology architecture.
The extra vertical middle column represents the internal and external information
and communication aspects of the organization. It is concerned with the information
and communication processes at the strategic level (top), the structural level (mid-
dle) and the operational level (bottom).
The generic framework was also combined with the Integrated Architecture Frame-
work of CapGemini36 into a three-dimensional framework, called the Unified Frame-
work for Alignment.

21.2.2. THE ALIGNMENT MODEL OF WEILL EN BROADBENT

According to Weill and Broadbent, the traditional approach to alignment has four
ingredients (see Figure 0.2):
• The strategic context. This context is concerned with the business products and
markets, the customers and the investment. The most important elements of the
strategic context are the strategic intent and the current strategy. The strategic
intent articulates the long-term business goals. It is the main driver of the long-
term investments in information technology. The current strategy describes how
the organization functions today. It changes more frequently and drives the IT in-
vestments on a smaller timescale. According to Weill and Broadbent, the long-
term IT investments should mainly be in IT infrastructure while the shorter-time

36 A recent version of this framework can be found at CapGemini (2006)

81
 investments should be oriented towards strategic, informational and transac-
tional IT systems (see below).
• The environment. The business environment has a profound impact on the busi-
ness. Three environmental factors are of particular importance for the alignment
between the business and IT:
1. New technological developments offer opportunities to use IT;
2. Competitors are a continuous threat;
3. Regulations are constraints for the business.
• The information technology strategy. The IT strategy contains three important el-
ements:
1. The articulation of the role of IT in the organization;
2. The delivery of services to the users;
3. The IT policies and standards, imposed on the organization.
• The information technology portfolio. The portfolio is the entire investment of the
organization in information technology. It includes the hardware and the soft-
ware, but also the people, managing and supporting the IT systems. Weill and
Broadbent split the portfolio into four parts:
1. The infrastructure, implementing basic IT services throughout the organiza-
tion.
2. Transactional systems, automating the operational processes in the organiza-
tion.
3. Informational systems, aimed at a better control of the organization and a bet-
ter information provisioning;
4. Strategic systems, aimed at improving the strategic position of the organiza-
tion, at becoming more competitive, at gaining market share and at becoming
more innovative.
Weill and Broadbent identify five links between these components. These links are
necessary to achieve alignment between the business and IT. The links are:
1. The environment impacts the strategic context. Competitors, regulations and
even emerging technology have an influence and may even determine the
current strategy and the long-term strategic intent of the organization.
2. The environment impacts the IT portfolio. New technological opportunities,
but also competitor actions and regulations impact the IT portfolio, leading
to the implementation of new infrastructure and new applications.
3. The strategic context drives the IT strategy. The traditional view is that the IT
strategy is a consequence of the strategic business context. In particular,
Weill and Broadbent argue that the strategic intent drives the long-term in-
vestments in IT infrastructure, while the current strategy drives the invest-
ment in the application portfolio.

82
 4. The IT strategy aligns the IT portfolio. As the role of IT in the organization
changes, as new services are to be delivered and new policies and standards
are put in place, the IT portfolio is adjusted to the evolving IT strategy.
5. The IT portfolio is an enabler of new strategic context. Finally, a well-designed
IT portfolio enables new strategies to emerge, influencing the strategic busi-
ness context.
Weill and Broadbent identify three kinds of barriers to perfect business-IT align-
ment:
• Expression barriers. These barriers arise when the operational management does
not understand the strategic intent of the organization. It may be that the business
strategy is not clearly articulated, that the organization’s strategic intents change
too rapidly or that top management has insufficient vision of the use of technology
in the organization.
• Specification barriers. These barriers are caused by the business and IT developing
their strategies without communicating with each other. The “two monologues”
situation is a typical specification barrier, where both the business and IT have
their own ideas but do not understand each other. The unwillingness to consider
technology in business strategy development is another specification barrier.
• Implementation barriers. Here there is the clear intent to align the business and IT,
but the actual alignment is hindered by practical issues, such as technical, finan-
cial, political or regulatory constraints.
According to Weill and Broadbent, alignment of the business and IT is a dynamic
process, so business-IT alignment will always be difficult to achieve.

83
Figure 0.3. The basic IT architecture for the four stages of architecture maturity. ‘A’ stands for
application, ‘D’ for data and ‘I’ for infrastructure. After Ross, Weill & Robertson (2006).

21.5.3. ARCHITECTURE MATURITY

How enterprise architecture contributes to business-IT alignment is addressed in
the four stages of architecture maturity 37:
1. Business silos architecture. Functional needs are managed in individual busi-
ness units. IT focuses on the automation of specific business processes 38. The
business silos architecture typically creates bothersome legacy systems and
hinders integration and standardization. However, business silo architec-
tures remain attractive because they address immediate and local needs and
usually lead to systems with lower cost on the short term.
This form of enterprise architecture represents a low level of business-It
alignment. The business and IT are only locally (per business unit) integrated
and there are no efforts for a global enterprise wide alignment.
2. Standardized technology architecture: Basic infrastructure (network, compu-
ting platforms, basic applications) is shared, standardized and managed cen-
trally. The number of technology platforms and individual applications is re-
duced, reducing risk and improving reliability and security. In this stage, spe-
cific business data and applications (mostly) remain bound to individual di-
visions.
In this architecture, there is business-IT alignment at the level of the basic
infrastructure. In addition, there are efforts towards global alignment.
3. Optimized core architecture. Data and processing (applications) are standard-
ized throughout the organization. Systems and data are fully integrated and
used enterprise-wide 39 . The number of technology platforms is often very

37 Ross, Weill, & Robertson (2006)

38 These organizations are clearly in the stage of task automation, one of the three ways of using infor-
mation systems (see Doom 2017, IT Management, course text).
39 These organizations are clearly in the stage of integrated information systems, one of the three ways

of using information systems (see Doom 2017, IT Management, course text).

84
 limited (one or two). IT focuses on reusing data and on building versatile
business platforms. Typical for this stage is the use of ERP systems.
This stage embodies the alignment of infrastructure, data and applications.
4. Business modularity architecture: in addition to global standards, local differ-
ences are enabled. In this stage, the enterprise is agile and reacts promptly to
changing business situations by extending the essence of the business with
customizable or reusable modules, on top of the core architecture. These are
often created at the discretion of local managers. The aim is to extend core
functionality, not replace it.
This enterprise architecture model corresponds to a high level of global busi-
ness-IT alignment, combined with local alignment efforts.
Generally speaking, the four stages of architecture maturity reflect a growing ma-
turity of tactical business-IT alignment, where silos represent the lowest form of
alignment and business modularity the highest form. There is also a relation with
the enterprise operating models. Enterprises with a diversification operating model
would usually not evolve beyond a standardized technology architecture, while the
other operating models (replication, coordination, unification) can evolve further.

21.7. MEASURING BUSINESS-IT ALIGNMENT

21.7.1. THE LUFTMAN MODEL

The Luftman alignment model offers a framework to actually measure business-IT
alignment. Since its inception, the model has evolved through several closely related
variants. Here we discuss the variant, published in 200340, but for some of the as-
pects of the model (e.g. maturity), we revert to older versions of the model 41.
The Luftman model uses 38 criteria in six maturity categories to assess the business-
IT alignment. Each criterion is assessed at five levels (from 1 to 5), level 1 represent-
ing a minimal maturity and no alignment and level 5 representing maximal maturity
for the criterion and complete alignment.
The six maturity categories and 38 assessment criteria are:
1. Communications maturity. This category of criteria is concerned with the com-
munication between the business and IT.
The model measures the maturity of the communications between business and
IT by evaluating six criteria:
• How good does IT understand the business?
• How good does the business understand IT?

40 Luftman (2000)
41 Luftman (2000)

85
 • The quality of the organizational learning.
• How the interaction between business and IT is regulated.
• The organization of knowledge sharing between business and IT.
• The breadth and effectiveness of the liaison between business and IT.
2. Competence/value measurements maturity. This set of criteria looks at how IT
demonstrates its value to the business. Important aspects here are service level
agreements, benchmarking and performance reviews.
The maturity is measured by considering seven criteria:
• The quality of the IT metrics.
• The quality of the business metrics.
• The link between the business and IT metrics.
• The extent of use of service level agreements.
• The use of benchmarking.
• The use of formal assessments and reviews of the IT investments.
• The implementation of continuous improvement programs.
3. Governance maturity. This category considers governance: the processes and
structures put in place to make common decisions about IT related matters.
The governance maturity is measured by considering eight criteria:
• The extent of formal business strategic planning.
• The extent of formal IT strategic planning.
• How does IT fit into the organization (reporting line, organizational struc-
ture)?
• The reporting relationship between the CIO and the organization (CIO re-
ports to CFO, COO or CEO).
• The way IT costs are budgeted (cost center versus profit center)
• The rationale for IT spending (cost reduction, productivity increase, com-
petitive advantage)
• The role of the IT steering committee.
• The prioritization of IT projects (reactive, by IT or by the business).
4. Partnership maturity. Here we consider the relationship between the business
and IT. We also look at the business perception of IT, sponsoring from the busi-
ness and the management of the business-IT relationship.
The partnership maturity is measured by considering six criteria:
• The business perception of IT (cost-of-business versus value-creating busi-
ness partner).
• The role of IT in the business strategic planning.
• The extent to which the business and IT share risks and rewards.
• The management of the business-IT relationship.
• The business-IT relationship style (mistrust versus trust, conflict versus
partnership)

86
 • The sponsoring of IT projects from the business.
5. Technology scope maturity. Is IT able to provide flexible and customizable sys-
tems and do we take full advantage of emerging technologies?
The maturity is measured by considering four criteria:
• The use of the primary systems (office support, transaction support, busi-
ness strategy enabler)
• The enforcement of standards.
• The integration of the IT architecture into the business.
• The perception of the IT architecture (utility, driven by business strategy,
fast & agile).
6. Skills maturity. Here we assess the quality of the IT human resources manage-
ment.
The skills maturity is measured by considering seven criteria:
• The entrepreneurial environment and the encouragement of innovation.
• Who takes the key decisions on IT human resources management?
• The attitude towards change.
• The frequency of career cross-over.
• The implementation of cross-functional training and job rotation.
• The level of social interaction between IT, the business and the customers
and partners.
• The ability to attract and retain top level talented staff.
Each of the 38 criteria is evaluated on a scale of five maturity levels:
Level 1: Ad hoc process. This is the lowest level of maturity. There is minimal
awareness. It is improbable that alignment is achieved.
Level 2: Beginning process. There is commitment to begin the alignment pro-
cess. Alignment awareness is still minimal.
Level 3: Established process. There is focused alignment awareness. IT is em-
bedded in the business. IT assets are successfully used throughout
the enterprise.
Level 4: Improved process. There is effective governance. IT is considered to
be valuable, innovative and contributing to success.
Level 5: Optimal process. Governance processes are mature and integrate IT
strategic planning into strategic business planning. IT is successfully
used into the organization’s supply chain.
For each of the 38 criteria, the model describes the characteristics for each maturity
level.
The average score of an organization on the six groups of maturity criteria then
yields the maturity of the business-IT alignment.
Luftman recommends conducting a business-IT alignment assessment in four steps:

87
 1. Form the assessment team. In this step, the assessment team is formed, typi-
cally consisting of 10 to 30 executives. Both business and IT executives should
participate.
2. Gather information. The team members evaluate each of the 38 criteria, giving
a maturity level for each criterion. Team members also discuss their scores.
3. Decide on the scores of each criterion. The team members reach an agreement
on an average score for each criterion. These scores are then averaged, yield-
ing the average score on each of the six categories.
4. Decide on the overall alignment score. Finally, the team agrees on an overall
score for the business-IT alignment. The scores of the six maturity categories
are averaged. The average score can further be adjusted after a discussion
among the team members.
Luftman reports that Global 1000 executives score their organizations at level 2 to
level 3.
The Luftman model is a comprehensive technique to measure business-IT align-
ment. However, it requires the evaluation of many criteria, so measuring the actual
alignment maturity in an organization may be elaborate.

21.7.2. THE COBIT BUSINESS AND IT GOALS

Another potential method of measuring business-IT alignment is the use of the en-
terprise goals and IT goals of COBIT (see section 0 on page 63). COBIT specifies re-
lationships between business goals and IT goals. Measuring business-IT alignment
with this framework could be done as follows:
1. Business managers are asked to identify their major business goals from the
COBIT list of enterprise goals.
2. IT managers are asked to identify their major IT goals from the COBIT list of
IT goals.
3. It is established to what extent the identified business goals and IT goals are
related according to what COBIT prescribes. The extent of relationship is ex-
pressed in a number, indicative of the level of business-IT alignment.

88
 LITERATURE

Acohido, B., & Swartz, J. (2004). Unprotected PCs can be hijacked in minutes. USA Today,
November 29, 2004.
Ansoff, H. I. (1965). Corporate Strategy: an Analytical Approach to Business Policy for Growth
and Expansion. New-York: McGraw-Hill.
Avison, D., Jones, J., Powell, P., & Wilson, D. (2004). Using and validating the strategic
alignment model. Journal of Strategic Information Systems, 13, 223-246.
Ayres, I. (2007). Super Crunchers: How Anything can be Predicted. London: John Murray.
Bartels, A. (2000). The Difference between e-business and e-commerce. Computerworld,
October 30, 2000.
Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley
Professional.
Beck, K., & Andres, C. (2004). Extreme Programming Explained: Embrace Change (2nd ed.).
Addison-Wesley Professional.
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Grenning, J., . . .
Thomas, D. (2001). Manifesto for Agile Software Development. Retrieved april 21,
2008, from www.agilemanifesto.org.
Boehm, B. W. (1988). A Spiral Model of Software Development and Enhancement. Computer,
21(5), 61-71.
Bowman, C. (1998). Strategy in Practice. Harlow: Pearson Education Limited.
CapGemini. (2006). Architecture and the Integrated Architecture Framework. Retrieved
October 1, 2007, from www.capgemini.com:
http://www.capgemini.com/services/soa/ent_architecture/iaf/
Carr, N. G. (2003). IT Doesn't Matter. Harvard Business Review, May 2003, 41-49.
Chan, Y. E. (2002, June). Why haven't we mastered alignment? The importance of the
informal organizational structure. MIS Quarterly Executive, 1(2), 97-112.
Chen, P. P. (1976). The Entity-Relationship Model: Toward a Unified View of Data. ACM
Transactions on Databases, 1(1), 9-36.
Ciborra, C. (1991). From thinking to tinkering: The grassroots of strategic information
systems. Proceedings of the Twelfth International Conference on Information
Systems, (pp. 283-291). New-York.
CMMI Product Team. (2010). CMMI for Services, Version 1.3. Sofware Engineering Institute.
CSC Computer Sciences Corporation. (2000). CSC Catalyst overview. Computer Sciences
Corporation.
CSC Index. (1993). Building the New Information Infrastructure. CSC Index.
Cumps, B. (2007). Business-ICT Alignment: Practices and Determinants. PhD Report,
Katholieke Universiteit Leuven.

89
Dedene, G., Viaene, S., Cumps, B., & de Backer, M. (2004). An ABC-Based Approach for
Operational Business-ICT Alignment. Sprouts: Working Papers on Information
Systems, 4(19).
Department of Defense. (2007a). DOD Architecture Framework version 1.5, volume I:
Definitions and Guidelines. DOD.
Department of Defense. (2007b). DOD Architecture Framework version 1.5, Volume II:
Product Descriptions. DOD.
Department of Defense. (2007c). DOD Architecture Framework version 1.5, Volume III:
Architecture Data Description. DOD.
Department of Treasury Chief Information Officer Council. (2000). Treasury Enterprise
Architecture Framework. Department of Treasury Chief Information Officer.
DSDM Consortium. (2003). DSDM V4.2: Framework for Business Centered Development.
DSDM Consortium.
Evernden, R. (1996). The Information Framework. IBM Systems Journal, 35(1), 37-68.
Federal Chief Information Officer Council. (1999). Federal Enterprise Architecture
Framework (FEAF), version 1.1. Federal Chief Information Officer.
Goodall, G. (2008). TCO: What's Old is New. Processor, 30(12), 24.
Gurney, K. (1997). An Introduction to Neural Networks. UCL Press.
Han, J., & Kamber, M. (2001). Data Mining: Concepts and Techniques. Academic Press.
Heene, A., Vanhaverbeke, J., & Vermeylen, S. (2008). Praktijkboek Strategie. LannooCampus.
Henderson, J. C., & Venkatraman, N. (1993). Strategic Leveraging Information Technology
for Transforming Organizations. IBM Systems Journal, 32(1), 472-484.
Holmevik, J. M. (1994). Compiling SIMULA: A Historical Study of Technological Genesis.
Annals of the History of Computing, 16(4), 25-37.
IEEE. (2007). Recommended Practice for Architectural Description of Software-intensive
Systems. ANSI/IEEE (ANSI/IEEE 1471 ISO/IEC 42010 Standard).
IFIP-IFAC Task Force on Architectures for Enterprise Integration. (1999). GERAM:
Generalised Enterprise Reference Architecture and Methodology. IFIP.
Inmon, W. H. (2002). Building the Data Warehouse. Wiley Publishing.
ISACA. (2012). COBIT 5, a business framework for the governance and management of
enterprise IT. ISACA.
ISACA. (2012a). COBIT 5: A Business Framework for the Governance and Management of
Enterprise IT. Rolling Meadows: ISACA.
ISACA. (2012b). COBIT 5: Enabling Processes. Rolling Meadows: ISACA.
ISO/FDIS. (2000). ISO/FDIS 15704:2000 Industrual automation systems — Requirements for
enterprise-reference architectures and methodologies. ISO.
ISO/IEC. (2005). Information Technology — Service management — Part 2: Code of practice.
ISO/IEC.
ISO/IEC. (2008). Corporate Governance of Information Technology. ISO/IEC 38500:2008
standaard.
ISO/IEC. (2009). Information Technology — Service management — Part 3: Guidance on
scope definition and applicability of ISO/IEC 20000-1. ISO/IEC.
ISO/IEC. (2010). ISO/IEC 20000-4:2010 Information technology -- Service management --
Part 4: Process reference model.

90
ISO/IEC. (2010a). Information technology — Service management — Part 4: Process
reference model. ISO/IEC.
ISO/IEC. (2010b). Information technology — Service management — Part 5: Examplar
implementation plan for ISO/IEC 20000-1. ISO/IEC.
ISO/IEC. (2011). Information Technology — Service Management — Part 1: Service
management system requirements. ISO/IEC.
ISO/IEC. (2011). ISO/IEC 20000-1:2011 Information technology -- Service management --
Part 1: Service management system requirements. ISO/IEC.
ISO/IEC. (2012). ISO/IEC 20000-2:2012 Information technology -- Service management --
Part 2: Guidance on the application of service management systems.
ISO/IEC. (2012). ISO/IEC 20000-3:2012 Information technology -- Service management --
Part 3: Guidance on scope definition and applicability of ISO/IEC 20000-1.
ISO/IEC. (2013). ISO/IEC 20000-5:2013 Information technology -- Service management --
Part 5: Exemplar implementation plan for ISO/IEC 20000-1.
ISO/IEC. (2015). ISO/IEC 20000-10:2015 Information technology -- Service management --
Part 10: Concepts and terminology.
ISO/IEC. (2015). ISO/IEC 20000-11:2015 Information technology -- Service management --
Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and service
management frameworks: ITIL®.
ISO/IEC. (2015). ISO/IEC 20000-9:2015 Information technology -- Service management --
Part 9: Guidance on the application of ISO/IEC 20000-1 to cloud services.
ISO/IEC. (2016). ISO/IEC 20000-12:2016 Information technology -- Service management --
Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service
management frameworks: CMMI-SVC.
ITGI. (2008). Aligning COBIT 4.1, ITIL V3 and ISO/IEC 27002 for Business benefit. IT
Governance Institute.
ITGI. (2008). COBIT Mapping: Mapping of ITIL V3 with COBIT 4.1. IT Governance Institute.
Iyer, B., & Gottlieb, R. (1996). The Four-Domain Architecture: An Approach to Support
Enterprise Architecture Design. IBM Systems Journal, 43(3), 587-597.
Jacobson, I., Booch, G., & Rumbaugh, J. (1999). The Unified Software Development Process.
Addison Wesley Professional.
Kaplan, R. S., & Noeton, D. P. (1996). The balanced scorecard: translating strategy into action.
Harvard Business School Press.
Kearns, G. S., & Lederer, A. L. (2000). The effect of strategic alignment on the use of IS-based
resources for competitive advantage. Journal of Strategic Information Systems, 9,
265-293.
Kruchten, P. (2003). The Rational Unified Process: An Introduction (3rd ed.). Addison Wesley
Professional.
Lambert, D. M. (2008). Supply Chain Management: Processes, Partnerships, Performance (3rd
ed.). Sarasota, FL.: Supply Chain Management Institute.
Laudon, K. C., & Laudon, J. P. (2006). Management Information Systems: Managing the Digital
Firm (10th ed.). Pearson Prentice Hall.
Leuf, B., & Cunningham, W. (2001). The Wiki Way: Quick Collaboration on the Web. Addison-
Wesley Longmann.

91
Luftman, J. (2000). Assessing business-IT alignment maturity. Communications of AIS,
4(Article 14).
Luftman, J. (2003). Assessing IT/Buisiness Alignment. Information Systems Management,
20(4), 9-15.
Maes, R. (1999). A Generic Framework for Information Management. PrimaVera Working
Paper, Universiteit van Amsterdam.
Maes, R. (2007). An Integrative Perspective on Information Management. PrimaVera Working
Paper 2007-09, Universiteit van Amsterdam.
Maes, R., Rijsenbrij, D., Truijens, O., & Goedvolk, H. (2000). Redefining business-IT alignment
through a unified framework. Landelijk architectuur congres, PrimaVera Working
Paper Series. Amsterdam.
Mell, P., & Grance, T. (2011). The NIST definition of Cloud Computing. National Institute of
Standards and Technology.
Minsky, M. L., & Papert, S. A. (1969). Perceptrons. Cambridge: MIT Press.
Mintzberg, H. (2000). Rise and fall of strategic planning. Financial Times Prentice Hall.
Mitchell, M. (1996). An Introduction to Genetic Algorithms. Cambridge MA: MIT Press.
Nolan, R., & McFarlan, F. W. (2005, October). Information Technology and the Board of
Directors. Harvard Business Review.
Office of Government Commerce. (2005). Managing Successful Projects with PRINCE2. The
Stationary Office.
Office of Government Commerce. (2007a). ITIL Service Strategy. Norwich: The Stationary
Office.
Office of Government Commerce. (2007b). ITIL Service Design. Norwich: The Stationary
Office.
Office of Government Commerce. (2007c). ITIL Service Transition. Norwich: The Stationary
Office.
Office of Government Commerce. (2007d). ITIL Service Operation. Norwich: The Stationary
Office.
Office of Government Commerce. (2007e). ITIL Continual Service Improvement. Norwich:
The Stationary Office.
Olson, E. (2006). Strategic planning for dummies. For Dummies.
Porter, M. (1980). Competitive Strategy: Techniques for analyzing industries and competitors.
The Free Press.
Porter, M. (1985). Competitive Advantage: Creating and Sustaining Superior Performance.
New-York: Free Press.
Reigh, B. H., & Benbasat, I. (1996, March). Measuring the linkage between business and
information technology objectives. MIS Quarterly, 55-81.
Ross, J., Weill, P., & Robertson, D. C. (2006). Enterprise architecture as a strategy: creating a
foundation for business execution. Boston, Massachusets: Harvard Business School
Press.
Ross, J., Weill, P., & Robertson, D. C. (2006). Enterprise architecture as strategy. Harvard
Business School Press.
Royce, W. W. (1970). Managing the Development of Large Software Systems. Proceedings,
IEEE WESCON, August 1970, 1-9.

92
Schekkerman, J. (2006). Extended Enterprise Architecture Framework Essentials Guide.
Institute For Enterprise Architecture Developments.
Schwaber, K., & Beedle, M. (2001). Agile Software Development with Scrum. Prentice Hall.
Sogeti. (2006). DYA. Retrieved October 16, 2007, from www.dya.info: http://www.dya.info
Sowa, J. F., & Zachman, J. A. (1992). Extending and Formalizing the Framework for
Information Systems. IBM Systems Journal, 31(3), 590-616.
Spewak, S. H., & Hill, S. C. (1993). Enterprise Architecture Planning: Developing a Blueprint for
Data, Applications, and Technology. John Wiley & Sons.
Sumner, M. (2007). Enterprise Resource Planning. Amsterdam: Pearson Education Benelux.
Supply-Chain Council. (2006). Supply-Chain Operations Reference-model Version 8.0. Supply-
Chain Council.
Takabi, H., Joshi, J., & Gail-Joon Ahn. (2010). Security and Privacy Challenges in Cloud
Computing Environments. Security & Privacy, IEEE, 8(6), 24-31.
Tapscott, D., & Caston, A. (2003). Paradigm Shift, the New Promise of Information Technology.
New-York: McGraw-Hill.
The European Commission. (2010, February 12). Commission decision of 5 February 2010
on standard contractual clauses for the transfer of personal data to processors
established in third countries under Directive 95/46/EC of the European
Parliament and of the Council. Official Journal of the European Union, L39/5 - L39-
18.
The Object Management Group. (2007). OMG Unified Modeling Language (OMG UML),
Infrastructure, V2.1.2. The Object Management Group.
The Object Management Group. (2007). OMG Unified Modeling Language (OMG UML),
Superstructure, V2.1.2. The Object Management Group.
The Open Group. (2011). TOGAF version 9.1; The Open Group Architecture Framework
(TOGAF). The Open Group.
The Open Group. (2015). The Open Group IT4IT Reference Architecture, Version 2.0. The Open
Group.
The Open Group. (2017). ArchiMate 3.0.1 Specification. The Open Group.
Treacy, M., & Wiersema, F. (1995). The discipline of market leaders. Reading: Addison-
Wesley.
Van Grembergen, W., & De Haes, S. (2009). Enterprise governance of information technology.
Springer.
Van Grembergen, W., & De Haes, S. (2009). Enterprise Governance of Information Technology.
Springer Science+Business Media.
Van Grembergen, W., De Haes, S., & Van Brempt, H. (2007). How does the business drive IT?
Identifying, prioritizing and linking business and IT goals. Information Systems
Control, 6.
Weill, P., & Aral, S. (2004). Managing the IT Portfolio: Returns from the different IT asset
classes. CISR Research Briefing, IV(1A).
Weill, P., & Broadbent, M. (1998). Leveraging the new infrastructure: how market leaders
capitalize on information technology. Boston: Harvard Business School Press.
Weill, P., & Ross, J. W. (2004). IT Governance. Boston: Harvard Business School Press.
Wijegunaratne, I., & Fernandez, G. (1998). Distributed applications engineering. London:
Springer.

93
Wijegunaratne, I., Fernandez, G., & Valtoudis, J. (2000). A federated architecture for
enterprise data integration. Proceedings of the Australian Software Engineering
Conference.
Zachman, J. A. (1987). A Framework for Information Systems Architecture. IBM Systems
Journal, 26(3), 276-292.

94
 INDEX

7-step improvement process (ITIL), 11 heterogeneous IT funding, 76

access management (ITIL), 11 homogeneous IT funding, 76
administration, 6, 56 IBM, 52
availability, 5, 52 incident, 57
availability management (ITIL), 9 incident management (ITIL), 11
battery, 55 information security management (ITIL),
business relationship management, 8 9
capability level, 21 intervention, 57
capacity, 6, 55 ISO/IEC 20000, 12
capacity management (ITIL), 9 IT funding, 76
change evaluation (ITIL), 10 IT portfolio management, 75
change management (ITIL), 10 IT service continuity management (ITIL),
Charge-out, 76 9
cluster, 52 IT value chain, 14
CMMI-SVC, 19 IT4IT reference architecture, 16
COBIT, 17, 18 IT4IT reference architecture model, 17
compliance, 5 ITIL, 7, 17, 18
conceptual service model, 14 knowledge management (ITIL), 10
concern, 5 lead time, 56
configuration management (ITIL), 10 life cycle, 8
continual service improvement (ITIL), 11 logical service model, 15
Corporate overhead, 76 maintainability, 6
cost of computer processing, 28 maturity level, 21
CSI. See continual service improvement money cash flow, 31
current cash flow, 31 Moore’s law, 29
customer service request, 23 nominal cash flow, 31
dark fiber, 53 outsourcing, 26
data flow, 17 parity block, 54
data object, 17 percentile, 56
demand management (ITIL), 8 performance, 6, 55
deployment management (ITIL), 10 printing, 56
design coordination, 9 problem, 57
DevOps, 15 problem management (ITIL), 11
disaster recovery, 55 RAID. See redundant array of
disk mirroring, 53 inexpensive/independent disks
disk storage, 52 RAID-1, 53
economies of scale, 25 RAID-5, 54
event management (ITIL), 11 real cash flow, 31
financial management (ITIL), 8 real interest rate, 31
functional component, 16 Redundant Array of
generator, 55 Inexpensive/Independent Disks, 52
Grosch’s law, 25

95
release and deployment management
(ITIL), 10
reliability, 5
remote mirroring, 53
request fulfillment (ITIL), 11
request fulfilment, 56
response time, 56
scalability, 6, 25
Scrum, 15
security, 6
service asset and configuration
management (ITIL), 10
service catalog management (ITIL), 9
service design (ITIL), 8
service desk, 10
service level, 5, 9
service level agreement, 9
service level management (ITIL), 9
service operation (ITIL), 10
service portfolio management (ITIL), 8
service request, 11
service strategy (ITIL), 8
96
service transition (ITIL), 9
service validation and testing (ITIL), 10
single point of failure, 52
SPOF. See single point of failure
stakeholder, 5
storage, 56
striping, 54
supplier management (ITIL), 9
support, 6, 56
system of engagement integration, 17
system of insight integration, 17
system of record integration, 17
transition planning and support (ITIL),
10
uninterruptible power supply, 55
UPS. See uninterruptible power supply
usability, 6
user friendliness, 6
value stream, 14, 16
virtualization, 52
VMWare, 52