Data Import/Exports in CMDB

[Dan Brown2]

Hi,  We have a great start on getting data into our CMDB, and the Business Applications, Application Services and other CIs like Servers are taking shape.

I have been asked how we can store details of imports and Exports of data.  There is a Receives data from / Sends data to - relationship that we can use, but I have been asked where we could store information about the data import/export - like the schedule, data included etc, so it makes it useful on the on the dependency view etc

How have people done this?

Cheers,

Dan

[SebastianKunzke]

Hi Dan,

That is a great question. I am not aware of such detailed information attached to a relationship.

My first idea would be to create information objects, where you can store the information, which business application creates, reads, update or deletes, what kind of data set. 
But the technical deep about the implementation wouldn't be stored there either. For me this sound more like a technical documentation. This could be managed over a knowledge base article, which you then link to this information object. 

At the end I wouldn't suggest to make it too complicated, if you just start your journey with ServiceNow. Maybe you start displaying the relationship and if the team realize, that they often need this additional information for solving tasks you add the next complexity level. But this depends on your maturity level.

I hope this helps.

Kind regards 

Sebastian

[mikkojuola · Accepted solution]

Hello Dan,

If these "data exchanges" are important enough to be managed in ServiceNow, I would recommend using a specific CI Class to document and keep track of these.

I've been involved in cases where these have been defined as "Integrations" or "Integration use cases". The "Integration" CI class would include details about the data exchange and technicalities related to implementation. This way you could formally describe things like sequence, direction, payload, integration method, etc. And of course, use CI relationships to connect these Integration CIs to Application Service or Business Application records related to them.

This requires more data maintenance work, than a simple link between applications, but from impact analysis and integration management point-of-view, it's probably worth it. Pro Tip! You don't have to define all "integrations" like this, but only the once that matter the most.

Here's an example diagram about the "Integration" class and how it could relate to other classes.

Cheers,

--Mikko

[Tobias]

Hi, 

We have gone with a solution like shown by Mikkojuola. 

As mentioned I would be cautious if you are early in the journey, as it is a lot of extra maintenance, and the people responsible for doing the integrations then need to play a larger part in maintaining. 

If you already have good documentation practices it is of course a smaller step to implement - else I would make sure to focus on questions such as: what processes will ensure creation, maintenance and retirement.

And will it add value for Incident and Change Management? What is the specific need for having this in CMDB?

[Dan Brown2]

Sebastian, Mikko, Tobias,

Many thanks for the responses - they are really helpful.  

I like the Integration CI Class - then we can add the fields we need.

I think we are ready - but definitely for the most important to start with.

Thanks again all,

Dan