© Abhinav Krishna Kaiser 2021
A. K. KaiserBecome ITIL® 4 Foundation Certified in 7 Dayshttps://doi.org/10.1007/978-1-4842-6361-7_9

9. Practices to Enable Service Support

Abhinav Krishna Kaiser1  
(1)
Staines, UK
 

A service is essentially conceived, designed, built, and supported throughout its life cycle. Throughout the life cycle, two things happen: the services are supported, which necessarily means that services keep going as they should; and if anything breaks, then a break fix is applied. Then there are several changes that happen during its lifetime. Smaller modifications to a service are done on an ad hoc basis on the back of change management. Major changes undergo a continual improvement cycle. While all these activities are visible to stakeholders and highlight various achievements, there are silent players in the game that make it happen. These are the enablers that buttress the service support practices.

This chapter discusses the three support enabling practices that are quintessential for managing operations, running modifications, and implementing improvement initiatives. The practices that we are going to look into are:
  1. 1.

    Information security management

     
  2. 2.

    IT asset management

     
  3. 3.

    Service configuration management

     
Exam Tip

You can expect between one and two questions to appear from this chapter.

Information Security Management

Information security is one of the general management practices. It is an area that has held higher significance every passing day because the threats from hackers and malwares increase quite rapidly. No application or service is exempt from information security threats. In ITIL, information security is introduced in the design and is not an afterthought during the operational stages.

It is true that the lines between information security in ITIL and DevSecOps or Rugged DevOps have blurred somewhat. Although DevSecOps or Rugged DevOps define the boundaries for information security, the exclusivity of information management is retained in the ITIL framework. For example, Rugged DevOps could lay the boundaries for setting up services. While the interfaces to the service and to the outside world are managed through Rugged DevOps, the inner workings of the service are managed by ITIL. However, with DevSecOps, the DevOps processes collaborate with the ITIL information security practice to define and implement controls that manage the external interfaces as well as the data contained within.

ITIL Definition of Information Security Management Practice

The purpose of the information security management practice is to protect the information needed by the organization to conduct its business.

The definition of the information security practice is defined at a high level to take care of the data element within the service. The result is to ensure that the business that we serve does not get affected by the materializing of threats of information security.

Information security is achieved through the definition and implementation of various security controls, policies, processes, and work procedures. Primarily, it is three sets of activities that set the tone and leverage the definitions of the controls, policies, and processes:
  1. 1.

    Detection (monitoring)

     
  2. 2.

    Correction

     
  3. 3.

    Prevention

     

Various information security threats and risks must be defined and tools set up to detect them. Monitoring security threats is done on several data mediums such as monitoring emails, Internet pages, malwares, anomalies, data loss prevention, and intrusion. For each of these areas, there are several competitive tools that become robust by the day.

Many of the detection tools also play the correction part. Once they detect, they are able to self-correct the threat through a programmed sequence of correction procedures. When it comes to information security, time is of the essence. Threats must be identified and rectified in a timely manner to ensure that the viruses and intrusion attacks do not get the luxury of time to carry out their mission.

Prevention is the real cure that ensures that the identified threats are no longer an issue. It can be seen as a permanent solution. While corrective action provides a one-time fix, preventive action offers no chances for threats to take shape.

The question thus becomes about the balance that organizations must strike between the three sets of actions. The ideal situation is to prevent all threats, but in the process innovation gets stifled. An environment that restricts risk taking goes against the principle of Agile and DevOps. So, how should organizations decide on the balance that they need to strike? Well, that depends on their risk appetite and the chances they are willing to take in the name of experimentation and innovation.

Areas of Information Security

Information security is an ever expanding field of practice. With technology reaching new heights, information security areas is playing catch up with identifying and tightening controls for each of the technological aspects. There was a time when security was mainly concerned with viruses. Today, it has stretched to various angles such as phishing users, DDoS (distributed denial of service) attacks, MITM (man-in-the-middle) attacks, among the usual suspects such as malwares, adwares, spywares, and trojan horses.

