Infrastructure Management Consolidated CS Slides (Mid-Sem 1 To 6) 20220310A

Infrastructure Management
Dr. Phalachandra HL
Acknowledgements:
Significant portions of the information in the slide sets presented through the course in the class are
extracted from IT Systems Management -Rich Schiesser and other books/sources from Internet. Although
BITS Pilani SS ZG538 Infrastructure permission for use from the book was requested, there has been no response to the same. Since these were
intended only for presentation in the class room, have continued to use but would like to sincerely thank,
Pilani|Dubai|Goa|Hyderabad Management
acknowledge and reiterate that the credit/rights remain with the original authors/publishers only
1
BITS Pilani
Pilani|Dubai|Goa|Hyderabad
Introduction
Session 1
SS ZG538 Infrastructure Management BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 2
In the course
• IT Infrastructure, IT infrastructure Management, Challenges, Support needed by executives (Business Case) and then
designing and structuring the IT Organization, Process owners and responsibility of Process owners
• The need for staffing and retaining people with required skills and skill levels, the personal and business ethics or lack of it
and it’s impact in-terms of legislation and what that drives into organizations
• Evolution of the IT Systems management as customer centric services & the approach of sharing of the best practices
with ITIL
• There are 12 key processes used in IT Systems management which would be discussed as part of the course
• Availability Management • Network Management
• Performance/Tuning • Configuration Management
• Production Acceptance • Capacity Planning
• Change Management • Security
• Problem Management • Business Continuity
• Storage Management • Facilities Management
• How would you build world class processes and integrating the processes described above
15 Jan 2022 CSI/SS ZG538 Infrastructure Management 3

IT Infrastructure
What does IT infrastructure mean to you?

IT Infrastructure
Defn:
– IT infrastructure consists of equipment, systems, software and services, used in common across an organization,
that are required to develop, test, deliver, monitor, control or support IT Services to customers regardless of
mission/program/project
Different Views of IT Infrastructure

Organization and its IT Infrastructure
• IT Services and processes enable the organization in the

“creation”, “management” and “optimization of” or
“access to” Information and Business Processes using
Business and Technical expertise.
• The Services a firm is capable of providing to its

customers, suppliers, and employees is a function of its
IT infrastructure.
• IT infrastructure should support the firm’s business and

information systems strategy.
Relationship between an Organization,

Business Capabilities and its IT
Infrastructure
15 Jan 2022 SS ZG538 Infrastructure Management 6

IT Infrastructure Systems Management
Systems Management:
• Is the activity of identifying and
integrating various products and
processes in order to cost
effectively provide a stable and
responsive IT environment
• It also involves setting up of policies

for the IT environment and
providing tools and information for
the IT services management

Objectives of IT Infrastructure Systems Management
• IT Infrastructure typically consists of number of Physical devices right from

• Servers • Networks • Disk storage • Desktop computers
and other software products like Databases , which are required for running the “Applications” needed for functioning of the
Enterprise.
• This infrastructure needs to
• Provide stable (and Available) and responsive IT infrastructure
•Stability : Systems are always up and accessible as scheduled, 24x7
: Measure : % of uptime, % of Down time, MTBF and MTTR
• Responsiveness : How quickly the jobs can be processed and completed
: Throughput, Avg TAT
• Predictable support and service costs that scales with business
• Reduction of cost of IT Management
• Increased flexibility and responsiveness to business needs (agile)
• Improved productivity and customer satisfaction
• Improved security, reliability and availability of IT infrastructure
• Ability to integrate existing technologies and add new technologies
Objectives of IT Infrastructure Systems Management
• Developing organizational capabilities to efficiently and effectively manage enterprise IT

is what ITSM is all about and is an essential component of IT transformation story
• This stable and responsive IT environment, is provided by the Infrastructure using a set of
products, services or processes
• There are 12 key processes used in IT Systems management which would be discussed
as part of the course
• Availability Management • Problem Management • Capacity Planning
• Performance/Tuning • Storage Management • Security
• Production Acceptance • Network Management • Business Continuity
• Change Management • Configuration Management • Facilities Management

IT Infrastructure
In your perspective what would you believe are the challenges towards
managing the IT Infrastructure?

IT Infrastructure Systems Management Challenges
▪ Scale ▪ OS and Configuration Diversity/Hygiene

▪ Physical Expansion ▪ Support Personnel
▪ Capacity Planning ▪ High Availability/Resiliency
▪ Diversity of an IT equipment ▪ Special H/W (trader desktops)
▪ Focus on uniform components (H/W ▪ Environment, Power saving

and S/W) ▪ Technology Obsolescence, Change and
Evolution
▪ Vendor Locking
▪ Business environment changes
▪ H/W and S/W lifecycle Management
▪ Cost
▪ Custom Solutions
▪ Deployment and OS Build
▪ Security

IT Infrastructure Management
Executive Support
IT infrastructure management will need Executive support in terms of

• IT Budget and Resources
• Contemporary data centers need significant resources as they have to handle
availability, provide online response times, support storage management, capacity
planning, change management, problem management, and disaster recovery
• Air-support
• Infrastructure support groups will need to support technical issues and requests from
a technical user community, who are more demanding
• Mindshare
• Relating to and being empathetic to the requirements and importance of a well-
implemented infrastructure

Executive Support : Business Case a means of soliciting support
• Focus of CIOs typically is towards application of cost effective technology, rather than on
the technology itself.
• A Business case is a clear and succinct cost justification for funds for IT Infrastructure
management
• An effective and thorough business case will itemize all of the associated costs of a new
system or process and compare it to the expected benefits.
• Challenge:
It is often very difficult to predict accurately the true benefits of a new system or process.
Even when the estimated benefits are reasonably accurate, its very hard to put a $ figure
for the same as some of the benefits could be qualitative rather than quantitative

IT Infrastructure
What are the important things from your perspective which you will need
to factor in when building a Business Case?

Executive Support : Building a Business Case
Steps for Developing a business case for a systems management function:

1. Setting up the current situation (Why)
2. Understanding which IT business goals are most critical to achieve the company’s Business
goals. (Alignment)
3. Determining which systems management functions are most critical to meeting the IT business
goals at that point of time. (Selection)
E.g. Focusing on scalability would be more beneficial when the provisioned capacity is crossing an
identified critical level rather than during startup when capacity is not a constraint
• Awareness that these could change over time as the goals of the company changes
4. Meeting and conferring with IT senior management to confirm and prioritize the systems
management functions to be focused on. (Validation)

Steps for Developing a business case for a systems management function (Contd.)
5. Estimating all costs associated with the implementation and maintenance of a particular function.
• Cost of software licenses • Cost of Hardware
• Procurement • Procurement
• Enhancement • Hardware upgrades
• Maintenance • Hardware maintenance
• Cost of Manpower • Office space
• Recruiting • Scheduled outages
• Training
6. Itemizing all benefits associated with the function.
• Being able to predict capacity shortages before they occur
• Reducing the frequency and duration of outages and hence the un-productive time
• Increasing productivity by improving response times
• Ensuring business continuity during disaster recovery
• Avoiding the cost of rebuilding databases and reissuing transactions
Steps for Developing a business case for an systems management function (Contd.)
7. Converting benefits to dollar savings to the extent possible.
8. Building credibility to the proposed Business case by Surveys, Soliciting testimonials from
customers of other similar companies and demonstrating real-life benefits of a product in an
actual business setting
9. Presenting the same in the Business terms as would be related by the Executive audience
with the technical knowledge supporting it

Executive Support : Presenting a Business Case
Three Universal Principles Involving Executive Support

1. Managers love alternatives.
▪ Primary responsibility of managers is to evaluate alternatives and make
a decision of an alternative for the current scenario.
▪ Presenting viable alternatives say for infrastructure decisions in terms
of products, vendors, platforms, levels of support, time of
implementations, ways of procurement, deployment etc. supports and
eases the process of decision making.
2. Managers hate surprises.
▪ Managers do not like to be blindsided by business surprises, such as
hidden costs, unpredicted delays, or unscheduled outages or
unplanned dependencies and limitations. Risks can be mitigated with
contingency plans, but surprises are not welcome.

Executive Support : Presenting a Business Case
Three Universal Principles Involving Executive Support (Contd.)

3. Managers like metrics.
▪ Metrics make decisions to be more data based and deterministic.
So metrics can be a persuasive tool for obtaining Executive
support
▪ Most CIOs depend on a small number of meaning-full
metrics which demonstrates the business value of a decision
E.g. In a banking system using no of transactions which is processed/sec (response
time)
▪ Understanding the Business environment and then developing a few meaningful
metrics which reflects the Business will help in getting executive support
▪ Sustained ongoing Executive support needs positive reinforcements like the
improvements in the Business processes over a period of time presented as charts
graphs or tables
▪ Staying informed of the strategies of Business & trends of the enterprise, and keeping
the Executives appraised on the synergistic strategies & trends of IT, will support
sustained ongoing support for the System management disciplines
BITS Pilani
Once Executive Support is obtained focus

shifts to structuring and effectively organizing
Dr. Phalachandra HL
Acknowledgements:
Significant portions of the information in the slide sets presented through the course in the
class are extracted from IT Systems Management -Rich Schiesser and other books/sources
from Internet. Although permission for use from the book was requested, there has been no
BITS Pilani response to the same. Since these were intended only for presentation in the class room, have
continued to use but would like to sincerely thank, acknowledge and reiterate that the
credit/rights remain with the original authors/publishers only
SS ZG538 Infrastructure Management 1

IT Infrastructure
Recap
▪ IT Infrastructure typically consists of number of Physical devices right from Servers, Disk
storage, Databases, Networks, Desktop computers and other software products which are
required for running the “Applications” needed for the functioning of the Enterprises.
▪ These resources are orchestrated through a set of ITSM services or processes which are
built factoring in the Business and Technical context and enable the organization in the
“creation”, “management” and “optimization of” or “access to” Information and Business
Processes
▪ These IT Services and Processes are then offered by IT organizations to its customers (..all
employees and stakeholders in the organization) for supporting and furthering the
Business of the organization
▪ Building these ITSM processes and keeping it effectively operational will need significant
resources which will need executive support, which is obtained using a Business case.
▪ We discussed on Building a Business case in terms of Why, Alignment, selection, Validation,
Estimating the costs and Benefits, Establishing Credibility and Communicating
BITS Pilani
Once Executive Support is obtained focus shifts

to structuring and effectively organizing
Session – 1 (Continued)
Organizing the IT infrastructure for Systems Management
• Organizing an organization or a group, supports coordination of work through a structured

hierarchy and business processes. It also has the culture embedded with it.
• Organization structure can be looked at as the way in which IT organization arranges its
tasks, groups tasks to departments, defines or delegates authority, allocating people and
other resources.
• IT departments, which are responsible for the IT Infrastructure needs to be organized for
Optimal efficiencies and effectiveness of the system management processes.
• This will also typically involve a systematic review of human resources, finances, and
priorities.
• This arrangement builds in relationships between the different departments (and its
members) and assigns roles and responsibilities and authority to carry out different
activities.
• Typically there exists a leader responsible and multiple (layer’s of) subordinates.
• There are different alternative approaches/scenarios of structuring the various groups that
comprise the IT infrastructure. These could be Functional, Divisional, Matrix, Flat

• Key factors which could be considered for Designing the IT organizations

▪ Departmental Responsibilities (Work specializations and Functionality)
▪ Planning Orientation
▪ Infrastructure processes
▪ Chain of Command (reporting structure) and Span of Control (Capacity)
[Need to also consider centralization and decentralization of decision making]
• In most times, higher the position of a process/function/ group in the organization
structure, higher is its effectiveness, visibility and stature
• Organizations will and should evolve as the Business evolves
A Basic IT Organization

IT Organization with a separate Administration department - as the company evolves
▪ Billing, Invoices, Asset

Management, procurement, HR
and a few tactical
responsibilities
IT Organization with all the three groups evolving further as below

▪ Split into functions as part of
Application, Splitting of
Infrastructure to Network/Tech
services and operations, Addition of
Strategic planning to Administration

IT Organization evolving still further to Business Units, Different technical Services, Project
Management, Budgeting and HR … (combination of functional and divisional)

Designing the IT infrastructure for Systems Management
Why wo
What would you think are the Factors to Consider in

Designing IT Infrastructure organization

Factors to Consider in Designing IT Infrastructure organization

• Size of the organization
• Maturity of the organization (is it a startup or the duration of its existence)
• Understanding Specialization and division of work
• Nature of business, which may have tracking and accountability needs influencing the
Organization
• Orientation of the firm and its IT organization
• Combining Voice and Data groups

• Consider IT-wide functions like Security, Planning, Quality Assurance, Procurement, Asset
management to be with in the Infrastructure organization or to be independent of it
• Location of Departments in the Infrastructure Organizations
E.g. Location of Service Desk
• Since Service Desk is the first point of contact for users with the IT organization and will have a
lasting impression on the quality, hence positioning it higher in the Organization can increase its
effectiveness, visibility and stature Positioning.

• Location of Service Desk (Contd.)

• Some of the practices like number of rings before response, response by a
machine to a human agent, agents' attitude, time and determinateness of the
response and follow-up to closure
• The number of Service Desks (could be a factor of the Maturity of the
organization), consolidated or otherwise and how they interface with say the
support group and other peer support groups.
Service
Desk

• Location of Departments in the Infrastructure Organizations (Contd.)

Location of Database Administration
• Should this be a part of Application development group, as DB structure & design is
closely linked to Application requirements & development
or
• Should this be part of technical services infrastructure group as majority of the
activities beyond the design is with performance and tuning
or
• Combination of design being with the application design and post design as part of
services
Database
Administration

Location of Departments in the Infrastructure Organizations

Location of Network Operations
Location of Systems Management

Systems management: ~12 services like Change Management, problem Management,
configuration management, capacity management, storage management, security
management, Disaster recovery
Systems
Management

Process Owners
Why wo
What would you think should be the responsibilities and skills needed for different IT
process owners?

Responsibilities of Process Owners
Having the right process owner is one of the critical factors in the implementation of the systems
management processes. This role will need to lead
• Assembling of the cross-functional design team;
• Implementing of the agreed-upon process;
• Communication of all appropriate parties;
• Developing and maintaining the process’s documentation;
• For establishing and reporting on its metrics; and,
• Depending on the specific process involved, for administering other support tasks such as
• Chairing change review boards or
• Compiling user-workload forecasts.

Recommended Attributes for Process Owners



BITS Pilani
Lecture 2 Dr. Phalachandra H.L

Staffing and Ethics
IT Systems Management
Introduction
▪ As seen with the characteristics which were expected from a Process Owner, building an
effective robust processes, will not only need reliable technologies, but will also need
appropriately skilled people to be involved (as participants/process owners).
▪ Since having appropriate people is one of the critical success factors in developing
plans, designing processes, evaluating technologies and implementing and ensuring
smooth running of these systems management processes, there is a need for systemic
ways of considering people who would be part of these processes in terms of the right
orientation (strategic, tactical), background, capabilities and attributes as discussed earlier
▪ In this session we will continue to discuss on qualifying and quantifying the diversity of the
skills needed. We will also discuss on keeping the current staff engaged and motivated, and
look at alternate ways of staffing the teams. We will also look at some common themes
used for recruitment, choosing and retaining the staff.
▪ Since ethics of the people who are going to be part of the processes will determine the
effective institutionalization of these processes, we will also look at different ethical
perspectives and a few Case studies of corporate fraud to dwell on.
What would you think are the steps involved in Staffing in your
organization

Staffing Process typically could involve

