Recently I had the opportunity to share with my local SNUG a presentation around building a future-ready data foundation using the Health Dashboards & CMDB/CSDM Best Practices Dashboards.
Below is an adaptation of this presentation for the community at large, hopefully this spurs some conversation or helps you with thoughts on how to continue improving the CMDB on your ServiceNow instance.
-----
For introduction my name is Marshall Parker, I am a ServiceNow CTA & CIS x3 certified individual with extensive background working on data products related to overall governance, architecture, and building strong data foundations across multiple CMDB methodologies, with the last 10 years focused on the ServiceNow ecosystem.
Before we get into some of the real-world examples and scenarios of how to build a future-ready data foundation, let me begin with a set up of what I mean by this phrase ..
What defines a future-ready data foundation?
For any modern system, especially a platform like ServiceNow, the heart at the center of all of our business processes, activities, and user interactions is a vast amount of data, collected from many aspects of your business.
When it comes to building anything, you want to build on a strong foundation. Well, the ServiceNow platform is no different – all of the foundational data that underpins everything you want to do – from Servers to Applications, Locations, Users, Databases – the iPhone in your sales guys hand to the balance sheet of each Business Unit in your company, this vast amount of data can feel like a great pile of Lego bricks.
You know you have the data needed to unlock value, streamline processes and build elegant automations, but unless there is a thoughtful design and ongoing governance it is hard to see how we go from where we are today to a bright future.
When you start to look at the varied data available to your platform, one of the first areas we look at for organization is implementing a strong CMDB…
And yes, the CMDB helps us to structure where data fits and put it into logical groupings.
Like this picture of sorted bricks – the CMDB structure tells us we have all of the Linux VMs gathered together over here, the network routers over in this segment, applications we run grouped together, and so on.
While the important configuration of these items is available in your CMDB [after all, it is a Configuration management database] – like who owns Server 123, or what firmware version is installed on this Load Balancer appliance, if we want to truly understand this info, we need to know how it fits into the bigger picture for our company.
And when we look at all the data necessary to build a future-ready data foundation the CMDB only holds part of the story as it doesn’t own or define all of the foundational data we need - like how our organization is built (Business Units, Locations, Departments), assigned (Users, Groups, Life Cycles), and operates (end to end Services and Digital Products used or sold)
This is where ServiceNow has provided the prescriptive approach called CSDM ..
The CSDM (Common Services Data Model) is a prescriptive method to connect your foundation data, CMDB, and relationships both for how devices are connected to each other & how they are supported by your organization, and helps you to define your Digital Products and Services that your teams provide both for internal use across your company and those you sell to your customers.
Properly applying CSDM methodology results in transforming your pile of organized bricks …
… into a completed structure.
Just like this Lego city pictured would not exist without the right pile of bricks [not just any pile], an instruction book and someone willing to do the work to put it together ..
Preparing for a future-ready data foundation requires having all of your data gathered in a single place [ServiceNow], a guideline [CSDM] and a team willing to put in the work and champion best practices.
For my team, driving towards a mature CMDB enabled by CSDM is helping us to start driving better experiences for our teams
- Improving end to end processes by relying on data driven routing for Incidents, Changes and more
- Measuring our data to improve quality, correctness and compliance using best practices and health dashboards
- Simplifying tasks by automating repeatable processes with OOB workflows and tools
Some of the initial benefits we are seeing from aligning to this model include:
- Faster resolution of incidents by reducing ticket hops, getting the right level of visibility to the right teams more quickly
- Visibility of IT changes for key approvers
- Measuring value add for internal teams from request response time, change lead time and overall trust in the data
Now that we have a definition of where we would like to be – and some of the “Why we should go there?” my team had to take a good look at the current state of our environment.
The Current State
When I was brought into my current environment, our team had been given the reigns to analyze the current ServiceNow platform and identify a path to mature an existing platform with several years of history to align to CSDM standards following industry accepted best practices.
The first step on this journey was to analyze all of the existing foundation & CMDB data to see where current maturity mapped to the CSDM Foundation, Crawl, Walk, Run, Fly steps
This analysis gave us our first priority steps:
- Custom fields that now exist OOB
- Moving CIs to appropriate class
- Define data governance roles, scope & purpose
- Large volume of stale & unreferenced CI data
Some of the underlying details for each of these include:
- Heavy use of customization led to many new fields being created that were a replacement for functionality that is now out of the box. In some cases, these fields came about with platform releases over time, but in others it was a lack of aligning to standards and creation of custom fields that already existed with maybe a slightly different name or format.
- Some classes were used initially with “best guesses” as to what data to store there (i.e. cmdb_ci_appl being used for all application listings – instead of using cmdb_ci_business_app for the application inventory and splitting the running executables from discovery into cmdb_ci_appl) along with some classes that were repurposed for entirely different styles of data.
- There was a lack of data governance in the initial planning for the ServiceNow system, instead data was pumped in from external data feeds without regard to tracking ownership, data roles, and a defined purpose for each data class being added.
- History of several years of importing & updating data with no thought towards a life cycle management to retire, archive, or delete stale and unnecessary data. This drove some initial cleansing rules to identify and purge unnecessary data and build rules using the Data Manager functionality to ensure the data retained in our CMDB was accurate and up to date.
Evaluation of Best Practices
In addition to working through the initial cleansing actions mapped out above, we next turned to aligning our plan to mature the CMDB by using the store app CMDB & CSDM Data Foundations (link).
This app creates 2 dashboards and ongoing metrics to ensure that CMDB and CSDM are properly configured for optimal usage.
Matching our initial scoring results to our current CMDB maturity, we leveraged the linked remediation playbooks to get a quick start by planning some strategic changes.
Restore Status fields to baseline
The best practice review highlighted a critical customization where the labels & values of status fields had been changed from OOB, causing a misconfiguration of what our system considered Installed & Operational vs. the choice values that some ServiceNow modules were expecting to see. In order to proceed towards using the Life Cycle fields we had to move back towards these baseline standards.
To solve for this required effort across multiple teams to:
- Scan for all code that reads or writes to status fields
- Update references to standardize updates to a common status field
- Plan for updates to all CIs across the CMDB to ensure they use the corrected status values
Defining link from Business App to App Service
With the introduction of the Business Application layer, an additional data alignment was needed to move the operational systems out of the base Application table [cmdb_ci_appl] and introduce Application Services, including automating creation of relationships to link the Business Application to the relevant Application Services.
Reducing custom field utilization
Custom fields that had been introduced over time to our CMDB table were evaluated to ensure functionality and reduce the volume of customized fields actively being used.
Some fields were replaced with baseline fields that have been introduced over time, other fields were identified as rarely populated and removed as no longer necessary. For those fields that have a defined business purpose, building a metadata repository to document why those fields exist, how they are used, and who is responsible for the data population of these fields.
Process CIs via IRE
Additionally, opportunities were identified to increase the volume of CIs that are processed through the IRE (Identification & Reconciliation Engine) vs. simply loaded into target tables from external data feeds. The benefit of moving source feeds into leveraging the IRE is to have a consistent method to identify and classify CIs so that data from multiple sources can be evaluated correctly and reduces the number of duplicate records that make it into our CMDB.
Expanding Governance by Measuring CMDB Health
The next step in our focus was standing up evergreen Data Governance with the use of the CMDB Health Dashboard.
Using the CMDB Health dashboard as part of CMDB Workspace, we worked on a designing a repeatable process that could be applied across every Principal Class in our CMDB.
- Identify data owner & custodians
- Apply MVP template for all health rules
- Measure & report initial results to data owners
- Engage data owners to remediate issues with a combination of adjusting health rules and fixing data at the source (in ServiceNow CMDB or in an upstream source system as applicable)
Short term benefits realized include:
- Identifying engaged SMEs to help focus our governance patterns
- Closed data gaps on inbound CMDB integrations
- Removed duplicate records to improve speed & overall user experience
CSDM Best Practice adherence is a journey
Building a future ready data foundation is a journey, but hopefully you can see there are many tools that can help you make progress. Ensuring your data is ready will allow you to build a more mature CMDB and prepare you to introduce CSDM concepts like Digital Products, dynamic service catalogs, and app harmonization.
1st Year Milestones
- Increased overall measured CMDB health quality by 50%
- Major increase in adherence to Best Practices
- Established CSDM Foundation & Crawl methodology
- Launched formal governance framework
- Began awareness towards a Digital Products / Service-Aware enterprise
The actions needed for a journey like this are not always linear – sometimes the team felt like they were a little bit all over the map but every action we took supported the overall goal.
