How should I design a dynamic CI for a server CI that is part of an application service?

[ahbrook]

Hello everyone! 

This post is continuing off of a few I've made in the CSDM forum (such as this one), but I felt this was more directly tied to operation of the CMDB and therefore I'm posting it here.

We currently only have access to ServiceNow ITSM and the SCCM Service Graph Connector. We do not have ITOM, Discovery, Service Mapping, or any additional service graph connectors.  This is leading me to wanting to use CMDB groups / Dynamic CI groups to define Application Services to tie to Business Service Offerings and Technology Management Service Offerings. I want to avoid manually creating service instances as much as possible.

I wanted to know - should I have the CMDB queries / Dynamic CI setup aimed at the server as a whole for the application instance, or should I narrow it down to just software installed on the server? I'm worried about proper inheritance of support groups and change groups, but more than anything I want to make sure people know these servers are dedicated to a given application.

Traditionally at my organization, we have identified ownership and management of systems (applications) as the core of our groupings. For example, here's how one of our financial ERPs breaks down:

• Ownership and final decision making for the ERP is maintained with our Comptroller's department and functional users. 
• The comptroller's office has dedicated staff that help employees with issues inside the ERP and day to day usage. 
• The installation, patching, access, integrations, and database maintenance of the ERP are handled by our central IT "applications" team. The database would be with our "database administrators" team, but it is a one-off rare platform that doesn't fit under their duties. 
• Our application administrators request virtual servers from our central compute / infrastructure team. This team maintains our ESX environment, as well as the windows/linux guest servers themselves. They are responsible for patching the guests and establishing the "Standard operating environment" that all of our servers use, regardless of where they are hosted. They also establish connecting it to directory services, and maintain cloud backups of the guest.
• the central compute team maintains the local "root" permissions on the guest server, as well as having domain-based administrator access. Our application administrators are also given administrator access.

Whenever the servers involved in the ERP are discussed, they are considered "owned" by the application administrator team, not the central compute team or the functional users. But I don't know if that simplified view is the right way to go.

From what I've pieced together in studying the CMDB and CSDM rules, I think things break down like this:

• Business Service: Financial Services
  • Offering: (ERP name)
• Technology Management Service: Application Management Services
  • Offering: Enterprise Application Management
• Technology Management Service: Hosting and Compute Services
  • Offering: Windows Server Management
  • Offering: Linux Server Management
  • Offering: Virtualization Management
• Application Service Instance: (ERP Name) Production

The Application Service Instance would contain the installed applications, as well as the servers they were running on.

The two server management offerings would cover the multiple OS's that make up the ERP. 

The virtualization management offering would cover the guest object and its components/infrastructure that the OS and app run on.

And then all those would be tied together, in theory, and reflect ownership/responsibilities properly. 

All this gets even more complex when I throw in that we have additional Test and Development environments, only the development environment runs on a different virtualization platform from Production and Test. And all 3 environments connect to different Active directory instances. 

In my experimentation so far, I've been able to make a CMDB group query that uses the server name to specify that it is part of the application instance. However, I think that conflicts with doing a similar query for "All computer CIs running Windows Server." The documentation I've read says not to have more than 1 dynamic CI query for a given CI... but if I associate with the individually installed process/application (assuming I have that data in the CMDB), I am worried that the relationships won't show up.

I know all of this would be "simpler" (or at least automated) if I had more ServiceNow tools to work with. But I need to show a working theory of how all this connects together in order to make the case for those products. My biggest worry is that I will just have to go through and manually create these relationships based on various associations, and as a result will need to invest a large amount of man-hours into such a process.