Each of these information security threats target different systems, and their approach is different on what they target and how they go about it. All these threats can be explained through the information security quintet consisting of:
  1. 1.

    Confidentiality

     
  2. 2.

    Integrity

     
  3. 3.

    Availability

     
  4. 4.

    Authentication

     
  5. 5.

    Nonrepudiation

     
The quintet is illustrated in Figure 9-1.
../images/385197_2_En_9_Chapter/385197_2_En_9_Fig1_HTML.jpg
Figure 9-1

Areas of information security

Note

In ITIL V3, the information security triad (confidentiality, integrity, and availability) was considered. With the technological advancements, it is now a quintet. As we explore newer areas, the length and breadth of information security too will expand.

Confidentiality

Confidentiality is the protection of information from unauthorized access. In other words, only those with access to information are able to access it. Service providers and customers store information on servers, SharePoint application servers, and other file servers, and this data could contain sensitive business strategies, tactics, credit card information, or personal information of the end users. This information needs to be secured through methods known best to information security professionals, such as encryption and safeguarding.

To protect confidentiality, service providers must ensure that access controls exist along with rigor to ensure that the accessor can only do what is allowed. Further, information classification is necessary to protect secret and confidential information.

Integrity

Integrity is the protection of information from getting modified by those who are not authorized to do so. It tightly integrates with confidentiality and goes a step further in protecting the interests of all the involved parties. Information is valuable if it is accurate, and when it is modified by unauthorized users, the resulting data can pull companies down faster than a speeding bullet.

There are several ways integrity is protected these days, cryptography being one of them.

Availability

Availability ensures that the authorized parties have access to information when they need it. If you provide the right level of encryption through confidentiality and ensure integrity through cryptography, but fail to provide accessibility to those authorized, the whole exercise of securing information is counterproductive, right? The value from service comes from parties having the availability to access information when they desire to access it. Hackers have found a way to breach information security by blocking access to information through distributed denial of service (DDoS) attacks.

Several popular websites such as Facebook get hit by such attacks fairly regularly. In this sense, denial of access to information is a breach in achieving information security objectives.

Authentication

Authentication is the process of identifying the right entity to provide access to gateways and resources. It is an area that is quite vulnerable, as it is primarily used by users and protecting it would not just be in the hands of the service provider but with all users.

However, there are things that a service provider could do to ensure that the system authenticates with the right level of details. For example, a service provider could enforce a certain complexity of passwords. With more complex passwords, systems can be protected from brute attacks. These days, multifactor authentication has taken effect, with the password being followed by a one-time password sent to mobile phones or authenticators apps providing the additional layer of security. There are other means as well, such as fingerprint scanners and face recognition methods. The objective is to ensure that only the right person can authenticate and move past the system’s threshold.

Nonrepudiation

Nonrepudiation is a fairly new-ish term. It refers to keeping timestamps, artifacts, and tracking to ensure that a certain action can be backed with ample proof. Let us consider an example: a user could subscribe to a daily newsletter. To ensure that the user accepts the agreement, the newsletter service sends an email out every day wherein certain information needs to be provided. The user will be asked to check a box to confirm if he agrees to receive an email daily. Plus, an email goes out to the user to confirm by clicking on a link. By following up with these actions, the user cannot claim in any court of law that the newsletter is spam sent without their consent. Other real-time examples could be the payment terms and agreements signed up on various websites and applications. Although no formal contract in the form of legal stamped papers are used, the digital agreements serve the same purpose.

With my publisher, I signed a contract through an online agreement service called Docusign, where the terms of the contract were laid out and I digitally signed on the terms put forth. The agreement that I have signed is valid in a court of law, and neither my publisher nor I could ever deny signing it because ample proofs are made available.

Engagement in Service Value Chain

You should expect information security management to play a significant role in every activity in the service value chain.
Table 9-1

Information Security Management in SVC

SVC Activity

Involvement

Details

Plan

High

Information security is not an afterthought. It has to be driven and considered from the planning stages.

Design and Transition

High

The design and transition activity must consider all the security aspects during the design of products and services, and appropriate controls must be defined. During transition, effective transfer of security controls is to be done to operations.

Obtain/Build

High

Based on the inputs from design, information security controls are to be translated into development of the products and services, including the outsourced components to suppliers.

