Planning for a ServiceNow Discovery Implementation can be a challenging task unless you know how! That is why in this article we are looking at three aspects to consider when planning for ServiceNow Discovery: Organization, Process and Technology – the three pillars for setting any implementation up for success.
Values
First, let us quickly look at why companies and public administrations invest their time and money into ServiceNow Discovery.
There are two main reasons:
- Organizations want insights into their IT infrastructure; They want to track every device they operate within their environments accurately.
Keep the scale in mind: we’re speaking of potentially thousands of devices, from on-premise servers in datacentres to virtual machines in various public clouds or simple end-user workstations.
With ServiceNow Discovery, organizations have better data quality simply because automation by its very nature brings standardization and consolidation; Plus, it is easier to manage and scale. - Organizations also want that operational data is kept up-to-date in the most efficient way
Automated Discovery into a single CMDB is the best approach because it allows for better overall awareness of operations, reducing risk and cost.
Strategy
People
Whatever project we’re working on, we always need to consider everyone involved:
- Management and project sponsors,
- Developers and administrator,
- Assisting SMEs and end-users,
- Vendors and customers.
Establishing an effective communication strategy is the greatest tool to keep all stakeholders well informed and alert.
Keep in mind, ServiceNow Discovery is not a small point-product solution!
In most use-cases, it is far-reaching, spanning across multiple departments within the organization, often requiring access to all parts of the network.
Do not underestimate implementations that need to cover multiple geographical locations.
Working together is the ultimate key to success!
Fortunately, most ServiceNow Customers are well aware of this and have the necessary governance in place. However, if this is not the case, the next pillar should undoubtedly help you.
Process
Processes are the routines that drive productivity and thus the business – and nowadays, there are plenty of standardized processes.
ServiceNow Discovery is not a process, but it typically builds on top of the ITIL Configuration Management process.
The scope of Configuration Management includes the monitoring and management of all Configuration Items and their relationships that make up the IT environment.
The ServiceNow Configuration Management process encompasses the definition of:
- CMDB classes and attributes,
- data sources such as Discovery or other,
- the actual CMDB governance, including functional roles and responsibilities,
- as well as interaction with other processes such as Change Management.
Speaking about Change Management – another ITIL process, it is critical for maintaining a successful Configuration Management process. But, unfortunately, it is often very much underestimated or even forgotten.
If the underlying processes are not adequately established, it becomes clear that it should be the first order of business before considering Discovery. Consequently, if Discovery is implemented without these fundamentals, it certainly does its job from a technical point of view. However, you run the risk that your CMDB will become outdated and cluttered very fast, thus losing all its value to the organization.
Technology
The tools people use to drive their routines, aka processes, are becoming more and more standardized and thus interconnected. It also means that many dependencies to consider already when choosing between technologies.
If dependencies and limitations are only considered during implementation, you’re likely to encounter some bad surprises. So let’s have a closer look at an organization’s technological landscape and how we can leverage the different technologies of ServiceNow’s Discovery solution.
Cloud
The Cloud is here to stay, or – to be more precise – the Hybrid-Cloud Model is here to stay and takes an even bigger role in the strategy of IT organization with every passing year.
With that growing demand, there is also the need to manage all the resources.
ServiceNow Discovery allows for Cloud Inventory of the most common cloud service providers on the market simply by connecting to the available APIs.
And there are a few things that are important to know about:
- The list of supported Cloud Service Providers and supported features for each can change with every release. Read about current as well as future releases!
- On-premise virtualization environments, such as Citrix vCenter, can also be considered “Cloud Service Providers”- their resources are discovered through APIs.
- And last, but not least: Cloud Inventory – all that I just mentioned – does not return OS-level information!
Meaning the configuration of the host system running on the virtual machine instance will not be read; We are not writing anything into the cmdb_ci_computer class-hierarchy or its related classes – that’s why we need the other Discovery technologies.
Agent-less
Agent-less Discovery, also often referred to as IP-based Discovery, requires the deployment of MID servers that allow the communication between a ServiceNow instance in the public Cloud and the resources on an internal network.
The MID server securely communicates with the instance using the HTTPS protocol. Well noting that, for security reasons, it is always the MID server that initiates communication. It is the MID servers asking the instance for the tasks they need to perform next.
When, for example, in our case, a Discovery instruction is received, the MID server will communicate with the internal resources on the network using protocols such as WMI, SSH, SNMP – just to name the most common ones.
This means the MID server sends a command to another resource on the network. Providing the right accesses are given, the resource will reply to the command. The received information will then be sent back to the instance for processing.
Without digressing further into the technicalities of this topic, you can probably now already observe what is important to consider:
- First and foremost: You need to be aligned with the Security team!
They need to be on-board right from the start, otherwise they might see the solution as intrusive and outright refuse it. - Next, you need an overview of the network – work together with the network team.
They should be able to provide you a list of the IP-ranges, a topological map of the network and a good understanding of technical dependencies such as firewalls.
The goal is simple: you want to be able to design your Discovery Schedules and the MID servers properly.
Keep in mind:
- Timing is important: broadcasting through a network may have an impact on network performance. Plan accordingly!
- Performance and redundancy requirements towards the MID servers: they depend entirely on the scale of your Discovery deployment.
- Consider also special cases such as DMZs, high-security environments, or even requirements towards certifications and regulations.
It may be that you cannot use agent-less Discovery, for example, core-banking environments in the financial sector. This is because they are usually heavily regulated, and the use of IP-based Discovery might be considered too intrusive.
Agent-based
That’s why since this year, ServiceNow also offers agent-based Discovery with their Agent Client Collector, short ACC.
As the name suggests, a light-weight agent can be deployed on devices to collect information.
Interesting enough, the agent does not communicate with the instance directly, it requires accessible MID servers to send information back to the instance.
Have a look at my hands-on video to get a better understanding!
Nevertheless, you should consider the following when evaluating agent-based Discovery:
- An agent cannot be deployed on all devices – there is a list of supported operating systems.
Meaning devices such as appliances or network equipment cannot be discovered using this technology.
- If the devices to be discovered with agent-based technology are Windows hosts and you have Microsoft SCCM, integrating with the latter might just be simpler.
- The ServiceNow Agent Client Connector is very interesting to consider if you want to use it to monitor the devices (using Event Management) or orchestrate them.
- However, the agent does currently not support Service Mapping. It’s not using patterns, so it will be interesting to see how this will be solved in future.
The agent-based Discovery is currently still pretty new to all of us, only time can tell how well this technology will be adopted.
My personal opinion: I love it! Yes, it’s still rough around the edges, like any newly introduced feature; nevertheless, the Agent Client Collector framework has a solid underlying architecture that is scalable and reliable when correctly set up.
