Hgc Servicenow Cmdb101

HICHEM GUEMIRI PATRICK LAROCHE

NOEL NATHAN

MAXIME CARRIER

ALAIN LAPOINTE

XOLANI NGWENYA

SER VICENOW

CMDB

101

AWAKEN YOUR SERVICE MANAGEMENT FROM WITHIN

HGC TECHNOLOGIES INC. All rights reserved @HGCNOW

[email protected] WWW.HGCNOW.COM

©

C ONTENT 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 TABLE OF DIAGRAMS ................................................................................. 90

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 complementary 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 HICHEM @HGCNOW.COM

SER VICENO W CMDB 10 1

WHO WE ARE? We are a modern-day consulting firm focused entirely on providing advisory, administration, 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 integrations, application development, program governance and ServiceNow ® maintenance 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 whenever 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, development work, incidents, and enhancement requests, all within the same space in ServiceNow® - the single source of record.

HGCNOW.COM

5

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

SER VICENO W CMDB 10 1

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.

HGCNOW.COM

7

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 outage, 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. 8

HGCNOW.COM

SER VICENO W CMDB 10 1

1.2

HO W T O GET Y OU 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 system 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 HGCNOW.COM

9

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 infrastructure and services, which provides the basis for satisfying the following business needs and drivers:

FIGURE 4 – CMDB BUSINESS DRIVERS

10

HGCNOW.COM

SER VICENO W CMDB 10 1

1.3

HO W T O GET 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. HGCNOW.COM

11

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.

12

HGCNOW.COM

SER VICENO W CMDB 10 1

1.3.2

SET Y OUR P R O C E S S GO 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 Management, 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.

HGCNOW.COM

13

1.3.3

DESIGN

Y OUR

CMDB MODEL

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.

14

HGCNOW.COM

SER VICENO W CMDB 10 1

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 stakeholders before proceeding with the CMDB implementation in ServiceNow® .

FIGURE 7 – CMDB DESIGN STEPS

1.3.4

C ONS TRUCT Y OUR CMDB

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. HGCNOW.COM

15

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. 16

HGCNOW.COM

SER VICENO W CMDB 10 1

FIGURE 9 – CMDB DESIGN FEDERATION

It is extremely important to plan for improvements and automation where opportunities 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 authoritative 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 utilization, 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. HGCNOW.COM

17

1.4

HO 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

BUILD

Y OUR PRO JECT TEAM

Since a tight relationship exists between Change, Release and Configuration Management, 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. 18

HGCNOW.COM

SER VICENO W CMDB 10 1

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 IL D A S A CM PRO JE 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 stewardship of data must be formalized. HGCNOW.COM

19

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. 20

HGCNOW.COM

SER VICENO W CMDB 10 1

• 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 Management 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 documentation.

1.4.4

D E V E L OP A D E T A I L E D C M D B D E S I G N BL 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 cooperative work with Release and Change Management processes, as there are many interdependencies among them. Depending on available resources, the organization, and the IT infrastructure, Configuration 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.

HGCNOW.COM

21

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 Configuration, 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 Management, Change Management and Configuration Management. 22

HGCNOW.COM

SER VICENO W CMDB 10 1

FIGURE 14 – CMDB BLUEPRINT MODEL

1.4.5

R E V IE W YOUR S A CM P R O C E S GO V E R N A N C E & R O LE 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.

HGCNOW.COM

23

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. 24

HGCNOW.COM

SER VICENO W CMDB 10 1

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 io n Pr oc es 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 Configuration 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.

HGCNOW.COM

25

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

CI A n a l y s ts

The configuration analysts are responsible for coordinating all Configuration Management 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.

26

HGCNOW.COM

SER VICENO W CMDB 10 1

• 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 contract 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.

ALIGN Y OUR

REPOR TING R E Q U IR 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.

HGCNOW.COM

27

• 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.

28

HGCNOW.COM

SER VICENO W CMDB 10 1

2.

DESIGN

Y OUR CMDB

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.

FIGURE 16 – CMDB SCOPE & SPAN

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, maintained, 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

2. 1

CMDB

DESIGN POLICIES

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

CMDB DESIGN W ORK SHOPS

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. 30

HGCNOW.COM

SER VICENO W CMDB 10 1

• 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

CMDB

DESIGN DELIVRABLES

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 HGCNOW.COM

31

• • • • • • • • • •

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 configuration template workbooks including attributes by CI types, and proposed CI relationships.

32

HGCNOW.COM

SER VICENO W CMDB 10 1

2.4

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

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

IDENTIFY Y OUR BUSINES S SER VICES & MAPPING LAYERS

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. HGCNOW.COM

33

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. Sample 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)

34

HGCNOW.COM

SER VICENO W CMDB 10 1

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

Change

Management

• 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. HGCNOW.COM

35

• 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

Incident Management

• 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 36

HGCNOW.COM

SER VICENO W CMDB 10 1

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 el 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 Ca 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 services to clients. HGCNOW.COM

37

2.4.2.6

Pr 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

Busines s Continuity

• 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 TAND Y OUR CI 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.

38

HGCNOW.COM

SER VICENO W CMDB 10 1

FIGURE 23 – CI CATEGORIES

2.4.3.

1 REFERENCE

D ATA

FIGURE 24 – REFERENCE DATA

HGCNOW.COM

39

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.

FIGURE 25 – SERVICENOW © REFERENCE DATA ARCHITECTURE

2.4.3.2

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

FIGURE 26 – CI CATEGORY – BUSINESS SERVICES 40

HGCNOW.COM

SER VICENO W CMDB 10 1

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

Applica tions

FIGURE 27 – CI CATEGORY – APPLICATIONS HGCNOW.COM

41

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 execution 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 purchased, 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

SER VICENO W CMDB 10 1

FIGURE 28 – EXAMPLE APPLICATION CI TYPE

2.4.3.4

Da t a b a s e s

FIGURE 29 – CI CATEGORY - DATABASES

HGCNOW.COM

43

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. 44

HGCNOW.COM

SER VICENO W CMDB 10 1

• Hardware memory: The electronic holding place for instructions and data that the processor can reach quickly. • Hardware network interface: The device that connects the computer with other computers using some type of a communication medium. A network interface may be an Ethernet card, Token ring card, modem etc. 2.4.3.6

I n f r as t r u c t u r e C o m p u t i n g

Data Center Is the IT component a physical location that supports some form of IT operations or houses other IT components

FIGURE 31 – CI CATEGORY –INFRASTRUCTURE COMPUTING

Infrastructure CIs have a unique property – they can be layered in relation to the other CI types they support, particularly servers and applications. Infrastructure computing can be comprised of other infrastructure elements. Consider a business process which utilized a server/client application. The infrastructure elements can be identified in terms of (and in relation to the person executing the process): • • • •

Client – computer system, application interface. Network – routers, bridges, firewalls, access points, protocols, etc. Data Center – Power, UPS, Rack, Locations, etc. Facilities – power, water, cooling, space, etc.

HGCNOW.COM

45

2.4.3.

7 S t or a g e

FIGURE 32 – CI CATEGORY – STORAGE

Most of the complex CIs to map are related to storage; in the following section, we will illustrate how you can define the CI attributes and data model for storage, fiber and storage arrays systems. • Hardware Network Attached Storage (NAS): Storage that is set up with its own network address rather than being attached to the department computer that is serving applications to a network’s workstation users. • Hardware Storage Attached Network (SAN): A high-speed special-purpose network (or sub-network) that interconnects different kinds of data storage devices with associated data servers on behalf of a larger network of users. • Hardware Storage: The holding of data in an electromagnetic, optical, or electronic form for access by a computer processor. • Physical Disk: A storage medium consisting of a spinning disk coated with magnetic material for recording digital information. • Disk Array: A enterprise storage system that contains multiple disk drives. It is differentiated from a disk enclosure in that an array has cache and intelligence so can perform functions like RAID and virtualization. 46

