SI-710 IT Management

Professors: Eng. Ronald Mejía Tarazona

Eng. Julio Quispe Tuesta
AGENDA

2
Major IT Services Failures

3
 Change control

Main office Branch 3

yesBranch 2
Branch 1
C company x
Bank A
1ch voice LAN
1ch voice 1ch voice
Cisco Branch 4
1750
128Kbps
LAN Cisco
Cisco 1 BRI 1750 1 BRI
1ch voice
1 BRI 1750 64Kbps Cisco
LAN
DigiRed 64Kbps
CAR GOLD: 16 Kbps
SILVER CAR: 48
64Kbps 1750
CAR GOLD: 16 Kbps
CAR GOLD: 16 Kbps Kbps
SILVER CAR: 48
SILVER CAR: 48 Kbps 1 BRI
Kbps
128Kbps
PBX LAN
64Kbps
RS232 CAR GOLD: 16 Kbps
SILVER CAR: 48
Kbps
30Ch voice
2Mbps
CAR GOLD: 512
Kbps Branch 5
SILVER CAR: 1554
Kbps

Cisco
converter
vpn-ip 2ch voice
Cisco
3640
4 LBW 1750
Optical Mux 128Kbps
16X2 1 BRI
CAR GOLD: 32 Kbps
CAR SILVER: 96 LAN
SWITCH 128Kbps Kbps

CATALYST 512Kbps CAR GOLD: 32 Kbps 128Kbps

CAR SILVER: 96
4006 Kbps
INTERNET CAR GOLD: 32 Kbps
SWITCH
CAR SILVER: 96 2Mbps
Kbps
CAR GOLD: 512 ATM
Kbps
Cisco SILVER CAR: 1024
2620 LAN
Kbps

firewall 2ch voice LAN mux 30Ch

Cisco converter Cisco
PIX 2ch voice Optical voice
1 BRI 1750 Cisco 4x2 1 3640
525
1 BRI 1750 BRI
Inter-LAN
64Kbps
TACNA
64Kbps
Apeseg TRUJILLO Lead Agency PBX

4
 Situations to consider
• A large trading company is going to implement a new version of the SAP ERP
software that manages its operations (approx. 2000 users)

• An important bank must build and implement a fix for a bug in a critical customer
service application. (4,900 users service 24 x 7)

• An insurance company is going to renew the internet security infrastructure:

firewalls, IDP's, etc. (1,700 users service 24 x 7)

• A telecommunications company must implement changes in its Sales application

to attend regulatory requirements. (2,000,000 subscribers, billing processes and
customer service 24 x 7)

• A department store is going to upgrade OS Windows 7 to Windows 11 for their

2,800 workstations nationwide.

What activities should we consider?

5
Situations to consider

what is a change?

why do we make a change?

What consequences a change implies?

How should we control a change?

What activities should we consider?

6
 Change control

• To implement solutions to problems, improvement of services, provide better

capacities (services), regulatory obligations, etc. The requirements for changes
are more and more numerous.

• Most IT service quality problems are caused by changes to some

component of the service. This can translate into high costs and risks
for the business.

• Each change in a component of an IT service implies a risk that

requires the adoption of an effective practice to manage them. You
must balance the need to execute changes that add value VS the need to
protect customers and users from the adverse effects that a change could have.

• The agility and speed required in IT operations should not become an obstacle.

• The scope is determined by the organization. Examples: IT infrastructure,

applications, processes, documentation, suppliers relationships, etc.

7
Change control

• Change: addition, modification or removal of any component that may have a

direct or indirect effect on the service.

• The change control purpose is to maximize the number of successful

product or service changes by ensuring that risks are properly addressed,
authorizing execution, and managing a change schedule.
 Change Control in Production environments

DEVELOPMENT TESTING PRODUCTION

- HW - HW - HW
- SW - SW - SW
- Applications - Applications - Applications
- Data - Data - Data

Development Teams QA Teams Customers and Users

X X
Segregation of
environments CHANGE
Register RFC -- Change Authority-- EVALUATE AND APROVE---
GO INTO
PRODUCTION

9
 Change control

• An effective change control practice should ensure:

 Each change must be evaluated by a person in charge who properly understands
the risks and expected benefits of the change.
 Each change must be approved prior to its execution.
 The evaluation and approval of the change must not cause an unnecessary delay in
said management.

• The person or group of people who is responsable to authorize the change is:
The Change Authority. This can be a team, supervisor, manager, CEO, board,
customer or regulator depending on the nature of the change as well as the
organizational approach and culture.

• The change applies for various types in terms of scope, risk, complexity, etc. It
is essential to assign adequate change authority to each type of change, to
ensure that control is effective and efficient.

• In organizations that require high speed in their operations, it is usual to

decentralize the approval of changes.

10
 Type of changes
