Service Mapping is one of the most valuable ITOM capabilities in ServiceNow, and one of the easiest to start badly. Maps built on weak discovery data, missing credentials or unclear service definitions produce diagrams nobody trusts.
This checklist covers what NowBench validates before starting a Service Mapping engagement. Working through it honestly will save weeks of frustration later.
1. Service definition and scope
- Have you chosen a small set of genuinely important services to map first, rather than attempting everything?
- Can someone describe each candidate service in business terms: what it does, who uses it and why it matters?
- Is there an agreed entry point for each service, such as a URL, load balancer or application endpoint?
- Do the services have named owners who will review and confirm the maps?
2. CMDB foundation
- Is the CMDB data for the infrastructure behind these services reasonably accurate and deduplicated?
- Are identification and reconciliation rules in place for the data sources involved?
- Is there a CSDM aligned structure for the maps to hang from, or at least a plan for one?
- Do you know which CMDB classes the mapped components will land in?
3. Discovery coverage
- Is horizontal Discovery already running reliably across the infrastructure supporting the candidate services?
- Are MID Servers placed with network access to the relevant environments, including cloud?
- Are discovery schedules current, and are errors being reviewed rather than accumulating?
- For cloud hosted services, is cloud discovery configured for the relevant accounts and subscriptions?
4. Credentials and access
- Is there a credential strategy for the operating systems, applications and platforms involved?
- Has the security team approved the access Service Mapping requires, with a documented and auditable approach?
- Are credential owners identified for the systems where access will need to be requested?
- Is there a process for handling credential failures quickly during mapping?
5. Patterns and technology fit
- Have you identified which technologies in the candidate services are covered by standard patterns?
- For anything unusual, is there appetite and skill to build custom patterns? As one example, NowBench built custom patterns for Oracle Pluggable Databases during the M&G engagement.
- Do you know where tag based mapping might be more practical than pattern based mapping, particularly in cloud environments?
6. People and process
- Who will maintain the maps after the initial build, and do they have time allocated?
- Which processes will consume the maps: incident, change, event management, or all three?
- Is there an agreed definition of done for each map, confirmed by the service owner?
- Is there a plan to connect the maps to Event Management so the service context is actually used?
If most answers are yes, you are ready to start with a good chance of maps people trust. If several are no, address those gaps first. Readiness work is far cheaper than remapping.