Use of Custom Attributes in CMDB

Get Well Playbook

Use of custom attributes in the CMDB

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

Table of Contents

Summary . 1

Goal of this Playbook . 1

Audience . 1

Problem Overview .. 1

Executive Summary . 1

How this playbook can help you achieve your business goals 1

How this playbook is structured . 1

Problem Analysis 1

Upstream Causes 1

Downstream Consequences 1

Impact on Your Business 1

Engagement Questions 1

Remediation Plays 1

Summary . 1

Play 1 - Analyze Existing Custom Attributes 1

Play 2 – Analyze Placement of Existing Custom Attributes 1

Play 3 – Analyze why Attributes were created . 1

Play 4 – Ready to Fix . 1

Data Governance . 1

Summary

Goal of this Playbook

This playbook does not provide specific remediation steps, but general guidance in identifying custom attributes and if they are on an appropriate level in the CMDB hierarchy. Excessive custom CMDB attributes should be reviewed to ensure they are both relevant and appropriate.

Author John Walker (Johnny), Callan Bond Date 07/15/2020 Addresses HSD # HSD0001703, HSD0006591 Applicable ServiceNow Releases All Releases Time required Varies, based on your customization level Audience

ServiceNow Admin

Configuration Manager or Configuration Management team

Problem Overview

ServiceNow provides an enormous amount of flexibility to meet specific business outcomes. While customizations can often help achieve business value, using customizations inappropriately - either when an out-of-the-box solution exists, or at an incorrect implementation level, should be avoided.

For the CMDB, custom attributes provide this flexibility to address business needs. In older versions of the ServiceNow CMDB, some attributes did not exist that are now available out-of-the-box. Whatever the reason, the result of the decision to create these as custom attributes (indicated by the u_ prefix of the field name) is that now platform provided fields are available, and data should be migrated to make use of the native fields as soon as possible.

Using out-of-the-box attributes provides benefit both from ease-of-upgrades, and from ensuring that data is in well-understood locations that can be used by multiple applications throughout the platform. If business data resides in custom attributes, these may be shown on specific reports that have been created to consume the data, but the value may be lost in other applications that would also consume this information in out of the box reports or processes.

Another area of concern when customers have customized the CMDB is that attribute creation should be at the correct level in the class hierarchy. Sometimes custom values are set at the child level when they should instead be set at the parent level or vice versa. These misplacements can impact performance and again lead to inconsistent or incorrect reporting. Single child specific attributes created at a parent level will unnecessarily propagate to all siblings.

Executive Summary

How this playbook can help you achieve your business goals

Identifying custom attributes will enable you to review them, determining which can be migrated to make use of out-of-the-box attributes.

Similarly, identifying any custom attributes at an incorrect level (too high or too low), can lead to an evaluation and corrective action.

How this playbook is structured

This Playbook is structured to guide you through an analysis of the current state of CMDB custom attributes. This playbook does not offer specific remediation steps as a result of the analysis, but rather we provide some general guidelines. None of the plays are required actions. Good judgement and careful thought should be used in choosing one or more of these plays to guide you towards optimal CMDB experience and performance.

Once analysis and validation are complete, you can determine which custom attributes are to be migrated and/or deleted. These decisions should be based on the out-of-the-box alternatives, business value, and effort required. Doing so will support a cleaner and more maintainable CMDB, while avoiding potential data issues that can severely impact CMDB trust and efficacy.

Problem Analysis

Upstream Causes

At the time of customization there were no appropriate attributes provided for a legitimate and urgent business need, which led to the decision to add a custom field

Implementation, development or administration team member did not realize that an appropriate attribute already existed within the CMDB hierarchy

Development mistakes such as correcting a field name typo within the same Update Set, without pruning the incorrect attribute from the Update Set before promotion A legacy system had a particular attribute defined, and the migration implementation team decided to create a new field rather than advocate for use of out-of-the-box fields

Downstream Consequences

Data Consequence

Duplicate data and columns both in parent and child tables, leading to confusion and unintended behaviors

Record updates become slower due to the unnecessary overhead of updating records in 2 tables

Unnecessary complexities in data model

Discovery and other applications might populate base attributes as intended, leading to data mismatches and confusion

List views could contain more than one of the same labels for different fields, leading to confusion

Operation Consequence

Extra overhead to maintain these additional fields in database, including the time required for new team members to learn custom attribute names

Form views with the same attribute duplicated can have unexpected behaviors around UI Policies, leading to functional problems

Additional overhead of updating discovery patterns, probes and sensors to use non-standard fields

App Consequence

Sluggish report generation due to higher database query times

Overhead of maintaining custom solutions to populate data in non standard fields

Newer applications and features provided by the platform will expect that data resides in provided fields