▪ Planning – Roles, Responsibilities, Capabilities, Number of
positions, when, where and the planned how.
▪ Sourcing
▪ Selection
▪ Offering and Getting the personnel to the organization
▪ Orientation - mandatory new employee paperwork, mandatory
company wide trainings, culture, mission, vision and values, policies
and benefits, tools, procedures – typically classroom and generic
▪ Onboarding introduction to specific department, products, project,
strategically planned induction into teams, activities, trainings and
responsibilities – typically on the job and individualized
IT Systems Management : Staffing
• Staffing is the process of hiring suitable candidates according to their

knowledge and skills into the organization
• Staffing will need to be looked at from the perspective of variety (Skill set)
and depth (Skill level).
• Skill set is defined as technical familiarity or knowledge with a particular
software product, architecture or platform
• Skill level is the length of experience and depth of technical expertise
an individual has acquired and can apply to a given technology (skill)
• Staffing the IT Systems Management team with the right skill sets at the
right skill level needs a good understanding of the System Management
functions being implemented.
• A well staffed team will be motivated and excel in terms of execution
capability and cost
How would you or your organization plan for

staffing IT teams

IT Systems Management - Staffing
Identification of Skills needed
• A Skill set matrix for an environment for a set of positions can simplify the process
of identifying and quantifying the skill levels needed
Skill Set Matrix
No of Skill Level
Skill No Area of focus Platform Positions
or FTEs Intern Junior Associate Senior Lead Expert
1 Operating System HP Unix 2
Other 1
2 DBMS Oracle/Unix 1
MongoDB/Ux 2
3 Network Systems LAN 1
• Skill set matrix like the one above is very generic – more specific matrices will need
to be evolved for specific IT functions

IT Systems Management - Staffing
Sources for staffing
1. The first place to source candidates with the required skill set and skill level
would be to look inside the IT organization to see if there are any qualified
candidates (either with exact skills or with necessary technology skills)
available for redeployment.
2. Second option would be to look for infrastructure experienced candidates who

can be cross trained from within the organization (IJPs)
3. Opening up a staffing requirement and staff the positions from outside the
company (through referrals, online, recruiters, ads etc)

IT Systems Management – Staffing
Recruitment process
• Once the skills have been identified, and candidate details are sourced, selection
process will start
• Selection of the candidates could be based on the assessment of the following
characteristics. Weightage could be added based on the criticality of the attribute.

Recruitment process (Cont.)
• This could be supplemented by Chemistry, Communication skills, Personality etc

• Process followed for non external candidates would be formal Interview, with the
manager and other key staff members with different focusses and finally validated
by references
• These are supported by HR in terms of scheduling of interviews, and clarifying
C&B issues for external candidates.

What are the activities which supports retention

of people in IT teams

Retention process
Retention of the candidate could be through

▪ Creative Compensation
▪ Training and skill enhancement opportunity
▪ Currency of technology of work
▪ Support for furthering education and attending conferences
▪ Nature of the work
▪ Stability
▪ Soliciting the importance of different “C & B” choices from employees and
evolving the offerings around it
▪ Proposing progressive benefits
▪ Ensuring Employee engagement
▪ Conducive, Empathetic and Strong Management team
▪ Rotational Opportunity
▪ Career growth opportunity
IT Systems Management : Outsourcing
Many organizations also consider outsourcing some or all of their IT functions to staff
skills.
Factors to consider while outsourcing their IT environments are
• Overall cost savings or increases
• Scalability of resources
• Potential loss of control
• Total cost of maintaining an outsourcing agreement (Hidden costs)
• Credibility and experience of outsourcer
• Possible conflicts of priority
• Geographic and time-zone differences
• Language barriers
• Cultural clashes/morale of employees
• Knowledge retention
The effects of outsourcing also depends on whether all of the IT is being outsources or
part of the IT.

BITS Pilani
ETHICS
IT Systems Management : Ethics
What are the Ethics?
Are unethical practices punishable?

IT Systems Management – Ethics & its
Role
• Ethics are Moral principles or view points that governs the behavior of
people, Business or conduction of an activity
• Law involves rules for conduct of individuals and Businesses that may be
used for punishing violations
• We will briefly look at
• Principles and theories associated with Ethics
• Personal Ethics and Business ethics
• Well known breaches of ethical behavior in terms of corporate
accounting, fraud and abuse of position and where it leads to the
punishment to Senior executives
• Legislations which have come up to address and manage these
• Some of the approaches which companies have taken to mitigate these
unethical behaviors and approaches to delegate these to others

IT Systems Management – Ethics
Principles and Theories
Principles :
▪ The principle of beneficence guides the decision maker to do what is right and
good. This priority to “do good” makes an ethical perspective and possible solution
to an ethical dilemma acceptable.
▪ The principle of least Harm deals with situations in which no choice appears
beneficial
▪ The principle of Respect for Autonomy .. Focus is on self directing freedom or
allowing people to feel free to make decisions which can lead to moral
independence or autonomy to make decisions that apply to their situations without
interference from others. Autonomy is the source of all obligations.
Are there limits to autonomy?
▪ The Justice ethical principle states that decision makers should focus on actions
that are fair to those involved. Unless there are extenuating circumstances Eg?

Principles and Theories
Ethical Theories
▪ Deontological theory states that people should adhere to their obligations and
duties when engaged in decision making. This can lead to very consistent
decisions as they will be based on the individual’s set duties. Drawback to this
would be in terms of rationale of an individual’s duties.
▪ Utilitarian theories are based on one’s ability to predict the consequences of an
action. The choice that yields the greatest benefit to the most people is the one that
is ethically correct. There can be Act or Rule utilitarian types too.
▪ The Rights established by a society are protected and given the highest priority.
Rights are considered to be ethically correct and valid since a large population
endorses them.
▪ The Virtue ethical theory judges a person by his/her character rather than by an
action that may deviate from his/her normal behaviour. It takes the person’s morals,
reputation, and motivation into account when rating an unusual and irregular
behaviour that is considered unethical.
Role
Moral principles that govern a behavior or conduction of an activity can be looked at
from a Personal and Business perspective
Personal Ethics : Personal ethics are the set of values or

viewpoints, an individual uses to influence and guide his or
her personal, social or professional behavior
▪ The degree to which these values are reinforced &

strengthened from childhood is dependent on the context of the individual
Business Ethics : Business ethics are the set of values which a Business
and “Individuals when doing Business” use to influence and guide their
behavior and actions.
▪ Business ethics tends to focus on the behaviors of an individual

as it pertains to his or her work/Business environment.

Role
Contrasting Personal and Business Ethics
Breach of Personal
Category Ethics Breach of Business Ethic
Relative number of people
Few Many
impacted
Nature of relationship to people Personal or family Business or professionally

impacted oriented oriented
Type of legal offence Civil Criminal
Examples Substance abuse Embezzlement
Gambling Falsified accounting
Infidelity Tax fraud

IT Systems Management – Ethics & its Role
Some of the unethical Business practices which have been followed :

▪ Overstating revenues
▪ Understating expenses
▪ Inflating profits
▪ Underreporting liabilities
▪ Misdirecting funds
▪ Artificially inflating stock prices
▪ Overstating the value of assets
Case Studies :
1. Enron
• Energy Company in Texas, US, trading Natural Gas and was 6th largest energy company
• Although it externally showed profitability it hid its debts with questionable accounting policies,
offshore partnerships, bribery and strong-armed politics etc.
• It was considered one of the most innovative companies till 2001
• CEO and CFO were found guilty and were asked to pay around 26 million $ and was
sentenced to 45 years Jail term.
• Enron and Arthur Anderson, one of the big 5 auditing firms finally went out of Business
& its Role
Case Studies (Cont.) :
2. Equifax
• Formally known as Retail credit Company, One of the largest credit bureaus and
made reports to insurance companies when people applied for new insurance
policies including life, auto, fire and medical insurance.
• Retail Credit Company's extensive information holdings, and its willingness to sell
them to anyone, incentivizing employees for collecting negative information on
consumers, attracted criticism of the company in the 1960s and 1970s.
• Retail Credit Company to change its name to Equifax in 1975 to improve its image
• New law called Fair Credit Reporting Act came out due to the enactment of the
hearings of Retail Credit Company
3. Tyco
• Diversified manufacturing conglomerate (toys, plastics..)
• CEO and CFO guilty of stealing US$150 million because of greed and dishonesty,
falsifying business records, and violating business law
• Had to pay up US $ 205 million and were imprisoned for 8-25 years

& its Role
Case Studies (cont.):
4. WorldCom
• MCI-WorldCom (A company which was formed from the merger of WorldCom and MCI
Communication worth 37 billion$) planned for a merger with Sprint worth $129 billion
which did not get approved. MCI WorldCom borrowed significantly at inflated valuations
and diversified into non-profitable timber yachting etc.
• CEO,CFO, Director of Accounting used fraudulent accounting methods to hide its
declining financial condition, presenting a misleading picture of financial growth and
profitability.
• Arthur Anderson the external Auditing firm which was supposed to audit this failed
• WorldCom (renamed from MCI-WorldCom) with a new CEO filed for bankruptcy with ~6
billion $ debt
• CEO and other executives was convicted for fraud, conspiracy, and filing false
documents with regulators for 70million $ and 25 years in prison

Legislations for greater governance of corporations
Every country has laws (like the ones below) to place greater governance on corporations.
1. Sarbanes-Oxley Act
The Public Company Accounting Reform & Investor Protection Act of 2002 popularly known
after the law makers who sponsored it as SOX, has 11 sections which addresses things like
▪ Creation of a Public Company Accounting Oversight Board (PCAOB)
▪ Stronger penalties for fraud
▪ Public companies cannot make loans to management
▪ Report more information to the public
▪ Maintain stronger independence from external auditors
▪ Report on and have audited financial reporting controls
▪ Companies to establish and maintain a set of internal procedures to ensure accurate
financial reporting. The signing officers must certify that such controls are in existence and
are being used, and within 90 days of the signing, they must certify that they have
evaluated the effectiveness of the controls
▪ Since in most companies financial reporting processes are driven by IT systems, and the
Chief Information Officer (CIO) is responsible for the security, accuracy, and reliability of
the systems that manage and report on financial data, they also will need to sign off on
SOX. There are variants in CSOX, PCAOB etc.
Legislations for greater governance of corporations (Contd.)
2. Graham Leach Bliley Act

The Graham-Leach-Bliley Act, also known as the Financial Modernization Act,
regulates the sharing of personal information about individuals who are doing
business with financial institutions.
• The law requires financial companies to inform their customers about the
company’s privacy policies and practices, especially as it relates to non-public
information (NPI). Based on these policies and practices, customers can then
decide whether or not they want to do business with the company.
• NPI stands for non-public information and pertains to the private, personal
information of an individual not readily available in public records. Customers
typically disclose such information to private or public companies to transact
business. Examples of NPI are social security numbers, unlisted telephone
numbers, and credit card account numbers
▪ This law provides an option to the consumers to opt-out from sharing the NPI
with any other organization.

Legislations for greater governance of corporations (Contd.)
3. California Senate Bill 1386.

▪ This requires that any business, individual, or state agency conducting
business in the state of California disclose any breaches of security of
computerized NPI to all individuals with whom they conduct business
▪ This puts emphasis on security processes used by IT to ensure the
likelihood of such a breach is kept to an absolute minimum.
▪ This also means information systems must be readily able to contact all
customers on a moment’s notice should even a single compromise of NPI
occur.
E.g. If a bank (happened with Wells Fargo Bank in 2003) , for example,
unintentionally discloses a customer’s credit card number, the bank must
disclose to all of its customers the nature of the security breach, how it
happened, the extent of exposure, and what is being done to prevent its
reoccurrence.

IT Systems Management :
Compliance and Outsourcing
Effects of Compliance on Outsourcing :

▪ Outsourcing is also being used to mitigate the increased
accountability of corporate executives and their IT reporting systems.
▪ Most outsourcers now add in compliance as a pre-requisite to
outsource
▪ Its beneficial to maintain high ethical standards and gain long term
benefits than to look for short term gains and long-term losses

Session 3
Dr. Phalachandra HL
Acknowledgements:
Significant portions of the information in the slide sets presented through the course in the
class are extracted from IT Systems Management -Rich Schiesser and other books/sources
from Internet. Although permission for use from the book was requested, there has been no
BITS Pilani response to the same. Since these were intended only for presentation in the class room, have
continued to use but would like to sincerely thank, acknowledge and reiterate that the

Recap
• IT infrastructure includes all of
▪ Physical devices and software required to operate enterprise
▪ Some of the commonly looked at resource components of the IT environment are Servers,
Disk Storage, DBs, Networks and Desktop environments
• IT Infrastructure Systems Management is about how an IT organization manages IT services (for
its customers) and provides a stable and responsive IT environment which supports or furthers
the Business of the organization. This would mean looking at a group of products and processes
which interact with each other to bring stability and responsiveness to an IT environment.
• The objectives of an IT infrastructure Systems Management would be to support Availability,
Responsiveness, Cost reduction, Scaling, Security etc.
• ITSM would need support from executives in-terms of IT budget, resources, mindshare etc.
Support obtained through business case and then structuring the organization well, and
positioning the processes in the organization for efficient and effective execution

Recap
• One of the critical success factors for ITSM are also people. These could be in terms of
process owners and the people who form the process teams.
• We discussed on mechanisms which are typically used for getting the people who
have the right skills and skill level.
• These people could have different personal and Business ethics which could breach
the commonly accepted values and behaviors leading to corporate frauds and abuse
like the Enron, Tyco etc. globally and like Satyam in India, and looked at the
legislations (like Sarbanes-Oxley Act) which have come into being to address some
of these.
• We also looked at how this has a relationship to IT executive behaviors

BITS Pilani
ITIL
(Information Technology Infrastructure Library)
ITSM Frameworks :
• There are number of ITSM frameworks which businesses can use. Some of the frameworks are targeted
at specific industries or business needs e.g. telecommunications.
• Some of the popular frameworks are
• ITIL (ITIL V4) - a framework of best practices for delivering IT services
• Business Process Framework (eTOM): a framework designed for telecommunications service

providers
• COBIT (Control Objectives for information and Related Technologies): an IT governance framework
• FitSM: a simplified, streamlined service management framework typically aligned with ISO/IEC 20000
• ISO/IEC 20000: considered the international standard for IT service management and delivery

ITIL:
• ITIL is a framework and is a set of IT service management (ITSM) best practices that
focuses on aligning IT services with the needs of business and also provides
approaches which have worked on some scenarios, for selection, planning, delivery,
maintenance and overall lifecycle of IT services within a Business
• It helps businesses manage risk, strengthen customer relations, establish cost-

effective practices, and build a stable IT environment that allows for growth, scale
and change.
• ITIL described best practices are not organization-specific or technology-specific, and

can be applied by any organization looking to use IT Services.
• It allows the organization to establish a baseline from which it can plan, implement,
and measure. It is used to demonstrate compliance and to measure improvement.
• It is a public domain framework for practitioners

Quality Approach and Standards
• ITIL constitutes practical approaches for quality management of IT services and

infrastructure processes, with focus on automating processes, improving service
management and integrating the IT department into the business. Some of these are
▪ Best practice guidance: it is a methodology of what works in actual practice derived

from what practitioners around the world have indicated as it truly works
▪ Non-Proprietary: ITIL is not a single vendor view of IT processes and you don’t have to
pay to apply it in your organization
▪ Comprehensive: ITIL captures all of the essential service support and services delivery
processes, and integrates them to work together. E.g. Incident, Error, Issue, Problem,
Fault

