Foundation data and TMF API Spec alignment for Place-Location-Site-Address

[Bharat H]

Hello,

Can you please help with details on below; As location data used in different process, INC, CHG, CSM, FSM, etc. aspects customer site(where service/product delivered) Vs Data center/exchange(where network device reside). or medical device at one site/hospital and field engineer need to visit.

1.how servicenow using and planning to get foundation data with TMF API 673/4/5 Spec alignment for Place-Location-Site-Address?

2.What is the each element/object from below snip. and how we should segregate and flag entities in SN? and to store them(customer place Vs exchange/data center place) and used in servicenow platform? 

3.And what target CI/TNI(site/network site) class ?

4.

#CSDM

#etnerpriseAssetManagement

#FSM

#CSM

#HAM

#ITSM

#Teleco

[SteveMacWWT]

@Bharat H I'm not familiar with the TMF Spec, but this can be accomplished using the 'Parent' field on the Location table. You can also expose the Location Type field to refine your locations. 

Steve

[Bharat H]

Thanks @SteveMacWWT , for response. 

We could think of utilizing the cmn_location table and could implement with parent-child location record structure. However,  not sure about to determine what the parent location would be and at what level of granularity we should create the nested structure child location (e.g., floor/room/space/tile).

Should the CI link or refer to the parent or the child in this tree hierarchy? (i think leaf element in structure).

And this approach would result in a complex nested structure and heavily rely on "cleansed nested" data that flows into ServiceNow. If there are multiple systems feeding the location table with different 'models', could raises concerns about the sustainability of the parent-child location structure.

Here is a link to TMF, a widely-used standard API in multiple organizations. (About TM Forum | TM Forum)

I'm curious to know about others or ServiceNow's plan regarding this, considering we know SN is "platform of platforms." might team is already working on addressing this challenge.

@Mark Bodman 

@scotlemm

[SteveMacWWT]

To the question of granularity, I'm going to give a very vague answer: Whatever level makes sense for your company. Don't gather / store information that will not be consumed. 

For me when it comes to hardware location, I would put it at the "'room" level, which in this case would represent the data-center. 

When it comes to where users are located, I go to the building / floor level. This way we have a general idea of who is affected by a (semi) broad network outage.

In that regard, we are not using any of the tools / toolsets that would benefit from going further than building / floor. If I were using Workplace Service Delivery, it could make sense to go down to the room level.

A couple of notes for the above:

• If there is a building that only has the data-center in it, I would still go to the room level. Buildings get re-purposed all the time so I prefer to be specific in that regard.
• We may go down to a 'pseudo-room' level that represents a sub-set of the data-center. Our company has Labs set up where we work with customers on hardware implementations, so tracking that separately could be beneficial. 

[SteveMacWWT]

@Bharat H I forgot to add: in Utah, the IRE & Integration Hub ETL can be used for managing Locations coming in from multiple sources. Check out the video linked in Mark Bodman's post What's new in Utah CMDB, CSDM and Service Graph Connectors.