Engage

High

Information security can be successful only if all involved stakeholders are part of requirements, design, development, and operations. The Engage activity must ensure that all parties are in sync on information security aspects.

Deliver and Support

High

The mechanisms built for monitoring security incidents should be prioritized. And, as an when security incidents are reported, they must be ably dealt with.

Improve

High

While improvement of services is imperative, security aspects have to go hand in hand with the proposed improvement initiatives.

IT Asset Management

Asset management is a general practice across industries. The practice refers to managing assets in various industries. For example, in the automobile industry, a car is made up of several components, and the car itself is a finished end product. Each of the individual parts and the car are referred to as assets. An asset is the lowest detail of a component that is tracked throughout its life cycle. Perhaps in the same company, they may track components like steering wheels and doors as assets but not the screws, rivets, and bushes that hold them together.

IT asset management practice manages assets in the IT industry, and more specifically in the industries that are run on the ITIL framework. Therefore, it has been categorized under service management practices and not general management practices.

ITIL Definition of IT Asset Management Practice

The purpose of the IT asset management practice is to plan and manage the full life cycle of all IT assets, to help the organization:
  • maximize value

  • control costs

  • manage risks

  • support decision-making about purchase, re-use, retirement, and disposal of assets

  • meet regulatory and contractual requirements

The IT Asset Management practice is essential to ensure that the assets that contribute to a service are critical, and managing it is a backend activity that if not carried out seamlessly can cause disruptions. Take, for example, a server: its warranty information needs to be tracked and extended as necessary. When it reaches close to its end of life, it needs replacing. All the requisite information for extending or replacing is contained with this practice. As the definition states, the decision making around purchase, reuse, retirement, and disposal is made possible through the asset management practice. Managing it well and effectively also reduces the risks surrounding IT assets.

Further, costs can be controlled by having an accurate inventory and an equally accurate estimate of the upcoming demand. If the organization knows what it has in store, then they will not go on a buying spree but rather use what they have. Likewise, buying or renting decisions can be made as and when needed, aided by the asset inventory information.

Finally, there are various standards like ISO 9001 and ISO 20000 that mandate that inventory information be maintained and retained to attenuate the risks that come with mismanagement of IT assets. Plus, there could be government regulations that can be met only through accurate asset inventories.

Well, we spoke of the value coming from the IT asset management practice. But what is this IT asset that we are talking about?

ITIL Definition of IT Asset

Any financially valuable component that can contribute to the delivery of an IT product or service.

Any component that contributes to products and services and that has a financial cost associated with it is an IT asset. Examples are servers, routers, switches, software, or smart watch. Why only financially valuable components, you might ask? Look at the latter part of the definition: components that contribute to the delivery of an IT product/service. There are IT components such as processes, policies, and frameworks that contribute toward a service and can be considered essential components. However, such components do not come under the purview of the IT asset management, as the life cycle differs, and the objective of the IT asset management is to oversee inventories that start with procurement and end with disposal.

A typical life cycle of an IT asset is illustrated in Figure 9-2. It starts with a planning exercise that includes estimation, forecasting, and getting demand-related information. This is followed by procuring the asset or building it, followed by its implementation. The IT asset is maintained and upgraded until it reaches its end of life, and upon reaching its end of life, it is retired and disposed of.
../images/385197_2_En_9_Chapter/385197_2_En_9_Fig2_HTML.jpg
Figure 9-2

Life cycle of an IT asset

Table 9-2

Asset Management in SVC

SVC Activity

Involvement

Details

Plan

Medium

Asset management practice maintains financial data, and planning activities leverage this data. It helps the organization manage costs and create value.

Design and Transition

High

IT asset statuses are determined based on the activities carried out by this activity.

Obtain/Build

High

This is an essential part of the asset management, as it has a direct correlation with asset procurement.

Engage

Low

Customers may at times seek information on the residual value of their IT assets.

Deliver and Support

Medium

The practice supports this activity by identifying the assets along with current statuses.

Improve

Low

Improve may consider the impact on IT assets by the recommended improvement initiatives.

Exam Tip