The Origins of ITIL
• ITIL started as a process-improvement initiative in mid 1980’s in Great Britain, to improve the quality of
products and services provided by IT infrastructure, which at that time was not providing reliable and
responsive services to the bureaucracy and various agencies which were dependent on these services.
• In 1986, the British government’s Centralized Telecommunications and Computing Agency (CTCA)
formally sponsored a program to promote improved management of IT services. As part of this around
40 IT experts from the public, private, and academic sectors to establish a framework of best practices
for managing the IT environment. In 1989 this team came out initially with a set of 42 books that
comprised first version of ITIL
• 1995, the total number of ITIL books had grown to >60 volume and had become unwieldy.
• In 2000 a more condensed ITIL Version 2 came in. This reduced the list of available books to ~7 in
which Service Support and Service Delivery were the most prominent.
• In 2007 ITIL V3 consisting of 26 processes and functions were grouped into 5 volumes around the
concept of a Service Lifecycle.
• In 2019 ITIL V4 came in which focusses on business and technology while working with Agile, DevOps
and digital transformation.

ITIL V3 - Service Lifecycle
• Service life cycle management (SLM) refers to a strategy that supports service organizations
in examining the service opportunities proactively as a life cycle instead of a solitary event or
set of discrete events.
• Then for each of the phases in the Lifecycle, it provides best practice guidance as a set of
processes which can be followed for IT Service Management.
These sites have a lot of description of these concepts

https://www.greycampus.com/opencampus/itil-foundation/
https://wiki.en.it-processmaps.com/index.php/ITIL_Processes
https://www.cio.com/article/2439501/infrastructure-it-
infrastructure-library-itil-definition-and-solutions.html

ITIL V3 - Service Lifecycle
▪ Service strategy: Understand organizational objectives & customer needs and provides strategic guidance
for investments in services. Includes service value definition, business-case development, service assets,
market analysis, and service provider types
Processes involved : Strategy Mgmt, Portfolio Mgmt ..
▪ Service design: Involves turning the service strategy into a plan for
delivering the business objectives, technology service
delivery
Processes involved : Service Level Mgmt, Availability Mgmt
▪ Service transition: Developing and improving capabilities for
introducing new services into supported environments. It
relates to the delivery of services required by a business into
live/operational use and encompasses the "project" side of IT
Processes involved : Transition Planning & Support, Change Mgmt
▪ Service operation: Involves managing services in supported environments. Aims to provide best practice
for achieving the delivery of agreed levels of services both to end-users and the customers.
Processes involved: incident mgmt., Ops management, Service management, Service desks etc.
▪ Continual service improvement: Includes incremental and large-scale improvements to services

ITIL V4 –Holistic Service Management
▪ ITIL V4 looks to facilitate value to customers and stakeholders by holistically looking at service
management along the four dimensions of
▪Organizations and people: An organization needs a culture that supports its objectives, and the
right level of capacity and competency among its workforce.
▪Information and technology: This includes the information, knowledge and the technologies
required for the management of services.
▪Partners and suppliers: This refers to an organization’s relationships with those other
businesses that are involved in the design, deployment, delivery, support, and continual
improvement of services.
▪Value streams and processes: How the various parts of the organization work in an integrated
and coordinated way is important to enable value creation through products and services.
▪ ITIL V4 expands from processes to practices of managing IT services, by factoring in elements such
as culture, technology, information and data management to provide a holistic vision of the ways of
working.
▪ ITIL V4 includes 34 management practices as "sets of organizational resources designed for
performing work or accomplishing an objective". There is various types of guidance, such as key
terms and concepts, success factors, key activities, information objects, etc. for each of these
processes.
ITIL V4 –Holistic Service Management
▪ ITIL defines the Service Value System (SVS), built around the Service value chain, a flexible
operating model for the creation, delivery and continual improvement of services enabling
the components and activities of an organization to work together to enable value creation
▪ Service value chain defines six key activities:
1. Plan 4. Obtain/build
2. Engage 5. Deliver and support
3. Design and transition 6. Improve
They can be combined in many different sequences, thus allowing an organization to define a
number of variants of value streams, like the ITIL v3 service lifecycle.
ITIL V4 has 7 guiding principles to help adopt and adapt ITIL guidance to specific and
different needs and circumstances. illustrating the integration of the Agile, DevOps principles,
& supporting digital transformations
1. Focus on value 5. Think and work holistically
2. Start where you are 6. Keep it simple and practical
3. Progress iteratively with feedback 7. Optimize and automate
4. Collaborate and promote visibility
https://www.axelos.com/news/blogs/february-2019/from-v3-to-4-this-is-the-new-itil https://www.bmc.com/blogs/itil-service-value-chain/

IT service management :
Comparison of Infrastructure Processes
No IT Systems Management Processes Corresponding ITIL Processes

1 Availability Management Availability Management
2 Performance and Tuning (Part of Capacity Management)
3 Production Acceptance (Part of Release Management)
4 Change Management Change Management
5 Problem Management Problem Management
6 Storage Management (Not specifically covered by ITIL)
7 Network Management (Not specifically covered by ITIL)
8 Configuration Management Configuration Management
9 Capacity Management Capacity Management
10 Strategic Security Security Management
11 Business Continuity IT Service Continuity
12 Facilities Management (Not specifically covered by ITIL)

Comparison of Infrastructure Processes
No ITIL Processes IT Systems Management Processes

1 Service Desk Availability Management
2 Performance and tuning Covered under Performance and Tuning
Process
3 Incident Management Covered under Problem Management
4 Configuration Management Configuration Management
5 Change Management Change Management
6 Release Management (Covered under Production Acceptance)
7 Service Level Management (Not specifically covered here)
8 Financial Management of IT services (Not specifically covered here)
9 Capacity Management Capacity Planning
10 Availability Management Availability Management
11 IT Service Continuity Business Continuity
12 Security Management Strategic Security
Common Myths concerning the Implementation of ITIL
There are 10 Common Myths concerning ITIL implementation

1. You must implement all ITIL or no ITIL at all .. Continuous journey
2. ITIL is based on infrastructure management principles
3. ITIL applies mostly to data center operations
4. Everyone needs to be trained on ITIL fundamentals
5. Full understanding of ITIL requires purchase of library
6. ITIL processes should be implemented only one at a time
7. ITIL provides detailed templates for implementation
8. ITIL framework applies only to large shops
9. ITIL recommends tools to use for implementation

BITS Pilani
Customer Service in ITSM
Customer Service
How IT Evolved into a Service Organization
• IT Services management, having IT process groups which are structured, positioned and
staffed with the requisite skills, will need to have the focus on quality of Service it can
provide, for meeting reasonable expectations of customers
• Since IT Systems management involves people who provide services to customers
(employees within the organization), the focus for this topic is to consider customer
service and some of the best practices followed around IT Services for IT systems
management

Customer Service
How IT Evolved into a Service Organization
• IT organizations were initially (1970s) focused to provide infrastructure like machines and
systems that were bigger, faster and cheaper and keeping track of them. They were typically
looking at accounting, and evolving technologies with the focus of being IT suppliers for
different groups within the organization, and did not have specific focus on Services within
the organization.
• In 1980s industries like airlines, banking discovered how IT services affected revenue, profits
and public image. Demand for factors like high availability, responsiveness, simple and clear
answers etc. gave rise to user groups, help desks, Service Level Agreements (SLAs) and
eventually to customer service and Customer service representatives within the corporate
structure
• In 1990s demand and expectations for excellent customer
service grew to a level where lack of it could lead to demotions
terminations & outsourcing.
• Its now evolved to being service-oriented with end user
departments having SLAs with the IT team in some organizations

IT Services - Customer Service … Orientation
▪ Is there a goal which IT organizations look at as part of customer satisfaction
▪ Do IT users in an organization need to be delighted? or is it OK as long as they can

use the services offered ..
▪ If you believe users need to be satisfied and happy, say given the organizations you
are working could you share your thoughts on how you (assuming you will be
empowered) would drive the IT organization to be more customer oriented.
▪ what in your opinion would change with a satisfied and happy IT Service
consumer.
▪ What would delight you as an IT service receiver or What would make you to be
satisfied with the IT services offered by your organization
▪ Benefits of good Customer Service from ITSM perspective

Key Elements of good Customer Service
Good customer service would mean meeting and exceeding expectations of your
customers. There are four elements of achieving good customer service:
A. Identifying key customers
B. Identifying key services of key customers
C. Identifying key processes that support key services
D. Identifying key suppliers that support key processes
Key Key Key

Key Services
Customers Processes Suppliers
Reasonable Critical to Adds Provides

Expectations Customers Value High-Quality
Met Success Input

Illustrating
A. Identifying key customers
Although all company employees are customers of IT, typically a small subset of the
employee customers can represent the rest of the company employees and can be
used for evaluating Customer service and working towards effective process
improvements
The following could be used as a mechanisms/criteria for choosing the key customers
for a typical infrastructure
1. Someone whose success critically depends on the IT services provided
Identifying the groups who are most essential to the core business of the company
and/or applications which are considered mission critical for the company and the
leaders in these (heads or leads) are good candidates for key customers.

A. Identifying key customers (Contd.)
2. Someone who, when satisfied, assures your success as an organization some

positions in the organization have significant visibility and influence. If the individuals
in these positions are satisfied, then that’s a positive influence across the non-IT
organizations. These could be key customers.
3. Someone who fairly and thoroughly represents large customer organizations.
▪ Identifying representatives/leads who are high users of the services (identified by
the volume of users) within the organization can be key customers to solicit
feedback from.
4. Someone who frequently uses the services
5. Someone who constructively and objectively critiques the quality of your services
6. Someone who has significant business impact on your company as a corporation
7. Someone with whom you have mutually agreed‐upon reasonable expectations
B. Identifying Key services of key customers

Once the key customers are identified, the subsequent step from providing good customer
service would be to identify the key IT services of these key customers.
The approach towards identifying the key services (or revalidating the usage patterns of
current IT services) of these key customers would be
▪ To set up a face to face discussion/interview/meeting with the customer for understanding
their IT services needs
▪ Differentiate between the “Needs” and “Wants”
▪ Negotiating and managing a realistic expectation with them.
Steps which could be followed for this would be
1. Preparation for the face-to-face meeting by researching and understanding the Customer
environment, preparing an interview script, and preparing for potential asks. These asks
could be “needs” or “wants”.
2. Have the Interviewers trained to interact with the primary customers in terms of asking
open-ended questions, active listening and restatements/paraphrasing, effective ways to
cut off ramblers and negotiate compromise and non confrontationally agree to disagree
B. Identifying key services of key customers (Cont.)

Steps which could be followed for this would be (cont.)
3. In the interview consciously adhere to “Validate”, “Solicit” and “Negotiate”. This

would mean validating they were really the key customers, get the requirements,
negotiate the reasonable requirements to frequency and type of measurements
and eliminate unreasonable requirements through explanations, getting around
and compromises. In case of non closure, agree to disagree and move to other
matters
4. If negotiations fail, “Escalate” to the manager of the customer and attempt to

resolve it.
The result of this would be better understanding of the key services necessary for the
customers, more realistic expectations to support, more empathy towards the
challenges by the customers.

C. Identifying key Processes that Support Key Services

Once the key customers are identified along with their key IT services, the next step
would be to identifying the activities/processes that provide and support the key
services to the customers.
E.g. Legal department may need an IT service to retrieve records that have been
stored some months previously.
The activities involved with this would be
– Backing up the data
– Archiving and storing it offsite
– Retrieving it quickly for customer access.
E.g. HR department may need activity/processes for providing safeguards towards the
confidentiality and security of payroll and personnel data.

D. Identifying key Suppliers that Support Key Processes

Once the key customers are identified along with their key IT services, and the
activities that provide the support are identified, then key suppliers of these activities
would need to be identified.
Key suppliers provide direct input in terms of products or support to the key processes
E.g. In the earlier example of the Legal department needing the IT service to retrieve
records that have been archived some of the key suppliers would be
• Individuals responsible for storing the data offsite and for retrieving it back to make
it accessible for users.
E.g. In the earlier Human resources example to provide data- security process,
• Developers of the commercial software security products and the individuals

responsible for installing and administering the products would be key suppliers.

Key things to not overlook
▪ Presuming customers are satisfied because they are not complaining
▪ Presuming there are not customers
▪ More Focus of customers success in using the services and gaining business value
rather than satisfaction
▪ Measuring what you want to measure for determining customer satisfaction
▪ Presuming SLAs will solve all problems which prevent Customer satisfaction

Customer Service
Challenges in mindsets
• Stop Trying to Delight Your Customers

• Make it easy ..
• Don’t just resolve the current issue—head off the next one.
• Low effort experience
• Customer Effort Score
• Doing self-support should be as easy—or easier—than not doing self-support.

ITSM – Session 4
Dr. Phalachandra HL
Acknowledgements:
Significant portions of the information in the slide sets presented through the
course in the class are extracted from IT Systems Management -Rich Schiesser and
BITS Pilani other books/Internet. Since these were intended for presentation in the class room
for teaching, instructor resources has been requested from the publisher, but not
Pilani|Dubai|Goa|Hyderabad received yet. I would like to sincerely thank, acknowledge and reiterate that the
12 Aug 2018 SS ZG538 Infrastructure Management 1

11 Feb 2022
BITS Pilani
Availability Management
Recap - 1
• IT infrastructure includes all of Physical devices and software in an IT environment
required to operate an enterprise, like the Servers, Disk Storage, DBs, Networks and
Desktop environments
• IT Infrastructure Systems Management involves building processes which can manage
the IT Services running on these IT environment components (for its customers), and
providing a stable and responsive IT environment, which supports or furthers the
Business of the organization, while being Available, Responsive, Cost efficient, Secure,
Scalable,…
• Building and institutionalizing process would need resources, obtained by putting up a
business case to the executives. Once support for a process is obtained, these
processes being built will need to appropriately hosted within organization structure for
ensuring efficient and effective execution. People, whether process owners or
individuals playing different roles in the process and their ethics are critical for the
success of the process. We discussed on different approaches for staffing,
engagement, retention and the influence of ethics on the IT organization.
12 Feb 2022 SS ZG538 Infrastructure Management 3

Recap -2
• We discussed on ITSM best practices shared through de-facto standards like ITIL associated
with these processes.
• We discussed the ITIL V3 defined Service Life cycle with different phases as below
▪ Service strategy (Aligns the IT department to the core Business):
▪ Service design (Design of new services, as well as changes and improvements to
existing ones ):
▪ Service transition (Moving from a development phase to a operation phase):
▪ Service operation (Ensuring that the services are delivered at an agreed upon service
level):
• We also discussed the evolution of ITIL to the Service Lifecycle and the current ITIL 4.
• We also discussed on the relevance of being customer centric how the IT systems
management processes evolved to provide customer centric services, the key elements of
providing good customer services and an approach to get to good customer service.
12 Feb 2022 4
• We discussed that there were 12 key processes which we would discuss
as part of IT Systems management as part of the course
• Availability Management • Network Management
• Performance/Tuning • Configuration Management
• Production Acceptance • Capacity Planning
• Change Management • Security
• Problem Management • Business Continuity
• Storage Management • Facilities Management
• Availability Management is the first of the key Infrastructure process used
in IT Systems Management
• As part of this, we will look at how we would define & assess the current
state of availability and then look at approaches which will support or
enhance availability

What does IT infrastructure Availability mean to you?

Definition
• We can consider that a system/process when up and running, is available, and if its
not running (regardless of the reason), the system/process is not available.
• The focus for maximizing Availability would be for timely recovery from outages to
service, and methods to reduce the frequency and duration of these outages
Defn Availability:
• Availability is the probability that a system or the IT services will work as required
(may be driven by SLAs), when required, during the period when it needs to be
used for a purpose.
• Availability management process involves planning on how we are going to
prevent failures to have an impact on the IT services and hence the Businesses
and what we are going to do when things go wrong. We look at planning for
optimizing the readiness of production systems by accurately testing, measuring,
analyzing, managing and reducing outages and their impacts to those production
systems and services to meet expectations.

What would you believe are the goals of IT

Infrastructure Availability Management?

Goal of IT Infrastructure Availability Management
could be
To meet/exceed the expected/agreed/guaranteed levels of functioning of the

