Business Services Using OOB CMDB Tables



Get Well Playbook

Business Services Using Base System CMDB Tables

A step-by-step guide to analyze and remediate CMDB data

 

Table of Contents

Summary

Goal of this Playbook

Audience

Problem Overview

Executive Summary

How this playbook can help you achieve business goals

How this playbook is structured

Problem Analysis

Upstream Causes

Downstream Consequences

Impact on Your Business

Engagement Questions

Remediation Plays

Summary

Play 1: Analysis

Play 2: Validate Business Applications

Play 3: Validate Application Services

Play 4: Validate Technical Services

Play 5: Migrate Custom Tables

Data Governance



Summary

Goal of this Playbook

To help identify and validate CIs using custom service tables that are no longer needed due to added ServiceNow capabilities, and aligning your CMDB data model to the baseline

Details about this playbook

Author
Scott Lemm
Date
08/19/2020
Addresses HSD #
HSD0007996
Applicable ServiceNow Releases
New York, Orlando, Paris, Quebec
Prerequisites
CMDB and CSDM Data Foundations Dashboards
Time required
Approximately 1 to 8 hours

Audience

  • Configuration Manager or Configuration Management team

  • ServiceNow Admin

  • Service Owner

Problem Overview

ServiceNow is a highly configurable platform that continues to evolve over time. The Common Service Data Model (CSDM) ensures the CMDB will provide its tables as part of the base platform with no need for module licensing to gain access to cmdb_ci base tables. Beginning with the Kingston release, ServiceNow has been making tables, previously only available through licensing, part of the base platform. As these and other CMDB based capabilities evolve, the need for custom service tables diminish.

If CIs are using a custom service-related table then those CIs risk not receiving the full value of the Now Platform where many products assume CIs exist with data model aligned to the CSDM. With the introduction of Application Portfolio Management, Application Services, and enhancements to Service Portfolio Management, the need for CIs in custom service tables have diminished.

Ultimately, ServiceNow value is created by ServiceNow products for the data model outlined by the CSDM. Deviation from CSDM may result in reduced base capabilities and related value.

This playbook helps you identify those custom service tables for your review and subsequent remediation.

Executive Summary

How this playbook can help you achieve business goals

Identify the CIs residing in custom service related tables within the Now Platform and common opportunities to move 'back to the baseline'. Use of base tables vs custom tables improves upgrade efficiency, reduces manual management activities associated to customizations, increases value in the use of Now Platform capabilities within such areas as Customer Service Management, IT Service Management, IT Operations Management, and IT Business Management

How this playbook is structured

This Playbook will guide you through 6 plays.

  • Play 1 (an analysis play) helps you identify which CI’s are using custom service related tables

  • Play 2 (a fix play – Business Applications) tells you how to validate if your CIs in custom service tables are really Business Applications

  • Play 3 (a fix play – Application Services) tells you how to validate if your CIs in custom service tables are really Application Services

  • Play 4 (a fix play – Technical Services) tells you how to validate if your CIs in custom service tables are really Technical Services

  • Play 5 (a fix play – migrate from custom tables) tells you how to migrate CI’s from custom tables

  • Play 6 (a Data Governance play) lists the guidelines and processes for custom service table management. Use these guidelines to maintain effective data in your CMDB

Problem Analysis

Upstream Causes

  • A rapid implementation required a ‘lift and shift’ effort into the CMDB for service related tables which required some customizations

  • Requirements led to customizations that are no longer needed

  • ServiceNow has evolved to offer capabilities that were not present when we customized

  • You may not be aware how services are modeled in the CMDB

Downstream Consequences

Data Consequence

  • Duplicate data may occur when customizations are created where base items exist for similar functionality

Operation Consequence

  • Erodes trust in the accuracy of the CMDB. Results in a poor user-experience

  • Processes that rely on CIs in base tables will be unable to process data

  • Base reporting, reliant on CIs in base tables, will lack correct data

  • Service Owners will be unaware of service value related to CIs in custom service tables

App Consequence

  • ITOM Health will not determine and display service impacts using CIs in custom service tables

  • Change will not identify service impact to CIs in custom service tables

  • Incident will not identify service impact to CIs in custom service tables

  • Service Portfolio Management can not provide a Service Owner Workspace view of CIs in custom tables


