How to model integrations/interfaces within CMDB?

[jamesmcwhinney]

Could anyone provide any guidance in to the best practice for modeling integrations/interfaces between applications within the CMDB?

For example:

• web service call from application A to application B
• Flat file export from application C via nightly job and uploaded to application D

Will this be 100% achieved via Service Mapping?

What about scheduled jobs which would not be active at the time the top down discovery takes place?

Is there any good means of modeling these interfaces manually? (Ideally in such a way as to align with CSDM)

Thanks in advance!

[Animesh Kar]

Based on my understanding of CSDM 3.0, an interface must be represented as an application service CI. Only then it can have a 'sends data to' relationship with the source and destination systems that are also represented as application service CIs.

Of course there is the option to represent underlying infrastructure that does the 'interfacing' eg. web api, windows process, file transfer etc. as records in cmdb_ci_appl or one of its child tables. 

If we store the interface in the cmdb_ci_appl then csdm only recommends use of depends on relationship type between application service and application ci, which is a bit of a limitation. 

[Stig Brandt2]

I don't see any reason for not using cmdb_ci_appl it could also be considered a "application_services" / subclassed as "Integration" if you have an entry point in your scenarios

The question is about what KPI's do you have on these interfaces, are they part of a business process, what is the business process monitoring services, what happens if the service / file is broken down, will the process continue or stop.

[Animesh Kar]

Based on my understanding of CSDM 3.0, an interface must be represented as an application service CI. Only then it can have a 'sends data to' relationship with the source and destination systems that are also represented as application service CIs.

Of course there is the option to represent underlying infrastructure that does the 'interfacing' eg. web api, windows process, file transfer etc. as records in cmdb_ci_appl or one of its child tables. 

If we store the interface in the cmdb_ci_appl then csdm only recommends use of depends on relationship type between application service and application ci, which is a bit of a limitation. 

[edannenb]

Good morning. I'm following up on this. Are there any new schools of thought or actions folks are taking with regards to classifying integration records in their CMDB's?

This has recently come up via pushback from service owners regarding classifying integrations as application services (the somewhat consensus back in 2019-2020).

[Barry Kant]

Good day all,

we used to simply link between AS1 and AS2 to show/identify that there is a dependency between between them. 
In the design area we have Digital Interface solution (part of APM) which is an new object. To achieve something similar in the manage (run) domain you can use the API classes.
This is often to be considered when there is more information needed about the integration then just a relation. This at least shows that solutions are related.

What does it give from an operational point of view?
The one integration is significant different than another integration. 

A real-time payment solution for a claims solution is different integration than a nightly data sync from AD to ServiceNow. In my view it would make sense to have 2 different relationship types to distinct between impact vs non impact. In impact analysis there are options to blacklist relations from an impact point of view.

BR,
Barry