Services and Systems :
• In a cost-effective manner
• In a consistent manner
• In a timely manner
• Providing a single point of contact for all of the systems and processes which
have a play towards Availability
While Supporting the meeting of both the current and future availability needs
of the business
• Ensure clear and consistent understanding of the terminologies
• Proactively and reactively managing the infrastructure to support these

ITSM : Availability Management
Summarily the challenge here is to ensure

Differentiating Availability from Uptime
• Availability, is oriented towards the users (customers of an IT

Infrastructure management system), and is the assurance that,
the application system which the users need for their job, is
available to them when they need it.
• Uptime is oriented towards the Service provider (Supplier of the
IT Infrastructure management system or the IT organization) and
is the assurance or the measure of the time that the individual
components of the system which make up the IT Infrastructure
are functionally operating

Relationship between Service Availability & Component Availability
• There can be a lot of components like Datacenter facility, Server H/W components, Server
System SW components, Application S/W, Disks Subsystems HW, DB or Network HW,
Network SW, Desktop HW, Desktop SW which can potentially fail and reduce Availability
• IT Systems management folks face few dilemmas/challenges while managing Availability in
terms of
• Trading the costs of outages of components (and system) against the costs of total
redundancy
• Accountability challenges due to having multiple components corresponding to
multiple process owners
Identifying a process owner responsible for overall availability across different
components of the Datacenter would be ideal for effective Availability management
Differentiating Slow Responses from Downtime
• Downtime refers to the total inoperability of a hardware device, a

software routine, or some other critical component of a system that
results in the outage of a production application
• Slow or non-responsiveness refers to a service e.g. a transaction
taking unacceptably long periods of time for processing and returning
the response to the user (depending on the transaction)
Slow response is usually a performance and tuning problem, or a
capacity planning problem requiring specialized expertise to look at.
Typically occurs due to growth of DB, traffic on the Network, Contention
of Disk volumes, Disabling of processors etc.
Slow responses can infuriate users and frustrate infrastructure
specialists.

High Availability
High Availability:
High availability refers to the design of a production environment such that

all single points of failure are removed through redundancy, to eliminate
production outages.
This involves designing the IT Infrastructure to have virtually no downtime
Fault Tolerance:
Fault tolerance refers to a production environment in which all hardware

and software components are duplicated such that they can automatically
fail-over to their backup component in the event of a fault. This supports
High Availability

Different Approaches towards Availability Management
Proactive approach of Availability Management:

▪ Involves proactive planning, design & activities/work necessary to
ensure the new or changed services can & will deliver the agreed
levels of availability & appropriate measurements are in place.
▪ Performing risk assessment and management activities to ensure
the prevention and or recovery from service and component unavailability
Reactive approach of Availability Management:
▪ Work to ensure that current operational services and components
deliver the agreed levels of availability and to respond
appropriately when they do not
▪ Involves monitoring, measuring and investigating and analyzing
all events, incidents, service and component unavailability etc.
for availability and instigating remedial action.

Desired Traits of Availability Process Owner
IT organizations with focus on availability, should choose a single individual (could

be called availability process owner or operations manager or technical lead) to own
the overall availability process. Some of the sample characteristics of such a role
would be

Methods of Measuring Availability
1. Percentage of system availability

▪ Common approach to measure Availability which is found in SLAs (Service-
level agreements)
▪ It’s got by dividing the amount of actual time a system was available by the
total time it was scheduled to be up.
Percent Availability (Uptime) = (Hours Agreed Up - Hours Down)/Hours Agreed Up
▪ Customers started with expectations of availability in terms of percentage at

90% say for 24/7 operations and moved to …
90 99 99.9 99.99 99.999
Per Week in Hrs 16.8 1.68 0.168 0.0168 0.00168
Per Week in Secs 1008 100.8 10.08 1.008 0.1008
Per Day in Sec 144 14.4 1.44 0.144 0.0144

2. The Rolling average

In this approach instead of calculating for a week, the goal is rolled across a few
weeks period and then looked to see if it met the Availability criteria and using the
same expression
Percent Availability (Uptime) = (Hours Agreed Up - Hours Down)/Hours Agreed Up

3. Downtime
▪ Another approach is to track the quantum of downtime and hence the
Availability occurring on a daily, weekly, and monthly basis.
▪ Infrastructure personnel can pinpoint and proactively correct problem areas by
analyzing the trends, patterns, and relationships of these downtimes
▪ Infrastructure personnel can also track several of the major components like
the server environment, the disk storage environment, databases and
networks
▪ Improving levels of availability often involves capital expenditures which most
companies are reluctant to invest in unless a strong, convincing business
justification is offered like the cost of downtime below

4. Rule of Nine
▪ Significant number of service suppliers measure their availability in
percentages of uptime as the rule of 9s. If you have a working week of 100
hours or working hours of 24x7
Per Week in Hrs Per Week in Secs Per Day in Sec

90 16.8 1008 144
99 1.68 100.8 14.4
99.9 0.168 10.08 1.44
99.99 0.0168 1.008 0.144
99.999 0.00168 0.1008 0.0144
▪ This is the percentage of System Availability time but specified in 9s.

5. Approaches used by some of the cloud service providers to measure

availability
▪ Microsoft cloud services : time when the overall service is up, divided by total time.
▪ Gmail : percentage of successful interactive user requests for uptime
error rate & consecutive minutes of downtime for downtime.
▪ Amazon Web Services : error rate - average percentage of requests that result in
errors in a 5-minute interval.
▪ Recent published work also use approaches as “Windowed user-uptime”1 factoring
in user perceived availability over many windows to distinguish between many short
periods of unavailability and fewer longer periods of unavailability.

The Seven Rs of High Availability
▪ Goal of availability process owners will be to maximize the uptime of the various online systems
for which they are responsible and make them fault tolerant with minimal impact to the budget
▪ The challenges towards a 100% Available system are the Budget, Component failures, Faulty
code, Human error, Flawed design, Natural disasters, Unforeseen business shifts like mergers,
downturns, political changes
▪ There are several approaches which has been taken to maximize availability for extending
uptime, minimizing downtime, and improving the overall level of service. These are referred
to as 7 Rs
1. Redundancy
2. Reputation
3. Reliability
4. Repairability
5. Recoverability
6. Responsiveness
7. Robustness

1. Redundancy
▪ This is practiced by Manufacturers by designing this into products. E.g. Power supplies, Multiple
processors, Segmented memory, Redundant disks etc.
▪ This can also refer to entire server systems running in a hot standby mode. Infrastructure analysts can take
a similar approach by configuring disk and tape controllers, and servers with dual paths, splitting network
loads over dual lines, and providing alternate control consoles—in short, eliminate as much as possible any
single points of failure that could disrupt service availability
2. Reputation
▪ To build IT environment using products like Servers, disk storage systems, network hardware etc from
suppliers of repute. Reputation refers to the track record of key suppliers
▪ Reputation can be validated with percent of Market share, Industry analyst reports, Track record of
reliability, customer references (which can also confirm factors as cost, service, quality of the product,
training of service personnel, and trustworthiness)
3. Reliability
▪ Reliability pertains to the dependability of the components to function under the stated conditions.
▪ It depends on the process which has gone into building the same ..
▪ This can be verified from customer references and industry analysts. (cont.)

3. Reliability (Contd.)
▪ Reliability can also be verified using the empirical component reliability analysis by following the
7 steps
▪ Review and analyze problem management logs.
▪ Review and analyze supplier logs.
▪ Acquire feedback from operations personnel.
▪ Acquire feedback from support personnel.
▪ Acquire feedback from supplier repair personnel.
▪ Compare experiences with other shops.
▪ Study reports from industry analysts.
▪ An analysis of problem logs should reveal any unusual patterns of failure and should be studied by
supplier, product, using department, time and day of failures, frequency of failures, and time to repair.
▪ A common metric for reliability of components, applications or systems is the average or mean time
between failures (MTBF). This is a measure of the average length of time an entity is expected to stay
up and operational over a given period of time; this timeframe is often a year and it’s known as the
sampling interval. The formula used to compute MTBF is:
MTBF = sampling interval / # of failures during sampling interval

4. Repairability
▪ It’s a measure of how quickly and easily suppliers can fix or replace failing parts
▪ Availability could be increased by planning for increased repairability or reducing
MTTR
▪ MTTR (Mean time to Repair or Recover or Restore or Resolve) is a common metric
used to evaluate this trait and measures the average time it takes to do the actual
repair
▪ Its computed as: MTTR = sum of repair times / # of failures

5. Recoverability
▪ This refers to the ability to overcome a momentary failure in such a way that
there is no impact on end-user availability.
▪ It could be across the spectrum from a single bit error recovery to a having an
entire server system switch over to its standby system with no loss of data or
transactions.
▪ Recoverability also includes retries of attempted reads and writes out to disk or
tape, as well as the retrying of transmissions down network lines.
▪ This could also includes mechanisms of acknowledgements used to ensure
missing or non-ordered delivery of sequence of data in protocols like TCP
6. Responsiveness
▪ Its the sense of urgency all people involved with high availability need to exhibit
in terms of quickness and efficiency when needing to respond to problems
▪ This could also be how quickly automated recovery systems get triggered for
action to restore availability

7. Robustness
▪ It describes the overall design of the availability process to withstand a
variety of forces—both internal and external—that could easily disrupt and
undermine availability in a weaker environment
▪ Robustness is achieved through documentation and training to withstand
▪ Technical challenges related to Platforms, Products, Services,
Customers
▪ Personnel changes as they relate to turnover, expansion and Rotation
▪ Business changes as they relate to New direction, Acquisitions, Mergers
8. Resilience :
▪ If the system has some of the ML capabilities to learn based on patterns and
adapt to the changes

Availability Management Techniques
Techniques that have being used to understand the reason for the disruption
of availability
1. Component Failure Impact Analysis :
Component Failure Impact Analysis (CFIA) can be used to predict and evaluate
the impact on IT service arising from component failures within the technology.
The output from a CFIA can be used to identify where additional resilience
should be considered to prevent or minimize the impact of component failure to
the business operation and users
2. Single Point of Failure analysis
A Single Point of Failure (SPoF) in any component within the IT infrastructure
that has no backup or fail-over capability, has the potential to cause disruption
to the business, customers or users when it fails. It is important that no
unrecognized SPoF’s exist within the IT infrastructure design or the actual
technology, and that they are avoided wherever possible. If the system has
some of the ML capabilities to learn based on patterns and adapt to the
changes

Availability Management Techniques
Techniques that have being used to understand the reason for the disruption
of availability (Contd)
3. Fault Tree Analysis Fault Tree Analysis (FTA) :
Its a technique that can be used to determine the chain of events that causes a
disruption to IT services. FTA, in conjunction with calculation methods, can offer
detailed models of availability.
Operations can be performed on the resulting fault tree; these operations
correspond with design options

Assessing an Infrastructure’s Availability Process
• One of the simple methods which has been used to asses and evaluate the quality, efficiency
and effectiveness of the Availability processes is through a worksheet, which is filled up by
appropriate individuals in collaboration with the process owners and their managers.
• There are 10 categories or key measures or characteristics about a Process. These could be
categorized into the three objectives of Quality, Efficiency and Effectiveness
Quality Efficiency Effectiveness
1. Executive support 4. Supplier Involvement 8. Customer involvement
2. Process owner 5. Process metrics 9. Service metrics
3. Process documentation 6. Process integration 10. The training of staff
7. Streamlining/automation
• The degree to which each characteristic is put to use in designing and managing a process is
a good measure of its relative robustness

Assessing an Infrastructure’s Availability Process
Quality
• Executive support
• Process owner
• Process documentation
Efficiency
• Supplier involvement
• Process metrics
• Process integration
• Streamlining/automation
Effectiveness
• Customer involvement
• Service metrics
• The training of staff
Characteristics within each category is rated
on a scale of 1 to 4 with 1 indicating no
presence and 4 indicating a large presence
of the characteristic.

Assessing an Infrastructure’s Availability Process (Contd.)
• Since all categories are rated in the same fashion, a single column could have
been used to record the ratings of each category
• if we format separate columns for each of the four possible scores, categories
scoring the lowest and highest ratings stand out visually and quantifies areas of
strength and weakness for a given process
• This also acts as a benchmark from where future process refinements can be
quantitatively measured and compared
• The score of a particular process can be compared to those of other

infrastructure processes to determine which ones need most attention
• Many infrastructures do not attribute the same amount of importance to each of

the 10 categories within a process. This can be introduced as a refinement into
the work sheet to account for this uneven distribution of category significance by
the introduction of a weightage to each of the categories.

Assessing an Infrastructure’s Availability Process (Contd.)
• Weights are assigned to each
of the categories ranging from
1 for least important to 5 for
most important, with a default
of 3
• The weight for each category
is multiplied by its rating to
produce a final score
• An example worksheet with
weightages is as seen below
• The overall weighted
assessment score is
calculated by dividing this final
score of 90 by the Maximum
weighted score (MWS).
• Maximum weighted score
would be total weight * 4 %
Measuring and Streamlining the Availability Process
• As discussed, we can measure and streamline the availability process with the
help of the assessment worksheet
• We can measure the effectiveness of an availability process with
▪ Service metrics such as the percentage of downtime to users, dollars lost
due to outages etc
▪ Process metrics—Degree of automation, Ease and quickness with which
servers can be re-booted—help us gauge the efficiency of the process.
• We can then streamline the availability process by automating actions such as
the generation of outage tickets whenever an online system goes down (rather
than having service desk staff doing this) and by notifying users with automated
voicemails and emails (if email is up) when outages occur.

Summary of the Activities Involved
1. Understand the definitions and terminologies involved in Availability

Management
2. Understand the Availability requirements
3. Determine the metrics/measures of Availability
4. Use approaches as with the 7 Rs for building the process
5. Assessing an Infrastructure’s Availability Process
6. Using the metrics identified Identify approaches for streamlining the
Process

Discussions
In your organization what do you see as the planning and activities which
people do to ensure that new or changed services can support the expected
SLAs and what are the kinds of measures which you would use
How do you go about assessing the risk of a process ..
Can you think about what are those things in the environment which people
monitor

Discussions
What are those performance indicators which will indicate whether your
availability of key processes in your organization is supported or not
supported .. What kind of indicators would you use and what are the Key
Performance Indicators (KPIs) and CSFs (Critical Success Factors).

ITSM – Session 5
Dr. Phalachandra HL
Acknowledgements:
Significant portions of the information in the slide sets presented through the
course in the class are extracted from IT Systems Management -Rich Schiesser and
BITS Pilani other books/Internet. Since these were intended for presentation in the class room
for teaching, instructor resources has been requested from the publisher, but not
Pilani|Dubai|Goa|Hyderabad received yet. I would like to sincerely thank, acknowledge and reiterate that the
12 Aug 2018 SS ZG538 Infrastructure Management 1

BITS Pilani
Lecture 5
Performance & Tuning
SS ZG538 Infrastructure Management
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 2

Recap - 1
• IT Infrastructure Systems Management involves managing the IT Services running on the IT
infrastructure environment components like the Servers, Disk Storage, DBs, Networks and
Desktop environments, and providing a stable and responsive IT environment, which supports
or furthers the Business of the organization, while being Available, Responsive, Cost efficient,
Secure, Scalable,…
• We discussed on the support needed from executives, organization structure and positioning of
the groups which provide these management services, given that one of the KSF are people,
we discussed on approaches for staffing and retaining people with required skills and skill
levels, the personal and business ethics or lack of it and it’s impact in-terms of legislation and
what that drives into organizations
• We discussed on how the ITSM best practices are shared through de-facto standards like ITIL.
We discussed the evolution of ITIL to the current ITIL 4 and the IT Service Life cycle of Service
Strategy, Service Design, Service transition and Service operation and Continuous
Improvements.