Standard Change
• Examples: replacement of a
PC, installation of an MS
Project on a laptop, monthly
data upload to a system, etc.
• low risk
• Routine and duly documented
changes.
• They do not require additional
evaluation, they are managed with
pre-authorizations already
established.
• It only requires evaluation and
authorization when a new standard
change is managed or modified.
Regular change.
• Examples: update Database SW
version, network switch replacement,
program update due to error (patch).
• They need to be evaluated, authorized and
scheduled according to a process pre-set.
• The Change Models must be established
based on the type of change to establish the
roles for evaluation and authorization.
• For low-risk changes, the change authority
must be able to make quick decisions, even
handling automated tools.
• For major changes the change authority may
become a committee or equivalent. These
changes must be initiated with a change
request (Request for Change RFC), either
manually or automatically through
continuous deployment tools.
11
 Type of changes

emergency change
• ex: update version of Windows
Server to correct a vulnerability ,
application correction due to
critical functional error, correct
database configuration due to a Change schedule
failure. • It is used to plan changes, communicate
• It needs to be implemented as soon as them to stakeholders, allocate resources,
possible, often to resolve a major and avoid conflicts.
incident or apply a security patch.
• They are not normally included in a • It also helps after the execution of the
change schedule but must be changes, to provide information for
evaluated and approved just like Incident management, Problem
normal changes. This must be done management, planning improvement, etc.
expeditiously to ensure rapid
implementation.
• An ad-hoc change authority must be
designated to manage them. It is a
small group of senior managers, who
can properly assess the business risks
and impacts of change.

12
 The Authority of Change

Change Advisory Board Emergency Change Advisory Board

(CAB) (ECAB)

• A group of people who meet regularly • Group of people with authority to make
to approve change requests. urgent decisions.
• They must be in a position to assess
changes from a technical, functional and • It is normally a small group of senior
business needs point of view. managers, who can properly assess the
• Members: change manager, users, business risks and impacts of change.
developers, technical support and
service desk staff, service
administrators, technical consultants,
vendors, etc.
• The composition can vary and have a
regular schedule.

13
 Activities: Regular Changes

• Registration of Change (RFC), by the requestor of the change.

• Initial Evaluation and Classification: Type and Priority, by the Change Manager.
• Evaluation and Approval, by the assigned Change Authority.
• Programming
• Building
• Implementation
• Post-implementation review
• Closing.

14
 Change Control – SW for registration and control

Request for Change (RFC) … continued RFC

• Form or screen that records the details · Version to implement
of a change to a component of a · Date of implementation
service. Detail:
· Location of the implementation plan
· Unique identifier
· Data of the people who will implement
· Description and identification of the
the change
CI’s change objects.
· Change reversal plan (back-out plan)
· Reasons for the change.
· Current change implementation date
· Consequences of not implementing it.
· Review date post-implementation (PIR)
· CI version to be changed.
· PIR results,
· Name and contact information of the
applicant for the change · Risk assessment and management
· Proposed date for the change · Impact on business continuity and
contingency plans.
· Change Priority
· RFC status: entered, evaluated,
· Evaluation of impact and resources
approved, rejected, closed, etc.
required for the change
· Evaluator Recommendations
· Record of approval, including date and
time.
15
Management information metrics and reports

Statistical reports of changes should be issued regularly in order to identify

opportunities for improvement. Report examples:

· Number of changes per period, per CI type, per configuration type, etc.
· Summary of Changes by Reason for Change (Incidents, Problems, Service
Requests, Enhancements, etc.)
· Number of successful changes
· Number of changes rolled back, including the reason: bad evaluation, build,
testing, etc.
· Amount of RFC's, including growth/decrease trend.
· Number of implemented and verified changes. Pending review.
· Incidence of changes by CI: can reveal defects in the CI, needs of users, etc.
· Amount of RFC’s rejected.
· Pending changes, classified by CI.

16
 Change control

• Contribution of Change Control with the service value chain:

o Plan: changes need to be controlled, this practice is used for that.
o Improve: improving services requires implementing changes, which must be evaluated
and authorized.
o Engage: clients and users may need to be consulted about the changes to be made.
o Design and transition: changes can be initiated by creating or modifying services.
o Obtain/build: changes to a component of a service must be controlled.
o Deliver and support: the changes can impact the delivery and support and must be
informed to those responsible for this and even include them in the approval of the
changes.
 Service Configuration

Main office Branch 3

yesBranch 2
Branch 1
C company x
Bank A
1ch voice LAN
1ch voice 1ch voice
Cisco Branch 4
1750
128Kbps
LAN Cisco
Cisco 1 BRI 1750 1 BRI
1ch voice
1 BRI 1750 64Kbps Cisco
LAN
DigiRed 64Kbps
CAR GOLD: 16 Kbps
SILVER CAR: 48
64Kbps 1750
CAR GOLD: 16 Kbps
CAR GOLD: 16 Kbps Kbps
SILVER CAR: 48
SILVER CAR: 48 Kbps 1 BRI
Kbps
128Kbps
PBX LAN
64Kbps
RS232 CAR GOLD: 16 Kbps
SILVER CAR: 48
Kbps
30Ch voice
2Mbps
CAR GOLD: 512
Kbps Branch 5
SILVER CAR: 1554
Kbps