Impact on Your Business

Utilizing custom Service Classes instead of the baseline classes affect the following areas of your business

  • A poor User Experience (internal and external) making Work harder than it needs to be

  • Erosion of CMDB trust accompanied with a general lack of adoption and enthusiasm

  • Data management is 100% manual as the base processes that utilize base service tables are unaware of CIs in custom service tables

  • Inability to consume 3rd party solutions

Engagement Questions:

Consider the answers to these questions:

  • What are the major sources of service CIs in your CMDB?

  • Do these custom tables provide more value, with all the added manual management requirements, compared to the base table equivalents?

  • Can you harness the power of the platform without making significant changes to it?

Remediation Plays

Summary

The table below lists and summarizes each of the remediation plays in the playbook.  Details are included later. 

Play



Play 1: Analysis

What this play is about

Identify CIs in custom service related tables

Required tasks

Run report to help identify target CIs

Play 2: Fix Existing Data – Validate Business Applications

What this play is about

Validate CIs in custom service related tables that are actually Business Applications

Required tasks

Review CI data that aligns to Business Applications

Play 3: Fix Existing Data – Validate Application Services

What this play is about

Validate CIs in custom service related tables that are actually Application Services

Required tasks

Review CI data that aligns to Application Services

Play 4: Fix Existing Data – Validate Technical Services

What this play is about

Validate CIs in custom service related tables that are actually Technical Services

Required tasks

Review CI data aligns to Technical Services

Play 5: Fix Existing Data – Migrate Custom Tables

What this play is about

Migrate CIs from custom tables to base tables

Required tasks

Backup data, perform attribute rationalization, identify dependencies, mitigate dependencies, migrate CIs

Data Governance

What this play is about

Helps you establish standard operating procedures, as well as periodic data certification

Required tasks

Provides detailed advice, best practices and data audit instructions


Play 1 - Analysis

What this Play is about

Identify which service related tables are custom

Required tasks

  1. Install CMDB and CSDM Data Foundations Dashboard from the ServiceNow App Store

  2. Navigate to the CSDM Data Foundations Dashboard module in the left navigation menu

  3. Select the Run tab

  4. Select the Business Services Using Custom CMDB Tables report to view a list of CIs that reside in custom service-related tables. If you see a count of zero then this playbook is not applicable to you.



Play 2: Fix Play - Validate Business Applications

What this Play is about

This play tells you the common data associated to Business Applications for validation and migration consideration. Many customers created CIs in custom service related tables that reflect a Business Application prior to Business Application being a base CMDB table beginning in Kingston