HGCNOW.COM

SER VICENO W CMDB 10 1

Components of a typical disk array include: - Disk array controller - Cache - Disk enclosures - Power supply • Hardware Disk Enclosure: A computer storage device designed to contain physical disk drives. The term is normally used to differentiate such a device from a more advanced disk array. Therefore, a disk enclosure is a simple container, sometimes with a power supply, but very little intelligence. 2.4.3.8

B a c k up

The attributes are categorized mainly as CI type, CI status, common hardware attributes, software attributes, backup system attributes, and other attributes. A domain consists of a master server with one or more media servers and storage units. A media server may be on the same machine as master or on a different one. Storage units are owned and monitored by the master server, while the media server is responsible for doing the backup of data from the client to the storage unit. All servers which are backed up by the master server are called clients. A storage unit is represented by: • A storage unit CI is used as target for backup image by media server CI • A storage unit CI communicates with media server CI • A storage unit CI is controlled by media server CI

FIGURE 33 – CI CATEGORY – BACKUP HGCNOW.COM

47

2.4.3.9

End-user

C omputing

FIGURE 34 – CI CATEGORY –END-USER COMPUTING

Your CMDB must be designed to enable the centralized management of the financial, contractual and demographic data relating to hardware Assets and end-user computing related CIs such as Mobile phones, Workstations, monitors, etc. The same data used by Assets will then be found in the CMDB tables, this will enable you to make informed decisions regarding how assets can be used more effectively, when to retire or cascade and help in budget exercises to determine future needs of the Business based on the existing baseline. It’s recommended to integrate with discovery tools or use ServiceNow® discovery to discover your Hardware assets, populate the CMDB and then run hardware reconciliation to identify any disparities in the baseline to verify you have control over the environment and reduce the likelihood of rogue systems from being introduced or existing on the network and to also identify any missing hardware such as mobiles, laptops, etc.

2.4.4

I D E N T I F Y A T T R I B U T E S B Y CI T Y P E / T A B L E

CLA S S

The configuration management database (CMDB) employs the following tables: • The core Configuration Item [cmdb / cmdb_ci] tables, which stores the basic attributes of all the CIs. • The CI Relationship [cmdb_rel_ci] table, which defines all relationships between CIs. 48

HGCNOW.COM

SER VICENO W CMDB 10 1

When you design your CMDB, there are 3 types of CI Attributes to consider: ATTRIBUTE TYPE

DEFINITION

EXAMPLE

• ID

CORE

• Name • Owner Mandatory attributes that apply to every • Description CI Type in the CMDB. • Version • Status • Creation date • Update Date

• Server

CLASS

CUSTOM [OPTIONAL]

• Make Supporting attributes that are unique to • Model • Manufacturer a type/class of CIs. Categories are a special class of CI that • Serial number pass on attributes based on inheritance, • Document through parent-child relationships. • Version • Author • Editor Complementary attributes unique to a specific CI to provide detailed information not expressed in core or class based attributes.

Server ABC123

• Last security audit date/time • Operator minimum security clearance level

Attributes are data elements that describe CIs, much like adjectives that describe nouns. Attributes help to identify and detail the important characteristics of what is in use, the status of the items, and the item’s location. Samples of hardware CI attributes could include make, model, serial number, location, version, license number, and so forth. For each CI attribute to be considered, the following topics should be addressed during the design workshops: • What are the data sources that will populate your federated data model? • Where and how will the CMDB data be used in other systems? • How will you populate the CMDB with CI attribute information? • How can you simplify management of attributes through inheritance? Some examples of attributes per CI Types might include the following: • Application Software: code version, code language, build, compiler version, operating system version, image version. • Hardware: Manufacturer, make, model, serial number, MAC address, primary IP address (fixed), firmware version. • Documentation: version number, author, editor, review process HGCNOW.COM

49

CI CATEGORY TYPE

CI ATTRIBUTE

APPLICATION SOFTWARE

• • • • •

SUPPORT SOFTWARE

• Operating system version • Build • Image version

HARDWARE

• • • • • • •

Manufacturer Make Model Serial number MAC address Primary IP address (Fixed) Firmware version

REFERENCE DATA

• • • • •

Client ID Location ID Address Postal/ZIP code Organizational identifier

DOCUMENTATION

• • • •

Version number Author Editor Review process

2.4.4.

Code version Code language Build Compiler version DSL ID (could be a relationship) -> Future

1 M a n d a t o ry a t t r i b u t es

Before determining which attributes are to be managed by CI class, you must establish common attributes, which ones are mandatory and which ones are optional/ custom (unique to your organizational needs). The list below is a good start-up for determining your common mandatory attributes for all CIs in your CMDB.

FIGURE 35 – COMMON MANDATORY ATTRIBUTES 50

HGCNOW.COM

SER VICENO W CMDB 10 1

2.4.4.2

O p t i o n a l a t t r i b u t es

Before determining which attributes are to be managed by CI class, you must establish common attributes and which ones are optional. The list below is a good start-up for determining your optional common attributes for all CI in your CMDB.

FIGURE 36 – COMMON OPTIONAL ATTRIBUTES

Attributes are dependent on the CI classification in ServiceNow ® -- Reclassify a CI by modifying its ‘Class’ attribute. You can upgrade, downgrade or switch a CI’s class. When downgrading or switching a CI’s class, attributes that are unique to the current class, and are not defined in the newly reclassified class - are lost. Each class in the class hierarchy is defined with a unique set of attributes. This set consists of attributes that were inherited from the parent class, and additional attributes specifically defined for the class. When you reclassify a class: The set of attributes is adjusted to match the set of attributes of the newly assigned class. Attributes are added or removed as needed. A new record, with the CI’s sys_id, is inserted to the table of the new class, with the appropriate set of attributes for the class.

2.4.5

I D E N T I F Y R E L A T I O N S H I P S B Y CI T Y P E / CLA S S

One of the most significant benefits of ITIL Configuration Management is the identification of how configuration Items relate to one other in various relationship types. This information is used to facilitate component impact analysis and endto-end service modeling. To this end, physical and logical relationships between configuration items and service structures must be identified and registered within the CMDB.

HGCNOW.COM

51

Since automated administration of relationships is limited with the current available monitoring tools, balance of need and cost should be found when defining relationships, as too many relation types will complicate maintenance and control of the CMDB. Identifying the specific CI relationship data that you will initially start with in the CMDB, will be the key to a successful implementation of your CMDB. For each entity in the CMDB, the data model specifies: • The unique identifier (primary key). • The suggested attributes. • The bi-directional links to other entities (reference data, drop-down values)

expressed as foreign keys. These links (or relationships) are illustrated in the entity relationship diagram and further explained in architecture data model section. They are of three types: • Parent/child relationships between CIs. • Internal relationships between the CMDB entities (e.g. hardware - location) • Links between CMDB entities and external entities (e.g. hardware - change

management data) Our recommendation is to implement only a generic relationship (depending on the situation) at first and then introduce more as needed. The key is to have the right number of relationship types. Too many, and it may become unmanageable and not easily understood by users. Too few, and it may not give you the detailed view you need to interrogate the CMDB and analyze the information. Relationships should not be determined in isolation. You must consider relationships along with attributes, infrastructure and service configuration structures, and levels when you create the CMDB service model blueprint.

