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

ahbrook · 3 weeks ago

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.

Kieran Anson · Saturday

Hi,

Thank you for providing such thorough context. First, some comfort: the headache you are facing is incredibly common. Trying to implement CSDM without automated Service Mapping feels like staring at a sheer mountain cliff.

Your conceptual breakdown of the Services and Offerings is actually spot on. The hurdle you're hitting is shifting from "who owns what" to "how do we represent this in the CMDB."

To put it simply, you all look at the same "asset," but you own different layers. Infra provides the chassis, OS runs the engine, App drives the passengers, and the Business handles the roadside assistance. Here is how to translate that into ServiceNow without drowning in manual maintenance.

1. Addressing the "One Dynamic CI Query" Worry

The documentation warns against overlapping Dynamic CI Groups because a Dynamic CI Group can be an Application Service in CSDM. Additionally, the inheritance of support group, managed by group, and change group from a TSO can't be determined if a CI relates to more than one Dynamic CI group. However, you can target the same server with multiple CMDB Groups used for patch management or infrastructure scoping.

2. Server vs. Software: Use what SCCM gives you

Since you have the SCCM Service Graph Connector, you aren't just getting bare metal; you are likely getting populated Software Instances (cmdb_software_instance) or running processes linked to those servers.

You can use a Dynamic CI Group aimed at the infrastructure class (e.g., Windows Servers) to represent the horizontal support provided by your Central Compute team. This keeps infrastructure support automated.

This pattern allows us to capture the horizontal support your teams provide because we have the relationships between compute devices and what is running on them. What we are missing is the service-aware vertical context that ITOM would automate. We know what is supported, and who supports it, but not the why.

3. Connecting Service Instance

This is where you're likely going to have manual effort. To prevent breaking the "one Dynamic CI Group per CI" rule, your Application Service (the Service Instance) should be created as a Manual Service (cmdb_ci_service_discovered).

Your app teams or service owners will then need to manually connect this Application Service to the specific Software Instances populated by SCCM. Because the Software Instances are already linked to the underlying servers by the SCCM connector, your manual map stops at the software layer, and the infrastructure dependency maps itself.

This puts the manual effort exactly where it belongs for a lean stack,just bridging the top-level app service to the discovered software instances, while keeping the infrastructure support entirely dynamic.

View solution in original post

ahbrook · yesterday

Alright. Maybe I can figure a way to manipulate both options, and just be on the safe side with Dynamic CIs only applying to the application, not to the OS or hardware.

ahbrook · yesterday

For anyone who is following along, this appears to be a bust too.

Because the Software Instance table is not a CI Class, I cannot use it as a root item in a CMDB Query Builder setup. So that leaves the Software CI (Software Package). however, there is no direct relationship between the Software Package and a given computer. If I make a query for the software package, the best I can get is "Installed on" count, which is derived from software instance as far as I can tell.

I've been using Adobe Creative Cloud as my test subject. I know there are a few thousand installs of that out there. In theory, each of those would be part of the Application Instance. But without each of those instances being represented uniquely in the CI table, it just isn't coming through.

I guess the obvious answer is "Get ITOM/SAM and Discovery" ... I may just have to propose that.