Data in custom attributes not used in newer platform provided reports, features, dashboards, notifications etc..

Impact on Your Business

Increase Operational Visibility When using baseline fields, there is greater chance of process alignment to well understood practice guidelines which are built into the platform

Data integrity and reliable operation of your platform will contribute directly to providing the maximum amount of information for any business process using it

Audit/Compliance

Keeping or returning your CMDB schema to baseline will result in more reliable adherence to Data Governance, including ACLs, audit logging and UI Policy enforcement

Service Level Awareness There are powerful dashboards provided throughout the diverse ecosystem of applications built upon this platform - and more are being added with each release - these dashboards expect data to reside within provided fields Report generation will be more efficient at run time and less time will be spent to alter or create custom reports when fewer custom attributes are in use

Process Automation There are many provided digital workflows throughout the platform its applications. These can be used immediately when data resides within the provided fields

As these workflows evolve, less time will be spent updating customized versions of them to continue the use of custom attributes

Better User Experience Fewer customizations within the table schema will result in much simpler implementations and application development

When data resides within expected fields there is a more reliable and consistent experience for developers, admins and users

Engagement Questions

Do you have a list of all custom attributes in your CMDB?

Does every custom attribute have an identified business reason behind its existence?

For each field, is there an owner who needs that attribute? Has that field been populated, maintained, governed and secured or has it been forgotten?

Can you verify where the custom attribute is being used? Is it being populated simply because "we've always had to populate it", or because there is actual value being realized?

Was a custom field added with the intent to drive a particular user behavior, and is that goal obtainable through any means other than customization?

Has the effort of maintaining the customizations outgrown the value of having them?

Have custom attributes been reviewed to ensure there are no newer base fields that can be used?

Have custom attributes been reviewed to ensure they are at the appropriate level in the CMDB hierarchy?

Are any of them propagated to child / extending CI classes where they are not used? (the attribute is 'too high')

Are any of them individually added on several child / extending classes that share the same parent class? (the attributes are 'too low')

How do you decide when to add a new attribute to the CMDB? Is there an Architect or governance team helping to make informed decisions?

Remediation Plays

Summary

Play

Outcome

Analyze current schema

What this play is about

Query and Analyze existing schema of your instance to get an idea of the current state

Required tasks

Review list of custom attributes in your CMDB

Play 1 – Analyze custom attributes

What this play is about

Review custom attributes in your CMDB

Required tasks

Review custom attributes in your CMDB

Play 2 – Analyze placement of custom attributes

What this play is about

Review placement of custom attributes in your CMDB

Required tasks

Review placement of custom attributes in your CMDB

Play 3 – Analyze why custom attributes were created

What this play is about

Identify why these attributes exist

Required tasks

Interview SMEs on history around these attributes

Play 4 – Ready to fix

What this play is about

Review Usage of attributes

Required tasks

Guideline on how to approach the cleanup process

Data Governance

What is this play about

Includes guidelines and processes for managing customizations to the CMDB

Required tasks

Follow these guidelines and processes to prevent unauthorized customizations to the CMDB

Play 1 - Analyze Custom Attributes

What this play is about

In this play you will review the number of custom attributes on your CMDB tables and the specific tables they are on. You will also be provided guidance on what these values can mean and what to do if you have extraneous customizations.

Required tasks

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

Navigate to the CMDB Data Foundations Dashboard module in the left navigation menu

Select the Customizations tab

Select the Use of Custom Attributes line in the score card shows the current score

Download and import the Custom Attributes in CMDB Fix script

Run the Fix script

Upon successful completion, review the output from the query

Note the actual table names and column names will be different, but a sample of the output is below:

In general, we are looking for high counts of custom attributes. A rule of thumb is that if you have 10 or fewer custom attributes, and you can identify a business reason behind the attributes, you are not overly customized and are in good shape.

If you have more than 100 custom attributes, you have too many and have some work to do to identify owners and examine custom attributes to see which can be migrated to base attributes. Generally some concentrated effort will be required here.

If you have between 10 and 100 custom attributes, you should follow the same steps (identify owners, business value, and look to migrate where you can), but likely at a lower urgency than those with 100+ custom attributes.

There is no 'magic number' for custom attributes on CMDB tables. In general, fewer customizations are better. However, customizations can be necessary as you may have a specific need to capture and report on data from an attribute of a configuration item that is not in the base offering. For most customers though, this tends to be 10 or fewer attributes. If you have more than 10 custom attributes, you should do further analysis on them using the guidance in section 4 "Attribute Analysis" of this play below.

Play 2 – Analyze Placement of Custom Attributes

What this play is about

In this play you will review the number of custom attributes on your CMDB tables and evaluate their placement.