2.4.5.

1 H ar dw ar e Hardware> Network

RELATIONSHIP

Hardware> Storage Hardware> Server

NAME

depends on, runs on, connects to, is based on

DESCRIPTION

The unique identifier of a Hardware CI related to this one

RELATIONSHIP

Hardware> Software Hardware> Database

NAME

Hosts

DESCRIPTION

The unique identifier of the Hardware CI that hosts this Software CI

52

HGCNOW.COM

SER VICENO W CMDB 10 1

2.4.5.2

S o f t w ar e

RELATIONSHIP

Software> Application Software> Database

NAME

depends on, runs on, is based on, Exchanges data with, provides access to

DESCRIPTION

The unique identifier of a Software CI related to this one

2.4.5.3

P erson Person> Hardware

RELATIONSHIP

Person> Software Person> Document

NAME

Owns / Uses

DESCRIPTION

The unique identifier of a Hardware CI that this person/Organization owns/uses

RELATIONSHIP

Person> Business Service

NAME

Uses

DESCRIPTION

Each person / Organization may use an IT Service

2.4.5.4

Or g a n i z a tio n

RELATIONSHIP

Organization> SLA

NAME

Has

DESCRIPTION

An Organization Unit may have SLAs for one or more services Organization> Hardware

RELATIONSHIP

Organization> Software Organization> Business Service

NAME

Provides

DESCRIPTION

Unique Id of the Provider (external Organization) of the CI

2.4.5.5

L oca tion

RELATIONSHIP

Location> Hardware

NAME

Houses / Accommodates

DESCRIPTION

Hardware CIs are to be found at a Location

HGCNOW.COM

53

RELATIONSHIP

Location> Person Location> Organization

NAME

Houses / Accommodates

DESCRIPTION

Persons/Organizations are to be found at a Location

RELATIONSHIP

Location> Document

NAME

Houses / Accommodates

DESCRIPTION

Documents are to be found at a Location

2.4.5.6

Document

RELATIONSHIP

Document> Hardware / Network / Data Center / Telecom / Storage / Virtualization…

NAME

Documents Each Hardware CI may be documented by documents

DESCRIPTION

(For example, this link is to be used to link Hardware CIs to contracts (e.g. maintenance))

RELATIONSHIP

Document> Software / Database / Applications

NAME

Documents Each Software CI may be documented by documents

DESCRIPTION

(For example, this link is to be used to link Software CIs to contracts (e.g. license))

RELATIONSHIP

Document> Business Service

NAME

Documents

DESCRIPTION

An IT Service may be documented by documents (e.g. SLA)

54

HGCNOW.COM

SER VICENO W CMDB 10 1

2.5

CMDB

D E S I G N A UT O M A T I O N

To properly manage and maintain your CMDB, you must implement automation to monitor and control the technology services and their underlying infrastructure. For each CI Attribute by CI Class, you need to establish which CI Data will be populated, federated and/or modified. Once those decisions are taken during the design workshops, you should take full advantage of ServiceNow® capabilities to automate the CMDB. Begin by taking an inventory of your organization’s existing data repositories that are internal and external to IT, in accordance with your organization’s data requirements identified in step four. This will facilitate establishing priorities for each usage. This information may appear in the form of a list or spreadsheet, or reside in formal databases. Once these data 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 data detail (too little or too much) 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 anew. Investigate what current tools are available within your organization for collecting, storing, managing and updating the CMS data. Identify which tools meet the defined requirements, and which requirements have yet to be met by existing tools. Knowing your tool inventory will have a huge effect on the creation of your organization’s eventual data model and CMS structure. Use tools to automate data collection and help mitigate the risk of errors that can be introduced by manual data entry and maintenance. 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. While developing a business case may be difficult, aligning it back to the planning activities conducted in steps three and five will help justify their purchase. ServiceNow® Discovery product gives the means to create an accurate, up-to-date single system of record for the infrastructure.

HGCNOW.COM

55

• It identifies IP-enabled configuration items (CIs), maps their interdependencies,

and populates and maintains them in the ServiceNow© Configuration Management Database (CMDB). • Discovery is scheduled on a regular basis to help ensure the accuracy of the CI data underpinning ServiceNow © applications across the enterprise. • Using ServiceNow © Service Mapping in combination with Discovery, you can discover both infrastructure and services, making the ServiceNow © CMDB and all applications service-aware. • Rapidly configure and launch secure, agentless discovery of hardware, software, virtual and cloud resources, and their relationships. • Integrated discovery facilitates quicker service restoration from incidents, more effective root cause analysis, proactive problem resolution, lower-risk change execution, and better-informed business decisions. • Create custom patterns for any discoverable resource; identify custom applications and their dependencies; customize CMDB fields, tables, and relationship descriptions; and federate with other data sources through integrations. Without a discovery tool: • CMDBs struggle to remain current, do not contain the right type of information

to drive processes effectively. • IT staff cannot determine which business services are affected by changes,

failures, or performance issues. They can’t easily determine root causes of service problems.

56

HGCNOW.COM

SER VICENO W CMDB 10 1

3.

C ONFIGURE

Y OUR CMDB

The CMDB data model defines a certain number of categories and sub-categories of CIs. These categories do not represent the individual CI types contained in the CMDB but instead logical groupings of various CI types. The number of CIs in a typical category and the level of details describing the CIs and their components define the granularity of the CI structure. The diagram below details this structure for each category. The key factor in determining what to treat as a CI and what not to is dependent on whether it should (and can be) managed. CIs are typically grouped into categories such as hardware, software, and network, and then into classes, such as server, router, application, etc. The data model complies with the ITIL specification of baselines definition. Baselines will be particularly useful for the definition and management of standard CIs (standard models) to support activities such as procurement, software distribution, etc.… • Hardware standard configuration > hardware baseline • Software standard configuration > software baseline • Hardware and software standard configuration > hardware baseline + links

to software baselines For each type of CI, managing it properly requires maintaining a CI record that keeps track of specific characteristics about that CI, including system names, configuration settings, capacity, versions, operating system, and so forth. ServiceNow © provides a very large number of fields that are specific to certain categories and classes of CIs. As seen in the next section, the Configuration Item table is extended to other tables such as Database [cmdb_ci_database] and Computer [cmdb_ci_computer]. The Computer table is extended to the Server [cmdb_ci_server] table, which is extended to the UNIX Server [cmdb_ci_unix_server] table, and so on.

3. 1

CMDB

TABLE CLA S S IFIC A TIO N S

The CIs are defined down to the lowest level at which a component can be independently installed, replaced or modified. It should be considered that the chosen level represents the level at which future changes will be managed (change management). The appropriate level must be defined so that a balance can be achieved between information availability and the effort needed to support it. During the CMDB conceptual model workshops, you should determine which CI’s sub-types will be managed as CI attributes, CI Relationships or a distinct sub-type. To help decide between these two options the following criterion is suggested: a component should be identified as a CI if one of these four aspects is to be managed:

HGCNOW.COM

57

• • • •

Its change history Its incident / problem history Its location Its cost

3. 1. 1

BUSINES S SER VICES

FIGURE 37 – CMDB TABLES – BUSINESS SERVICE

3. 1 . 2

SER VER C OMPUTING

FIGURE 38 – CMDB TABLES – SERVER COMPUTING 58

HGCNOW.COM

SER VICENO W CMDB 10 1

3. 1.3

NETW ORK

FIGURE 39 – CMDB TABLES - NETWORK