The definition of an IT asset is one of the frequently asked questions on the ITIL foundation exam. The question will center on identifying the right definition from a list of choices. So, it is prudent for you to understand and memorize the definition verbatim.

Types of Asset Management

At the heart of IT asset management is a database that consists of all IT assets along with other pertinent information including its status. This is the asset register. If the organization would like to carry out an inventory check of their assets, their first and only point of inspection is the asset register. The basis for carrying out planning and acquisitions is the asset register. When users raise incidents, the service desk personnel look into the asset register to identify the type of laptop that is assigned to them. Audits are carried out based on the information stored in the asset register against the physical/software asset. All practices, be it incident management, change control, problem management, or deployment management can function provided the asset register is available and is accurate. Such is the importance of the asset register in organizations.

The IT asset register is a subset of the configuration management system (CMS)—either homogenously or in a federated structure.

Note

The asset register was referred to as an asset database in the previous ITIL versions although it was assumed to be coherent with the configuration management database (CMDB), which we are going to talk about in a later section.

Not all IT assets can be managed in the same way, although the life cycles of all IT assets are similar. The type of IT asset management is determined by the nature of the asset and its ownership. Broadly, asset management can be classified as follows:
  1. 1.

    Hardware asset management

     
  2. 2.

    Software asset management

     
  3. 3.

    Client asset management

     
  4. 4.

    Cloud-based asset management

     

Hardware Asset Management

Hardware asset management , as the name indicates, is the management of hardware assets: assets that are physical in nature. Example: racks, servers, switches, laptops, telephones, and IoT devices.

Maintaining hardware requires processes that are rugged, precise, and complete to ensure that all circumstances and scenarios are considered during its design. Managing hardware may not always be automated where they can be monitored. Many times, a physical inventory needs to be carried out. So it is essential that all hardware assets have a label that asserts a unique asset ID, to identify the asset in the asset register.

I was tasked with pulling together an inventory for a German manufacturing giant that was spread across 45 locations in India. While a majority of IT assets were on the network, there was a good proportion that was behind a firewall. And many more were in stores (and probably forgotten). For all the assets on the network, I was able to carry out an automated inventory through a Java program that we pushed to all systems. For those in stores and behind the network, I hired close to a hundred staff who went around searching for assets. It was like looking for a needle in a haystack. After this humongous exercise, based on the customer’s internal financial records, the inventory that I carried out was just about 97 percent accurate, which was better than their expectation of 95 percent .

Software Asset Management

Software assets are a different beast. With software asset management, we manage the licenses, including freeware and trialware. Licenses come in multiple shapes and sizes: there are licenses that are tagged to assets, tagged to users, and concurrent licenses, among others. It is imperative that organizations are compliant at all times, as software publishers carry out regular audits, and penalties for noncompliance are quite severe (especially for CIOs).

A few challenges with software asset management are to maintain the software register where the licensed copies are stored, and access is controlled. Software licenses often go down the drain when hardware assets are decommissioned. So, tight processes must be wound around the hardware management processes to ensure that licenses do not get lost.

Client Asset Management

Client assets refer to assets that are handed to individuals, such as laptops, mobile phones, smart watches, and data loggers. The challenge comes from the danger of data loss that could result because of lax processes and information security controls. Sufficient controls need to be put in place to ensure that secret and confidential data does not get into the wrong hands.

Several techniques are employed, such as using BitLocker on laptops and carrying out remote wipes at the scent of repeated wrong authentication.

Cloud-Based Assets

Cloud assets are a different breed altogether. Typical hardware assets are no longer physical assets, and software too is generally bundled with the hardware. Management of cloud-based assets must consider various factors such as the dynamic nature of asset creation and deletion. At the click of a button, servers can be created and spun down through pipelines. How does one carry out IT asset management on assets that are dynamic in nature?

Well, in such circumstances, we employ configuration management. The cloud assets are managed through a configuration management (not service configuration) tool that maintains the data based on the servers that are spun and despun. Examples include Chef, Puppet, and Ansible.

Further, how do you identify specific costs to specific services when servers are shared across services? That is another challenge that the emergence of cloud in IT service management has thrown up, which is what makes ITIL and IT service management evergreen and interesting .