Required tasks

Download the Custom Attributes in CMDB Level Fix Script

Run the script as a Fix Script in your target instance

Upon successful completion, review the output from the query

Ignore lines above output that differ from below Typically, a custom attribute on multiple tables indicates that it should be placed 'higher' in a hierarchy. In particular, if a field is on all child tables from a parent, it should always be on the parent table instead and removed from the children.

Continue with the analysis in the next section to determine appropriate next steps.

Play 3 – Analyze why Custom Attributes were created

What this play is about

Identify the reason behind why these attributes exist. Find out why were they created, who owns them and are they still used.

Required tasks

For each custom attribute output from the scripts above, consider the following:

Who is the owner of the attribute and who is using that data?

A team or individual should ultimately be responsible for adding the attribute in the CMDB in the first place. This team or individual often can also be the person consuming the information that is captured here.

If an owner cannot be identified, or more importantly, if individuals or teams cannot be identified who are actively using the data, the attribute is a strong candidate for removal (not migration).

Is the information used for a business critical process?

While the information captured in the custom attribute may have an identified owner, often the fields additions were to support a legacy business process. Identifying the business value that a particular custom field delivers is an important factor in determining if the attribute should be retained. If the attribute population is done simply because "we've always done it this way" or because it is to maintain historical trend data that otherwise has no current value, then that field is also a candidate for removal.

Are there now equivalent base attributes available?

Many custom attributes were created for good reason: they captured data critical to a business process in a field that was not available in the product at the time of release / implementation. However, with the rapid evolution of the ServiceNow platform, new and improved table structures are introduced with every family release. Forms, reports, dashboards, workflows, notifications and much more are all built to make use of these provided fields.

One way to check if a similar column exists is through the CI Class Manager. If, for example, the custom attributes are on a table that descends from cmdb_ci_hardware, navigate to the Hardware class. Under 'Attributes' on the right panel, search for columns that have similar names and/or labels to the names of your custom attributes. Review the Type of these base fields to determine if they are a possible match to take the place of your custom fields.

Are there similar attributes in other tables that could be used via a relationship?

Sometimes during an initial implementation, relationships between tables are not leveraged as fully as they could be. If the data for a custom field is already tracked in another table, the existing table and column should always be used rather than creating a new field. More than likely there is a reason the data is in that other table, and there might even be other fields in that table which can be made accessible through this intended use of relationships and related lists.

Establish a relationship between the two records instead of copying and maintaining data in two places. Play 4 – Ready to Fix

What this play is about

Once you have identified candidate attributes for retirement or migration to a base attribute, you should review the usage of it before carrying out any remediation.

This section does not give explicit step-by-step instructions on everything that can be impacted. However, as a general rule, you will need to confirm what uses the extraneous attributes you have today, and then determine if that usage outweighs the costs of having each custom field. This effort can require time and careful consideration. It may be best to align efforts to coincide with platform upgrades when users are already expecting small changes to their experience. You may save time in User Acceptance Testing by doing these in tandem.

Remember to not make changes directly in production. Always follow your established development practices such as a frequently cloning production down to dev and test instances. Use scripts to migrate existing data in custom fields to any base or equivalent fields, making sure to check that field types and maximum lengths are the same or appropriate.

Check for any CIs and relationships that use a particular custom attribute including:

Forms Reports Business Rules Relationships UI Actions Client Scripts Email Actions Transform Maps Any other components

Required tasks

Once you have identified where any data is used (if at all), you can understand the impact of deleting the custom attributes. Reference ServiceNow docs for more information around deleting table fields.

Data Governance

What this play is about

It is recommended that the CMDB owner, in partnership with the CI Class Owner, should approve any changes to CI Class attributes that are requested. Not all custom field additions should simply be approved. For instance, if the total record count is 10k+ and the audience for this new field is 2-4 people within an organization of 50k or so users, does it make good sense to make a customization for just these 4 people?

These types of requests are fairly common from within the user base. It is a strong indicator of CMDB adoption when users are asking for fields to be added. Usually, a platform Architect (preferably one with specific CMDB experience) is responsible for determining how to meet the needs of all users (or as many as possible), without adding unnecessarily to the complexity of the entire system.

This play tells you how to set up a process that keeps others from creating custom CMDB attributes without proper review and approval.

Required tasks

Document an internal policy that prevents the creation of CMDB attributes without approval from a qualified person or team

Institute a code review process that watches for custom attributes in Update Sets

Create a report that shows any custom fields on tables descending from cmdb_ci created after the last attribute cleanup was performed

Regularly review Configuration Management Database (CMDB) release notes for announcement of new CI attributes Congratulations

You have completed this Get Well Playbook.