3. 1 . 4

D A TA C E N T E R

FIGURE 40 – CMDB TABLES – DATA CENTER HGCNOW.COM

59

3.2

CI O W N E R S H I P

Through the CMDB, it should be possible to identify who is responsible for various aspects of each CI, including approving changes and support. Within ServiceNow © , you can assign an approval and a support group, as well as designating specific users as owner and manager of a CI. For any CIs or groups of CIs listed above, be prepared to identify who needs to be assigned to which CI. Determining the assignments and ownership level required is not an easy task. You should always ask the questions below to help determine which CI attributes to track and control. • Owner

- Who bought the hardware? - Who bought the software? - Who bought the licenses for the software product? • Management owner - Who managed the CI in the environment? - Who provides sys admin duties for the CI? - Who accepts changes on the CI? • Service owner - What services are provided by the CI? - Who owns the services? - Who provides that service? - Who defines the service? • Users - Who uses the CI? - Who physically has the CI under their control? • Governance - Who audits the CI?

3.3

C I ST A T U S

The CMDB is also used to track the status of a CI from several perspectives. The following tables show the default values for several of these fields. Please make a note of any values that you or your team feel should be modified or added, and be prepared to identify the value of these parameters for any CIs you manage or support. The following figure indicates a common life cycle over a period. There are many fields/attributes that can be used by default in ServiceNow© . • • • • • •

60

Install status Hardware status Operations status Business criticality Classification Used for

HGCNOW.COM

SER VICENO W CMDB 10 1

3.3. 1

BUSINES S CRITICALITY FIELD

Business Criticality can be used to automatically set priorities, and to guide support teams in addressing issues or assessing the impact of a change, thereby using the information to set the appropriate risk. This information can also be used as an input to your Business Continuity Plan (BCP). • Most Critical • Somewhat critical • Less critical 3.3.2

INS TALL S TATUS F IE LD

The lifecycle of a configuration item (CI) is the span of time that begins when the CI is created, and ends when it is no longer available for use. During its lifecycle, a CI takes on different states, which should be reflected in its status. The following table indicates possible status that may be used within the CMDB. • • • • • • • • •

Absent In Maintenance In Stock Installed On Order Pending Install Pending repair Retired Stolen

3.3.3

HARD WARE S TATUS FIELD

Optional status – mainly used for Asset Management, our recommendation is to combine the default values with the Status field. • • • • • • • • • • • • •

In Maintenance In Stock Installed On Order Pending Install Pending repair Retired Stolen Out of stock In Transit Defective In Disposition Pending Transfer

HGCNOW.COM

61

3.3.4

USED

F OR F IE L D

The field ‘Used for’ (environment) in ServiceNow© defines the deployment environment of a specific CI, and can also be used to guide priority and risk analysis, as well as mapping to outage or blackout windows. If a CI supports multiple environments, it should therefore be assigned to the one with the most rigorous requirements. • • • • • • • •

Production Staging QA Test Development Demonstration Training Disaster Recovery

3.3.5

OPERATIONAL

S TATUS FIELD

The ‘Operational Status’ field in ServiceNow© can be used to track the current ability of the CI to function in its intended role. It assists in preventing changes that might otherwise be dependent on deploying a non-operative component. • • • •

Operational Non-Operational Repair in Progress DR Standby

3.3.6

CLA S SIFICATIO N FIELD

The ‘Classification’ field can be used to automatically set the criticality of a hardware CI, and to guide support teams in addressing issues and/or assessing risks and impacts of changes. • • • • • •

62

Production Development UAT Disaster Recovery Critical Infrastructure Development Test

HGCNOW.COM

SER VICENO W CMDB 10 1

3.4

CI SER V I C E M A P P I N G

Business Services are another category of CIs that are key for achieving a true service oriented organization and identify capabilities. These represent the services that customers request that the organization deliver to fulfill their business functions. Examples of business services and service offerings might include patient medical records, radiology services, accounts payable, etc. Certain IT-specific business services provide general technology support, including desktop computing, messaging, or network access to the Internet, or they may be specific components underlying both business services and IT services, such as databases, server computers, storage, or backup.

FIGURE 41 – SERVICE MAPPING

A Business Service Map (BSM) is a representation of the relationships between Configuration Items, including other Business Services. Recording where CI’s are installed, what they are connected to, where data is stored or exchanged, and so on, makes it possible to identify the dependencies between CI’s. This simplifies trouble isolation, impact and risk analysis, identification of change conflicts and capacity limitations, and much more.

HGCNOW.COM

63

FIGURE 42 – MANUAL SERVICE MAPPING ON PAPER 64

HGCNOW.COM

SER VICENO W CMDB 10 1

3.5

CI R E L A T I O N S H I P S

Understanding relationships between CIs is what differentiates a CMDB from an asset database. One of the most significant benefits of implementing a CMDB is the identification of how Configuration Items relate to each other in various relationship types. This information is used to facilitate component impact analysis and end-toend service modeling. To this end, physical and logical relationships between configuration items and service structures must be identified and registered within CMDB. Since automated administration of relationships is limited with the current available monitoring tools, balance of need and cost should be found when defining relationships as too many relation types will complicate maintenance and control of the CMDB.

FIGURE 43 – CI RELATIONSHIPS

Any time you create a new classification (extend a table), you must create new relationship rules. ServiceNow © relationship rules use separate tables to define the relationships between specific CI base classes and dependent classes. When you extend a table HGCNOW.COM

65

in the CMDB, you must create a new relationship rule in Configuration > Suggested Relationships. You must define your CI Types and relationships on paper first; then proceed to align in the design in ServiceNow © .

3.5. 1

REFERENCE

D ATA

FIGURE 44 – CI RELATIONSHIPS – REFERENCE DATA

3.5.2

BUSINES S SER VICES PROVIDER

DEPENDANT

RELATIONSHIP

Business Service

Business Service

Composed of

Business Service

Process CI

Realizes

Process CI

Application Service

Uses

Application Service

Application Service

Composed of

Application Service

Application CI

Realizes

Application CI

Application Service

Uses

Application CI

Infrastructure Service

Uses

Infrastructure Service

Infrastructure CI

Realized by

Infrastructure CI

Infrastructure CI

Composed of

66

HGCNOW.COM

SER VICENO W CMDB 10 1

3.5.3

APPLICATIONS

FIGURE 45 – CMDB MODEL – CI APPLICATION RELATIONS HGCNOW.COM

67

3.5.4

DATABA SES

FIGURE 46 – CMDB MODEL – CI DATABASE RELATIONS 68

HGCNOW.COM

SER VICENO W CMDB 10 1

3.5.5

SER VER COMPUTING

FIGURE 47 – CMDB MODEL – CI SERVER RELATIONS

3.5.6

D A TA C E N T E R

FIGURE 48 – CMDB MODEL – CI DATA CENTER RELATIONS HGCNOW.COM

69

3.5. 7

NETW ORK

FIGURE 49 – CMDB MODEL – CI NETWORK RELATIONS

3.5.8

S T ORA GE

FIGURE 50 – CMDB MODEL – CI STORAGE RELATIONS 70

HGCNOW.COM

SER VICENO W CMDB 10 1

3.5.8. • • • • •

1

NA S

One NAS CI can host many tenants (EVS) One tenant (EVS) space can host many files systems One NAS CI can connect to one or many Ethernet switch ports One NAS CI can connect to one or many UPS CIs One NAS CI can connect to one or many Anti-Virus servers

3.5.8.2

S AN S w it ch