Engagement in Service Value Chain

Service Configuration Management

Most projects fail because of the lack of managing configurations and having total control over the various components that make a project tick. Service configuration management is the foundation upon which the entire project is built. Ignoring the foundation will logically see the walls and roofs of the project crumbling down in record time. The practice plays a significant role for systems made up of multiple components that are integrated with other systems and run on multiple dependencies. Sound familiar? Yes, almost all systems today are complex, owing to the need for integration and its respective data sources and data consumers. In such a complicated setup, it is imperative that systems are driven by configuration management, which is relied on heavily by projects.

ITIL’s service configuration management practice (formerly service and asset configuration management) has matured over the years and has been powering the service industry for several years. The practice has been the spine for IT services over the years, and within ITIL the process has matured with each version. It is a practice that determines whether a service provider succeeds or not in delivering IT services and defines the breadth of the services offered.

Note

You will notice me using service configuration management and configuration management. They are one and the same. While service configuration management is the official practice name, generally the practice is referred to as configuration management.

ITIL Definition of Service Configuration Management

The purpose of the service configuration management practice is to ensure that accurate and reliable information about the configuration of services, and the CIs that support them, is available when and where it is needed. This includes information on how CIs are configured and the relationships between them.

Configuration management gives you a blueprint of IT services, the architecture underneath, and the dependencies. It provides an accurate reflection of the connected pieces and dependencies. It is this network of components that makes the service work. Having it in a form that’s alive and accessible gives the ammunition to make changes to services with ease, identify business impact with minimal analysis, and resolve outages in a jiffy.

These are the tools that you need, to be a valid player in today’s market where changes happen on the fly and customer wish lists change faster than the lifespan of mayflies. A project without accurate and dynamic configuration management is a living nightmare. Imagine making changes to one part of the system without understanding the impact they could cause on other dependent systems. This happens commonly in the software development industry. It is not uncommon that architects are baffled when they have certain dependencies and defects crop up through the regression of acceptance testing quite late in the development life cycle. This is a blunder of sorts because there is a good likelihood that software delivery might not happen as per the promised schedule, and if the development teams try to cram in fixes at the last minute, defects pop up. If only the architects had a working configuration management process in place, they could have identified everything that needed to be changed and could’ve avoided the negativity that emanates from failures.

Let us try and understand the term CI, which stands for configuration item.

ITIL Definition of Configuration Item

Any component that needs to be managed in order to deliver an IT service.

Exam Tip

The definition of a configuration item is one of the frequently asked questions on the ITIL foundation exam. The question will center on identifying the right definition from a list of choices. So, it is prudent for you to understand and memorize the definition in verbatim.

A CI is a fundamental component of a service that can be configured, tracked, accounted for, and controlled. For example, in an email server involving servers, routers, and MS Exchange applications, each server, router, switch, application, and firewall can be considered a CI. Why? Because these CIs can be tracked, controlled, accounted for, and audited.

You might ask me if a server is a CI or if the hard drive, memory, and other components inside a server are CIs. Who decides what can or cannot be a CI? This is a decision made by the configuration architect based on the nature of the service, its interfacing to other practices such as incident and change control, and most importantly the cost. For example, a server can be considered a CI. Conversely, each of the components of a server such as the processor, memory, and hard drives can be considered as CIs, which necessarily alludes to a lot more effort (and cost) in coming up with the configuration management and maintaining it. Therefore, generally the decision is left to the architect to make a judgment call on what level a CI should be considered. The general practice is to measure the value that is derived by delving deeper into the services for deriving CIs.

Every CI has several attributes attached to it. Attributes are various details that get recorded against a CI, such as owner, location, date of commission, status, and configuration. All these attributes are controlled through change control. This is the layer of control that ensures that the configuration management remains accurate and nobody can make changes to it without the approval and consent of the change control governance.

CMDB, CMS, and Service Model

Configuration management database (CMDB), configuration management system (CMS), and service models are inherent elements of the service configuration management practice.

Configuration Management Database

A CMDB is a repository containing all the CIs including their relationships. For example, in a CMDB, the dependency between the CIs can be defined through relationships such as “runs on” and “supported by.”