Required tasks

  1. Open a CI from the Business Services Using Custom CMDB Tables report

  2. Review and compare your data attributes against those associated to Business Applications

    Business Applications form

    Field

    Description

    Name

    Name of the business application.

    Business process

    Business process for which the application is used.

    Portfolio

    Name of the portfolio to which the application belongs.

    Application type

    Indicates whether the application is custom or commercial.


    • Homegrown: The application was built in-house.

    • COTS: The application is a commercial application purchased from another company.

    Architecture type

    Type of application architecture.


    • Client Server: Application structure that divides tasks between the service providers and service requesters.

    • N-Tier: A multi-layered architecture where presentation, processing, and data management are physically separated.

    • Web-based: Applications accessed over a network connection.

    • Other: Any other type of architecture.

    • Platform Host: A hardware or a software that hosts the business application.

    • Platform Application: Application that runs on a platform and can be associated to a host.

    In this case, the business application relies on the platform for standard operations such as development tools, execution services, data services, and so on.

    Platform Host

    A hardware or a software that hosts the business application.

    This field is mandatory if you select Platform Application value in Architecture type field.

    Install type

    Type of install.

    Platform

    Applications hosted by platform.

    Business Unit

    Attach a business application to the business unit organizational structure.

    Department

    Attach a business application to the departmental organizational structure.

    Status

    Operational status of the application.

    Auditing is enabled and hence, whenever a user updates the value in this field, the Activities field in the Activities tab displays the update.

    Application scoring profile

    The profile used to calculate the application score for strategy.

    Application category

    The application purpose and function. Use this information to rationalize or consolidate applications.

    Application family

    A set of related applications that have a common platform or vendor.

    Technology stack

    Technology stack on which the application was built.

    User base

    Number of users using the applications.

    Auditing is enabled and hence, whenever a user updates the record in this field, the Activities field in the Activities tab displays the update.

    Active user count

    Number of active users out of the overall user base. Auditing is enabled for the field.

    Last change applied date

    Date on which the application was last updated. Auditing is enabled for the field.

    Description

    Unique description of the application.

    Contract

    Vendor

    Vendor details of the application.

    Support vendor

    Vendor who currently supports the application.

    Contract end date

    Expiry date of the subscription contract or the support contract. Auditing is enabled for the field.

    Owners

    Portfolio manager

    Owner of the portfolio, typically from IT.

    Business owner

    Person who owns the application from the business side. Every application should have an assigned business owner.

    IT Application owner

    Person who owns the application from the IT side.

    The business application must have an owner assigned to it.

    If you are the owner of the business application and designated so in this field, then you can view all the applications for which you are the owner in the My Applications menu.

    Last updated by

    Person who last updated the application record.

    Supported by

    User supporting the business application.

    Support group

    User group supporting the business application.

    Compliance

    Business criticality

    How critical the application is to the business? Auditing is enabled for the field.

    Emergency tier

    This attribute determines the actions or plans that are executed for the application in an emergency situation.

    Data classification

    Security level for the data in the application. This attribute determines which Governance, Risk, and Compliance (GRC) policies are applicable to the application.

    Auditing is enabled for the field.

    Certified

    Status of the application that it meets requirements or complies with the policies of your organization.


  3. If your CIs in the custom table aligns fully to the field/descriptions from Business Application, then you may desire migrating your CIs to the base table Business Application

  4. If your CIs in the custom table does not fully align to the field/descriptions from Business Application, then move onto Play 3 for further validation

    NOTE: The Business Application table is NOT an operational table. Incidents and Changes are not placed against Business Applications. If your existing CIs in your custom table have a history of Incidents and Changes tied to them then DO NOT MIGRATE THE CIs TO BUSINESS APPLICATION.


Play 3: Fix Play - Validate Application Services

What this Play is about

This play tells you the use and purpose of Application Services for validation and migration consideration. Many customers created CIs in custom service related tables prior to Application Services being part of the base CMDB in the London release

Required tasks

  1. Understand the purpose of an Application Service

    Application Services is a Logical representation of a deployed application stack. They represent a unique instance/deployment of a Business Application. Key Details include the following:


    • An Operational CI

    • Focus in Incident, Problem, Change (IPC)

    • Unique Instance of a Business Application

    • May be created per "Environment” ex. Dev, QA, Prod

    • May be created per region

    • Creation Methods (more details here): Manual Mapping, Service Mapping with Entry Point, Tags, Dynamic Query

      Note: The Application Service was made a base CMDB table in the London release with further enhancements for creation methods in subsequent releases.

  2. The use of an Application Service includes the following:

    • Unique Deployment – if you have CIs in your custom service tables that represent the unique deployment of an application such as MyApp Prod and MyApp Dev, then these likely would be considered Application Services

    • Focus in Incident, Problem, Change (IPC) – if you have CIs in your custom service tables that represent an application AND have a history of IPC tied to them, then these would likely be considered Application Services

  3. If your CIs in the custom table aligns fully to the purpose/use of Application Services, then you may desire migrating your CIs to Application Services

  4. If your CIs in the custom table do not fully align to the purpose/use of Application Services, then move onto Play 4 for further validation


Play 4: Fix Play - Validate Technical Services

What this Play is about

This play provides you real-world examples of Technical Services, as utilized by other ServiceNow customers, for validation and migration consideration. Many customers created custom tables to reflect these objects prior to being formally documented as part of CSDM