• One host physically connects to one physical SAN switch • One physical host port (either host or storage array) connects to one physical SAN switch port • One logical host port may connect to one or many logical storage array ports • A SAN switch IP will be part of a VLAN • Many physical SAN switches are connected to create one logical fabric • One physical SAN switch is connected to one or more physical UPS • One physical SAN switch is (assumed) connected to one physical Ethernet switch 3.5.8.3

S t or a g e A rr a y

• One physical SAN switch port connects to one physical Storage Array port • Many logical host ports (WWNs) can connect to one logical Storage Array port • A Storage Array IP will be part of a VLAN • One physical Storage Array is connected to one or more physical UPS • One physical Storage Array is (assumed) connected to one physical Ethernet switch • One Storage Array can contain one or many storage pools CI 3.5.8.4

S t or a g e P o o l

• One Storage Pool can contain many Parity Groups • Many hosts/servers can subscript to one Storage Pool • One host/server can subscribe to may Storage Pools 3.5.8.5

H o s t gr o u p

• Many host/server ports can be logically connected to one Storage Port; i.e. One Storage Port can service many WWNs (organized by host groups) • One Storage Array can have many Storage Ports • One Host Group can exist in many storage Ports • Many WWNs can exist in one Host Group • One Host Group can only have one set Host Mode

HGCNOW.COM

71

4.

C ONS TRUCT Y OUR CMDB

The conceptual target state, which must align with your business requirements, should be implemented in a phased approach. With each phase, you will be positioned to capitalize on the benefits of implementing your IT Service Management on an evolved and trusted CMDB. The formula for implementing SACM includes PEOPLE, PROCESS and PRODUCTS. • People must be sufficiently trained. • Policies must be enacted to reduce the complexity and politics of environments (i.e. multiple desktop models, multiple LAN standards, and complicated support management and maintenance efforts). • Robust processes must be in place, and automation must be considered to add efficiencies to manual and repetitive tasks. The target state goal of implementing Your CMDB, is to support the Service Management objectives, by efficiently providing required data to supporting processes. As such, access to the extended CMDB would allow you to: • Reduce incident duration and impact – objectives of Incident Management. • Reduce recurrence of Incidents through identification of errors – an objective of Problem Management. • Reduce impact, risk, and cost associated with making Changes – objectives of Release and Change Management. • Provision of objective availability data for supporting Service Level Agreements and Service Management review meetings – objectives of Service Level Management. The concept of maturity model was popularized by the Capability Maturity Model (CMM) that defines the stages of sophistication for software development. This has now been replaced by CMMi (CMM integration), which focuses on process improvement. In both models, the five stages of maturity are defined. They are numbered from 1 (low maturity) to 5 (high maturity) and there is also an implicit stage, zero, that indicates a state of no formal process culture. In most organizations, we were involved with, their initial overall Configuration Management Maturity Level was around 2.5 on a scale of 1 to 5 and it is usually due to the following: • Non-standardized discovery tools. • The Change Management Process in place was not linked to Configuration Management. • A CMDB tool was already deployed but it was not fully trusted and not maintained. • Asset Management deployed, but usually only for managing hardware assets. • No formal integration with procurement or having a sound financial management solution.

72

HGCNOW.COM

SER VICENO W CMDB 10 1

4. 1

CMDB

IMPLEMENTATION

BES T-PRA CTICES

Our implementation recommendation is based on the information gathered and analyzed to date, that you must formally recognize SACM, as being vital to your IT organization and then adopt an organized approach for gaining process control.

To do this, a co-operative effort, including a senior management process owner and stakeholders, must be undertaken to formulate a plan for moving forward. This plan includes developing and documenting the conceptual, logical, and physical design as it relates to process, people, and tools. It is the underlying process of SACM that positions an organization to identify, track, record, and report on infrastructure data as it is related to the management, costing, and delivery of services. The strategy recommended consists of stages, phases and data load by CI waves, emphasizing pre-requisites, identification of stakeholder requirements, and validation against business drivers for each step. Our recommended ‘best practice’ provides the starting point, and high level guidance, for a well-defined process (organizational structure, tools, business requirements, CI data, etc.). Adopting a phased approach for cutover allows the initiative to demonstrate benefits early, as well as fine-tune the implementation activities to improve their effectiveness. The Configuration Manager has the responsibility of creating and maintaining this information in a formal Configuration Management Plan and drafting a CMDB blueprint model on paper before embarking on bringing data into ServiceNow© and/or automating any data sources. The CMDB, when catered to your environment, functions as a decision-making tool, impact and root cause analyzer. But, by populating a large amount of data, your CMDB may turn complex, causing a loss in structure and information, thereby making its analysis less effective. To set up a less complicated CMDB design, strategize on your CI List and their supported attributes and relationships. Given below are 3 easy steps through which we can effectively populate CIs in the CMDB.

HGCNOW.COM

73

4. 1. 1

IDENTIFY BUSINES S CRITICAL

CI

The first step is to identify the business-critical CIs as per the environment. Next, group them in appropriate CI Types. Each CI Type holds its own attributes and relationships that are defined with key stakeholders from the Service Catalog Management, and Change Management. Some of the entities that can contribute to your CI list are: • Business services including: • Application services • Technology services including Hardware (IT and Non-IT assets, components) • Software (which are installed in the server/workstation like applications, operating systems, database) • Departments • Documents (license agreement, contract, lease agreement) • Users and supporting groups Not all software CIs are considered as CIs. The softwares which are installed on servers and workstations, and grouped under a CI Type are alone considered as Configuration Items (CIs).

FIGURE 51 – DATA LOADING APPROACH BY CI TYPE 74

HGCNOW.COM

SER VICENO W CMDB 10 1

4. 1 . 2

POPULATE

C I D A TA I N W A V E S

After the CI List is strategized and confirmed, you need to populate the Configuration Items (CIs). Various ways exist through which you can effectively populate CIs into your CMDB. • Populate Workstation/Devices - Auto-Discovery - Manual Notify • Populate Users/Analysts -Importing from Active Directory - Importing from Locations - Importing from Organizations - Importing Groups Populate other CIs such as IT services, Business Services, Departments, CI lists… - Automating Data sources and recurring integrations - Importing CIs from CSV file - Manual Addition of CIs

FIGURE 52 – DATA LOADING APPROACH BY PROCESS WAVE

HGCNOW.COM

75

4. 1.3 C ONTINUOUS LY AD APT THE INF ORMATION MODEL The overall information model is complete only when the relationships between the CIs are defined. While populating Configuration Items using any of the methods. the inter-dependencies between the CIs are identified and established. The relationships can be viewed from the Relationship Map which helps in impact and root cause analysis.

4.2

C M D B D ATA L O A D I N G

It is recommended that Service Asset & Configuration Management process be implemented gradually, in phases, beginning with the types of CIs or parts of the IT infrastructure where control is perceived to be the most important, or in the greatest of improvement, and then expanded to encompass other areas. The diagrams below depict a view to build and construct the CMDB in a waved and progressive approach. Since implementation refers to cutover to the new processes, rather than implementation of the tool, there is an additional planning associated with cutover. These plans may be developed, as they will happen (and likely be improved) with each repetition of process implementation, they are included here: • Determine what area (system or platform) will see most benefit from implementing SACM. • Train your staff just prior to cutover to the new procedures and tools. • Define/develop Service Asset & Configuration Management plans for each group and create local procedures. • Analyze and build modules for the Service Asset & Configuration Management system to support processes & interfaces. • Assess and establish updated staff roles and responsibilities. • Develop and plan registration procedures for new or existing CIs. • Populate CMDB - Load Initial Configuration and related records into CMDB. • Cutover to new process - go live and support the implementation. • Continue taking on IT infrastructure CIs (CI inventory, populate CMDB, populate DSL, etc.). • Monitor progress to ensure the new procedures and tools are being used effectively and efficiently. Approval to proceed with subsequent stages will require each time a formal charter and an updated project plan. The plan would be expanded and further detailed by the process owner, key stakeholders and Configuration Manager (who would also be responsible for managing the project and maintaining the Configuration Management plan and related documentation as each CI wave is automated and/ or imported in ServiceNow© ). A long-term program utilizing a multi-phased deployment approach is intended to deploy several individual phases of any ITSM project in ServiceNow© . The recommended approach, based on current state and foundation guidance provided by ITIL, is to perform the required work in stages. 76

