Thoughts on monitoring ServiceNow integrations (part 3): The building blocks

[Richard Smith]

Following on from the first two posts in this short set, we have now an understanding of what we need to record and measure.

Now we move on to the how. How should record that an integration is not working in a reliable way, given the plethora of different types of integrations and types of issues. For instance:-

• Authentication failures, inbound or outbound
• Complete absence of an invocation (i.e. remote side does not attempt to hit our API)
• Less data (or no data) received during an integration
• More data that expected from an integration
• Hard errors caught during processing (i.e. processing cannot continue)
• Business logic errors caught or counted during processing (subset of records unexpected/cannot be processed)

The key thing for me here, is to ensure that the way that we react to detecting such an issue is consistent regardless of the systems involved or of the cause. In short, and if you are able to, you should use ITOM Event Management here.

Why is this important?

• In the future, we want all detectable events in the IT infrastructure to hit Event Management, so we can quickly suppress noise, create actionable alerts and avoid service outage, and improve our time to detect
• This will include all integrations, not just those which are directly connected with ServiceNow. I.e. Teams performing incident management for failures between Workday and Payroll providers.
• We do not want integrations between ServiceNow and other systems to be missing from this bigger picture.

So what do we do?

• Ensure that for each of the integrations we have built, or build in the future that interact with the platform, we ”catch” issues with them, and generate appropriate ITOM health “events”
• Ensure that actionable alerts/incidents are created and assigned to the ServiceNow BAU team to handle ‘as they happen’ (i.e. the operational response for key integrations do not rely on viewing a daily dashboard)
• Later, we look to apply the same logic to integrations between other systems too (not ServiceNow). The only difference, will be the team(s) which react

Now consider the other key building blocks:-

• Digital Integration Management. Ensure that we have records in the CMDB representing our integrations, and the APIs they provide/consume
• API Insights - an optional component to help bring into ServiceNow APIs from across the wider enterprise; this is helpful when we look at the broader enterprise wide picture
• Ensuring that the integrations between systems are represented in the CMDB as part of the appropriate Application Services

We now have actionable alerts going to our ServiceNow admin team when an integration fails, or breaches an agreed threshold. We are in a position to represent other integrations for integrations between non ServiceNow systems too. This might be far enough.

If we want to bring things together in a single pane of glass specifically for ServiceNow though; we need to extend things a little.

1. Intro
2. Governance & Preparation
3. Building blocks
4. Bringing it all together