Within the CMDB, you can have multiple services, the individual CIs, and their relationships. Most modern ITSM tools, such as ServiceNow and BMC Atrium, offer placeholders to record the upstream and downstream impacts. If you pick up a service and want to use it visually to see how CIs connect to one another, you will see an array of connections between the CIs. Using this visual image, other processes such as incident management can troubleshoot incidents with ease, and processes such as change management can identify upstream and downstream impacts with a click of a button. Imagine if this were not in place; the whole activity involving analysis and troubleshooting would be tough.

In an organization, you could have multiple CMDBs depending on the requirements, business structure, and customer obligations. For example, you can have a CMDB for business units A, B, and C; a CMDB separately for customer ABC; and yet another CMDB for internal infrastructure and software. There is no limit, as long as the logic makes sense to manage, control, and simplify matters .

Configuration Management System

The CMS is the super database that contains all the CMDBs and more in its ecosphere. It is the layer that integrates all the individual CMDBs along with other databases in the IT service management space, such as known error databases, incident records, problem records, service request records, change records, and release records.

ITIL Definition of Configuration Management System

A set of tools, data, and information that is used to support service configuration management.

Figure 9-3 provides an illustration of a CMS.
../images/385197_2_En_9_Chapter/385197_2_En_9_Fig3_HTML.jpg
Figure 9-3

Configuration management system (CMS)

Table 9-3

Service Configuration Management in SVC

SVC Activity

Involvement

Details

Plan

Low

The CMS could be leveraged during identifying and proposing changes to services.

Design and Transition

High

Design leverages on the CMS and also provides inputs based on design changes. Transition too is highly dependent on the CMS.

Obtain/Build

High

Generally, CIs are created on the back of the obtain/build activity.

Engage

Low

Third parties could leverage on the CMS to identify dependencies or provide impact information.

Deliver and Support

Medium

This activity, as explained earlier in service model, leverages on the CMS for achieving efficiencies and work completion.

Improve

Medium

Configuration management has evolved over the years, and it has become better because of the various improvements that have happened. Based on the needs of IT, the practice will evolve and adapt.

In this illustration , you have three different CMDBs sitting in it: one could be a SAP ecosystem, and the other two for different technology ecosystems. Remember that the individual CIs in the CMDB can possibly link to CIs that are in another CMDB. Example: A .net application that retrieves data from an SAP system. Also, in a CMS you have various other databases like the known error database (KEDB), incident records, problem records, service request records, and change records. The data within the CMS can get interlinked to support the service management practices. Suppose a server goes down and the corresponding CI gets mapped on an incident record. With a workaround put in, a problem record is raised and the same CI gets mapped in there. A permanent solution is identified, which requires the server configuration to be changed. A change record is raised and the server CI is mapped. Likewise, no matter what activity you perform within the service management space, they all come under the CMS.

Remember that there could be multiple CMDBs in an organization, and all the CMDBs and other databases will be part of a single CMS .

Service Model

A service model is also referred to as a service map. It is a graphical view of the CMDB that showcases the relationships between the interconnected CIs. A view of a service model is shown in Figure 9-4.
../images/385197_2_En_9_Chapter/385197_2_En_9_Fig4_HTML.jpg
Figure 9-4

Illustration of a service model

In this simplistic example, there are 2 services that are powered by 3 applications. Applications 1 and 2 are required for service 1 to function, and applications 2 and 3 are required for service 2 to function. These applications are hosted on servers as shown in the figure: application 1 on server 1 and applications 2 and 3 on server 2. There is a database that is utilized by applications 2 and 3, and this database is hosted on server 1. Both the servers are hosted in a data center.

The value is not in representation of a CMDB in a graphical format ; it lies in its application. If an incident is reported that service 1 is down, the incident management practice would look at the service model and determine the dependencies—namely application 1, application 2, database, server 1, and server 2. Then they start troubleshooting by tracing the data flow and connections.

Remember that the connections between CIs have a relationship name, such as parent of, child of, hosted on, mounted on, etc. Based on these relationships and dependencies, the efficiency of resolving incidents will improve multifold.

