CMDB Governance model

Go to solution
Allen_Deepak
Mega Guru

‎03-24-2023 03:10 AM

Hi,

We just migrated to ServiceNow OOTB instance in our organization and the initial discovery and CI population is almost done.

To support the ongoing CMDB maintenance activites, we are thinking to implement a Service request form which users can submit a request for any type of CI updates and configuration manager can look into it.

My question is, is it something worth to have these kind of manual forms or should we automate these updates via workflows? If we choose complete automation, there is no control over the data and we get lots of questions on how the data is being populated. Please help with some best practices or sample process flows on how we can implement this. 

 

Thanks in advance

0 Helpfuls
  • 5,013 Views
1 ACCEPTED SOLUTION

Go to solution
CMDB Whisperer
Mega Sage

‎03-24-2023 06:08 AM - edited ‎03-24-2023 06:09 AM

My recommendations are as follows:

 

1. It should not be the configuration manager's responsibility to control the data.  It is the data owner's responsibility to control the data.  For CMDB that role is typically assigned per CI class, and it is stored in the "Managed by Group" field.  As a configuration manager, your general position should be "hands off" when it comes to the actual configuration data, except when required to intervene as a configuration admin to do things like bulk edits, data migrations, user requested edits, etc.

 

2. There is certainly a valid argument to be made that updating CI attributes via a controlled process such as Service request provides a much more controlled experience, allowing more advanced business logic to be put into the request fulfillment process and thus leading to improved data and process.  However, in reality this may cause you a lot of headaches if you practice it widely across the entire CI.  So unless you have specific policies that mandate centralized control of the CI data, I would suggest exercising some caution here.  If the process is too cumbersome, the likely result is that your CIs won't get updated at all because... well, CI owners are human.  And humans don't like unnecessary red tape that they don't see as valuable.  And noncompliance is the inevitable result.  Instead, look for ways to add value by using this control judiciously.  For example, Status/Operational Status fields might be worth locking down for manual edits, forcing users to go through a controlled process such as Request or Change Management to change it.  But submitting a Request to modify the Description of a CI is likely to be seen as unnecessary red tape.

 

3.  Keep in mind that there are two kinds of data on a CI.  Technical data and business data.  Technical data can be discovered and thus having users update those fields might be not only unnecessary but also pointless, unless that data is getting discovered only sporadically, and then allowing users to modify the data themselves might be very useful.  Business data, on the other hand, is not discoverable, and needs your CI data owner involvement to make the data complete.

 

4.  Use CMDB Health to manage the Completeness and Correctness of your data.  Focus on a finely tuned configuration to measure just what you are most interested in.  Have a laser focus only on the most important data and exclude everything else until you get your scores where you want them, and then broaden your view to take on additional CI classes, data, and metrics.


The opinions expressed here are the opinions of the author.

View solution in original post

3 REPLIES 3

Go to solution
CMDB Whisperer
Mega Sage

‎03-24-2023 06:08 AM - edited ‎03-24-2023 06:09 AM

My recommendations are as follows:

 

1. It should not be the configuration manager's responsibility to control the data.  It is the data owner's responsibility to control the data.  For CMDB that role is typically assigned per CI class, and it is stored in the "Managed by Group" field.  As a configuration manager, your general position should be "hands off" when it comes to the actual configuration data, except when required to intervene as a configuration admin to do things like bulk edits, data migrations, user requested edits, etc.

 

2. There is certainly a valid argument to be made that updating CI attributes via a controlled process such as Service request provides a much more controlled experience, allowing more advanced business logic to be put into the request fulfillment process and thus leading to improved data and process.  However, in reality this may cause you a lot of headaches if you practice it widely across the entire CI.  So unless you have specific policies that mandate centralized control of the CI data, I would suggest exercising some caution here.  If the process is too cumbersome, the likely result is that your CIs won't get updated at all because... well, CI owners are human.  And humans don't like unnecessary red tape that they don't see as valuable.  And noncompliance is the inevitable result.  Instead, look for ways to add value by using this control judiciously.  For example, Status/Operational Status fields might be worth locking down for manual edits, forcing users to go through a controlled process such as Request or Change Management to change it.  But submitting a Request to modify the Description of a CI is likely to be seen as unnecessary red tape.

 

3.  Keep in mind that there are two kinds of data on a CI.  Technical data and business data.  Technical data can be discovered and thus having users update those fields might be not only unnecessary but also pointless, unless that data is getting discovered only sporadically, and then allowing users to modify the data themselves might be very useful.  Business data, on the other hand, is not discoverable, and needs your CI data owner involvement to make the data complete.

 

4.  Use CMDB Health to manage the Completeness and Correctness of your data.  Focus on a finely tuned configuration to measure just what you are most interested in.  Have a laser focus only on the most important data and exclude everything else until you get your scores where you want them, and then broaden your view to take on additional CI classes, data, and metrics.


The opinions expressed here are the opinions of the author.

Go to solution
mikkojuola
Giga Guru
In response to CMDB Whisperer

3 weeks ago

Thanks @Allen_Deepak and @CMDB Whisperer – fully agree that the key question here is governance, not whether people use a form or update the CI directly.

 

What we’ve seen work well is to make that governance explicit with a simple Consumer–Owner–Provider model:

  • Consumers – processes/roles that actually use the CI data (Incident, Change, Finance, AI use cases, etc.)

  • Owners – decide what data is needed and how it should look for their domain, or CI Class

  • Providers – people/tools that maintain that data (application owners, service owners, discovery, integrations…)

Once you have that, you can let Owners define the requirements per CI Class/domain, and then decide which of those must go through a controlled request/change and which can be updated directly or automated. That’s very much in line with CMDB Whisperer’s point about avoiding red-tape on every update while still protecting the critical bits.

 

In our own work (using Data Content Manager on top of ServiceNow), we implement this by:

  • capturing the Owner’s requirements as Blueprints for each data domain,

  • running audits to see where live data deviates from those requirements, and

  • giving each Provider a personal data quality view that only shows “their” gaps to fix, and provides the means to fix them.

We recently pulled these practices together in a short eBook called “The CMDB Data Quality Playbook”, which walks through the governance model and examples step by step (including how DCM supports all this). If that sounds useful, you can get the ebook from the link below:

 

The CMDB Data Quality Playbook

 

If that playbook raises any questions, I'm happy to jump on a call or try to respond to them here.

 

Cheers,

--Mikko

0 Helpfuls