Cisco
converter
vpn-ip 2ch voice
Cisco
3640
4 LBW 1750
Optical Mux 128Kbps
16X2 1 BRI
CAR GOLD: 32 Kbps
CAR SILVER: 96 LAN
SWITCH 128Kbps Kbps

CATALYST 512Kbps CAR GOLD: 32 Kbps 128Kbps

CAR SILVER: 96
4006 Kbps
INTERNET CAR GOLD: 32 Kbps
SWITCH
CAR SILVER: 96 2Mbps
Kbps
CAR GOLD: 512 ATM
Kbps
Cisco SILVER CAR: 1024
2620 LAN
Kbps

firewall 2ch voice LAN mux 30Ch

Cisco converter Cisco
PIX 2ch voice Optical voice
1 BRI 1750 Cisco 4x2 1 3640
525
1 BRI 1750 BRI
Inter-LAN
64Kbps
TACNA
64Kbps
Apeseg TRUJILLO Lead Agency PBX

18
 Situations to consider

• A company may have tens or hundreds of servers, switches, routers, firewalls,

IDP's, etc, all of them with with different HW configurations.

• The computers mentioned may have several different operating systems, each
with a different version number or release.

• Various applications present a series of compatibility requirements between

products and versions of the same.

• The PC’s of a company can be thousands and have different HW and SW

configurations, prepared to meet specific needs. Example: PC’s for window
service, PC’s for SW developers, PCs for Managers, etc.

• There are plenty of information systems around the company, there can be
various office SW tools, email, etc.

19
 Situations to consider

• In the event of an incident or problem, it is essential to have reliable

information about the PC's, servers or applications involved. The same
happens when we must carry out the evaluation of changes or
improvements in their capacity.

• When making changes to the HW or SW configuration of a device, these must

be registered, in order to have reliable information always available.

• To implement a server capacity upgrade I need to know its current capacity and
details of its hardware configuration.

• To negotiate user SLA’s, I must know the implications of certain requirements

(what-if).

• If I want to improve the system architecture availability, I must know its current
configuration.

How should a company control this complex situation?

20
Service Configuration

• Configuration Item (CI):Any component that needs to be managed to deliver an

IT service.

• Service Configuration: Its purpose is to ensure that an accurate and reliable

information about the configuration of services and the CIs that support them, is
available when and where it is needed. This includes information about how CIs
are configured and the relationships between them.

• Configuration Management System (CMS): A set of tools, data, and

information used to support service configuration management.
 Service Configuration

To be efficient and effective, organizations need to have control over their IT

infrastructure and related services. Service Configuration Management
allows us to achieve the control by providing a logical model of IT
infrastructure and services, identifying, controlling, maintaining and verifying
the versions of the configuration ítems (CI) existing.

By implementing this process, you will achieve:

 Specify version, property, and status information for CI’s that are part of the
IT infrastructure.
 Describe the relationships between these CI's
 Keep up-to-date records on CI's.
 Control changes to CI's, ensuring that the proposed changes are consistent
with the objectives of those responsible for them.

22
 Service Configuration

• Collect and manage information from a

variety of CI's: HW, SW, networks,
buildings, people, suppliers,
documentation, etc. ITEM Service

• It allows the organization to understand

how a group of CI’s works together to
support an IT service: relationships,
interactions, dependencies, etc., in SAAS APP
order to create value for customers and Component Local Application Client
users.

• It is represented with a high-level view

called a service map or model. Cloud Local customer
Infrastruct LocalServ Storage device
ure er
• It is important to balance the cost of
collecting and maintaining data from
CI’s against the value that such
information provides.
I provider data center User

23
 Service Configuration

• Characteristics of the Configuration Item (CI)

 All elements of the IT infrastructure that need to be controlled.
 The CI’s have details that describe them (attributes)
 Relationships with others are described (CI’s)
 The history of changes is known
 Minimum attributes: unique identifier, encoding of its type to facilitate its
grouping, a status code that indicates its location in its life cycle.

• CMS (Configuration management System): contains all the information of the

CI's. It also includes the relationship between CI's.

• Baseline (base line): represents the configuration of a CI at a specific time. It is

used as a reference to prepare for a change and to have information for a
configuration audit or rollback of a change. Configuration management should
ensure the proper preservation of the baseline and its documentation.
Service Configuration

Configuration Management System Activities

Planning

c ID

m
Control
s
monitoring

Verification and audit