Another example is that of the change management practice. If a change is raised to make configuration changes to server 2, then based on the service model, the change manager can ensure that all the applications and services that are dependent on server 2 are onboard the proposed configuration changes. This will ensure that no unwanted changes go into the system, and the changes that do go in have been thoroughly scrutinized by all stakeholders. The service model will also serve as a tool for identifying stakeholders as well .

Note

The real value of a service model or configuration management in general is not seen by the business or visible to the outside world, but it is the engine that powers all other practices that services depend on.

Primary Activities of Service Configuration Management

Service configuration management activities have multiple phases, like identifying the relationships and the CIs, validating that the CIs and relationships are accurate, and leveraging the CMDB to provide reports for various purposes. Broadly, it’s divided into four major activities.
  1. 1.

    First and foremost, the CIs have to be identified and populated in the CMDB. Their relationships with other CIs must be defined.

     
  2. 2.

    Changes are common, which means that the CIs in the CMDB change as and when a change is applied. The next process is to modify changes to the CI and the CMDB when changes are implemented.

     
  3. 3.

    Unauthorized changes are prevalent, which means that some changes could be performed outside the change management practice. Also, there is a possibility that the activity of identifying may not have been done with 100 percent accuracy. So, it is imperative for the service configuration management practice to conduct periodic validations across the CMDB. These validations could be done through technology and automation.

     
  4. 4.

    To formalize the validations, an auditor could be employed to perform checks against the CIs that are in the CMDB and against those that aren’t. An auditor might walk into a datacenter and randomly choose a server from a rack and pull up its details in the CMDB. The details in the CMDB are compared with the physical CI. An auditor could also come powered with discovery tools that will help uncover CIs that are not in the CMDB or vice versa.

     

Engagement in Service Value Chain

Knowledge Check

The answers are provided in Appendix.
  1. 9-1.
    Which of the following is the true purpose of information security management practice?
    1. A.

      To protect the information needed by the organization to conduct its business

       
    2. B.

      To protect the financial and regulatory information of the business

       
    3. C.

      To ensure that the systems, information, and networks are adequately secured against security threats

       
    4. D.

      To ensure that a security ring fence is built to protect the knowledge that the company holds in its repositories

       
     
  2. 9-2.
    Which of the following is the right definition of an IT asset?
    1. A.

      An IT component that goes through the life cycle starting from procurement to disposal

       
    2. B.

      A component that has a financial value and is owned by the service provider to provide services

       
    3. C.

      An IT component that is required to deliver a service

       
    4. D.

      Any financially valuable component that can contribute to the delivery of an IT product or service

       
     
  3. 9-3.
    What is the difference between CMDB and CMS?
    1. A.

      CMS consists of all the physical systems, while CMDB is a database of IT assets.

       
    2. B.

      CMDB has incident records, problem records, and others along with IT assets information; CMS contains multiple CMDBs.

       
    3. C.

      CMS is a database of CIs and CMDB consists of multiple CMS.

       
    4. D.

      CMDB is a database of CIs and CMS consists of multiple CMDBs.

       
     
  4. 9-4.
    What is the primary objective of a service model?
    1. A.

      To provide a graphical representation of the CMDB that will help projects understand the architecture and make decisions related to planning and improvements

       
    2. B.

      To provide a graphical representation of CIs and their relationships that will help the organizations identify the CIs whose relationships are not defined, thereby supporting the verification of the CMDB

       
    3. C.

      To provide a graphical representation of the CMDB that will provide an overall architecture of the services, and this can be used for making architectural decisions

       
    4. D.

      To provide a graphical representation of the CMDB in order to increase productivity, reduces outage times, and provide support for making decisions

       
     
  5. 9-5.
    Which of the following is the correct definition of a configuration item?
    1. A.

      Any financially valuable component that can contribute to the delivery of an IT product or service

       
    2. B.

      Any component that needs to be managed in order to deliver an IT service

       
    3. C.

      Any component that delivers value to a customer through the efficiencies provided by the incident management practice

       
    4. D.

      Any financially valuable component that needs to be managed by the service management practice

       
     
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.222.110.189