Non-Application role servers relationship in CSDM model

[Saurabh851]

Servers configured perform different roles like database server,  print server, file transfer, application server, etc.

They have relationship established with the application instance.

but in case of utility, print server, telnet, there are usually no relationships.

Such information can be vital from Server team's perspective. Is there a way to capture such relationships in CSDM framework?

Thanks in advance.

[Daniel Carvalho]

hello

I have seen the usage of Dynamic Ci Groups, DynCI on short form (previously called "Technical Services", which was a more useful naming convention, in my opinion) in equivalency to Application services, for non-Application "Services", Such as "Printing - Production" ; "Guest Wifi AP - Production" ;  "DHCP - Production" etc.

Then linking cmdb_rel_ci from DynCI to servers and devices is pretty straight forward..

Cordial

Daniel

[Saurabh851]

Thank you for the response. Yeah, that's right on top of our minds, but how we decide the ownership because might quite bigger umbrella assign to individual. 

Would it be wise to segregate locations basis?

[Daniel Carvalho]

Hi

therer are several "ownership"-like fields OOB that you could leverage. I currently expose on form 4: Owned by (we use as senior management) , Managed by (someone that answers directly to the SR. management, coordinator/supervisor level normally), then Support group and Assignment group. One is newer to SN data model the other is older but not yet fully deprecated. We use both for backwards compatibility but always with same data (same group on both).

From your point, I see support/assignment group as best answer to the concern exposed.

And on which group to fill, we try to keep within well stablished concepts. E.g. Printing for us is something led by End User Services, even thou runs (memory&cpu-wise) mostly on server side. We place the "Printing - Production" CI (DynCI) for the EUS team group as responsible, and the related servers are under the Operating Systems (Win/Linux) groups. In the sense that in case of Incident within the ability to print, It is EUS responsability to "make rain" a solution, talking to whoever thay have to talk.

Cordial

Daniel

[Daniel Carvalho]

About segregating to locations, that is much of a "personal question".

E.g..: you are a regional bank with several agencies over multiple cities, and some 2 main offices.

You certainly have several pieces of equipments doing similar services, which are not redundant only because they service of different locations.

What use will be made? What is the current maturity state for ITIL Practices? Manpower to maintain CMDB in higher detail?

Example starting from a simpler footprint.

"Core Network Switching - Prod" & "Agencies Network Switching - Prod". Using only 2 CIs to aggregate devices by their affinity, assumig that the hardware profile is quite different between any main office campus and a branch agency.  You could live with this setup from 12 to 24 months on your CMDB until evolving. Assuming all agencies would have same maintenance and blackout schedules, both offices sharing same change rules etc. The negative is that only by looking at "service" CI you cannot tell if a change request affected a single office or which office. Same to agency. You will have to rely on Location field on Incident for details etc.

2nd Maturity step, your retire the "both offices" CI and raise specific CIs per office building.

Next step you may decide to go per agency address or at least per macro/micro region (Southwest Florida Agencies Swiching Network - PROD).

Cordial