Recap - 2
• Evolution of the IT Systems management as customer services and an approach of how to get
to good service IT in an organization by identifying the key customers of IT, the key services
used by these customers, the processes which support these Key services and the inputs to
these processes.
• Then as part of the 12 Key processes which would discuss as part of the course, we discussed
on the Availability management and the goal of managing customer expectation of the
expected/agreed/guaranteed levels of functioning of the Services and Systems in a cost-
effective, consistent and timely manner. We discussed on the definitions of the terminologies for
consistent interpretation, contrasted with High Availability, looked at how do we measure
availability, pro-activeness in Availability and the 7 Rs or approaches towards achieving High
Availability and techniques that have being used to understand the reason for the disruption of
availability and how to streamline them
• We also looked at approach towards assessing an Infrastructure’s ITSM processes and
specifically the Availability Process using worksheets in terms of quality efficiency and
effectiveness using around 10 attributes.

What would you think are the performance
characteristics from an IT infrastructure perspective

Definition (s) of Performance-Tuning
Performance & Tuning are two related activities which are normally combined into
a process. Hardware and Software Infrastructures and their relationships are
continually tuned to meet up with/Optimize for the performance goals established
or simply to improve the performance.
Defn: Performance and tuning is a methodology to Maximize throughput and
Minimize response times on all platforms for all forms of workloads like batch
jobs, online transactions, and Internet activities in a cost effective fashion
There may be other parameters like
• Space optimization.
• Resource optimization and
• Sustainability.
Which might also influence “performance and Tuning”
Incident, Availability, Capacity and Service Level Management in ITIL together
support Performance Management

Can performance bottlenecks be solved for ever by
tuning? or would you just move the performance
bottleneck to a place where there is minimal
possibility of hitting it.
Is there an example which you can share on how a

performance bottle neck was addressed by your IT
organization

Generic observations of Performance-Tuning
• Addition of new hardware is seldom the best approach of solving a performance

problem. The performance gain in most situations are temporary and sub-
optimal. Its most likely the bottleneck will be relocated to another place
• Since workloads keep changing, Performance and tuning are ongoing, highly
iterative processes and for consistent acceptable good performance, this has to
be treated and dealt in that (ongoing and iterative) manner.
• Overall planning of the type and volume of current and future workloads
(capacity planning) is essential to a robust process for performance and tuning.

Difference between Performance-Tuning and Other Processes
Performance-Tuning Other Processes
Consists primarily of two major activities Primarily consists of one major activity
Will Include Will have one focus area
• Reporting of
▪ Real-time performance monitoring
▪ periodic management trend reports (daily, weekly,
or less-frequent basis.)
• Conducting of variety of analyses, adjustments, and
changes to a whole host of parameters
Normally has multiple subprocess owners Normally has one overall process owner
Shares ownership across multiple departments Typically Centralized ownership in one department
Nature of the tasks is continuous and ongoing. Tasks have definitive start and end dates.
Performance monitoring happens all of the time. E.g. Changes are implemented, problems are
resolved, and new applications become deployed
Tuning a portion of the infrastructure environment to Seldom iterative because most of the tasks associated
correct a performance problem can be a highly iterative with them are of a one-time nature
Process tools vary widely among the resource Process tools are usually shared across departments
environment and number of tools are used e.g. Problem management system
Utilizes a large number of diversified metrics which Processes utilize a small number of similar metrics
depends on the kind of environment
Preferred Characteristics for a Performance-Tuning Process Owner
Since this could involve addressing multiple resource areas, the process owner(s) will
need to have great depth of an area and good understanding of the other areas

What would you believe can be tuned from an IT
infrastructure perspective
What would you believe can be tuned from an Cloud

IT Infrastructure perspective

Performance & Tuning of Infrastructure Areas
Performance and Tuning of Infrastructure can be looked at from the perspectives of a Server Environment,
Disk Storage Environment, Network Environment, Desk top compute environment and Databases as the
discrete components of typical IT Infrastructure.
In case of cloud Infrastructure, this could also be looked at from the perspective of managing Virtualized
physical components and managing these abstracted virtual components for performance.
This could be in terms of
– Selection of the VMs or Containers based on the workload characteristics
– Allocation policies for VM
– Redefining Network and Firewall Usages
– Implementing autoscaling of services
– Implementing some of the caching services
– Adopting architectures like micro services architecture, event driven architectures
Cont.
1. Server Environment
This refers to looking at performance tuning across all compute platforms from mainframe computers,
midrange computers, workstations to servers.
Major places in a server environment where performance bottlenecks can be seen & addressed are
a. Processors
▪ The number and power of processors influence the rate of work accomplished for processor-
oriented transactions.
▪ The extent of utilization of the processor also has a bearing on the performance. Keeping the
processor utilization (as a tunable lever) to be ~70% can lead to more optimal performance
b. Main memory and size of swap space
▪ Size of the main memory, and configuration of the main memory for swap space (part of main
memory to hold frequently used portions of programs to reduce time-consuming I/O operations)
are potential bottlenecks and levers for tuning for performance
c. Number and size of Buffers
▪ The number and size of Buffers (which are high-speed registers of main memory that store data
being staged for input or output operations) can trade off the amount of memory available for
process-oriented transactions
Cont.
1. Server Environment (Contd.)
Major places in a server environment ..(Cont.)

d. Cache
▪ Size and availability of the Cache (lower performance than main memory and used for storing
programs and data which are likely to be used immediately), in the server environment is an
additional lever for tuning for performance
e. Number and type of channels
▪ Number, type and capacity of the IO channels or the IO buses (could be FC, SCSI, SATA ..) can
effect performance and are other levers to tweak for performance of the Server environment
Metrics commonly collected in a server environment for optimizing performance include:

i. Processor utilization percentages
ii. The frequency of swapping in and out of main memory
iii. Percentage of hits and misses to the main memory cache
iv. The length and duration of processing queues
v. The percentage of utilization of channels
vi. The amount of processor overhead used to measure performance

2. Disk Storage Environment
Disk storage equipment is the next resource which can have a bearing on performance-tuning.
Disk storage environment performance can be impacted by the following
a. Cache Memory in a Disk Subsystem
▪ Significant number of disk subsystems have Cache built into them. The size of the cache, the
algorithms which are used for prefetching & flushing can have a significant impact on the
performance (Discuss in the session)
b. Volume groups
▪ Volume groups are a logical grouping of physical disk drives. The intent is to improve performance with
reduced seek-and-search times by combining frequently used groups of physical volumes into one
logical group. Data could be distributed across different physical disks which would mean more physical
paths and have them to be logically grouped for providing performance.
c. Striping
▪ Striping is a performance improvement techniques in which blocks of data that are to be read or written
sequentially are stored across multiple disks (usually across the same logical volume) to increase the
number of data paths to overcome the difference of disk write speed and data transfer rates.

2. Disk Storage Environment (Contd.)
Disk storage environment performance can be impacted by the following (Contd.)
d. Storage area networks
▪ Configuring and using the storage disk equipment into a SAN can enhance the performance.
This coupled with addition of say FC switches will enable multiple paths for the data to be
transmitted/received and hence enhancement of performance. This could increase the fan-in.
This is offset by the cost which needs to be balanced.
e. Network‐attached storage
▪ Configuring the network as a NAS could reasonably increase the performance as the disk is
directly connected to the network, but is limited by the network bandwidth
f. Extents
▪ Extents are contiguous areas of storage reserved for a file or an object in a file system,
represented as a range of block numbers. In case of amount of data needing to be written
exceeds the amount of original contiguous disk space allocated, another extent is added to it.
So instead of abnormally terminating the request, the operating system looks for additional
available space on the disk volume and extends the original contiguous space. The negative
perspective would be .. Larger the number of extents, longer the response times.

2. Disk Storage Environment (Contd.)
Disk storage environment performance can be impacted by the following (Contd.)
g. Fragmentation
▪ Extents are needed due to fragmentation of disks. Higher the fragmentation, larger the
number of extents and the other way too. Reallocating for files reducing the extents,
defragmentation are good tuning methods to improve fragmentation

3. Database Environment
▪ The physical layout of a database can greatly influence the eventual response times of inquiries or
updates.
▪ Databases in large companies can grow to hundreds of columns and millions of rows.
▪ The placement of critical files such as system, data, log, index, and rollback files within the database can
spell the difference between acceptable responses and outright lockups.
Common performance issues associated with a database environment is as below
a. Placement of table files
▪ A table file, which describes the various tables that reside within the database, is a critical
navigational map of a database that serves as its data dictionary.
▪ Since most DB requests are channeled through the table file, the placement of this file is extremely
important to delivering acceptable online performance.
▪ The optimal location for this file is in the main memory of the server where fetch times are the
quickest. However, the size of this file often prevents its being located there. In that case, as much
of it as possible should be loaded into the cache memory of the disk array when space is available.
b. Initialization parameters
▪ There can be dozens of parameters from which to select and specify initial values. Some of the
more common of these are database block size, the shared pool size for locating the data dictionary
in memory, the system global area (SGA) for selected shared table files, log buffers, and the
database block buffers for data files.
3. Database Environment (Contd.)
Common performance issues associated with a database environment (Contd.)
c. Placement of data files
▪ When accessing data on disk drives, proper placement on the volume—as well as the
volume’s placement within a volume group—influences the amount of time it takes to
complete database-access requests
d. Indexes and keys
▪ Judicious use of indexes and keys is another performance and tuning aid that can drastically
reduce table lookup times.
▪ Keys are used to identify records uniquely in a table. The indexes are lists that hold the keys
(lists of keys) along with a pointer to the remainder of the data. Searching for a particular
record is typically much quicker using an index, key, and pointer scheme because it
eliminates the need to search the entire database.
▪ Indexes also allow for multiple sorting of records within groups of tables or keys. Complex
queries with multiple constraints will be faster with this.
▪ The use of indexes and keys must be balanced with the expense of additional storage, the
overhead of processing and maintaining the indexes, and the updating and merging of keys.

Common performance issues associated with a database environment (Cont.)
e. Locks
▪ Locks protect the integrity of a record of data by making it inaccessible to
unauthorized users. Locks often are used with multi-user files and databases to
ensure multiple updates are not made simultaneously.
▪ Locks implementation needs to be carefully planned since the overuse of locks can
extend both disk space and access times
f. Balance of system resources
▪ Balancing system resources of processors memory, channel, and disk is necessary
to ensure no single resource becomes saturated or grossly under-utilized in the
quest for good performance.
▪ Monitoring the usage and proactively ensuring the balance among the devices is the
way for ensuring performance

Common performance issues associated with a database environment (Cont.)
g. Access patterns
▪ Understanding the access patterns into a database is one of the best ways to optimize an application’s
performance.
▪ Anticipating what the read and write sequences are likely to be, and to which parts of the database they will
likely occur, allows database administrators to map out the physical database in an optimal configuration.
▪ At the same time, performance specialists can configure disk-volume groups to align as closely as possible
to the expected disk-access patterns.
▪ Measuring end-to-end response times would be relevant to verify the validity of these adjustments.
h. Database fragmentation
▪ Database records are rewritten in locations that are different from their optimal starting points. This causes
data to be not optimally placed for its anticipated access pattern and the fragmentation of the data records
causing less than efficient use of the disk space.
▪ Periodic defragmentation based on the reports and statistics can help in addressing the above

4. Network Environment
Variety of factors influence the performance of a network, beginning with its overall design and
topology..
Common Network issues which can influence Performance and Tuning are
a. Bandwidth
▪ Capacity planning when not based on number of concurrent users, peak traffic workloads and an
estimation of transaction arrival pattern and types can cause bottlenecks on the quantum of data
planned for.
▪ Robust capacity plan based on network load simulation using varying workloads should address
this
b. Line speed
▪ Speed of the link or line is another parameter which can affect the network performance. There will
need to be a balancing of the speed-bandwidth to the total cost of operation and planning/Tuning
for the same which can address it.
c. Protocols
▪ This is dictated by business, programming, and application requirements. In instances where
alternatives are possible, giving consideration to potential performance impacts, especially when
running diagnostic programs such as traces and sniffers can be approaches to address the same

4. Network Environment (Contd.)
Common Network issues which can influence Performance and Tuning (Cont.)
d. Single Sign-On
▪ There is a trade-off between performance and security. The convenience and performance
savings of logging on only once instead of multiple times for access to the network, operating
system, database management system, and a particular application must be weighed against the
potential security exposures of bypassing normal password checks.
▪ Most applications have robust security features designed into them to mitigate this risk
e. Number of Retries
▪ Transmission errors and particularly transient ones occur periodically in a network. Network
Protocols have this factored in and retry for a period of time or number of retries before its flagged
as an error. This value if very large or too small can impact the performance of the network and
needs to adjusted
f. Non-Standard Interfaces and Broadcast Storms
▪ Suppliers can sometimes offer interfaces to increase the compatibility of these devices with a
network. These when working fine, can support the business need at acceptable
productivity/performance levels.
▪ They can also cause major performance problems such as locking up lines, introducing
interference, or, in extreme cases, flooding the network with nonstop transmissions called
broadcast storms when not compatible.
▪ Caution needs to be exercised with heightened awareness of network performance in these
scenarios
5. Desktop Compute Environment
Common Desktop Environment issues which can influence Performance and Tuning are
a. Processors and Memory

▪ The type and power of the processor is influenced by the applications which will be running on the desktop
environment
▪ This is also dependent on the type and how many of them (no of windows and the applications therein)
you are running concurrently.
▪ Number of applications starting and running in the background like the Updaters for OS/Apps, Anti Virus
S/W, Parental protection software, Anti-spam, Firewalls and Anti spyware can impact the performance
b. Disk storage space
▪ Having applications locally on the disk, disks with current technologies like SSD, availability of disk space
for swap etc. can have a bearing on these environments
c. Network connections
▪ The speed of the network ports, the bandwidth/speed coming in from the access points, number of users
on the switch/hub can impact the performance.
d. Diagnostic and Administrative tools
▪ Diagnostic tools if running and not initialized properly can impact performance. Similarly tools like the
inventory management, asset management etc. send/receive large amount of information and can have a
bearing on the performance of the Desktop computer environment

Assessing Performance and Tuning
Continuing with the Worksheet for
assessing the overall quality,
efficiency, and effectiveness of the
performance & tuning process.
(without weighing factor)
Quality
Executive support
Process owner
Process documentation
Efficiency
Supplier involvement
Process metrics
Process integration
Streamlining/automation
Effectiveness
Customer involvement
Service metrics
The training of staff
Characteristics within each category is
rated on a scale of 1 to 4 .
1 - 4 indicating no presence to a large
presence of the characteristic.
Assessing Performance & Tuning
Work sheet with weighing factor
Maximum Weight – 28
Maximum Rating Value - 4
Maximum Weighted Score

= Max Weight * Max Rating Value
Max Weighted Score = 28 * 4
= 112
Weighted Assessment Score

= Total Score/Max Weighted Score
= 59/112 = 0.52678 = ~0.53
= 53%

Measuring and Streamlining the
Performance and Tuning Process
▪ We can measure and streamline the performance and tuning process with the help of the
assessment worksheet
▪ We can also measure the effectiveness of a performance and tuning process with
▪ Service metrics such as response times and the number and complexity of chained
transactions.
▪ Process metrics such as the amount of overhead used to measure online performance,
the number of components measured for end-to-end response, and the cost to generate
metrics
These can help us gauge the efficiency of this process.
▪ We can streamline the performance and tuning process by automating certain actions like
▪ Load-balancing of processors, channels, logical disk volumes, or network lines
▪ Notifying analysts when performance thresholds are exceeded.

BITS Pilani
Production Acceptance Process


