Hgc Servicenow Cmdb101

(1)

HICHEM GUEMIRI PATRICK LAROCHE NOEL NATHAN ALAIN LAPOINTE MAXIME CARRIER XOLANI NGWENYA

SER V I C E N O W

©

CMDB

101 AWAKEN YOUR SERVICE

MANAGEMENT FROM WITHIN

HGC TECHNOLOGIES INC.

(2)

(3)

C O N T E N T S

WHO WE ARE? ... 5

WHY WE WROTE THIS BOOK? ... 6

1. HOW TO PLAN YOUR CMDB ... 7

1.1 Set your CMDB now! ... 8

1.2 How to get you started? ... 9

1.3 How to get there? ... 11

1.4 How to prepare? ... 18 2. DESIGN YOUR CMDB ... 29 2.1 CMDB design policies ... 30 2.2 CMDB design workshops ... 30 2.3 CMDB design delivrables ... 31 2.4 CMDB design approach ... 33 2.5 CMDB design automation ... 55 3. CONFIGURE YOUR CMDB ... 57 3.1 CMDB table classifications ... 57 3.2 CI ownership ... 60 3.3 CI status ... 60 3.4 CI service mapping ... 63 3.5 CI relationships ... 65 4. CONSTRUCT YOUR CMDB ... 72 4.1 CMDB implementation best-practices ... 73 4.2 CMDB data loading ... 76 4.3 Implementation tips ... 77 4.4 CMDB ServiceNow© _{adaptation ... 78} 4.5 CMDB ServiceNow© _{plugins ... 78} 4.6 CMDB implementation plan ... 79

4.7 Data loading activities ... 81

CMDB DEFINITIONS ... 84

THE AUTHOR ... 86

THE COLLABORATORS ... 87

(4)

You’ve been asked to implement a CMDB in ServiceNow®_{. Or, you will soon have to}

improve the information that is found in your current CMDB.

There’s no surprise there! Statistically, most CMDB projects fail for many reasons, but the main reason being, lacking a practical approach to implementing a sustainable CMDB. With this book, you will start with the right approach – one that is logical and practical. So, stop chasing the unicorn and finally get on the right track to awaken your operational service management from within, by implementing your trusted

CMDB in ServiceNow®_!

To help you succeed where others have failed, we have put together this book based on vast experiences in helping many customers achieve their objectives and goals in implementing a sound CMDB.

In addition to this book, we have consolidated and made available, all the original diagrams found in this book. All documents are available on our website as a com- plementary download. Go to our website WWW.HGCNOW.COM or send us an email at [email protected] to get the link to download the diagrams.

Regards,

HICHEM GUEMIRI

(5)

SER VICENO W CMDB 10 1

WHO WE ARE?

We are a modern-day consulting firm focused entirely on providing advisory, admin-

istration, and development services exclusive ly on the ServiceNow® _{SaaS platform.}

Allowing clients to augment, improve, and evolve their IT and Business Service Management.

As a reputable ServiceNow® _{Partner based in Montreal, Quebec, we have over 15 years}

of experience in designing and building innovative solutions to ensure clients obtain the value they seek. Our services are tailored to each client’s unique requirements. We can do so through lessons learned, keeping abreast at industry best practices and by being extremely active in the ITSM, ITOM, and ITBM community.

Our technical expertise and capabilities cover the following aspects of all services delivered: project lifecycle, strategic planning, enterprise architecture, process inte-

grations, application development, program governance and ServiceNow® _mainte-

nance and support – all supported by our recognized IT management and governance practices.

Our service offerings provide the following benefits to our clients: • PROVEN: experienced and highly trained team.

• AGILE: adapt the solution and services offered to suit any organization’s unique business needs and outcomes desired. This may include a full turn-key support solution, or integrating with existing IT service providers, or specialist applications support teams.

• INNOVATIVE: committed to continually develop and improve the services offered

to ensure clients are kept in step with the latest developments in ServiceNow®_.

Leveraging our unique implementation approach, clients can have a clear understanding of all the essentials for a successful project delivery. Our mantra and methodology helps lower organizations’ implementation and maintenance costs as well as associated risks.

Our CMDB implementation approach, which can be adapted as your own CMDB Mantra, was developed using the following principles and guidelines:

• MINIMIZE manual data entries and maintenance -- promote automation when- ever and wherever possible.

• ACCOMODATE the right adaptations and customizations based on lessons learned as well as industry best practices.

• MAXIMIZE design simplicity in ServiceNow®_{, establish data ownerships, and}

responsibilities in ServiceNow®

• ALLOW for an easy path to upgrades by documenting all configuration, devel- opment work, incidents, and enhancement requests, all within the same space

in ServiceNow® _{- the single source of record.}

(6)

WHY WE WRO TE THIS BOOK?

The purpose of this practical CMDB design book is to provide you with a consistent

approach to develop and design a CMDB in ServiceNow®_{. This book will provide}

step-by-step instructions for creating an effective CMDB blueprint model to be used and awaken your service management from within by empowering you to make better decisions.

Service Asset Management and Configuration Management, collectively referred to as SACM, are the foundational processes that seek to provide an accurate and logical model of the IT infrastructure and the relationships that exist between components, systems, and provided services. They are one of the components of a larger IT Service Management vision that seeks to ensure Business Services are aligned with business needs. It also provides the core data used in other related processes such as Incident resolution, Problem analysis, Change Management risk analysis, Release Management development and design, to mention a few.

We have worked on this practical CMDB book with a single mindset! ‘Keep it simple’. Each chapter is divided into simplified practical steps that we use with many customers. Our approach has improved and amplified in our breadth of knowledge with each engagement.

The simple key to a successful CMDB implementation is to bring together people, process, and product. We hope this methodology will help you write you own CMDB

mantra, re-imagine your current CMDB and help you implement ServiceNow® _on

the right foot.

In this book, you will learn how to build and group Configuration Items (CIs) into a collection of CI Families and define CI Types - which can be used to further classify your CIs into sets of standards, common, and mandatory attributes based on the types of CIs involved.

This book was designed for anyone interested in implementing a sound CMDB but primarily for those with the following roles inside your organization:

• IT Executives • Enterprise Architects

• ServiceNow® _{System Administrators}

• ServiceNow® _{Implementation specialists}

• Process Managers • CMDB Process Owners • CMDB Librarians • CMDB CI Managers • CMDB CI Analysts 6 HGCNOW.COM

(7)

HO W T O PLAN Y OUR CMDB

Your ServiceNow® _{CMDB must allow you to identify, control, record, track, report,}

