top of page

Best Practices

Resources | Configure Directly in Prod | Lessons Learnt


 

Resources

 

We recommend the following roles to be engaged for a successful implementation of Discovery Admin. For smaller teams, it's natural to have the same resources wear 'different hats'.


It's important for the identified resource(s) to understand and be accountable for their responsibilities captured below:

  • Project Manager: responsible for the overall implementation timeline and timely execution of the scoped effort, including scheduling the necessary meetings for internal alignment.

  • Functional Resource(s): responsible for managing scope and engaging stakeholders to help execute the remediation of identified issues.

  • Technical Resource(s): responsible for configuring Discovery Admin and administering the ongoing Troubleshooting and Incident Generation.

  • Stakeholder(s): responsible for executing the remediation of identified issues and providing the necessary feedback.

  • Sponsor: responsible for escalations needed for engaging Stakeholders across different teams.

It is prudent to wait until we have resources identified for the roles above before implementing Discovery Admin.


 

Configure Directly in Prod

 

While it is recommended to independently validate the functionality of Discovery Admin in Non-Prod (before migrating Discovery Admin to Prod), configurations for Discovery Admin (Properties and Incident Error Codes) should be performed directly in Prod for the following reasons:

  • Data-Driven Configurations

    • There are two main Configurations allowed with Discovery Admin... updates to Properties and updates to Incident Error Codes.

    • As a result, all configurations for Discovery Admin are Data Driven.

    • There are no code changes permitted for Discovery Admin. In the context of CMDB and ServiceNow Discovery, it is a part of the standard workflow to have the data change directly in Prod.

  • Properties

    • Discovery Admin Properties may have different values in different instances.

    • As a result, Property values can be directly configured in Prod (and validated with a targeted Discovery followed by Ad-hoc Troubleshooting and / or Incident Generation)

  • Incident Error Codes

    • The validation of the configurations for Incident Error Codes depends heavily on the ServiceNow Discovery Logs and the data present in the CMDB.

    • As a result, Incident Error Codes can be directly configured in Prod (and validated with a targeted Discovery followed by Ad-hoc Troubleshooting and / or Incident Generation)

    • There is no value in synchronizing Incident Error Codes in Prod with non-Prod as elaborated in the next section: Prod vs Non-Prod Data.

  • Prod vs Non-Prod Data

    • Considering the variability between the Prod and Non-Prod environments, the data in the Non-Prod environment (in the context of the CMDB and ServiceNow Discovery) is not the same as the Prod environment.

    • Synchronizing Prod Data with Non-Prod Data requires excessive resource time and duration and is impractical to accurately replicate.

    • As a result, we still need to re-validate in Prod as the validation done in non-Prod doesn't accurately represent Prod.

  • Cloning


As a result, there is no need for any migration efforts supporting the Discovery Admin Application from non-Prod to Prod.


The only reason for configuring Discovery Admin in non-Prod is if you are in Project mode and ServiceNow Discovery is not implemented in Prod.

In this case, leverage Discovery Admin (Step 2 and Step 3) in the most current non-Prod environment supporting ServiceNow Discovery, until ServiceNow Discovery is implemented in Prod.


 

Lessons Learnt

 

Below are lessons learned from previous Discovery Admin Implementations:


  • Roll out Discovery Admin in the order of the Steps referenced in the Implementation Guidelines.

  • When testing / validating Discovery Admin in non-Prod, make sure the validation is done by a non-admin user with the discovery_admin and itil role (directly or via impersonation)

  • Don't wait till everything is perfect. There are bound to be data exceptions that can be addressed as a part of subsequent iterations

  • Allocate a Project Manager to help manage milestones and timelines

  • A Discovery Admin implementation is high on Duration (but low on Effort). This means that resource unavailability (conflicting priorities, vacations, etc) may significantly affect the timelines

  • Adjust for other ServiceNow Platform activities (instance clones, change freezes, etc) which may significantly affect the timelines

  • All the resources need to have a functional understanding of Discovery Admin. This can be addressed by leveraging the Articles and Videos on this website

bottom of page