Definition and Terminologies
Defn: Production acceptance is the process which supports consistent and successful
deployment of application systems into a production environment, regardless of the
platform
Few key terminologies from the above definition
Consistent :
• Consistent does not necessarily mean identical across platforms
• There are essential steps of the process which needs to be done for every production
deployment and there are other steps that can be added, omitted or modified depending
on the type of platform selected for production use
Deploying into a production environment
• Process of deployment is complete only when all planned users are running on the new
system
• This could take several months for installations with large number of users
Application System
• Any group of software programs necessary for conducting company’s business
• The end-users of these applications are primarily (but not necessarily) departments outside
of IT
• This excludes software under development & software used as tools for IT support

How does your organizations IT, deploy applications?
Is there a best practice which you can share with the
rest of the class

Benefits of a Production Acceptance Process
• An effective production deployment process offers several advantages for applications
department, executive management, various groups within the IT infrastructure,
customers, and suppliers
Beneficiary Benefits
Applications Adequate network & system capacity are planned and available for the Application
If application needs additional resources/budget/time, this can be planned upfront
Support groups could be trained in advance
Executive Increases the probability of successful deployment with minimum surprises and
Management disruption
Supports effective planning and opportunities for cost reduction
Infrastructure Provides an early view of requirements facilitating better capacity planning
Customers Early involvement, Conducive schedules, better experience as well planned and
tested
Suppliers Involves suppliers, supports communication and co-ordination, leverage
experiences PTO
Implementation Steps for an effective production Acceptance Process - 1
The following 14 steps are necessary for implementing an effective production

acceptance process
1. Identification of an executive Sponsor:
▪ An executive sponsor is necessary to ensure ongoing support and cooperation
between the Infrastructure group and the Applications development group.
▪ This could be the CIO, Infrastructure group head or other executive from the
Infrastructure group
▪ Executive sponsor being the champion of the process
▪ Should be as high as possible in the Organization
▪ Should be capable of persuading other executives both inside and outside of IT
to follow the lead.
▪ Responsible for executive leadership, direction, and support for the process.
▪ The executive sponsor is also responsible for selecting the process owner and
addressing conflicts that the process owner cannot resolve
▪ Providing marketing assistance.
2. Selecting the process

owner:
▪ Executive sponsor will select
the production acceptance
process owner from the
infrastructure organization
▪ Typically some one from the
IT infrastructure team or with
knowledge of Infrastructure,
as most of the activities will
fall within the IT
Infrastructure group
▪ Effective communication
skills as they will interact
with users at one end & IT
executives at the other.

3. Soliciting Executive Support

▪ Production acceptance requires policies and decisions about the design of the
process to be backed up by the sponsor, and pushed down to both the
applications development and infrastructure departments.
▪ Executive support from both of these departments should be solicited for ensuring
this support
4. Assemble a Production Acceptance Team:
▪ A cross functional team will need to be assembled by the process owner for
designing and implementing the production acceptance process
▪ This team should consist of representatives of development organization,
operations, technical support, capacity planning, help desk, and database
administration.
▪ Having adequate and proper representation (multiple based on size) from all key
groups will ensure proper implementation and buy-in/support for the process.

5. Identify and Prioritize Requirements:

▪ These requirements are a set of activities/actions which are needed for an effective
design of the Production acceptance process
▪ These Requirements will need to be agreed-upon and prioritized to ensure
successful implementations of Production Acceptance Process.
▪ Some of the common high priority requirements could be like
▪ Ensuring early involvement of the operations, technical support, helpdesk, network
services and database administration roles when implementing a new application
▪ Ensuring that the process of gathering capacity requirements for the process is
compatible with the gathered capacity requirements
▪ Application documentation shared with operations before the production turnover
▪ Developing and enforcing of management policy statements
▪ Developing an uninstall or rollback mechanism

6. Develop Policy Statements:

▪ Policy statements will define acceptable methods and behaviors with-in the team or
simply ways things are done, which will help setting a consistent expectations on
compliance, enforcement, and accountability, when communicated to all levels
▪ The cross-functional team should develop policy statements for a production acceptance
process which should be then approved by the executive sponsor
E.g. All major new versions of existing production applications are to go through the
formal production acceptance process prior to deployment into production
All new mainframe or server‐based applications are to go through the formal
production acceptance process prior to deployment into production
7. Nominate a Pilot System:
▪ A pilot system is a small-scale preliminary study conducted of a small/minimal impact
application, using the new deployment process and ironing out of issues before the
formal process can be institutionalized.
▪ In environments where production acceptance process is new and significantly different
from the way applications are deployed, its effective to introduce the process through a
pilot.

ITSM : Production Acceptance Process
8. Design Appropriate Forms:

▪ Forms are used to solicit the requirements for an application including the activities/actions
needed to be performed in the environment before this application can be deployed using the
production acceptance process being designed
▪ The cross-functional team in the requirements step would have envisaged on the requirements,
their priority and evolved on the different types, and characteristics of formal forms to be used
with a production acceptance process, which are very specific to the organization.
▪ In this phase the forms are designed to make them unambiguous, based on the right roles,
timing etc. Some of the forms would be filled up in the beginning at the time of project approval
for building of the production acceptance process, some a couple of months before the process
is rolled out into production, and some immediately before the process is executed and some
just after the deployment is completed. E.g.
Production acceptance request form contributed by PM, Network Ops manager, System
Administration (at the time of project approval). This can contain
▪ High level summary of the project including the description
▪ High level schedule
▪ Risks and categorization
▪ Service Level information in terms of who is spending how much time
▪ Minimum system requirements
8. Design Appropriate Forms (Contd.):

Eg. Production acceptance request form (Contd.)

8. Design Appropriate Forms (Contd.):

Capacity planning form on (at the time of project approval)
▪ Physical infrastructure
▪ Application usage information
▪ Application resource information
▪ Technical center capacity requirements
▪ Operations support requirements like FTE for different roles
Documentation from the Applications (few weeks before the start-up)

▪ Architecture, System flow diagram, Backup requirements, Disaster recovery
requirements, User acceptance test plans, User guides, List of all infrastructure tasks
Test plans and Training plans (few weeks before the start-up)
Documentation updates, and Closing on Service level agreements etc. (During/just
after deployment)
9. Document the Procedures:
▪ The procedures involved for this process has to be effectively documented and must be
accessible.

10. Execute the Pilot System:

▪ Since the pilot system is identified, forms signed and procedures are in place, the pilot
system is executed.
▪ This involves User testing and acceptance, along with the involvement of support
groups such as technical support, systems administration, and help desk
11. Conduct a Lessons-Learned Session:
▪ This is the pilot run retrospective session, with all the key participants including
representatives from the user community, development area, support staff, and help
desk involved with the pilot execution.
12. Revise Policies, Procedures and Forms:
▪ The recommendations from the retrospective sessions may involve changes to
policies, procedures, forms, test plans, training techniques etc. and may need to be
revised once agreed by the cross functional team

13. Formulate Marketing Strategy

▪ Once the final policies, procedures and forms are in place, the process owner and
design team should formulate and implement a marketing strategy to ensure
widespread acceptance of the process.
▪ The marketing plan should include the benefits of using the process with the active
support of the executive sponsor and his peers, with the cross functional team being the
evangelists within their organizations.
▪ Examples of any quick wins as evidenced by the pilot system; testimonials from users,
service desk personnel & support staff will help support the message
14. Follow-up for Ongoing Enforcement and Improvements
▪ Due to various factors like the Changing priorities, conflicting schedules, budget
constraints, turnover of staff or management, lack of adequate resources there can be a
de-emphasis on the novel process.
▪ Follow up with reviews, postmortems, and lessons learned to constantly improve the
overall quality, enforcement of following of the process, and continuous improvement of
effectiveness of the process will help in ensuring ongoing support and consistent use

Deployment of the Production Acceptance process for deploying a New Application
• We discussed on how the production acceptance process would be designed,

approved, documented, tested, and implemented.
• Execution of the installation is not part of the Production Acceptance process
described above. Having said that an application, when the forms are filled up as
specified, following the procedures of the production acceptance process
discussed earlier, should ensured of a successful deployment.
• Paraphrasing, Once an application is approved to be deployed in the IT
infrastructure, the development manager Involves the Infrastructure group and
submits the required forms. This will enable the Infrastructure personnel to plan,
coordinate, and plan for & provision the required resources and train the
personnel from the technical support, system administration and helpdesk prior
on the application prior to the deployment.
• Once the resources are provisioned, following the well documented procedure
from the Production Acceptance process should ensure successful deployment of
the application

Full Deployment of New Infrastructure & then Application deployment
Once the forms are filled up if you were assembling the Infrastructure from scratch,
then it would involve
• Build up the physical datacenter room
• Install redundant power cabling
• Install racks
• Test the facilities
• Install the server, networking, and storage hardware
• Allow for a burn-in period
• Check the power and cooling usage
• Configure the infrastructure components
• Install systems management tools
• Test systems management processes
• Follow the deployment process
Scenarios for Go-Live: Big Bang Parallel changeover or Phased changeover

Distinguishing New Applications from New Versions of Existing Applications
• Using of the Production Acceptance process for new versions of existing

applications depends on the amount of changes that the new version has that
would impact customers and infrastructure groups
• If the new version of the application has more than minimal impact on users,
support staff, service desk personnel then the process followed should be like for
deploying for a new application.
• All of the steps like
• The test plans to be developed
• Customer acceptance pilots should be formulated
• Capacity requirements should be identified well in advance
• Support staff and service desk personnel to receive updated training
• Customers should be communicated with the changes on what they are going to see
have to be done before the Application deployment using the production
acceptance process.
Distinguishing Production Acceptance from Change Management
• Both production acceptance and change management handle software changes

• Production acceptance is a special type of change that involves many more
elements than the typical software modification like
• Capacity forecasts
• Resource requirements
• Customer sign-off
• Service desk training
• Close initial monitoring by developers
• Production acceptance is involved solely with deploying application software into
production whereas change management covers a wide range of activities
outside of production software, such as hardware, networks, desktops, and
facilities

Case Studies: Generic factors considered
▪ Case studies of Production Acceptance processes as in real-life environments to relate into it
▪ Contrasting different Case studies will need some common factors to be considered
• Business-oriented attributes
– Type of industry of the company (Manufacturing, High technology, Entertainment, Services)
– Total number of its employees at the time of the study
– Number of years it had been in business
• IT Oriented attributes
– Number of IT workers
– Number of processors by platform
– Number of desktops
• Production Services oriented attributes
– Total number of applications in production
– Number of production applications deployed per month
– Existence of a production services department
– To which group the production services department reported



Case Study A
Context: Aerospace firm, Research, Cutting-edge technology focused company.

80000 Employees, 400 IT with 4MF+4 Servers+1200 DTC datacenter equipment.
Typically ran 350 applications daily, and 2 new applications a month.
No formal QA, bit of change management and production acceptance process but
manual. People focused with 2 trained expert engineers handling it based on tacit
knowledge. Minimum Documentation. Compartmentalized physically distributed
organization. Metrics collected.
Positive Outlook: Willing to try out new things, wants to improve
Limitations: Non effective communications, minimal documentation, tacit training, no
formal repeatable process for improvements.
Operations team-Initiated formal production acceptance process.
Learnings: Development and operations team need to work together. Infrastructure
group to support the Production acceptance process.

Assessment Worksheet for Case Study A

Case Studies : Lessons Learnt as per the book
Case Study A
• Ensure the operations department is involved very early with a new application projects.
This helps ensure that the appropriate operation’s group provides or receives the proper
resources, capacity, documentation, and training required for a successful deployment.
• Support from Infrastructure groups are essential
Case Study B
• Plan for and ensure long range commitments of IT
• Consider a change management process prior to a Production Acceptance process
Case Study C
• Organization structure can help or reduce the effectiveness.
• IT executives should ensure that operations control the PA process and that development
is involved in the process design from the start
Case Study D
• Commitment to follow the processes in spite of pressures
• There are significant benefits in standardizing across divisions and sites. This can help in
mergers integrations.
…

Case Studies

Infrastructure Management
Session - 6 Dr. Phalachandra HL
Acknowledgements:
Significant portions of the information in the slide sets presented through the course in the class are
BITS Pilani extracted from IT Systems Management -Rich Schiesser and other books/sources from Internet. Although
permission for use from the book was requested, there has been no response to the same. Since these were
Pilani|Dubai|Goa|Hyderabad intended only for presentation in the class room, have continued to use but would like to sincerely thank,
acknowledge and reiterate that the credit/rights remain with the original authors/publishers only

BITS Pilani
Change Management Process


Recap
• IT Infrastructure Systems Management, involves managing the IT Services running on the IT
infrastructure environment components like the Servers, Disk Storage, DBs, Networks and
Desktop environments for providing a stable and responsive IT environment
• We discussed on the support needed from executives, organization structure and positioning of
the groups which provide these management services, given that one of the KSF are people,
we discussed on approaches for staffing and retaining people with required skills and skill
levels, the personal and business ethics or lack of it and it’s impact in-terms of legislation and
what that drives into organizations
• We also looked at how to evolve the services to a customer centric approach and leveraging the
best practices using frameworks like ITIL
• Then as part of the 12 Key processes which would discuss as part of the course, we discussed
on the processes for managing Availability, Performance –Tuning and Production Acceptance
process.

Recap - 1
• In the last session, we looked at the definition and of Performance and Tuning and how it
contrasts with other ITSM processes. We then looked at the Process owner characteristics, and
then looked at the opportunities which exist for performance management & tuning with respect
to 5 major resources in an IT Systems Infrastructure viz. Servers, Disk Storage, Databases,
Networks and Desktop computers. We then looked at the assessment worksheets for
evaluating the performance and Tuning IT process and metrics which are used for measuring
and improving Performance and Tuning process.
• We also looked at the Production Acceptance process, when we looked at the terminologies
involved, benefits of production acceptance process, 14 steps involved in the Implementation of
production Acceptance Process, process of deployment of new application & a new version of
an existing application, and also looked at how deployment process differs from change
management and a few case studies which highlighted the production acceptance process

Change Management
Introduction
• Change Management has the most interactions with other disciplines. As part of
going through this process we will look at
• Introduction to Change Management in terms of, the process to control and
coordinate all changes to the IT production environment
• Components of Change Management
• Drawbacks of most Change management processes
• Key steps required in developing a Change management process
• Emergency changes metrics
• Assessing an Infrastructure’s Change Management Process
• Measuring and Streamlining the Change Management Process

Change Management
Objectives of Change Management
What do you think are the objectives for Change

Management

Change Management
Context of organizations without a ITSM change Management process
Development Organization Operations Organization (Security, DR, Availability, CP,

(feature or utility) – Functional Requirements Production Support) – Non-Functional Requirements
Meet
Speed - Stability
Value Chain Change Mgt

Change Management
Context of organizations without the ITSM change Management process
▪ Multiple control tower ▪ Standard practice -Stabilize and Improve

▪ Single Runway ▪ Good Practice – collectively functioning
Pictures leveraged from Troy DuMoulin’s youtube presentation https://www.youtube.com/watch?v=LyIdHTn-kuY

Change Management
Objectives of Change Management
1. Value Realization
Benefit realization (function and Non-Function)
• Responding to changing Business requirements and aligning to Business Goals (making it fit for
purpose)
• Responding to changes in terms of transition to emerging technologies and processes.
(we realize the benefit and would like to change)
Risk Mitigation
• I am managing risk by changing
(Addressing Issues or fixing things with goal of reducing disruption and enhancing effectiveness)
Asset Optimization
• Resource optimization
(Reduction in cost, increase utilization etc.)
All of these while
• Ensuring changes are properly handled and managed
• Ensuring all changes to CIs achieve the desired outcome and are recorded in the CMS
• Ensuring governance and compliance expectations are met