25
Service Configuration - Activities

1. Planning
· The strategy, policies, scope and objectives of the Configuration Management.
· Analysis of the current situation of IT assets and existing configurations.
· The organizational, technical and managerial context in which the activities of
the Configuration Management will be implemented.
· Existing policies for related processes, such as change management and
release management
· Interfaces with projects, suppliers, applications or support groups.
· Processes, procedures, support tools, roles and responsibilities relevant to the
activities of the settings management.
· The location of storage and libraries used to maintain hardware, software, and
documentation.
In this stage, the objectives and key success factors that the CM must achieve are defined.
For example, define what part of the IT infrastructure will be controlled by the CM.
Depending on this, relationships with Problem Management, Change Control, etc. they
will be different The impact on end user activities may also vary.

26
Service Configuration - Activities

2a. Identification of the configuration and CI's

27
Service Configuration - Activities

2a. Identification of the configuration and CI's

· The IT infrastructure needs to be broken down and its elements uniquely
identified to allow effective control, registration and reporting of data of CI’s to
the level of detail that the business requires.
· Examples of elements to be identified: services, servers, environments,
equipment, network components, PC's, mobile equipment, information
systems, base software, software licenses, telecommunications services, etc.
· A configuration structure shows the relationships and position of the CI’s in
each structure. This concept applies to infrastructure or services.
· The CI’s are identified by decomposition top-down. A CI can be part of several
CI’s different or a set of CI’s. Ex: a database system can be used by different
information systems.
· Examples of types of CI's: applications, system software, servers, mainframes,
workstations, laptops, routers, switches, etc.
· The level of detail to which they must arrive CI’s depends on the business and
service requirements. This is defined based on the availability of information,
the level of control required, and the resources and effort required to keep the
information updated in the CMS.
28
Service Configuration - Activities

2b. Identification of the configuration and CI's

29
Service Configuration - Activities

2b. Identification of the configuration and CI's

· The decomposition of configuration structures also implies the determination
of relationships between CI's. This is especially important to perform an
impact analysis before making a change. It can also be used to determine if
incidents are related or if a change has caused an incident or problem.
· Establishing the interrelationships also helps to manage the SLA's, availability,
etc.
· Examples of types of relationships betweenIC's:
A CI is part of: a switch is part of a LAN network (parent-child)
A CI is connected to: A server is connected to a LAN.
A CI uses a: A service uses a server.

30
Service Configuration - Activities

2. Identification of the configuration and CI's

· An IC's naming standard must uniquely identify it.
· Each CI must have attributes that adequately describe it.

31
Service Configuration - Activities

3. Control settings CI's

· It takes care that only the CI’s properly identified and authorized are registered
in the CMS. No CI should be added, modified, replaced or removed without
proper change control and approval documentation.
· Its processes are:
register new CI’s and their respective versions
Update the records of CI’s to changes in its status, attributes, property,
related documentation, etc.
Update the CI’s and associated records when the CI is removed or
deactivated.
Protect the integrity of configurations.

32
Service Configuration - Activities

4. Registration of the state configuration of the CI's

· It is responsible for recording current and historical data on the status of each
CI in relation to its life cycle. This allows the monitoring of changes in the state
of the CI’s throughout its useful life.

5. Configuration verification and auditing.

· It comprises a series of reviews and audits that verify the physical existence of
the CI’s and that these are correctly registered in the CMS and other controlled
libraries.

33
 Service Configuration

• Service desk contribution to the service value chain:

o Plan: Configuration management is used to plan new or changed services.
o Improve: Configuration management, Like any other aspect of service management, it must be
subject to continuous measurement and improvement. Since the value of configuration management
often comes from how it facilitates other practices, it is important to understand what use these
practices are making of configuration information, and then identify how it can be improved.
o Engage: Some stakeholders (partners and vendors, consumers, regulators, etc.) may require and
use configuration information, or provide their configuration information to the organization.
o Design and transition: Configuration management documents how assets work together to create
a service. This information is used to support many value chain activities and is updated as part of
transition activities.
o Obtain/build: Configuration records can be created during this value chain activity, describing new
or changed services and components. Sometimes the configuration record is used to create the code
or artifact that is being created.
o Deliver and support: The information about CI is essential to support restoration of service.
Configuration information is used to support incident management activities and problem
management practices.
Summary

o Improvements to our services require implementing changes. These changes

involve risks of failure.
o Change Control focuses on approve change, mitigate risk
o Operating IT services requires a large number, variety and complexity of
components (Configuration Items CI’s)
o Service configuration ensures that an accurate and reliable information about
the configuration of services and the CIs that support them, is available when
and where it is needed.
Activity 45’

o Activity 4: Implementation of a Change Control and Service

Configuration

o Please read carefully the document provided in Course Content

section from BlackBoard.
Thanks for your
attention

37