audit, and verify the value and ownership of all service assets throughout their lifecycle, including Business Services and all supporting services of your business. There are so many guides and information available about the steps needed to take for effectively building a CMDB, but none that spell out (step-by-step) an exact

practical methodology to design and implement a CMDB in ServiceNow®_.

FIGURE 1 – SERVICENOW© _{SHARED CMDB ARCHITECTURE}

Your CMDB must also provide a single logical view of all Asset Service CI components and relationships needed to effectively deliver Your Business Services to your customers via a single Portal. It also controls the revisions to all components of the infrastructure.

To make your IT service delivery effective and bring value to your users and customers you must bring together the following three elements: people, process and products.

(8)

S E R V I C E N O W CM D B 10 1

1. 1 SET YO U R CMD B NO W !

Configuration Management Database (CMDB) is a system, a database schema that holds all the information, inventories and documentation of both logical and physical components glued together allowing you to represent and manage your business services and service offerings.

The primary use of a CMDB is to help all the other processes become more effective and efficient by providing a consistent set of managed information regarding all service delivery components within your organization, including both your internal and external environments – including cloud services.

When information regarding the elements is provided by multiple sources, a federated CMDB provides a clear context on all and any services offered which enables greater coordination across your organization.

It is important to note that this book is not intended as a replacement to any existing

ServiceNow® _{documentation and official ServiceNow}® _{Wiki pages. It is intended}

to be a supplemental source of information provided by our experienced crew gathered over the last decade.

FIGURE 2 – SERVICENOW© _{APPLICATION CAPABILITIES}

The reasons for implementing a CMDB are far greater than just aiding the Change Advisory Board (CAB) in understanding the impact of a pending change. It is intended to provide a comprehensive view on which Configuration Items (CI) are linked to a Business Service, allowing you to understand the true impact of an out- age, an event or any organizational changes at large. Therefore, a truly federated CMDB should and must provide a solid foundation for enabling your organization to improve your day to day operations and the delivery of IT business services by understanding all the layers involved in the delivery of your IT services.

(9)

1.2 H O W T O G E T Y O U S T A R T E D ?

A well thought out plan is the key to achieving any objective in life. This also holds

true for deploying a federated CMDB in ServiceNow®_{. This means that, prior to}

deploying Service Asset & Configuration Management process or any other process, you need to identify what business services you must support, which CIs are needed to provide those business services and where/how are they to be implemented and maintained in a federated, single source of truth, CMDB.

You will also need to identify and implement the appropriate go ernance regarding how each CI type and attribute is added, kept current, controlled, and used by each process that has been implemented. The Service Asset and Configuration Management (SACM) processes enhance the links between the Service Management processes by providing standard data and historical information for all configuration items.

FIGURE 3 – SERVICENOW© _{CMDB ARCHITECTURE MODEL}

The ServiceNow® _{platform features a powerful single source of truth, a CMDB sys-}

tem and foundation to accelerate incident resolution, problem analysis and impact of changes. Your first and foremost goal of implementing a CMDB is to automate to the maximum all IT processes and leverage that information to assess and prevent impact to the critical business services; truly enabling the phrase – a happy customer, is a returning customer.

Establishing and agreeing on mission statement for your CMDB is by far one of the most important steps. Going through this process will ensure all contributors

(10)

and stakeholders are on the same page as to what you plan on achieving, why, and how you plan on getting there. Once you implement your CMDB, you will be able to achieve the following:

• Reduce risks, contribute to contingency planning and improve the ability of your organization to perform impact and risk analysis for Changes.

• Enable effective scheduling of changes through improved awareness of service windows and improved security through control of CI versions.

• Provide problem management with data on problem trends and increase the ability to deliver on SLAs.

• Improve the effectiveness of all Service Management processes.

• Support and improve release management, help with financial and expenditure planning.

• Track, manage and control valuable CI information. • Facilitate adherence to legal obligations.

• Facilitate Demand and Capacity management.

Your future ServiceNow® _{CMDB provides the mechanism for controlling the IT infra-}

structure and services, which provides the basis for satisfying the following business needs and drivers:

FIGURE 4 – CMDB BUSINESS DRIVERS

(11)

1.3 H O W T O G E T T H E R E ?

As we mentioned previously, you should not jump into implementing a CMDB without a clear vision supported by a strong mission statement. Controlling the IT infrastructure and business services across distributed systems and support groups requires careful planning. You should aim to have your CMDB include Inventory management and IT Asset Management. The Change & Release Management processes should work together and share the many interdependencies on a single CMDB.

FIGURE 5 – CMDB BUSINESS DRIVERS

To move forward with implementing a CMDB you will need to obtain the stakeholder’s requirements and combine those with business drivers, which you can then develop into a plan.

Our recommended approach involves practical steps and a phased implementation approach. We will discuss in more details the various implementation possibilities. This phased approach will ensure the resulting design and plans are aligned with your vision, mission statement, and goals. It will also help deliver early benefits required to establish the need to provide funding and resources for expanding the role and scope of your CMDB.

The four essential steps, will be addressed as part of our methodology in more detail as you move in adapting our mantra. With this book in hand you will be able to reduce many of the frustrations experienced by other organization that have failed

in their attempt to implement a federated CMDB on the ServiceNow® _platform.

1.3. 1 ES T A B L I S H Y O U R V I S I O N & GO A L S

Most often the primary use of a CMDB is to facilitate incident management by linking the incident record against the faulty CI. The use also extends into Change Management by making it easier to assess impact and risk. Other usages can include visualizing and displaying business service representations, and identifying applications’ infrastructure component dependencies.

(12)

As stated earlier, reviewing and agreeing on the vision, mission statement, and goals for your CMDB implementation is the most important step. Executing and going through this initial step will ensure all contributors’ and stakeholders’ expectations are aligned in so far as the road to take to achieve your federated CMDB.

To create a federated CMDB that effectively aids the goals of all other ITSM and ITOM processes:

• Incident Management – enable quick Incident resolution by providing information on on-going incidents related to a Business Services’ CI.

• Change Management – assist in risk management by displaying the connected components of a Business Service.

Based on your mission statement, an implementation roadmap should be developed that spells out how these capabilities will be obtained in an orderly, phased fashion. Be sure to recognize the key benefits and value propositions for each usage identified. The implementation of the CMDB enhances the links between the service management processes by providing standard data and historical information for all CIs. And in defining a vision for managing your IT department, you will be able to reduce the cost of managing your IT.

Your project goals and desired capabilities might include, but are not limited to, the following:

• Develop and populate a CMDB to support the implementation of a future ITSM tool set.