HGCNOW.COM

SER VICENO W CMDB 10 1

The next phases will position for subsequent phases; which are longer term. Agreement to the process definition, and high level plans in the initial Phase is required before proceeding. These high-level details will help to clarify what is and what is not in scope for each stage. As well, it helps clarify how ITIL logically divides the activities associated with ‘Detailed Planning’ versus ‘Implementation Roadmap’.

4.3

IMPLEMENTATION TIPS

4.3. 1 DESIGN You might be implementing a CMDB for a large enterprise that boast of hundreds of business services and thousands of configuration items (CI), relationships and CI attributes; or an organization with a handful of services, in any case, Do Not start with a big bang approach. Pick up a major business service as a pilot, spend the maximum time planning for this service, implementing it, and noting down the lessons learned. Also, you must map the chosen service on paper and include all relevant CI information to your processes in scope.

4.3.2

PLAN

How deep you go into each CI is a major decision you need to make; this decision will guide your vision for the foundation of the CMDB and related IT service Management processes in scope. Spend time analyzing how, where and when you would need to dig out information on CIs that would potentially be helpful.

4.3.3

A UT O M A TE

Building a CMDB involves a big data collection exercise, consolidating, and reviewing several documents from multiple sources. You should never assume the data to be accurate, instead, plan to verify every bit of data you receive and identify other sources who can verify the data for you. The only way to succeed in this task, is to review all the solutions within your operations at your disposal, also if you have the budget; consider investing in using discovery and service mapping toolsets.

HGCNOW.COM

77

4.4

C M D B SER V I C E N O W © AD A P T A T I O N

One of the most important decisions you must take early on when building your CMDB on ServiceNow © is to decide whether to extend the CMDB and which databases to use. The configuration steps for enhancing the CMDB consists, but are not limited to the following activities to be executed during this initiative: • Review and adapt ACL rules, Roles and groups assignments • Enable ServiceNow © discovery • Adapt and consolidate forms, and lists • Adapt Data certification and auditing • Enable the appropriate plugins • Conduct knowledge transfer sessions and mentoring • Review and adapt the ServiceNow© data model and structure • Review the business services CIs • Review implementation of CI Business Services • Review and adapt structure for CI Business Application • Document and adapt relationships between Security data & Business Application • Review relationships for Technology Dependencies associated to Business Applications and existing business Services • Document a migration plan for current Business Services/Software records to be used as Business Applications.

4.5

C M D B SER V I C E N O W © PL U G I N S

Before you start configuring anything in ServiceNow© , you will need to enable the following plugins: • Architecture Compliance • Assessment Components • Change Management - Core • Change Management - Standard Change Catalog • Data Certification, • Desired State • Extended CMDB • Field Normalization • Integration - JDBC • Integration - Multiple Provider Single Sign-On Installer • Process Flow Formatter

78

HGCNOW.COM

SER VICENO W CMDB 10 1

4.6

CMDB

IMPLEMENTATION PLAN

The work from the prior Stage will form the basis of the work for the next Stage. If work from a prior Stage is revisited at a later Stage, this will result in a change to the Project fee and schedule.

4.6. 1

S TA GE 1: P L A N I N G

During this Stage, the Client and project managers will: • Develop a Project management plan (the “Project Management Plan”) that establishes the procedures to be employed for the ongoing management of the Project and the communication plan to address the protocol for generating and submitting status reports and conducting status meetings. • Assign tasks and develop the Project schedule using an agreed upon project tool. • Validate that prerequisites as identified in the Assumptions and Client Responsibilities sections are accurate and complete. • Schedule kick-off meeting to introduce the team and Client team members (collectively, the “Project Team”) and stakeholders, communicate the Project scope and review the Project Management Plan and Project schedule. • Conduct technical kickoff meeting scheduled, and verify the Solution requirements • Defines the business drivers for the Solution and the high-level requirements; and identifies in-scope versus out-of-scope requirements of the planned Solution • Defines the current “as is” state of the in-scope business processes; provides an overview of the proposed Solution “to be” state; describes client (the “actors”) who will play a role in the Solution—their responsibilities and interactions; and identifies Solution use cases and maps them to the Solution’s functional requirements 4.6.2 STAGE 2: DESIGN During this Stage, we will work with the Client to establish the Solution design, plus the high-level Solution test and integration plans and phasing for the implementation. The Project Team will: • Review current environments and integration components • Conduct workshop to define Solution architecture specifications, high-level test plan for functional and non-functional requirements defined, and recommended phasing for the implementation • Review integration requirements • Produce the Solution design document that contains the CMDB Blueprint model, and includes the desired architecture HGCNOW.COM

79

• Summarize the Solution requirements and Solution design in an executive presentation in Microsoft PowerPoint format, and present this summary to Client 4.6.3

S TA G E 3 : A D A P T A T I O N

In this Stage, the Project Team will complete the Solution integration document and configure the selected Solution components in a DEV environment as defined in the Solution design and integration instructions. Simultaneously, you will compile the Solution test plan with systematic instructions to test each documented use case and non-functional requirement, and will review the test plan with the Client. • Complete the Solution integration instructions containing a task-level implementation plan with installation and configuration instructions mapped to Solution phases as described in the Solution design document • Configure selected components in dev environment and perform installation and configuration testing • Compile the Solution test plan • Define validation plan • Validation of use cases & validation of quality attributes 4.6.4

S TA G E 4 : V A L I D A T I O N

During this stage, in the dev environment the Project Team, plus administrators, operators and end users as agreed upon, will perform quality assurance by executing the tests defined and documented in the Solution test plan, and will document the test results. • Finalize Solution test plan & Document test results • Perform use case tests and other testing defined in the Solution test plan and review results • Refine component configurations for test results which do not materially reflect the agreed upon outcome and re-execute the test 4.6.5

S TA G E 5 : D E P L O Y M E N T

In this Stage, the Project Team will implement an initial limited and controlled implementation within the production environment as defined in the Solution design & integration instructions. • Prepare and verify the production environment • Upgrade and configure selected components in production environment and perform adaptation and configuration testing • Configure selected integrations and perform integration testing • Execute use case tests defined in Solution test plan. • Update Project documentation as required with results of production deployment • Provide final Project documentation (the “Solution Documents”) to Client 80

HGCNOW.COM

SER VICENO W CMDB 10 1

4 . 7 D ATA L O A D I N G A C T I V I T I E S The following are the detailed activities to execute per CI Grouping for each CI Class in scope; this is a sample list of activities and must be adapted to your organization.

4. 7 . 1 P R E P A R E D ATA • • • • • • • • • • • • • • •