Change Management
Introduction
Change Management is the standard process for approval, coordination and control & implementation
(the lifecycle) of all changes to an IT production environment, for enabling beneficial change to be made with
minimum disruption to IT Services or supporting changes to fix things with goal of reducing disruption and
enhancing effectiveness
▪ Change approval
▪ Change Control involves requesting, prioritizing and approving of any requested production change,
prior to the change co-ordination required for its implementation
▪ All Changes have an impact on the IT environment, and hence need to be assessed for it. Approval and
test & Validation process could be different based on the impact
▪ Scope of the impact could be based on the number of users impacted, number of systems impacted, time
period impacted, risk involved etc.
▪ If the scope of the change is “No-impact” or “low-impact” with limited scope, the approval process
may need approval at a lower level and the Verification may not be as stringent.
▪ If the scope of the change is higher, the change control process could include more formal process
of requesting, prioritizing, and approvals
▪ Change co-ordination
• Change co-ordination involves collaboration and work together, planning and scheduling the change,
Communicating/notifying effectively
▪ Change control and implementation

• This would bring in change requested into production with minimal impact to the stability/responsiveness
of the environment
Change Management
Components of Management (Change approval)
The following list describes the different components of change management.

1. Request: Submit the request for the change to a reviewing board (hard copy or
electronic request)
E.g. Tax tables needing to be changed for the new year in a payroll application.
Submitted by S/W maintenance programmer to the change advisory board (CAB).
2. Prioritize: Specify the priority of the change request based on criteria that have
been agreed upon.
E.g. In the above example the change is likely to be given a high priority.
3. Approve: Recommend by a duly authorized review board that the change
request be scheduled for implementation or that it be deferred for pending
action.
E.g. The change would likely be approved by the CAB pending successful testing of the
change.

Change Management
Components of Management (Change Co-ordination)
4. Collaborate: Facilitate effective interaction between appropriate members of support

groups to ensure successful implementation; log and track the change.
E.g. This may include database administrators who maintain specific tables and
end-users who participate in user-acceptance testing.
5. Schedule: Agree upon the date and time of the change, which systems and
customers will be impacted and to what degree, and who will implement the change.
E.g. The change will need to occur at the time the new tax tables would go into effect.
6. Communicate/Notify: Inform all appropriate individuals about the change via agreed-
upon means.
E.g. This could go out to all users, service-desk personnel (in the event users call in
about the change), and support analysts.

Change Management
Components of Management (Change control and implementation)
7. Evaluate Release Readiness: Consider the Exit/Entry criteria, Ensure

Roles and Responsibilities are clear, Establish configuration baselines
and review the handover activities.
8. Deploy to Production: Do a considered deployment to production. This

could e Pilot, Big Bang or as a Phased approach

Change Management
Drawbacks of Change Management Processes
• Although Change management process non-robust manner leading to non well
has been in existence for a long time, its managed process.
still one of the processes which are not The following indicate the percentage of
effectively executed. This could be due to occurrence of the following issues
improper process and communication.
• IT technicians for whom change is a way
of life, see Change control as restricting,
delaying or preventing change. They see
a formal change management process as
non-value-added steps which hinder their
day to day activities.
• Non-stabilized, Non-standard process
• Not being risk based and using a peanut
butter approach
• Given these viewpoints, some of the IT
organizations implement only part of the
change management process in a loose

Change Management
Key Steps required in a Change Management Processes
The following 13 steps are required 7. If change metrics exist, collect and
to implement an effective change analyze them; if not, set up a process
management process. to do so.
1. Identify an executive sponsor. 8. Identify and prioritize requirements.
2. Assign a process owner. 9. Develop definitions of key terms.
3. Select a cross‐functional process 10. Design the initial change management

design team. process.
4. Arrange for meetings of the 11. Develop policy statements.

cross‐functional process design team. 12. Develop a charter for a Change
5. Establish roles and responsibilities for Advisory Board (CAB).
members supporting the design team. 13. Use the CAB to continually refine and
6. Identify the benefits of a change improve the change management
management process. process.

Change Management
Key Steps required in a Change Management Processes : Details - 1
1. Identification of an executive sponsor:

▪ Change management process requires the support and compliance of every
department in the company that could be affected by the change.
E.g. Infrastructure groups like Technical services, database administration ..
Groups outside the infrastructure like the Application development, Facilities ..
▪ An Executive sponsor must be identified for
▪ Garnering support from and serve as a liaison to other departments
▪ Identifying and assigning a process owner
▪ Providing guidance, direction and resources to the process owner.
2. Assigning a process owner:
▪ Done by the Executive Sponsor
▪ Process owner needs to assemble and lead teams, facilitate brainstorming sessions,
conduct change review meetings, analyze and distribute process metrics, and maintain
documentation.

Change Management
2. Assigning a process owner (Contd.):

▪ Skill set associated with this role can vary on the organization, but may contain a list as
below
3. Select a Cross-Functional Process Design team:

▪ Since the success of the change management process depends on the support of all of
the impacted teams in following the process, one of the key steps would be to identify
representatives from these key functional areas and assemble a cross functional team.
▪ The process owner, with support from the executive sponsor, will select and lead this
team through this initial change management process

Change Management
4. Arrange for Meetings of the Cross-Functional Process Design Team:

▪ A well chosen Cross-Functional team can have scheduling conflicts, absentee
members, or misrepresentation at times of critical decision making
▪ It is best to have consensus from the entire team at the outset as to the time, place,
duration, and frequency of meetings and then the logistics can be worked out.
5. Establish Roles and Responsibilities of Change management participant team:
▪ Establishing and ensuring that the members of the Change Management cross
functional team are aware of their role and responsibilities
▪ Most importantly the roles of the Sponsor, Process owners, the contributors of the
cross functional team (the SMEs) and any others as relevant to the environment
6. Identify the Benefits of a Change Management Process:
▪ Identifying the benefits of the change management process can help promoting the
Change management process well can greatly help in fostering support for the same.

Change Management
What would you think would be the benefits of a change

management process

Change Management
6. Identify the Benefits of a Change Management Process (Cont.):

Some common benefits of Change Management process
▪ Visibility: The number and types of all changes logged will show the degree of change
activity being performed in each unit to the Change Advisory Board
▪ Communication: The CAB meeting ensures that the information about the key
changes, schedules and impacts are communicated
▪ Analysis: Changes that are logged into the access database can be analyzed for trends,
patterns and relationships
▪ Productivity: Change information logged could be analyzed for identifying some root
causes and elimination of supplicate work for enhancing productivity.
▪ Proactivity: Change analysis can lead to a more proactive approach toward change.
▪ Stability: All of the previous benefits can lead to an overall improvement in the
stability of the production environment which can benefit customers and support staff
alike
▪ Standardization: As discussed earlier
Change Management
Key Steps required in a Change Management
Processes : Details - 5
7. Change metrics to be defined, collected and

Analyzed:
▪ Metrics like the types of changes,
frequency of changes etc. can be helpful
in developing process parameters such
as priorities, approvals, and lead times.
▪ Percentage of emergency and planned
changes could give the planned state of
the environment
8. Identify and Prioritize Requirements
▪ Identifying the requirements and
prioritizing the requirements is essential
as there can be constraints on the time,
cost and resources.
E.g.

Change Management
9. Develop Definitions of Key Terms

▪ Need unambiguous usage of the terminologies and hence have to be defined
▪ Some of the terminologies of Change, Change Management, Change Control and
Change co-ordination have been defined earlier too

Change Management
10. Design the Initial Change Management Process

The major deliverables produced in this step are:
1. Priority Scheme – Changes grouped into levels
2. Actions to be taken based on level of change
3. Review Methodology
4. Metrics
5. Rollback Mechanism
1. A priority scheme : A set of criteria should be
identified to distinguish different levels of
planned changes for both planned and
unplanned changes. The criteria could be
▪ Qualitative like degree of complexity and
level of risk
▪ Quantitative criteria like number of internal
of external customers impacted, number of
hours needed to implement the change.
▪ Impact can be grouped into different levels
like 4 levels or 2 levels etc.
E.g. Criteria with four level impact based on
some of qualitative and quantitative criteria

Change Management
10. Design the Initial Change Management Process (Cont.)

1. A priority scheme (Cont.): 2. Actions to be taken based on the level
E.g. Impact grouped into two levels of change
Action Matrix for planned changes

Change Management

2. Actions to be taken based on the level of change (Contd.)
1. List of actions for emergency change 6. Support center to notify all appropriate
1. If not an emergency change, then follow the parties of the update.
actions in the action matrix for planned 7. Repeat steps #5 and #6 until problem is
changes. resolved.
2. Implementer or recovery team rep notifies all 8. Support center issues final resolution to all
appropriate parties, including the support appropriate parties.
center of the emergency change. 9. Implementer logs activity as an emergency
3. Recovery team should initiate recovery action change.
within 2 hours. 10. CAB issues final disposition of the
4. Recovery team should determine problem emergency change at the next CAB meeting.
status update interval for support center. 11. Change manager records the board’s final
5. If status interval is exceeded, recovery team disposition of the change into the emergency
rep updates support center. change request record.

Change Management

2. A change request form 3. A review methodology
▪ Constitute a Change Advisory Board-CAB to
have a formal centralized review and
approval mechanism to ensure changes and
its impacts are managed by an accountable
typically a cross-functional decision-making
team, considering the variety of impacts
which can arise out of the change.
▪ Periodic (weekly) review schedule of CAB
4. Metrics
▪ Establish metrics for tracking, analyzing,
and trending the number and types of
planned and emergency changes
occurring every week.
5. Designing a Roll back or backout process

Change Management
11. Develop Policy Statements

▪ Policy statements reflect the philosophy which will be followed by executive management, the
process design team and the users and makes the process to be visible and credible
▪ Objectives of policy statements is to have the change management process to be supportable,
compliant, enforceable, and accountable
E.g.
▪ All hardware and software changes that could potentially impact the stability or the
performance of company X’s IT production environment are to go through the change
management process.
▪ The IT change manager is responsible for chairing a weekly meeting of the CAB at which
upcoming major changes are discussed, approved, and scheduled; also, the prior week’s
changes are reviewed and dispositioned by the board.
▪ All IT staff members and designated vendors implementing production changes are expected
to log every change into the current IT tracking database.
▪ The change manager is responsible for compiling and distributing a weekly report on change
activity including the trending and analysis of service metrics and process metrics.

Change Management
12. Develop a Charter for a Change Advisory • Cancel at the discretion of the board.
Board (CAB) • Analyze total number and types of changes from the
prior week to evaluate trends, patterns, and
The first review meeting of the CAB would set up relationships.
the CAB charter statements like ones as below
Functioning
(Scope, Desired outcomes, Functioning, Duration
and time, Reporting ..) • Few of the roles may have Veto’s.
Scope • Changes will be approved, modified, or cancelled by
a simple majority of the voting members present.
• Review all upcoming high‐impact change requests
submitted to the CAB by the change coordinator Periodicity
Review a summary of the prior week’s changes • CAB will meet every Wednesday from 3 p.m. to 4
p.m. in room 1375.
• Validate that all emergency changes from the
prior week were legitimate. Reporting
• Review and track the status of all planned change • CAB typically is an independent team to begin with
requests from the prior week as to impact level • CAB meeting will eventually become part of a
and lead time. systems management meeting at which the status of
problems, service requests, and projects are also
Outcome
discussed.
• Approve if appropriate.
• Disputes will be escalated to the senior director of
• Modify immediately (if possible) and approve (as the infrastructure department.
appropriate).
• Send back to requester for additional information.

Change Management
13. Use the CAB to Continually Refine and Improve the Change Management Process
▪ A constant action item in the CAB (Change Advisory Board) meeting would be discuss
improvements for the change management process. If any approved by the CAB then
should be assigned, scheduled for implementation for follow on meetings.
PTO
Change Management
Emergency Change Metrics
▪ Emergency change is an urgent mandatory change requiring manual intervention in less than 24
hours (typically to be scheduled ~2-4 hours), to restore or prevent interruption of accessibility,
functionality, or acceptable performance to a production application or to a support service
▪ One of significant metrics for change management is the number of emergency changes
occurring each week, when compared to the weekly number of high-impact changes and total
weekly changes
▪ The degree of emergency change management reflects the proactiveness or reactiveness of the
environment. A number of ~15-20% could mean the environment is reactive
▪ Higher percentage of Proactive changes indicates that the changes are thoroughly planned and
properly coordinated well in advance.
▪ The number of emergency change metrics trended over time indicates maturity of the process
and gives a good indication on the progress towards being proactive.
Change Management
Process

Change Management
Assessing an Infrastructure’s Change Management Process
Continuing with the Worksheet for assessing
the overall quality, efficiency, and effectiveness
of the performance & tuning process. (without
weighing factor)
Quality
Executive support
Process owner
Process documentation
Efficiency
Supplier involvement
Process metrics
Process integration
Streamlining/automation
Effectiveness
Customer involvement
Service metrics
The training of staff
Characteristics within each category is rated on a

scale of 1 to 4 .
1 - 4 indicating no presence to a large presence of
the characteristic.
Change Management
Assessing an Infrastructure’s Change Management Process
Worksheet with a weighing

factor to assign relative
importance provided for a
particular category and the
worksheet is enclosed.

= 128

= Total Score/Max Weighted
Score
= 95/128 = 0.742188 = ~0.74
= 74%

Change Management
Measuring and Streamlining the Change Management Process
▪ We can measure and streamline the change management process with the help of the
assessment worksheet.
▪ We can measure the effectiveness of a change management process by analyzing service metrics
such as availability, the type and number of changes logged, and the number of changes causing
problems, number of changes which had to be rolled back.
▪ Process metrics like the changes logged after the fact, changes with a wrong priority, absences at
CAB meetings, and late metrics reports, which can help us gauge the efficiency of the process.
▪ Change management process can be streamlined by automating certain actions like changes
logged after the fact, changes with wrong priorities, absences at CAB meetings, and late metrics
reports etc.

Discussions (Change Management)
▪ How does Change Control and Co-ordination work

within your organization
▪ Name some of the metrics used with change

management process within your organization
▪ What is the ratio of emergency and non emergency

changes in your organization

Discussions (Change Management)
▪ Change Management in the context of Agile and DevOps oriented

continuous change environments
▪ Shifting from inspecting and approving individual changes
▪ Given the adaptive high velocity value streams the oversight

mechanisms need to be carefully planned for value addition
▪ More focus on Outcome performance, change governance and

continual improvement
▪ Baseline. Applies to all IT changes
▪ Value stream specific. Expectations that are unique to individual
value streams
▪ Adaptive. Apply differently, or to different degrees depending on
the circumstances
BITS Pilani
Problem Management Process


Problem Management
Topics Covered
• The next process which we will look to design and implement is Problem
Management. As part of going through this process we will look at
• Context of Problem Management
• Definition and Scope of Problem Management
• Distinguishing Between Problem, Change, and Request (Service Request)
Management
• Distinguishing Between Problem Management and Incident Management
• The Role of the Service Desk
• Segregating and Integrating Service Desks
• Key Steps (11) to Developing a Problem Management Process
• Client Issues with Problem Management
• Assessing an Infrastructure’s Problem Management Process
• Measuring and Streamlining the Problem Management Process

Problem Management
Introduction
Datacenters today have a large number of complex systems and support diverse set of services.
Problems are bound to occur leading to incidents like missing the targeted levels of service or non-
functioning of components. Problem management processes needs to support managing of the variety
and volume of these incidents to reduce the likelihood and impact of incidents by identifying actual
and potential causes of incidents, and managing workarounds and errors.
Problem Management is a process used to identify, log, track, resolve, and analyze problems
impacting the IT services. Sophistication of the DB and the Depth of the analysis provides the
robustness of the problem management system. There can be different variants of it.
Variations Description
End Programmers System
1 1-Tier reporting only - Incident Management User Admins
2 2- Tier Traditional Problem Management (SRM + Specialized Support) trouble call Problem
3 3-Tier - Escalation Management Service identified
Desk
4 Major Service Disruption - Crisis Management
5 1-Tier Reporting and Service Request management
6 All tiers reporting and Service request management Problem DB
7 All tiers reporting and both Service request and change management)
In ITIL processes focused towards ITIL service operation like problem management, incident
management, event management, request fulfillment and access management addresses this