• Provide a complete list of infrastructure CIs that support a business service, aiding in understanding the true cost of delivering said service.

• Provide a sound basis for incident management to improve the first-call resolution rate on the help desk.

• Improve the rate of successful changes by offering necessary information to support the change management process.

• Discover all infrastructure CIs and their relationships, verify the configuration records against the infrastructure and correct any exceptions.

• Provide data that enables IT organizations to write and meet comprehensive SLAs in the future.

• Provide a central repository for asset data to optimize controls for software licenses, leases, warranties, retirement, depreciation and total cost of ownership (TCO). • Enable low-risk infrastructure upgrades and changes, increase security and

reduce service outages.

For your organization to fulfill its common mission and communicated goals during the initial phase of implementing the SACM process, there are several activities and control mechanisms that must work effectively and in unison.

(13)

1.3.2 S E T Y O U R P R O C E S S G O V E R N A N C E

In most cases, it is common for organizations to begin with Inventory Management process, develop the Asset Management process, and finally the SACM process. Each process builds on the core data provided and managed by the previous, but it is important to note that these processes are not synonymous. Inventory Man- agement, Asset Management, and SACM do share some of the same activities and core data elements, but these three processes have different goals and objectives.

• INVENTORY MANAGEMENT - deals with the physical inventory.

• ASSET MANGEMENT - extends inventory management to include financial management of the physical assets.

• CONFIGURATION MANAGEMENT - further extends the two above to include the relational management of components, physical and non-physical, to provide a logical model and control over systems, business services, and supporting infrastructure.

Start by assigning a SACM process owner who will be responsible for owning the CMDB strategy, structure, and process. Working with your organization’s stakeholders, one of the first tasks that the process owner should undertake is creating and ratifying a common mission. In general, The SACM vision should define scope, span, roles and responsibilities, naming conventions, guiding principles, references to other related processes and standard operating procedures.

It’s crucial that your stakeholders and all participants in the SACM process must understand their roles and responsibilities, as well as the common roles and related responsibilities.

As presented previously, for a SACM process to fulfill its mission and goals, there are several activities and control mechanisms that must work effectively and in unison:

• PLAN and define your purpose, scope, objectives, policies and procedures, and technical context for implementing SACM process in your organization. • IDENTIFY the configuration structures for all the infrastructure configuration

items (CIs), including their ‘owner’, their interrelationships and configuration documentation. This includes allocating identifiers and version numbers for CIs, labeling each item, and entering it into the Configuration Management database (CMDB).

• CONTROL that only authorized and identifiable CIs are accepted and recorded, from receipt to disposal. It ensures that no CI is added, modified, replaced or removed without appropriate controlling documentation (approved change requests, and updated specifications).

• VALIDATE the reporting of all current and historical data concerned with each CI throughout its lifecycle.

(14)

1.3.3 D E S I G N Y O U R C M D B M O D E L

The CMDB blueprint model provides a representation of all the CI information within the scope and span of your configuration process effort. Based upon the outcomes of the previous step, determine what types of records and data can enable you to achieve your vision and goals. The diagram below depicts a practical approach to document your CMDB blueprint. We will address in detail; the steps required to reach and deliver the model below.

A CMDB integrates information from many sources including: • Incident, problem, change and release records

• Known error and knowledge management records • Application and infrastructure records

• Assignment groups, service level agreements (SLAs), operating level agreements (OLAs) and underpinning contracts (UCs)

• Corporate data about employees, suppliers, business units, and customers • Measurement and reporting metrics

We recommend you design a blueprint structure in a manner where it’s a balance between the following elements:

FIGURE 6 – CMDB DESIGN BLUEPRINT STRUCTURE

To build a CMDB, first design it by starting to determine how CIs will be categorized. Many organizations find groupings, types, CI family and classes to be an acceptable starting point. Then, decide on a naming convention and document where and how the data should be integrated into your CMDB.

(15)

A naming convention is essential for your organization, utilizing a standard naming convention helps to ensure the integrity of other IT service management processes. After categorization and naming conventions are in place, design your structure and align it with your mission and goals, considering your business priorities.

A good rule of thumb when designing your CMDB is to lean on the side of collecting less. Not all available data provides value and collecting excessive data can lead to an expensive system that is difficult to build and challenging to maintain. We will address this in more detail below.

You CMDB design is mainly based on inputs gathered from each design workshop’s participants and might include the following questions:

• Which raw data is currently managed and tracked by each team? • How are services being delivered to customers?

• How do clients view your IT department?

• Identify what can be discovered, manually entered, controlled and maintained. • What information and data to consider, present, link, maintain, and control for

managing your business services?

Construct the CMDB service model blueprint using the requirements identified for the Service catalog, the IT business processes, and the IT service model design, by assessing the data required. Then, present your model for approval by the stake-

holders before proceeding with the CMDB implementation in ServiceNow®_.

FIGURE 7 – CMDB DESIGN STEPS

1.3.4 C O N S T R U C T Y O U R C M D B

Once your CMDB structure is defined, you should determine how your organization populates CI information (this can include using a phased and/or waved approach). Additionally, the order of execution is important to identify as well are ownerships and support groups for all CIs.

Investigate what current tools are available for collecting, storing, managing and updating the data. Identify which tools meet the defined requirements and which requirements have yet to be met by existing tools. Knowing your solution inventory by product area will have a huge effect on the creation of your CMDB data model in

ServiceNow®_{. Also, deciding to use ServiceNow}® _{Discovery and/or Service Mapping}

capabilities might impact your scope and planning.

(16)

Use tools to automate data collection and help mitigate the risk of errors that can be introduced by manual data entry. An effort should be made to identify any additional tools that could help in the automation process and determine if a business case can be made to support their purchase.

The most important decision in adapting the CMDB in ServiceNow® _{is to understand}

the ServiceNow® _{data model, which tables to use and when to extend a table or a}

field. The model will cover the METHODS and PRODUCT definitions, as well as the data population strategy. Begin by taking an inventory of your organization’s existing data repositories that are internal and external to IT, this will facilitate in establishing priorities for each usage.

FIGURE 8 – CMDB DESIGN SCOPE + SPAN = ROADMAP

Once these repositories are identified, it is equally important to discover the following information for each:

• Primary purpose of the data • Location

• Owner

• Users of the data • Accuracy of the data • Completeness of the data • Level of detail

• How is the data supported and maintained? • Is the data integrated with change management? • What is the single trusted source for the data? • Is the data federated or is it replicated?

Next, assess and plan the level of work associated with scrubbing the data and gathering new data in support of the requirements. In some instances, you may even find it more effective and efficient to discard existing data and start from scratch.

