Hello again dear CSDM experts,
I have a hopefully last question so I can crawl off:
CSDM would like to establish a relation between Application and Infrastructure CI
We are not using Discovery, so our Application table is empty. We maintain the Business Applications and Application Services manually.
The problem with this is that there is a "Runs on" relation established between the Application table and the Infrastrucure CIs, which we also need.
SAP Finance (FI) >>> Consumes >>> SAP Finance-Prod
SAP Finance-Prod >>> Depends on >>> Application XYZ (Discovery)
Application XYZ (Discovery) >>> Runs On >>> Server mgmtsys123
I could create a Business Application runs on Infrastrucure CI connection.
This suggestion makes my stomach hurt or do i really have to create "Dummy Applications" within the Application table?
How would you solve it?
Kind regards
Martin
My company does not have discovery either. My understanding is that servers and databases should be associated with the Application Service level in that case. For instance if you have a Dev, Prod and QA instance of an Application Service these could all have different servers. All these separate instances are related to the Business Application. Not eveyone has the same set up, but here is an example of how we've set up ours.
My company does not have discovery either. My understanding is that servers and databases should be associated with the Application Service level in that case. For instance if you have a Dev, Prod and QA instance of an Application Service these could all have different servers. All these separate instances are related to the Business Application. Not eveyone has the same set up, but here is an example of how we've set up ours.
The intent of that Application (cmdb_ci_appl) table is to represent the code running on a server. The main reason for this is to support the proper level of detail that CAN be discovered, or populated from a data sources like SCCM.
From a dependency perspective, is the hardware goes away or has an issue, the Application on that hardware is impacted. The CMDB CI dependency rules supports this, and the CMDB Data manager will process those dependancies now as a "ripple effect", taking lifecycle actions such as retirement or deletion on that data.
Even if you are not using Discovery, I would support this structure as other products you may be using or may us in the future will expect it.
The App Service to Application relationship can be populated manually or through Service Mapping to, which will be more precise and automated if that were an option. So on one Server, you may have 2 Applications which are providing 2 different Application Services. Or one. This is all predicated on the architecture of the "system" that the Application Service(s) and hardware represent.
How you are populating this detail today? This must be daunting task. Are you creating your own population and automation process using our API's and Command line interfaces? Or do you have a team of folks doing this manually? In my experience, manual efforts are prone to mistake and delay. Those cost of those mistakes and delays typically offset the cost for Discovery given the operational processes that depend on that data...