Problem Management
Distinguishing between Problem, Change and Service Request Management
Problem, Change, and Service Request management are Change Management

three infrastructure processes that are closely related but
distinct.
E.g. Change process supporting a change of a DB, could cause Problem Management
a problem to the Backup window as it would then overlap into Service Request
Incident
production time. Management Management
Problem Management Change Management Service Request

Management
Problem with a desktop component E.g. Addition or modification of any Responding to an operational
• Customer not able to access the production hardware, software which service request for a customer
network can impact multiple customers from the production hardware.
• Slow response to online Applications Setting up an email account.
Fix when broke approach Could be a planned prioritized change Responding to request for help
or emergency needing mandatory on an action.
ASAP change
Some of these may be resolved on the • Add a backup server Change the file permissions of a
phone E.g. accessibility of the network • Add more disk volumes file etc.
• Associated with Priority level x
Sometimes Problems (which cannot be
resolved) can lead to Change Request
Problem Management
Distinguishing between Problem Management and Incident Management
In some environments Incident and Problem may be used distinctly

▪ Initially all calls are logged in by the Service desk (Tier 1 support) as incidents.
▪ These Incidents with some very initial investigation by the Service operator, if found to be some kind
of a request but not a problem, then its serviced and closed by the Service operator as Service
request.
▪ If the incident is resolved, with some further investigation and analysis by the Service operator, then
the call is closed as an Incident.
▪ If the call could not be resolved at the service desk, then the call is passed on to the Tier 2 (second
level) support and designated as a problem. Or if there is a pattern to the incidents, then these
incidents could be looked at as a class problem.
Summarily Calls closed by Tier 1 support are categorized as incidents and calls needing Tier 2 support
are categorized as problems.
Incident Management : Focus is on timeliness & resolution of the problem/restoration of services with
minimum disruption.. Reactive.. Incase of Shared IT I/F .. Business and who else is impacted ..
Communication
Problem Management : Focuses on root causing issues & looks for more permanent solutions –
Reactive and Proactive -
Problem Management
Service Desk – Role in Problem Management
▪ Most IT organizations have some type of Service desk as a Service function to offer
assistance to end-users.
▪ This may be called Service Desk, Help Desk, Call center, Trouble desk, Technical support
or Customer Support Center or Customer Service Center.
▪ Service desk serves as the single point of contact into IT for all users and customers
▪ Service desk is responsible for logging of the calls, classifying them, handling them as best
as possible and tracking the calls to completion.
▪ Service desk is the face of Function Process
Problem management and Has strict organizational Goes across organizational
effects the effectiveness of boundaries boundaries
Problem Management Involves personnel management Involves process management
• Hiring Staff • Process design
▪ Service desk is a service
• Training staff • Process Support
function and not a process. • Evaluating performance • Process metrics
The process and function are • Offering career paths
differentiated as shown. • Performance Management
E.g. Service Desk E.g. Problem Management

Problem Management
Segregating and Integrating Service Desks
▪ Many companies start and have number of service desks to offer assistance to end-users,
as many as the support groups and their IT services. E.g. A bank had ~ 100 separate
service desks for IT with one for each application which was in production.
▪ Over time the benefits of integrating service desks gradually prevailed in most instances,
although segregated service desks have still a place in Highly diverse user populations,
remote locations etc.
▪ Over all the Advantages and disadvantages of Integrating the Service desks as below.
Book-?

Problem Management
Segregating and Integrating Service Desks
▪ Here are the Advantages and disadvantages of a Segregated Service desk is as below.
Advantage Disadvantage
Ability to customize specialized support Hard to cross train
for diverse applications, customers, and
services
If there are too diverse a set of support Customers will need to call many times or
needing to be provided, a segregated have many service desks to choose from,
support center can offer better depth of making it not as effective
service
Increased cost
Easier to integrate to different independent
processes
▪ A compromise hybrid solution is sometimes used in which all IT customers call a single
service desk number that activates a menu system. The customer is then routed to the
appropriate section of a centralized service desk depending on the specific service
requested.

Problem Management
Key Steps to Developing a Problem Management Process
▪ The following are the 11 steps which are required for developing a robust problem
management process.
1. Select an executive sponsor.
2. Assign a process owner.
3. Assemble a cross‐functional team.
4. Identify and prioritize requirements.
5. Establish a priority and escalation scheme.
6. Identify alternative call‐tracking tools.
7. Negotiate service levels.
8. Develop service and process metrics.
9. Design the call‐handling process.
10.Evaluate, select, and implement the call‐tracking tool.
11.Review metrics to continually improve the process.

Problem Management
Key Steps to Developing a Problem Management Process - 1
1. Select an executive sponsor.

▪ An Executive sponsor must be identified for
▪ Bringing together and garnering support from different IT departments and
suppliers external to IT and acting as their liaison
▪ Identifying and assigning a process owner
▪ Providing guidance, direction and resources to the process owner.
2. Assign a process owner.
▪ Done by the Executive Sponsor
▪ Process owner needs to assemble the cross-functional teams for designing and
maintaining the problem management process.
▪ Process owner will also need to lead, organize, communicate, team-build, troubleshoot,
and delegate effectively.
▪ The recommended skill set for the
process owner would be
………..
Problem Management
3. Assemble a cross‐functional team.

▪ Problem management process involves the participation of several key groups. There
could be as many as dozen people as part of the group.
▪ This team is responsible for
▪ Identifying and prioritizing requirements
▪ Establishing the priority scheme
▪ Negotiating internal SLAs
▪ Proposing internal process metrics and external service metrics
▪ Finalizing the overall design of the call-handling process
▪ The groups which are involved can vary between organizations but commonly includes.
▪ Service desk ▪ Server support (includes mainframe
▪ Desktop hardware support and midrange)
▪ Desktop software support ▪ Database administration
▪ Network support ▪ Development groups
▪ Operations support ▪ Key user departments
▪ Applications support ▪ External suppliers

Problem Management
4. Identify and prioritize requirements for the process

▪ Once the cross functional team has been identified and assembled, the first activity of
this team is to identify and prioritize requirements
▪ The team will need to get to consensus on the inclusion and the priority of the
requirements for the system. Some of the requirements necessary for building a robust
process (like provides metrics, accountability … we will study as a independent module)
would be included. Typically dependent on the organization’s current focus and direction
beyond building a robust process
………..
Problem Management
5. Establish a scheme for Priority and Escalation of the incidents which reach
the Service Center
▪ This is the scheme on whose
basis you classify and assign
priority to the incidents/
problems which land into the
service center.
▪ This is also the step where
you will establish a scheme
which will prescribe how to
handle escalations (typically
these are high priority difficult
to resolve problems)
▪ Typically most organizations
attempt to prioritize problems
based on severity, impact
urgency, and aging.
………..
Problem Management
6. Identify Call-Tracking Tools with Alternatives to choose from
▪ An effective problem management process revolves around a call-tracking tool, whose requirements
are evolved in step 4, and number of alternative tools are identified as part of this step
▪ Companies usually custom build a tool (cheaper and built to the process of the organization) or buy
an off the shelf tool (more flexibility with integration capabilities but expensive)
7. Negotiate Service Levels
▪ External service levels enforceable, and mutually agreed upon by both the customer service
department and IT.
▪ Internal service levels should be negotiated with internal level 2 support groups and external
suppliers.
8. Develop Service and Process Metrics
▪ Service metrics should be established to support the SLAs that will be in place with key customers.
▪ The following are some common problem management Service metrics:
▪ Wait time when calling help desk
▪ Average time to resolve a problem at level 1
▪ Average time for level 2 to respond to a customer
▪ Average time to resolve problems of each priority type
▪ Percentage of time problem is not resolved satisfactorily
▪ Percentage of time problem is resolved at level 1
▪ Trending analysis of various service metrics
Problem Management
8. Develop Service and Process Metrics (Cont.)
▪ The following are some common problem management Process metrics:
▪ Abandon rate of calls
▪ Percentage of calls dispatched to wrong level 2 group
▪ Total number of calls per day, week, month
▪ Number of calls per level 1 analyst
▪ Percentage of calls by problem type, customer, or device
▪ Trending analysis of various process metrics
9. Design the Call-Handling Process
▪ The entire cross-functional team will need to design this.
▪ It dictates how problems are first handled, logged, analyzed and communicated
▪ This will also indicate how they might be handed off to level 2 for resolution, closing, and
customer feedback
▪ This will also design how the proactive calls will be selected
10. Evaluate, Select, and Implement the Call-Tracking Tool
▪ Alternative call-tracking tools are evaluated by the cross-functional team to determine the final
selection.
▪ The selected tool is then implemented
▪ In the initial phases, the tool is passed through a small subset of calls to pilot the
implementation.
Problem Management
11. Review Metrics to Continually Improve the Process

▪ All service and process metrics should be reviewed regularly to spot trends and
opportunities for improvement.
▪ This usually becomes the ongoing responsibility of the process owner
Opening of a problem is a critical activity of Problem Management
▪ Properly opened tickets can lead to quick closing of problems or to be forwarded to the
appropriate teams for a timely resolution.
▪ Infrastructures with especially robust problem management processes tie in their call-
tracking tool with both an asset management database and a personnel database.
The asset database allows call agents to view information about the exact configuration
of a desktop and its problem history. The personnel database allows agents to learn the
caller’s logistics and their recent call history.
Closing of a problem
Resolving of a problem is closure of the problem from the IT service personnel perspective.
This gets closed when the customer validates the resolution.

Problem Management
11. Review Metrics to Continually Improve the Process (Contd.)

▪ Analyzing a variety of trending data can help to continually improve the problem
management process.
▪ This data may concern the types of problems resolved, the average time it took to
resolve, devices involved, customers involved, and root causes
E.g. Monthly distribution of typical service desk problem types
Observations:
• Increment % indicates the
% distribution of the calls
• This can be grouped for
meaningful takeaways.
e.g. 92.3% are desktop related
issues
• This can be used to formulate
action plans to address as part
of continuous improvement
Problem Management
Client Issues with Problem Management
Results from a survey of infrastructure managers and senior analysts on what they believed
were the greatest exposures with their current problem management processes.

Problem Management
Assessing an Infrastructure’s
As discussed, this worksheet presents a
quick-and-simple method for assessing
the overall quality, efficiency, and
effectiveness of a problem management
process
Quality
• Executive support
• Process owner
• Process documentation
Efficiency
• Supplier involvement
• Process metrics
• Process integration
• Streamlining/automation
Effectiveness
• Customer involvement
• Service metrics
• The training of staff
Characteristics within each category is
rated on a scale of 1 to 4 .
1 - 4 indicating no presence to a large
presence of the characteristic.
26 Feb 2022 SS ZG538 Infrastructure Management
Problem Management
Assessing an Infrastructure’s
▪ Worksheet with a weighing
factor to assign relative
importance provided for a
particular category and the
worksheet is enclosed.

= 136

= Total Score/Max Weighted Score
= 94/136 = 0.6911 = ~0.69
= 69%

Problem Management
Measuring and Streamlining the Problem Management Process
▪ We can measure and streamline the problem management process with the help of the
assessment worksheet.
▪ We can measure the effectiveness of a problem management process with service metrics
such as calls answered by the second ring, calls answered by a person, calls solved at level
1, response times of level 2 and feedback surveys.
▪ We can also look at the Process metrics—such as calls dispatched to wrong groups, calls
requiring repeat follow-up, amount of overtime spent by level 2, third-party vendors etc.
which help us gauge the efficiency of this process.
▪ We can streamline the problem management process by automating actions such as
escalation, paging, exception reporting, and the use of a knowledge database.

Discussions (Problem Management)
▪ How is your support levels structured in your

organization?
▪ Is your Service desk integrated or segregated and why?
▪ Is Service desk a process or a function in your

organization
▪ Name some of the metrics used with problem

management process within your organization

Infrastructure Management Consolidated CS Slides (Mid-Sem 1 To 6) 20220310A

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Infrastructure Management Consolidated CS Slides (Mid-Sem 1 To 6) 20220310A

Uploaded by

Copyright:

Available Formats

Infrastructure Management

15 Jan 2022 CSI/SS ZG538 Infrastructure Management 3

What does IT infrastructure mean to you?

15 Jan 2022 CSI/SS ZG538 Infrastructure Management 4

Different Views of IT Infrastructure

15 Jan 2022 CSI/SS ZG538 Infrastructure Management 5

• IT Services and processes enable the organization in the

• The Services a firm is capable of providing to its

• IT infrastructure should support the firm’s business and

Relationship between an Organization,

15 Jan 2022 SS ZG538 Infrastructure Management 6

• It also involves setting up of policies

15 Jan 2022 SS ZG538 Infrastructure Management 7

• IT Infrastructure typically consists of number of Physical devices right from

• Developing organizational capabilities to efficiently and effectively manage enterprise IT

15 Jan 2022 SS ZG538 Infrastructure Management 9

managing the IT Infrastructure?

15 Jan 2022 CSI/SS ZG538 Infrastructure Management 10

▪ Scale ▪ OS and Configuration Diversity/Hygiene

▪ Focus on uniform components (H/W ▪ Environment, Power saving

15 Jan 2022 SS ZG538 Infrastructure Management 11

IT infrastructure management will need Executive support in terms of

15 Jan 2022 SS ZG538 Infrastructure Management 12

15 Jan 2022 SS ZG538 Infrastructure Management 13

to factor in when building a Business Case?

15 Jan 2022 CSI/SS ZG538 Infrastructure Management 14

Steps for Developing a business case for a systems management function:

15 Jan 2022 SS ZG538 Infrastructure Management 15

7. Converting benefits to dollar savings to the extent possible.

15 Jan 2022 SS ZG538 Infrastructure Management 17

Three Universal Principles Involving Executive Support

15 Jan 2022 SS ZG538 Infrastructure Management 18

Three Universal Principles Involving Executive Support (Contd.)

Once Executive Support is obtained focus

SS ZG538 Infrastructure Management 1

Once Executive Support is obtained focus shifts

• Organizing an organization or a group, supports coordination of work through a structured

22 Jan 2022 SS ZG538 Infrastructure Management 5

• Key factors which could be considered for Designing the IT organizations

22 Jan 2022 SS ZG538 Infrastructure Management 6

IT Organization with a separate Administration department - as the company evolves

▪ Billing, Invoices, Asset

IT Organization with all the three groups evolving further as below

22 Jan 2022 SS ZG538 Infrastructure Management 7

22 Jan 2022 SS ZG538 Infrastructure Management 8

Designing the IT infrastructure for Systems Management

What would you think are the Factors to Consider in

22 Jan 2022 SS ZG538 Infrastructure Management 9

Designing the IT infrastructure for Systems Management

Factors to Consider in Designing IT Infrastructure organization

• Combining Voice and Data groups

• Location of Departments in the Infrastructure Organizations

E.g. Location of Service Desk

22 Jan 2022 SS ZG538 Infrastructure Management 10

Designing the IT infrastructure for Systems Management

• Location of Service Desk (Contd.)

22 Jan 2022 SS ZG538 Infrastructure Management 11

Designing the IT infrastructure for Systems Management

• Location of Departments in the Infrastructure Organizations (Contd.)

22 Jan 2022 SS ZG538 Infrastructure Management 12

Designing the IT infrastructure for Systems Management

Location of Departments in the Infrastructure Organizations