Hello Ravish, all good?
Let me share the path I would take. Not having Discovery or an integration that correctly populates the application layer cmdb_ci_appl can impact your entire process, as loading and maintaining up-to-date L2 data is a big challenge. However, since you're doing this as a POC, let's assume you're correctly loading Servers and Applications that run on them.
Not having Service Mapping doesn't mean you can't manually create the Application Service. If, for example, the Splunk architecture is N-Tier, after properly loading this data, you should manually create an Application Service relating the different layers of the application from the application's perspective. Example: Frontend > App Server > Database Instance. It would be a prerequisite to first load L1-L2 (Server and related Applications with "Runs On").
If this environment existed in DEV, HML, PRE-PROD, and PROD, you should create 4 different Application Services, one for each. It's uncommon to share the same infrastructure across environments. If the 'simulation' uses the same set of servers supporting both DEV and HML, you would have the same servers but running two different sets of that application.
When you create an Application Service—either manually or with the help of Service Mapping—always prioritize doing it from the application perspective, as it links the machines that support each application. You’ll be able to view these relationships in svc_ci_assoc.
Now, regarding Infrastructure: this set of machines likely has OS, DB version, might be virtualized or not. Depending on how they're supported in the environment, I would create offerings and Dynamic CI Groups to monitor this. For Technical Services, the first step is to relate the operational technical services that support a group of CIs or an Application Service.
Here’s an example structure:
Technical Service > Technical Service Offering > CMDB Group + Dynamic CI Group
Server Operations > Windows Servers - Prod → Group of all production Windows servers (This will likely include some Splunk CIs if your architecture is Windows-based);
Server Operations > Unix-Like Servers - Prod → Group of all production Unix-like servers (Again, likely includes Splunk CIs if Unix-like);
Database Operations > Oracle Database - Prod → Group of all Oracle production instances (Could include Splunk components if you use Oracle DB);
Some follow other market standards for naming technical services and offerings, such as example Database Management > Database - Oracle.
And so on, based on technology groups.
Now, about the Splunk Application Service, it would be:
IT Application Operations > Splunk > Splunk - PROD (Manually created Application Service for PROD);
1.1 – If you choose not to create an Application Service and instead use a CMDB Group + Dynamic CI Group, you should use a query to retrieve the servers and applications that are part of Splunk. However, you won’t have a CI relationship view—just a grouping CI's. That’s why I said it makes more sense to use a manual Application Service.
Regarding the Log Search Offering delivered via Splunk, I have a different perspective here when comparing CSDM 4 and CSDM 5—this is where a great discussion begins. From a CSDM 4 standpoint, I would not place this offering on the technical side. See the definitions:
CSDM 4.0 – Technical Service definition:
Technical service is a service type that is published to service owners and typically underpins one or more business or application services. Using technical services lets you view and manage the technology you provide to the business. A technical service may have an operational view made up of one or more technical service offerings.
CSDM 5.0 – Technical Service definition:
A Technology Management Service, previously documented as a Technical Service, is a service type that is published to service consumers, and that provides the administrative and operational functions to manage the technologies that are typically layered under one or more Business and/or Application Services.
In summary, if I were using CSDM 4.0, the structure would be:
Business Service > Business Service Offering > Application Service
Log Systems > Log Request - Splunk > Splunk - PROD
Even though this is something "technical" and system-based, since it's a service delivered by the technical team through this system, I would map it on the Business side—not the technical. The technical part should strictly validate who supports/operate the infrastructure and application environment.
Now, moving to CSDM 5.0, I understand the perspective changes. It’s not just about supporting infra and applications anymore—the technical team is delivering services too. Then we’d follow this line:
Technology Management Service > Management Offering > Service Instance
Splunk > Log Request > Splunk - PROD
I would also take this opportunity to increase the POC's maturity by including the Splunk Business Application.
In my view, even though a Business Application is not an operational CI, it’s even more important than the Application Service because it guarantees a view of inventoried business apps used by the company. Then, when we move into the technical layer, we can see how that instance is deployed and supported.
That’s how I would approach it. I’d love to see input from others here, because this is a great topic—especially now with CSDM 5, it makes sense to start thinking ahead. The Product Manager is Mark Bodman—it would be great if he could take a look and give his input on this too.