Required tasks

  1. Understand the purpose of a Technical Service

    Technical service is a service type that is published to service owners and typically underpins one or more business or application services. Using technical services lets you view and manage the technology you provide to the business. A technical service may have an operational view made up of one or more technical service offerings.

  2. Understand real-world examples of Technical Services from ServiceNow customers

    The following example is from the Knowledge20 presentation: BRE1972 – Evolving from a basic CMDB to the CSDM at Canadian National Railway



  3. If your CIs in the custom table align fully to the real-world examples of Technical Services, then you may desire migrating your CIs to Technical Services

  4. If your CIs in the custom table do not fully align to these real-world examples, then you likely have Business Service CIs. If you feel you may have a unique use case. Contact the CSDM team at ServiceNow with details of your custom service tables.


Play 5: Fix Play - Migrate Custom Tables

What this Play is about

This play tells you how to migrate CIs in custom service-related tables into base tables of the CMDB

Required tasks

  1. Back up your data – ServiceNow takes data loss very seriously. Though you won't need this data immediately, it is always a best practice to back up your data prior to embarking on a data migration effort. Export your table data with all attributes to excel and place in a safe spot

  2. Attribute mapping – Identify which tables your data will migrate to (Business Application, Application Service, Technical Service, Business Service) and if the destination table has your required attributes available as base attributes. This is an opportunity to rationalize your custom attributes. Do you really need those customizations that were only used once 5 years ago or have only been populated on less than 10% of your CIs?

    In most cases, less is more. Use this opportunity to eliminate low use / no use attributes or those attributes with more effective methods of fulfilling their use case. Categorize your custom attributes as follows

    1. Best Practice – no related OOB attribute but is recommended by ServiceNow or a Partner

    2. Keep – no related OOB attribute but a unique use case requires the attribute be retained

    3. Refactor – there is an OOB attribute or capability that can be migrated to

    4. Do Not Need (DNN) – this customization is no longer needed

  3. The most important step!!! – In all honesty, it is relatively simple to move a CI from one CMDB class to another. But such effort may neglect an extremely important element of your environment – dependency on your custom table. You may not be aware of potentially hundreds of reports, business rules, scripts, table references and more that look for data specifically in your custom table. Moving the CIs to a new table does not automatically move the reports, business rules, and etc. Thus, we need to identify table dependencies.

    We accomplish this effort using a fix script developed by Austin Buono of ServiceNow Customer Outcomes. The script has a place to enter the name of the table you desire dependency details on. The result is a list of specific dependencies.

    ServiceNow makes this fix script freely available through our ServiceNow Community here. Please take the time to subscribe to our community forum for updates to the CSDM.

    After running the dependency script and evaluating the data, you will have a level-of-effort understanding for your dependency migration efforts. Use this time to validate the referenced reports – are they still needed? Validate the rules & scripts – are they still needed? Identify what should stay and make a plan for migrating these to the new table(s) as needed.


  4. Refactor attributes – Now is the time to get the data model solidified and ready for data migration.

    Using the attribute mapping effort of task 2, create the necessary best practice and keep attributes on the necessary CMDB tables as you or a partner have documented. This is also the time to perform the documented refactor efforts as needed.

  5. Data Migration – With the attributes refactored and dependencies ready to migrate we can begin our data migration:

    1. Validate the data backup in task 1 is still useful. Perform another data backup if necessary.

    2. Migrate your CIs –modify the class to the new class name. This will move the CI and all its related objects, incidents, changes, and so on to the new table. Perform a handful at first and increase as needed/comfortable.

    3. Custom attributes or OOB attributes not in the same table hierarchy will result in data loss. This is why we made a backup.

    4. Remediate your table dependencies:

      1. Modify reports to use new table

      2. Migrate business rules & scripts if needed

      3. Update table references as needed

    5. Reload data into new attributes using your data backup.

    6. Validate all data and dependencies.

  6. Deprecation – Once the custom table(s) are no longer needed (void of CIs), then delete them from the system. Keeping custom tables with no use may result in new unwanted life (table zombies).


Data Governance

What is this Play about?

This play lists the best practices and processes for managing custom service-related tables

Required tasks

Periodically review the CSDM Data Foundation dashboard report to see if there are any CIs in custom service related tables


Congratulations

You have completed this Get Well Playbook.