Integrations CMDB/ ITOM

[s03jlord1]

Hi,

As a new SAAS company, born out of a split from parent, subsequent acquisition and data centre moves (a lot of moving parts!) we have a requirement to 'discover' / 'log' a whole host of integrations between all the systems we have. Some are custom, some are legacy but span multiple applications and locations. Typically its Application A sending files to B which transform data and send to Application C and vice versa. There are other types of integrations also fairly similar in architecture.

The main driver is said DC move we did, during this time, legacy integrations were either unknown or we didnt know if any had stopped working (server up but not functioning or sending files etc)

What would be the best method/roadmap to do this?
Would it be, for example, mass upload of said integrations as CIs so they are in the CMDB and then let discovery run or manually service map them myself at a later date? is it the above as a baseline, then fine tune event management to warn of something malfunctioning or does Service mapping find these via traffic based discovery?

I know the end goal but finding it hard to locate the start of the journey.
Thanks for any interaction!

[s4scott · Accepted solution]

There are a few different ways to represent application to application dependencies. One is to simply relate the two applications to one another using a relationship type like Sends data to::Receives data from. The problem with that is you cannot use a relationship as a CI in an event or a change, and relationships don't have owners or support information. 
If you need to manage the relationship then one option is to create a class structure for different types of integrations. I'm not sure if ServiceNow has formalized a strategy for this yet, but starting a couple of years ago, we created a set of integration classes to be used for API, ETL, Batch, and other types of integrations.  When the integration is impactful to the providing or consuming application (or if it causes an outage) then the application teams are required to document it as a CI, just as they would infrastructure or other application CIs.
 

[Riya Verma]

Hi @s03jlord1 ,

Hope you are doing great.

Recommended method to address your requirements:

1.  Begin by performing a mass upload of the integrations as Configuration Items (CIs) into the CMDB.

2. Utilize ServiceNow's discovery capabilities to automatically identify and map the relationships between your integrations and the underlying systems. Service Mapping, in particular, can help in visualizing the dependencies and interactions among different applications.

3. Manual Service Mapping: Although discovery can automate the identification process to a great extent, some integrations may require manual service mapping to accurately capture the complex architecture and interactions. This step involves manually defining the relationships between applications, data flows, and transformation points within the ServiceNow platform.

4. Once your integrations are recorded and mapped, configure ServiceNow's Event Management module to monitor the functionality of your integrations. Fine-tune the event management settings to receive alerts or notifications in case of any malfunctioning or disruptions in the data flow.

[s4scott]

It might be a bit of a stretch to expect Service Mapping's ability to incorporate your integrations into the service map automatically. It will show direct communication between applications, but only if it is occurring during the discovery event and that communication is direct application to application. For most integrations there will be some platform in the middle, like Apigee or Biztalk, or your application could be using microservices to facilitate data transfer. In any case Service Mapping may help, but more reliable information can be gathered through pulling it from the platform managing the integration (Apigee or Biztalk for example) or through a managed process where the application team manually define the integration CI details and relationships.