Tracking Integrations as Information Objects?

[jonGriff]

I’ve been researching the best approach for storing "Integrations" within the CMDB. For example, an integration might be called "FidelityRetirementImport" which includes the relationship between two Business Applications, and various attributes specific to that integration such as the Type (file, sftp, api,...), Frequency (hourly, daily, weekly, biweekly, monthly...), Payload (small, medium, large), service account, and many other specifics to the type of integration/API.

My first instinct was to create a new, base CMDB class called “Integration” and relate that CI to the related Business Applications using “Exports to” and “Imports from” relationship types. Upon further discussion online, it appears this approach wouldn't be in alignment with the CSDM.

A better approach might be to leverage the out of the box “Information Object” CMDB class. For example, an Information Object record could be “Retirement Allocations”, which would map between our ERP and Fidelity.

Does this sound like the best approach, using Information Objects over a custom class?
Also, I’m a little hesitant to add 10+ custom fields on the base Information Object class; would it be best to extend this class or just add them and utilize UI Policies based on the Classification.

Any input is appreciated! Thanks!!

[Bruno De Graeve]

hello @jonGriff ,

As a Community Idea, I shared my own opinion how Integrations should be managed on our platform. The same information was shared on LinkedIn.

It looks your approach or 1st instinct using a CI Class in between two Business Applications, has the same approach as I implemented in my "Application Integration Governance - AIG" app. (the Community Idea has a link to a deck that shows my setup).

Can I ask why it wouldn't align with the CSDM. that wasn't my experience when I approached our CSDM BU leads.

kind regards, Bruno

[Maik Skoddow]

Hi @jonGriff 

in the following CSDM 4.0 introduction video you will see that your approach using the SDLC component would align: https://youtu.be/6MrekggoQ4A?t=775

And regarding your second question: I recommend using a custom class if you want to add many custom fields.

Kind regards
Maik

[Bruno De Graeve]

FYI: I also extended the SDLC Component class to be able to define specific API attributes. In my example, you'l notice the red boxes, which are extended SDLC Components, representing ServiceNow APIs 9C). The dark blue boxes, represent the Business Applications. The light blue box, the Interface (A) that collects all information why the 2 Applications are integrated with each other, as well link some of the ServiceNow APIs to it. In the ServiceNow world, we usually use more than one API when we integrate (f.i. the Table API, to read the data, the Import Set API or Process API to insert data, the Attachment API to relate attachments and the Aggregate API, to get some counts.)

[Stig Brandt]

Interesting topic, I see an Integration(API) as you describe it, as a "Technical Service / Technical Service Offering / Application Service" and "Business Application" as for example the Midserver example from ServiceNow., then Business Application is then "consume - application service/API"  and Business Services related to all "Terchnical Service/API" that are using this API, as a dependency.

In that case you will be able to identify if the API is down, what in a end2end process is impacted impacted.

Best regards

Stig