(17)

FIGURE 9 – CMDB DESIGN FEDERATION

It is extremely important to plan for improvements and automation where oppor- tunities exist. One of the most widely used improvement process is the infamous Deming Cycle (plan, do, check and act). To ensure your CMDB is providing the expected value, this requires a measurement and reporting strategy combined with a continual improvement process.

Before populating the CMDB manually, you must identify what can be discovered and what must be manually entered as well as maintained. Ideally, you are better off investing in automation by federating the information in the CMDB.

You should establish your ServiceNow® _{CMDB as the reliable and centralized authori-}

tative reference which houses the description of the CIs you’ve identified and seeking to manage by their ‘approved-for-service’ Configuration attributes. This requires the data to be managed across a full lifecycle, from originating, to maintaining it for utiliza- tion, and then sustaining its verifiability to determine whether it is current or obsolete. The representation of authorized CIs must be modeled first and foremost. The type of a CI determines the criteria by which it may be uniquely recognized in management processes such as discovery, classification and registration. All of which aim to detect and assure that a CI is recorded, deployed, and accountable in compliance with approved specifications.

The ServiceNow® _{platform is based on service-oriented architecture (SOA), in which}

all data objects can use web services to access bi-directional data-level integration. The interface is also direct and dynamic because all modifications to existing objects and all new objects are automatically published as a Direct Web Service. A more indirect web service creation and usage can be achieved through Mapped Web Service where a transform map is used to gather incoming web service data into the final target.

(18)

1.4 H O W T O P R E P A R E ?

Our recommendations are to undertake the following activities before you proceed with your CMDB initiative:

• Identifying a process owner and the relevant key stakeholders [users / customers / service owners, etc.…]

• Appointment of a Configuration Management & CMDB Team • Documenting and keep current your CMDB blueprint data model • Analyzing existing systems

• Documenting and establishing a roadmap strategy

• Developing a configuration plan and high level system design • Plann strategically and implement tactically

This activity is not likely to be as resource intensive as subsequent phases, but will require clear senior management support to be successful. The goal is to define and agree to the conceptual process definitions, mission, goals, objective and scope), perform a high-level analysis of current systems, processes and related initiatives, determine requirements and create a high level conceptual design most appropriate for.

FIGURE 10 – CMDB PREPARATION STEPS

1.4. 1 B U I L D Y O U R P R O J E C T T E A M

Since a tight relationship exists between Change, Release and Configuration Man- agement, it is advisable that all be considered together holistically. A single initiative may be required if a central function is to be set up to support these three processes.

A central function may be responsible for managing changes to hardware, software, communication equipment, documentation and procedures that are relevant to support and maintain your business services.

The management of these changes, and the rigor with which they are enforced, is a key element for a successful Configuration Management process. The SACM process requires staff who will adopt a disciplined and painstaking approach, all the while paying due attention to detail.

(19)

FIGURE 11 – PROJECT TEAM

A project team that is required to deliver any CMDB initiative, needs to determine the number of resources required. The following must be considered:

• Whether the Configuration Management team can be assigned as part of other responsibilities

• Whether the Configuration Management team is to be responsible for projects as well as the infrastructure

• Whether the group is to be part of a joint Change, Configuration Management and Release Management team

• The size of the IT infrastructure and the level at which control is to be maintained (number of CIs to be controlled)

• Number of staff who will be performing control activities in other groups and projects

1.4.2 B U I L D A S A C M P R O J E C T C O M M I T T E E

The degree to which a CMDB can be effectively implemented is based upon several systemic variables and factors. These domains of control reside (at least during critical provisioning and deployment processes) within your organization.

As part of a foundational CMDB process, entry points of control are critical to foundational data. The control processes & systems which provide these entry points of controls and governance must be controlled and tightened. Ownership and stew- ardship of data must be formalized.

(20)

This phase begins after you have successfully identified the process owner and respective key stakeholders. Once you have done that, your next step is to bring the two together for formal meetings aiming to define and agree on the process’ definition, goals, objectives and scope using the ITIL process documentation as the starting point and comparison. The objectives of this phase are to:

• Define the processes’ purpose and high level objective based on your IT business drivers

• Derive a list of detailed objectives (measurable process deliverables)

FIGURE 12 – SACM TEAM

To ensure stakeholder, input and consensus, a review committee/working group of key stakeholders should be established to promote ongoing process development and improvement. Initial key stakeholders would likely include Change, Release, Inventory/Asset, and Continuity process owners to start. Service Level Management, Financial Management and Security Management would be phased in as appropriate. A key to a successful CMDB implementation is to enforce Change Management Process by:

• Always attaching a Change to an existing and valid CI in the infrastructure • Open a service request for any non-existing CIs, which can then be investigated

and added to the CMDB accordingly, helping future change records from being easily created.

(21)

• Update the CMDB with the CIs version, once the change has been executed successfully.

• Identify which CIs are not controlled by Change Management by adding an attribute. For example, end-user computing CIs are not usually controlled by Change Management.

Facilitation of formal discussions between the process owner and the committee of key stakeholders will better position the successful implementation of the process by clarifying business requirements, identifying tactical changes (i.e. “quick wins”), and developing a longer-term strategy for positioning people, processes and tools.

1.4.3 P E R F O R M A N A LY S I S O F E X I S T I N G S Y S T E M S

To introduce a common CMDB with consistent processes, the following must be identified and analyzed:

• Determine or establish owners of high level CIs (Services, systems, platforms, application, etc.…)

• Current scope and resources (people and tools).

• Current Asset Management, Configuration Management and Change Manage- ment practices, processes and procedures.

• High-level Configuration data held in current inventories, hard copies, local spreadsheets and databases.

• Roles, responsibilities and capabilities of staff involved in current Configuration Management activities.

• Determine organizational context, both technical and managerial, within which Configuration Management activities are to be implemented.

• Analysis of interfaces (projects, suppliers, application and support teams). • Assessment of relevant processes, procedures, guidelines, support tools, roles

and responsibilities for each of the Configuration Management activities. • Identify location of storage areas and libraries for hardware, software and doc-

umentation.

1.4.4 D E V E L O P A D E T A I L E D C M D B D E S I G N B L U E P R I N T

Controlling the IT infrastructure and business services across distributed systems, multiple locations and support groups, requires careful planning. The planning stage uses the process definition and current state analysis as a basis and involves coop- erative work with Release and Change Management processes, as there are many interdependencies among them.

