What benefit is ServiceNow Discovery providing you?

[Brandon Warren]

What benefit is ServiceNow Discovery providing you? My company purchased discovery licensing with our initial contract about two years go and we've been unable to find any beneficial uses for it. We run a mostly virtualized environment and are able to pull in all of our Virtual Desktops\Servers via scheduled PowerShell jobs. All of our physical endpoints are in SCCM and are pulled in via SCCM\ServiceNow integration. We've tried to use discovery for some of our networking and power delivery equipment, but find that some of the information it pulls back about the devices is inaccurate. Even if it does pull back accurate information, it also pulls in a ton of CIs for information we have no intention of managing and doesn't give us an easy way to tune it back. We constantly hear about how amazing discovery is, but our experience with it hasn't been great and I was curious what others in the community though about it.

[Inactive_Use144]

Hey Ashutosh - definitely agree with you as usual. The part I would point out is the relationships. Discovery maps server to app relationships with relative ease which starts you down the path of mapping out not only your app to host relationships but laying the ground work to show real value for your ServiceNow CMDB at the executive level in your organization by starting to adopt the Common Data Services Model (CSDM) framework to track multiple pieces of your entire organization from the CMDB. When you can show value to executive leadership by mapping a Business Capability (what your business does at a foundational level) down to the file system level of a server supporting that Business Capability, then you are bound to receive more funding for keeping that CMDB accurate. Not only that, but it provides real value to more pieces of your organization (sales, asset management, of course ITSM and ITOM, etc.).

I would consider Discovery the gateway to the CMDB becoming a much larger organizational piece than merely an inventory database. It automates that technical app to host relationship which can then go on to Service Mapping or make use of the ETL Integration Hub which is a fantastic way to manually map on top of tech.

There is a great conceptual model of the CSDM at this link.

Also, after you spend some time with the pattern designer, it really is a nice way to customize the querying of devices to get the data you need from targets.

[Hitoshi Ozawa]

I've found that discovery itself won't add too much value if there's already some other software to monitor the devices. It just adds records to cmdb database and it really doesn't add any value having data if it's not utilized.

It's how CIs are used that creates the benefits to having discovery. If CIs are not specified in Alerts, Incidents, Requests, Problems and other places, it's not being utilized and there's not much value. CI is a key to correlate relations between all these events to find the overall problem. For example, a single alert on a printer may be related to an incident but may also be related to several requests from end users. This may lead to increasing risk factor of a printer. Without the CI, it would just be independent events.

There are other tools to do horizontal discovery, but I think ServiceNow discovery does a good job in service mapping (vertical discovery) to relate CIs together. Relationships between CIs enables me to better correlate events together. For example, an event on a printer may actually be caused by a failure event on a switch that the printer is attached to.

That said, ServiceNow implementation needs to be in mature state to fully see the business benefit of discovery. If I'm just starting out, I've found it sufficient to just populate CIs using some third party tools especially since Discovery is kind of expensive. The question for me is when Discovery should be installed rather than if it should be installed.

[David104]

One of the biggest advantages of ITOM Visibility (Discovery and Service Mapping) is the relationships that are populated - inventory tools like SCCM will not provide this for you.

For example, while SCCM will populate a server in the CMDB and possible tell you that MS SQL Server is installed on it (via 'Installed Software'), it does not tell you what SQL databases exist. When discovery picks up a server, it looks for running processes like SQL server and then know how to query SQL to find out which DB's are running, what databases files are being used for them etc.

A similar thing would happen for IIS or Apache Tomcat or any other web server that is supported.

These discovered CI's can then either be manually mapped to 'Application Services' or Service Mapping can be run to find relationships between a web application, the web server that it runs on and the database that the web server pulls data from.

There are lots of reasons why this kind of data might be useful to you in your CMDB but that depends on the maturity of your other ITSM processes and how much they rely on the CMDB. Hint, they should all use CMDB data.

One of the most common example is if you are using Event Management. Let's say one of your monitoring tools picks up an error on your SQL database. Rather then ServiceNow linking that event to a host, it can link it to the database CI itself. If you have multiple databases running on that server, that makes it a lot easier to determine which service is impacted.

With regard to your comment about the volume of CI's, don't let that be a deterrent. In Orlando (I think) servicenow introduced the 'Principal Class' flag in CI Class Manager. You can use that flag to highlight the important classes - preferably ones which are well managed - and filter incident/problem/change forms to only show CI's belonging to a principal class. Likewise, you can ensure your dashboards and reporting only present the information about classes that you really care about. You will find that as your processes mature, you may flag additional classes as Principal Classes. The additional CI data that you are not as interested in can be useful from time to time for running reports for Service Owners, or maybe to capture un-authorised change etc.

I've been doing config management for over 10 years now and I would recommend discovery on top of inventory data from tools like SCCM any time. I'm not discounting those data sources though, to have complete and accurate CMDB, it is good to not just rely on one source. Hence the work that ServiceNow have put into the Multi-source CMDB and Service Graph features in Paris.

I hope this gives you an additional perspective to consider. 

Regards,

David