Identify CI Owners Map each CI Class to Data Source(s) Identify Integration Method Assess Data Source(s) Document Data Source solution(s) plugins Create CSV/XLS/XML Data extraction(s) Grant JDBC Read-Only access to current databases Build SQL Statement(s) for Data Extraction Create SOAP/Web Service script(s) Provide and review Raw Data Create Reconciliation Rules Merge and Normalize Test Data Document Technology/Process Gaps Integrate with Automation Tool(s) Update Template(s) and Mapping document(s)

4. 7 . 2 • • • • • • • •

U P D A T E D A TA D I C T I O N A R Y

Map CI Tables Map CI Attributes/Fields Map CI Relationships Identify Common attributes Identify Mandatory attributes Identify Data source for each attribute Identify Data Ownership for each attribute Provide Cleaned/Normalized Ready Data for Load

4. 7 . 3 L O A D D ATA • • • • •

Create Import Map and Transform Map Adapt Import scripts / Rules Perform and validate Data Import Remove Failed Data Import if applies Input any additional data manually

HGCNOW.COM

81

4. 7 . 4 • • • • • • • • • •

Extend the CMDB tables Adapt CI attributes and CI Relationship Configure Choice List Configure Fields and forms Configure Lists and views Create Roles Create/Assign ACL’s Create UI Actions Create Business Rules Create Client Script and Workflows

4. 7 . 5 • • • • •

AD APT SO L U T I O N

AD APT P R O C E S S

Identify CMDB Support Processes Design Process Flow Identify Actions for Key Process Steps Identify Control Points for Each Process Step Document CMDB integrations and configurations

4. 7 . 6

V A L I D A T E D ATA

• Build VAT scenarios • Validate accuracy of the CMDB • Validate Security

82

HGCNOW.COM

SER VICENO W CMDB 10 1

CMDB DEFINITIONS A significant goal of ITIL is to promote the use of a common language and terminology to improve communication and understanding, for this reason the following definitions are provided: ASSET: Component of a business process. Assets can include people, accommodation, computer systems, networks, paper records, fax machines, etc. AVAILABILITY: The ability of an IT service or component to perform its required function at a stated instant or over a stated period. {Up or Down Time} SERVICES: The deliverables of the IT Services organization as perceived by the Customer; the services do not consist merely of making computer resources available for Customers to use. STAKEHOLDERS: Any individual or group who has an interest or ‘stake,’ in the IT service organization. CHANGE: The addition, modification or removal of approved, supported or hardware baseline, network, software, application, environment, system, desktop build or associated documentation. CLASSIFICATION: Process of formally grouping Configuration Items by type, e.g. software, hardware, documentation, environment, application. Process of formally identifying Changes by type. Process of formally identifying incidents, problems and known errors by origin, symptoms and cause. CUSTOMER: Recipient of a service. Generally, the Customer has a responsibility for the cost of a service, either directly, through charging, or indirectly through demonstrable business need. In this context, a Customer could be a “person on the street” banking customer or an internal business unit to which an IT service is provided. CLIENT: Internal business client using an IT service. CONFIGURATION BASELINE: Configuration of a product or system established at a specific point in time, which captures both the structure and details of the product or system, and enables that product or system to be rebuilt later. CONFIGURATION CONTROL: Activities comprising the control of Changes to Configuration Items after formally establishing its configuration documents. It includes the evaluation, coordination, approval or rejection of Changes. The implementation of Changes includes changes, deviations and waivers that impact on the configuration. CONFIGURATION DOCUMENT: Documents that define requirements, system design, build, production, and verification for a configuration item. CONFIGURATION IDENTIFICATION: Activities that determine the product structure, the selection of Configuration Items, and the documentation of the Configuration Items’ physical and functional characteristics, including interfaces and subsequent Changes. It includes the allocation of identification characters or numbers to the

HGCNOW.COM

83

Configuration Items and their documents. It also includes the unique number of configuration control forms associated with Change and Problems. CONFIGURATION ITEM (CI): Component of an IT infrastructure – or an item, such as a Request for Change, associated with an IT infrastructure – which is (or is to be) under the control of CFM. CIs may vary widely in complexity, size and type – from an entire system (including all hardware, software and documentation) to a single module or a minor hardware component. CMDB: A database that contains all relevant details of each CI and details of the important relationships between CIs. PLAN: Document setting out the organizational and procedures of a specific product, project, system, support group or service. CONFIGURATION STRUCTURE: A hierarchy of all the CIs that comprise a configuration. ENVIRONMENT: A collection of hardware, software, network communications and procedures that work together to provide a discrete type of computer service. There may be one or more environments on a physical platform e.g. test, production. An environment has unique features and characteristics that dictate how they are administered in similar, yet diverse manners. IMPACT ANALYSIS: the identification of critical business processes, and the potential damage or loss that may be caused to the organization resulting from disruption to those processes. INVENTORY: Automated identification of the components of a device in a network IT infrastructure. Inventory or auto discovery identifies what it is, where it is located, who is using it, and how it has changed over time. Value is generally not known and relationship information is restricted to containment hierarchies. IT INFRASTRUCTURE: The sum of an organization’s IT related hardware, software, data telecommunication facilities, procedures and documentation. IT SERVICE: A described set of facilities, IT and non-IT, supported by the IT service provider that fulfils one or more needs of the Customer and that is perceived by the Customer as a coherent whole. LIFECYCLE: A series of states, connected by allowable transitions. The lifecycle represents an approval process for Configuration Items, Problem Reports and Change documents.

84

HGCNOW.COM

SER VICENO W CMDB 10 1

T H E AU T H O R HICHEM GUEMIRI Hichem is a ServiceNow © Certified Administrator, Implementation Specialist and ServiceNow© Certified Application Developer with over 15 years or experience implementing IT Service Management and Operations Management solutions across industries, especially the banking and insurance industry. His technical expertise and capabilities cover a multitude of services: project lifecycle, strategic planning, enterprise architectures, process integrations, application development, and ServiceNow® maintenance and support – all supported by @HGCNOW recognized IT management and governance practices. Built over the years by delivering large scale enterprise engagements across North America, in both private and public sector. Hichem is the CEO at HGC Technologies Inc. @HGCNOW is a consulting firm specializing in the development of custom applications, integrations on the ServiceNow © platform, and delivering tailored business services; from the onset process and architecture assessments to a practical drafted desired vision.

HGC TECHNOLOGIES INC. CEO – CHIEF EXECUTIVE OFFICER [email protected] WWW.HGCNOW.COM

HGCNOW.COM

85

T H E C O L L A B O R AT O R S NOEL

NATHAN

Noel’s #1 brand is quality and his #1 skill is execution. A highly skilled, talented, driven individual who thrives in bringing order to chaos! Noel started his career in ITSM in 2005 after graduating from Toronto’s Humber Institute of Technology and Advanced Learning where he obtained a Diploma with Honors in Computer Engineering. Starting at the IT Service Desk, Noel has progressed throughout his career specializing solely in ITSM – from implementation (in several countries across the world), to ISO20000 certification, all the way up to Program Governance. He has over 10years in setting up ITSM programs for some of the most reputable global companies in the world including start-ups. His approach has transformed the IT departments of companies he has worked and consulted for by providing advisory, strategies, and vision establishment, helping senior management obtain the value they seek from an ITSM/ITBM program. Noel also hold several ITIL credentials, is a certified ServiceNow® system administrator, and a graduate in Business Administration (BSc.) with a specialization in International Business, from the prestigious University of London – Royal Halloway College.

HGC TECHNOLOGIES INC. CXO – CHIEF EXPERIENCE OFFICER [email protected] WWW.HGCNOW.COM