Depending on available resources, the organization, and the IT infrastructure, Con- figuration Management may be a completely centralized solution or it may be distributed, based on technology or platform. It is vital that an agreement be reached on the high-level design plan before any detailed work begins.

(22)

FIGURE 13 – IT INFRASTRUCTURE MAP

Once the fundamental decisions on scope have been made and the planning activities have been completed, a detailed plan for implementation must be created. This will involve either creating or revamping procedures and records.

The key activities during this stage might include the following activities: • Develop and obtain agreement on roles, responsibilities and training plans,

documented in the previous stage.

• Analysis of existing Configuration Management activities in more detail, including interfaces to other processes, procurement and development.

• Analysis of the capability of existing functions and staff involved in Configura- tion, Change and Release Management.

• Review of Asset & Configuration data held in hard-copy, local spreadsheets or databases, and develop a conversion/loading strategy with each team. • Gather, refine, and gain agreements on functional requirements and specifications. • Develop criteria for any additional automation.

• Design the Configuration Management system in detail, including interfaces to Change Management, and other Service Management processes in scope. • Set up CI types, attributes, types of relationships, high-level CIs.

• Review SACM business processes and procedures that are integrated with the discovery/monitoring tools.

• Test the CMDB and other support tool(s) allowing sufficient time to rectify any problems with future implementation.

• Communicate and train staff in both the importance and use of Asset Manage- ment, Change Management and Configuration Management.

(23)

FIGURE 14 – CMDB BLUEPRINT MODEL

1.4.5 R E V I E W Y O U R S A C M P R O C E S G O V E R N A N C E & R O L E S

Turn IT process touch points with other IT functions into specific requirements. The requirements must reflect how other groups will interact with the CMDB and any special needs these groups have. A detailed SACM process must be designed with the following in mind:

• Maintain accurate IT infrastructure data by utilizing audits of “what should be deployed” against “what is discovered”.

• Learn how configuration items are changing over time through capturing the configuration of each CI, tracking changes to it, and providing analytics to report on the history of these configuration changes over time.

• Decrease IT system management costs by providing visibility on up-to-date IT resource data directly to the incident and problem management process. • Increase IT system availability by providing change coordinators visibility to

application relationships, helping drive detailed impact analysis and decision support and reducing unintended upstream and downstream impacts, of changes.

(24)

FIGURE 15 – SACM PROCESS ROLES

SACM ensures that selected components of a complete service, system, or product (the configuration) are identified, baselined, and maintained, confirming changes to these CIs are controlled.

These objectives are achieved using the following sub processes:

• Identify configuration items: defines the types of CIs and attributes that will be placed under control of Configuration Mgmt.

• Control configuration items: [add/update/delete] ensures that all additions, updates, and deletions have the appropriate controlling documentation. • Report configuration status: ensure information for all configuration items is

available to any authorized requester.

• Verify and audit configuration items: Verify that the CMDB accurately reflects the environment and established standards by performing periodic audits followed by remediation process to rectify any discrepancies identified.

1.4.5. 1 CI S e r v i c e O w n e r

The CI Service Owner is a person or a team that is responsible for data accuracy and relationship mapping between CIs for their own services.

• The application service CI ownership of an application is defined by the Portfolio Director.

• The CI ownership of technology components is defined by technology and infrastructure team.

(25)

This service owner role is represented by a subject matter expert for specific business service, and a supporting service model in the CMDB. Specific responsibilities may include:

• Business process manager or delegated business analyst

• Provide subject matter expertise to develop and maintain the processes and technology

• Identify new service to be included in CMDB • Create detailed data model for new service

• Ensure that all theirs CIs are recorded and the associate attribute and relationship information is accurate

• Perform in CMDB audits as requested by the SACM Manager

• Provide input to the SACM manager into what attributes and relationships need to be tracked within the CMDB

1.4.5.2 C o n f i g u r a t i o n P r o c e s s M a n a g e r

This role is responsible for the Configuration Management process, which is focused on identifying, documenting, tracking, and maintaining information about the Con- figuration Items (CI) in the CMDB.

The SACM Process Manager is responsible for populating the CMDB for all parties that are interested. His/her role also encompasses verifying that the data within the CDMB is fit for purpose. As the business and technology change, this role ensures that the CMDB content will change in a lock step manner.

The SACM manager role is responsible for the ongoing maintenance and accuracy of the CMDB repository which is used for impact analysis, technical diagnosis, and in service entitlement – as a potential later as the process matures. Specific responsibilities may include:

• Own, maintain, and continuously improve the Service Asset & Configuration process.

• Sponsor improvement initiatives and drive the requirements for the CMDB application.

• Report on Configuration Management activities, e.g. number of CIs populated, number of CIs associated with changes, etc.

• Trigger the CMDB audit process and define the scope of the audit based on the input from CI owners and IT management.

• Work with CI managers to prepare for any requested CMDB reports and queries. • Document and maintain the Configuration Management process.

• Develop, announce, and maintain Configuration Management feedback process as well as suggest areas for improvement.

• Improve the SACM process continually as required.

• Define what CIs to track and what kind of data attributes for each CI as well as how the data is captured and maintained.

(26)

1.4.5.3 C M D B A d m i n i s tr a t or

This position is responsible for overseeing the CMDB data management, focusing on information security, training, backup and recovery, and long-term planning. Some of the key responsibilities are:

• Work with the SACM Process Manager to audit the CMDB to ensure accurate and appropriate use of all the data found in the CMDB.

• Develop and implement data administration policy, standards, and models. • Develop policies and procedures for data access and usage.

• Establish data security programs and policies.

• Establish long range data capacity plans and extend the CMDB data model only when needed.

• Determine what new data is needed to meet the identified business needs. • Define what data is used by each department within your organization. • Define the process for maintaining data throughout its lifecycle.

• Determine when data can be purged either due to business requirements or if the data adds no value.

• Populates the CI data and creates new CI classes as needed. • Establishes baseline for managing the services.

1.4.5.4 C o n f i g u r a t i o n A u d i t or

The Configuration Auditor plans and executes the verification and audit of configuration data as well as validating the accuracy of the CMDB content. This is conducted based on a pre-agreed timeframe. Specific responsibilities may include:

• Planning the CMDB auditing.

• Performing the audit and collecting of audit information. • Identify unauthorized CIs.

• Communicate audit findings.

• Accept, verify, and initiate work relating to configuration audit requests. • Use tools for reporting and information collection regarding the CMDB.

1.4.5.5 C I A n a l y s ts

The configuration analysts are responsible for coordinating all Configuration Man- agement activities at the business unit level and/or per specialized infrastructure. Ex: Network Analyst, Server Analyst, Data Center Analyst, etc.

