Application Service vs. Application

[marie_jp]

Broad question: What is the impact I should be considering when setting up the CMDB according to the CSDM framework and ignoring (post-poning to build on later) the cmdb_ci_appl_xx table and relationships and use the cmdb_ci_service_discovered/calculated/query_based instead? 

i.e., we would have an application service [cmdb_ci_service_calculated] "ServiceNow platform PROD" but not create an "ServiceNow platform PROD" record in the application table [cmdb_ci_appl_now_app].

Even the CSDM Data Model Examples slides provided by ServiceNow skips the Application layer.

Is it more at the DevOps level where the segregation is important?

Integrations/Interfacing

Objective: to understand the data flow between systems so if one is affected, the other that receives the data will be impacted/malfunctions given that we do not have the *interfaces* relationship type at the Business Application layer because we do not have APM.

Specific Question: If I were to forcefully create an Application Service sends data to Application Service (Workday sends data to ServiceNow--not application-->app service, but app service-->app service) or an Application Service sends data to Business Service Offering, are there long-term impacts I should be aware of?

I realize is that the framework is set up so data interfaces are modeled as: Application Sends data to Business/Technical/Application Service & Offerings.

I need a case to explain why we should register apps both at the App Service AND Application level. The application service is, of course, a logical representation and encompasses just more than the running program itself (application), however, it (application service) is used as a CI for incident, problem, and change so I see no immediate downside to treating application service records as an application. 

Product Model

Even bundling to track versions and product family appears to me, could be done at the Application Service layer and not necessarily at the Application but am I missing something important?

[tsondreal]

Would Software Instance (cmdb_software_instance) be deprecated for Application (cmdb_ci_appl) in the same path as Software Package and Software Product Model?

[CMDB Whisperer]

Software Product Model is not on that path.  Software Product Model represents the specific software product version that is used by Software Asset Management.  Both the use of Software Instance and Software Package are (practically speaking, but not officially, at least from an asset perspective) "deprecated" if you install Software Asset Management (either Foundation which is free or Professional which is paid).  Software Instances is replaced by Software Installations.

[tsondreal]

Doesn't Application (cmdb_ci_appl) represent a specific installation of a software product, aka instance?  What differentiates Application and Software Installation (cmdb_sam_sw_install)? 

[CMDB Whisperer]

Great question!  Yes and no.  An application represents more than just a software installation/instance.  It represents an installation that first runs as a process (or in Windows, runs as a "service"), and is accessed by other users or systems outside of that server it is running on, typically as part of an overall deployed instance of a business application.  Not every software installation runs as a process.  Some software is just installed and launched as needed.  And not every running process is accessed as an application.  Some running processes are just to handle internal jobs, tasks, functions on the hosting server, and are not directly accessed by users/systems outside of that server.  You can have hundreds of software installations on a server, and maybe only a hundred of them are running processes.  And maybe only a small handful (or none at all) are managed as Application CIs.

For example, say I have a Windows Server.  It has hundreds of software installations.  Some of them are part or extensions of the OS itself.  Some of them are monitoring utilities for IT operations.  Some are drivers, agents, data collectors, and a variety of other software installations needed to support the operation of the server.  And let's say this server also represents the database tier component of some Business Application, say a customer order management system.  Let's say we have MS SQL Server installed.  It includes a component to run the database configuration itself, but also has other components liks SSRS for reporting, all of which run as processes, along with some of the OS components.  But since this server has a dedicated purpose as the DB tier of the Business Application, the only thing we're really interested in managing as an Application is the Database Instance itself (an extended class of Application).  So maybe only a single Application CI is needed, even though there may be dozens of running processes and hundreds of software installations.  And then that Application (i.e. the Database Instance) is a single component of an Application Service (think "system") which is the deployed Production instance of the order management Business Application, and that deployed instance also consists of other Application CIs to represent the Web Application, and an API Service Layer to allow that system to talk to other systems in the enterprise.  So you have a single deployed instance of the customer order management Business Application, with three Application CIs for the entire instance (i.e. Application Service), which is comprised of several servers, with hundreds of running processes and thousands of software installations in total.  Make sense?

[marie_jp]

Hello @Barry Kant , thank you for your prompt response 🙂

I understand what you have explained. It makes a lot of sense to me, as the CSDM is broken down into domains for a purpose, so dividing the real vs. logical is I guess the answer to my question. It just seemed do-able to bypass the direct relationship building using the Application table and instead do it at the App Service level but I guess I needed someone to tell me it's not a good idea. Thank you for taking the time to read my post/advise. 

Have a good day,

Marie