P ATRICK LAROCHE Patrick is a ServiceNow® Certified Administrator. He has been designing and managing ServiceNow® for the past 2 years at a major Canadian retailer. He has previous experiences in network management, database management and SAP, combined with a high customer service delivery mindset. Patrick has joined HGC Technologies as the COO, and helps manage and oversee all ServiceNow© implementations and project deliveries. Patrick is the COO at HGC Technologies Inc., He is responsible for the day to day operations including service delivery.

HGC TECHNOLOGIES INC. COO – CHIEF OPERATIONS OFFICER [email protected] WWW.HGCNOW.COM 86

HGCNOW.COM

SER VICENO W CMDB 10 1

MA XIME CARRIER Maxime is a ServiceNow® Certified Administrator and a Certified ServiceNow® Implementation Specialist with over 10 years as a Consultant implementing ITSM products. He has been implementing, designing, scoping and delivering ServiceNow ® projects for the past 5 years around North-America. Maxime is the CIO at HGC Technologies Inc. He oversees both the development teams and remote ServiceNow® administrators. He is always optimistic but also realistic towards new challenges and situations. At HGC Inc. Maxime is responsible for: • Assessing current situations and architecting operational road-maps • Documenting CMDB designs and strategies • Implementing ServiceNow ® Discovery and service mapping • Architecting ServiceNow ® orchestrations • Implementing Event Management and correlation intelligence • Integrating operational monitoring products • Designing business and supporting services • Designing processes and automations capabilities

HGC TECHNOLOGIES INC. CIO – CHIEF INFORMATION OFFICER [email protected] WWW.HGCNOW.COM

ALAIN LAPOINTE Alain is a ServiceNow® Certified System Administrator & Certified Implementation Specialist. Alain has worked with different ITSM tools in the past until he feels in love with the ServiceNow® platform. He has a deep passion for technology, hiking and traveling. The need to always be challenged pushes him every day to find new ways to provide a better use of technology in managing business services.

HGCNOW.COM

87

X O L A N I N G W E N YA Xolani, an IT process and governance aficionado, has extensive training and practical experience in IT Service Management implementation and holds ITIL® Expert and TIPA® Assessor Certifications. Xolani has many years of experience in developing, implementing, assessing and improving IT service management processes; with a focus on ensuring IT processes reflect lean and agile principles, designed with just enough controls to effectively and efficiently deliver services and value, but not constricting flow of work. As a trainer, Xolani delivers some of the most energetic and engaging sessions with compelling practical examples, and analogies to “bring to life” concepts that help learners easily grasp new information . He loves travelling, is an an avid book reader and soccer fan.

88

HGCNOW.COM

SER VICENO W CMDB 10 1

TABLE OF DIA GRAMS FIGURE 1 – SERVICENOW® SHARED CMDB ARCHITECTURE ............................. 7 FIGURE 2 – SERVICENOW ® APPLICATION CAPABILITIES ............................... 8 FIGURE 3 – SERVICENOW ® CMDB ARCHITECTURE MODEL ........................... 9 FIGURE 4 – CMDB BUSINESS DRIVERS................................................................ 10 FIGURE 5 – CMDB BUSINESS DRIVERS ................................................................ 11 FIGURE 6 – CMDB DESIGN BLUEPRINT STRUCTURE ........................................ 14 FIGURE 7 – CMDB DESIGN STEPS ........................................................................ 15 FIGURE 8 – CMDB DESIGN SCOPE + SPAN = ROADMAP .............................. 16 FIGURE 9 – CMDB DESIGN FEDERATION ............................................................. 17 FIGURE 10 – CMDB PREPARATION STEPS ........................................................... 18 FIGURE 11 – PROJECT TEAM ................................................................................. 19 FIGURE 12 – SACM TEAM ....................................................................................... 20 FIGURE 13 – IT INFRASTRUCTURE MAP .............................................................. 22 FIGURE 14 – CMDB BLUEPRINT MODEL .......................................................... 23 FIGURE 15 – SACM PROCESS ROLES ...................................................................24 FIGURE 16 – CMDB SCOPE & SPAN ............................................................................. 29 FIGURE 17 – CMDB WORKSHOP TYPES ............................................................... 31 FIGURE 18 – CMDB WORKSHOP DELIVRABLES.................................................. 32 FIGURE 19 – SERVICE ARCHITECTURE LAYERS...................................................... 34 FIGURE 20 – SERVICE MAP VS. SERVICE OFFERINGS ................................. 35 FIGURE 21 – INCIDENT MANAGEMENT WITHOUT CMDB .................................. 36 FIGURE 22 – INCIDENT MANAGEMENT WITHOUT CMDB .............................. 37 FIGURE 23 – CI CATEGORIES ........................................................................... 39 FIGURE 24 – REFERENCE DATA .......................................................................................... 39 FIGURE 25 – SERVICENOW ® REFERENCE DATA ARCHITECTURE .......... 40 FIGURE 26 – CI CATEGORY – BUSINESS SERVICES ...................................... 40

HGCNOW.COM

89

FIGURE 27 – CI CATEGORY – APPLICATIONS ................................................. 41 FIGURE 28 – EXAMPLE APPLICATION CI TYPE ............................................. 43 FIGURE 29 – CI CATEGORY - DATABASES ......................................................... 43 FIGURE 30 – CI CATEGORY – SERVER COMPUTING ..................................... 44 FIGURE 31 – CI CATEGORY –INFRASTRUCTURE COMPUTING .................... 45 FIGURE 32 – CI CATEGORY – STORAGE ............................................................ 46 FIGURE 33 – CI CATEGORY –BACKUP ............................................................. 47 FIGURE 34 – CI CATEGORY –END-USER COMPUTING ................................. 48 FIGURE 35 – COMMON MANDATORY ATTRIBUTES ...................................... 50 FIGURE 36 – COMMON OPTIONAL ATTRIBUTES ............................................... 51 FIGURE 37 – CMDB TABLES – BUSINESS SERVICE ........................................... 58 FIGURE 38 – CMDB TABLES – SERVER COMPUTING .................................... 58 FIGURE 39 – CMDB TABLES - NETWORK ..................................................... 59 FIGURE 40 – CMDB TABLES – DATA CENTER ................................................ 59 FIGURE 41 – SERVICE MAPPING ........................................................................... 63 FIGURE 42 – MANUAL SERVICE MAPPING ON PAPER ................................... 64 FIGURE 43 – CI RELATIONSHIPS ..................................................................... 65 FIGURE 44 – CI RELATIONSHIPS – REFERENCE DATA ...........................................66 FIGURE 45 – CMDB MODEL – CI APPLICATION RELATIONS ......................... 67 FIGURE 46 – CMDB MODEL – CI DATABASE RELATIONS ............................. 68 FIGURE 47 – CMDB MODEL – CI SERVER RELATIONS .................................. 69 FIGURE 48 – CMDB MODEL – CI DATA CENTER RELATIONS ....................... 69 FIGURE 49 – CMDB MODEL – CI NETWORK RELATIONS ............................. 70 FIGURE 50 – CMDB MODEL – CI STORAGE RELATIONS ............................... 70 FIGURE 51 – DATA LOADING APPROACH BY CI TYPE .................................... 74 FIGURE 52 – DATA LOADING APPROACH BY PROCESS WAVE.........................75

90

HGCNOW.COM

Register on our site, or email us to get your complimentary download: all diagrams found in this book + get this book in pdf format Email us at [email protected] Hichem Guemiri

HGCNOW.COM

91

NO TES

Visit our website WWW.HGCNOW.COM