The Configuration Analysts coordinates all their respective department/group activities involving the CMDB. Some specific responsibilities may include:

• Identify and add physical and logical CIs. • Establish and construct CI relationships.

• Identify current data repositories, data sources, and work with the administrators to import the data into your CMDB.

• Responsible for the day to day updates to the CIs.

(27)

• Update the CMDB with new configuration items and relationships. • After the change is implemented, update the appropriate CI attributes and

relationships accordingly.

1.4.5.6 C o n f i g u r a t i o n C o n t r ol B o a r d

The Configuration Control Board is required to ensure that the overarching intention and policies of Configuration Management are employed throughout the Service Management lifecycle and with specific consideration for every aspect of the complete service. The Board has the following responsibilities:

• Defines and controls the service configuration baselines in terms of core and support services, applications, information, service, technical, infrastructure – ensure that they meet the requirements established in the Service Design. • Reviews changes in the service configuration for compliance with standards,

contractual and internal requirements.

• Originates requirement changes for service configuration to comply with con- tract change requests.

In some organizations, the Configuration Control Board will be combined with change, thereby providing a holistic view of the current and proposed services and service models, enabling better control, change evaluation, impact assessment and understanding.

1.4. A L I G N Y O U R R E P O R T I N G R E Q U I R E M E N T S

As with all processes, the performance of SACM should be monitored, reported on, and improved upon. To optimize the cost and performance of the configuration items, the following measures can be applied:

• Percentage improvement in maintenance scheduling over the life of an asset. • Degree of alignment between provided maintenance and business support. • Improved speed for incident management to identify faulty CIs and restore

service.

• Impact of incidents and errors affecting CI types, e.g. from suppliers or development groups, for use in improving the IT services, etc.

• Percentage of re-use and redistribution of under-utilized resources and assets. • Degree of alignment of insurance premiums with business needs.

• Achieved accuracy in budgets and charges for the assets utilized by each customer or business unit.

• Percentage reduction in adverse business impact due to outages and incidents caused by poor asset and configuration management.

• Improved audit compliance.

• Increased quality and accuracy of asset and configuration information. • Fewer errors caused by people working with out-of-date information. • Shorter audits as quality asset and configuration information is easily accessible.

(28)

• Reduction in the use of unauthorized hardware and software, non-standard, and variant builds that increase complexity, support costs, and risk to the business services.

• Reduction in the average time and cost of diagnosing and resolving incidents as well as problems.

• Changes that were not completed successfully or caused errors due to poor impact assessment, incorrect data in the CMDB, or poor version control. • Reduction in risks due to early identification of unauthorized changes.

(29)

2. D E S I G N Y O U R C M D B

SACM process is a requirement for an effective IT Service Management, and IT operations management. The SACM process relies on a solid inventory databases, as well as discovery and monitoring toolsets, which must be examined as part of your CMDB implementation initiative.

Configuration Management is responsible for tracking configuration information associated with hardware and software assets that are necessary to deliver operational services. During the first stage of the CMDB implementation, a project team must be formed, and the inputs should be gathered from various participants during the working sessions.

The CMDB model is needed to identify all the working data that will ensure that the SACM process will be able to meet its objectives. To help uncover your underlying CMDB and design it on paper you will need to seek answers to the following questions for all CIs that are in scope:

• Which raw data is currently managed and tracked by each team/unit. • How are services being delivered to clients (internal/external).

• Identify what can be discovered, manually entered, controlled and maintained • What information and data needs to be considered, presented, federated, main-

tained, and controlled for managing your business.

• Set standards and establish naming conventions for both CIs and relationships. • Manage movements into and out of secure libraries.

• Support configuration item audits and identify interdependencies. • Link configuration item changes to specific Requests for Change (RFC). • Which KPIs to track and which reports to create.

HGCNOW.COM 29

(30)

2. 1 C M D B D E S I G N P O L I C I E S

The most important key for a successful CMDB implementation is to establish your common CMDB design policies. As a general guideline and recommendation, the following policies can serve as a starting point:

• Align with enterprise architecture.

• Minimize manual data entries and maintenance (promote automation where applicable).

• Accommodate the right CI types that central IT might use (determine the value vs. complexity).

• Establish data ownerships and responsibilities.

• Maximize design simplicity so it can be applied to any IT unit.

• Support exploding business services into detailed CI’s that make up and support those services.

CMDB design principles are rules for managing configurations, ranging from identifying governance requirements to handling specific states of the configuration lifecycle, including procurement, retirement, and disposal of assets, as well as the detail and control required to maintain a desired level of traceability and auditability.

2.2 C M D B D E S I G N W O R K S H O P S

During the execution of the CMDB design workshops with the key stakeholders, you need to communicate your vision and goals as discussed in the previous chapters. Your objectives must be aligned and communicated up-front with the workshop participants. As a general guideline and recommendation, the following can serve as a list of CMDB objectives to adapt and use:

• Develop current state observations, target states, and design principles. • Enhance the future (to-be) configuration management process by improving

current policies, processes, procedures and establishing clear defined roles and responsibilities for managing CIs.

• Define and establish key performance indicators (KPIs) and associated critical success factors (CSFs) to effectively measure, report, and improve the configuration management process and CMDB (performance and accuracy).

• Develop the CMDB framework, which comprises of the conceptual CMDB data model and data sources.

• Develop a design document with supporting technical requirements in alignment with the enhanced configuration management process and approved conceptual CMDB data model.

• Identify key stakeholders and their business requirements through individual assessment meetings.

• Utilize inputs to identify and document the current state.

• Utilize inputs and ITIL CMDB “best practices” process activities to develop a desired or “target” state.

• Identify and assess gaps and issues that exist between the two identified states.

(31)

• Identify any gaps and issues for supporting processes.

• Prepare a summary of the findings and recommend a strategy for developing a formal CMDB implementation plan and design blueprint.

FIGURE 17 – CMDB WORKSHOP TYPES

2.3 C M D B D E S I G N D E L I V R A B L E S

The CMDB blueprint model (conceptual picture) is needed to identify the working data that will ensure that the SACM process meets its objectives with respect to the future requirements by other ITSM processes. Your expected workshop outputs can be summarized as below. But, your desired outcomes are not limited to list below.

• Establish common standards. • Review CI types and sub-types list. • Establish generic CIs (logical grouping).

• Determine what goes in the CMDB by order of importance and effort required. • Establish common CI attributes.

• Establish CI attributes and relationships by type of CIs.

• Establish and consolidate discovery sources for each CI type, attributes, and relationships

• Establish data sources and feeds for non-discovered CI types, attributes, and relationships

During the design workshop, you can provide your participants with a template workbook to fill any information they might have to help you to get started on mapping your services. Be forewarned – it is a rigorous exercise, but it will help you understand your services.

Our recommendation for documenting the workshop outputs is to document the information into separate Excel spreadsheets for each CI grouping (category). You can name your configuration workbooks as:

• CMDB- workbook-00-Reference Data • CMDB- workbook-01-Service

• CMDB- workbook-02-Application

(32)

• CMDB- workbook-03-Database • CMDB- workbook-04-Servers • CMDB- workbook-05-Data Center • CMDB- workbook-06-Network • CMDB- workbook-07-Telecom • CMDB- workbook-08-Storage • CMDB- workbook-09-Backup • CMDB- workbook-10-End-User Computing • CMDB- workbook-11-Hardware • CMDB- workbook-12-Other…

FIGURE 18 – CMDB WORKSHOP DELIVRABLES

NOTE: You can email us at [email protected] to get free copies of our con- figuration template workbooks including attributes by CI types, and proposed CI relationships.

(33)

2.4 C M D B D E S I G N A P P R O A C H

The Practical steps and guidelines to follow when documenting the CMDB blueprint can vary between each organization, depending on the goals you are trying to achieve or the issues you are aiming to resolve. But one constant element of this equation remains that you must obtain the right value versus the complexity of

building and managing your future CMDB in ServiceNow®_.

One way to define the CI attributes that you will maintain in the CMDB versus those that will reside in federated data stores is to establish a guideline based on Value vs. Complexity to maintain, as seen in the image below:

In the following sections, we will dive further into understanding the components of a CMDB blueprint, which can be simplified as:

• Business Services structure • Related processes requirements • CI types to include

• CI attributes to manage • CI relationships to control

2.4. 1 I D E N T I F Y Y O U R B U S I N E S S S E R V I C E S & M A P P I N G L A Y E R S

Services are defined in various places, and not all business services are defined and available in the current service catalog. Also, services are often referred to with application’s name.

• Definition of a service, per ITIL: A means of delivering value to customers by facilitating outcomes customers want to achieve.

• Definition of a service, per us: Any IT technology service made available to constituents in the context of their role(s), whether provided by central IT units or by some other supplier.

Identify requirements that specify how the service catalog will leverage the relationships between services and the underlying CIs. Understanding which CIs relate to a service enables you to better meet SLAs and allows you to conduct service-based costing during the design workshops. The analysis of the following questions will enable you to determine the types of attributes required to include in the CMDB design.

• A good understanding of the types of services your organization offers helps establish the CI structuring and relationships.

• Knowing the customers for the services you provide helps define CI relationships or attributes, or both.

• Understanding the services and infrastructure each service offerings relies on helps determine the CI structuring and relationships.

• Understanding service commitments helps define the CI attributes.

• Reporting requirements for effective delivery management helps define the CI Attributes.

(34)

The enterprise architecture approach is a layered view providing a natural way to look at the service-oriented models. The main objectives of EA are:

• Includes a formal description of a system, or a detailed plan of the system at component level to guide its implementation

• Document the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution

The business service depends on a network service, an application service, and so forth. By defining the business services as a CI in the CMDB and relating them to the technology services and the application services, will aid in identifying the impact of incidents and problems that are recorded against the infrastructure CIs or the application CIs to the business service.

FIGURE 19 – SERVICE ARCHITECTURE LAYERS

The service catalog includes specific business services to be available for use by the customer. These services are offerings that are bundled and consumed as requests on the portal or the regular application view of a Service Catalog.

The CMDB is a very effective tool, allowing viewing of information from both the service and infrastructure perspective. The following relationships were established to ensure that the CMDB will support an effective delivery of business services. The CMDB designs often overlook important service management attributes. Sam- ple service management attributes must include the following, as discussed during the workshops:

• Service level targets and priority

• Service entitlement information (hours of service, required approvals, etc.) • Service notifications, communication information, etc.

• Service owners (by their job titles, for example) • Service maintainers

• Service managers (by their job titles, for example)

(35)

FIGURE 20 – SERVICE MAP VS. SERVICE OFFERINGS

2.4.2 IDENTIFY REQUIREMENT S B Y PROCES S

SACM is the foundation process that endeavors to provide an accurate and logical model of the IT infrastructure as well as the relationships that exist between components, systems and provided services.

It is one component of the larger IT Service Management vision that seeks to ensure Business Services are aligned to business needs. It also provides the core data used in Incident resolution, Problem analysis, Change Management, Release Management development and design. It is important to understand that the processes are interrelated because the IT infrastructure being managed is also interrelated.

2.4.2. 1 C h a n g e M a n a g e m e n t

• Change requests to implement a new component (used for impact and risk assessments of a proposed change).

• Inbound and outbound CMDB controls and governance.

• The CMDB breaks down the barriers between IT and the business. The information removes silos and helps people, processes, and technologies work more efficiently together.

• As the complexity of the IT infrastructure increases, the CMDB containing information about all the CIs and how they work together will help avoid downtime, by more efficiently planning and better appreciating how those changes affect the business services.

(36)

• The CMDB will aid in better risk assessments and improve security. Use the CMDB data to assess the risks to the business associated with known vulnerabilities on servers and installed applications, which will assist in prioritizing changes on business services.

• Helps keep track of any changes in software. The data from the CMDB aids in determining if there are any unauthorized or illegal software being used. • The CMDB uses the concept of versioning. This allows the CMDB to track

the historical states of a CI over time and to determine recommendations for improvements to the business services.

• The various states of CIs can be compared to see what changes were recorded as of their evolution.

2.4.2.2 I n c i d e n t M a n a g e m e n t

• Helps to determine customer impact and assists with determining priority and severity of a failing component.

• Provides client and service criteria, as well as severity and priority information for configuration components based on service level objectives.

Usually, the lack of information found in the CMDB and the multiple operational toolsets used for monitoring, results in the following:

• Longer time to consolidate and detect issues. • Multiple configurations to maintain in various places. • Events at the Service Desk are not opened automatically. • Notifications and escalations not automated.

• No correlations between events and no automation to repair known issues.

FIGURE 21 – INCIDENT MANAGEMENT WITHOUT CMDB

(37)

FIGURE 22 – INCIDENT MANAGEMENT WITHOUT CMDB

2.4.2.3 Av a i l a b i l i t y M a n a g e m e n t

• Provides core data such as relationships between components to enable design of reporting and subsequent measurement of business services.

• Provides a central information repository that links availability, reliability and maintainability of services to the underlying IT components.

2.4.2.4 S e r v i c e L e v e l M a n a g e m e n t

• Identifies the IT infrastructure components that are required for the delivery of services to the customer, further allowing for accurate establishment and measurement of the objectives in a Service Level Agreement (SLA).

• Provides CI relationship data that links SLAs to customers and to all related CIs that are required to provide the service the Customer pays for.

2.4.2.5 S e r v i c e C a t a l o g

• Inventory of services (Services as CI’s) including business service, applications and technology services

• Presents configuration information about the services the clients are entitled to. • Provides configuration information about the components used to deliver ser-

vices to clients.

(38)

2.4.2.6 P r o b l e m M a n a g e m e n t

• Enables determination of components affected because of another failing component.

• Provides the IT infrastructure data required to identify root cause and course of action for problems.

• Asset and inventory tracking.

• Utilizes the same core data and are likely to interface for supporting license management efforts.

• Enables Operating Level Agreements (OLAs - with internal IT groups and external service providers) and Underpinning Contracts (UCs - with external service providers) showing customer ownership.

2.4.2. 7 B u s i n e s s C o n t i n u i t y

• Provides the baseline snapshot of the IT infrastructure which could assist in the recreation of an environment in the event of a disaster or major interruption to service delivery.

• Stores information about the IT infrastructure components, their configurations, and their dependencies to each other and key business processes.

• Identifies the priority and the agreed-upon minimum level of business operation following a major service disruption.

• Tune and/or upgrade various components to provide a higher confidence in high availability.

• Reduced cost of redundant systems by capacity planning at the group or organization level instead of the individual system level.

• Reduced time to resolve capacity-related incidents and problems.

2.4.3 U N D E R S T A N D Y O U R C I C A T E G O R I E S

A CI is any component or service asset that needs to be managed to effectively deliver an IT service. Information about each configuration item is recorded in a configuration record within the configuration management system and, is maintained throughout its life cycle by the SACM process.

Define the optimum level for CIs, both service CIs and infrastructure CIs, in your CMDB. This step helps determine the overall breadth and depth of the structure of your CMDB data model, based on the discovered information, inventory tools, and manually added data.

Construct the CMDB blueprint model using the requirements identified for the Service Catalog, the IT business processes, and the IT service model design, by assessing the data required. Then, present it for approval by your organization.

To better organize the workshops, process documentation, and configuration we recommend splitting your work into the following categories.

(39)

FIGURE 23 – CI CATEGORIES

2.4.3. 1 R E F E R E N C E D ATA

FIGURE 24 – REFERENCE DATA

(40)

Does the IT component represent a specific type of system, user, location, or organizational data that, when represented in a structured format, represents various types of information utilized inside the CMDB.

2.4.3.2 B u s i n e s s S e r v i c e S

FIGURE 26 – CI CATEGORY – BUSINESS SERVICES

(41)

A business service is composed of both physical and logical components. When building the CMDB it’s important to map your services manually but preferably automatically using both discovery tools and the operations solutions at your disposal.

• Service Portfolio: This object represents the top level of the service catalogue and represents a grouping of similar services.

• Service: A service is a combination of IT and non-IT systems that supports a business objective and is perceived by the customer as a coherent whole. • Sub-service: A sub-service is a discreet component of a service or services.

This level object is only used to provide clarity for complex services.

• System: An integrated composite that consists of one or more of the processes, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective.

• Sub-system: A discreet component of a system that is usually representative of a single function or purpose. This level object is only used to provide clarity for complex systems.

- Service availability & support - Service Cost

- Service metrics and SLA

2.4.3.3 A p p l i c a t i o n s

FIGURE 27 – CI CATEGORY – APPLICATIONS

(42)

Applications, residing on application servers, are a group of primarily software components that accomplish one or more tasks. This group is also viewed to be considered as a unit. Applications can be as simple as one executable file running on a single computer (such as Microsoft Word) or as complicated as a distributed multi-tier J2EE application, load-balanced across multiple web application servers. Managing software applications in the CMDB is not an easy task, but it starts with understanding what an application is. To maintain and manage applications inside your CMDB, use the following guidelines.

• Applications: A program designed to perform a specific function directly for the user or, in some cases, for another application program. Applications use the services of the computer’s operating system and other supporting applications.

• Middleware: Software that sits between two or more types of software and translates information between them. Middleware can cover a broad spectrum of software and generally sits between an application and an operating system or a network operating system.

• Application Management: Software that observes, supervises, controls, protects or verifies operations of a system.

• Software Logical Disk: A division of a disk or storage area that is treated by the operating system as a discrete physical disk.

• Network Protocol: Set of rules defining the syntax and semantics of commands and possible responses exchanged between two or more computers on a network, including the order in which the commands can be specified. • Operating System: Collection of software programs that supervises the exe-

cution of other programs and the management of computer resources. An operating system provides an orderly input/output environment between the computer and its peripheral devices. It enables user-written programs to execute safely. An operating system standardizes the use of computer resources for the programs running under it.

• Business Applications: The IT component of a piece of software; either pur- chased, developed, or composed (reuse of other software components) — that provides business functionality of a given service element or system?

- Developed or

- Service-specific commercial off-the-shelf (COTS) application

• Support Software: Is the IT component of a piece of software that indirectly supports a system function, but does not provide the core functionality of a given system? - Operating system - Backup software - Antivirus software - Monitoring software 42 HGCNOW.COM

(43)

FIGURE 28 – EXAMPLE APPLICATION CI TYPE

2.4.3.4 D a t a b a s e s

FIGURE 29 – CI CATEGORY - DATABASES

(44)

When you start adapting ServiceNow®_{, you will notice that the CMDB includes the}

following tables by default:

• Database: is a relational database management system (RDBMS) such as SQL Server, Oracle, mySQL, etc.

• Database instances: Are the instances of a database. (SQL: one instance can host several DB’s; Oracle: you can have two instances connecting to the same DB when using RAC)

• Database catalogs: Metadata information - dependent on the technology.

2.4.3.4 S e r v er C o m p u t i n g

FIGURE 30 – CI CATEGORY – SERVER COMPUTING

The Type of systems containing Computing Devices information are divided into the following,

• Hardware server: An electronic device designed to accept data (input), perform prescribed mathematical and logical operations at high speed (processing), and supply the results of these operations (output). A digital computer processes data as numbers and includes mainframe computers, minicomputers, and microcomputers.

• Hardware processor: The logic circuitry that responds to and processes the basic instructions that drive a computer or server.