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?

[CMDB Whisperer]

Software Product Model simply represents the versioned product, e.g. "MySQL 5.3" and would be used for all installations of that software product version.  

Applications (cmdb_ci_appl), including Database Instances, represent a specific installation of a software product that is running as a process on a specific server.

In @Barry Kant's post above when he said "the DB itself" is an extension of cmdb_ci_appl, this should have read "the Database Instance is an extension of cmdb_ci_appl".  Note that there is a separate class called Database (cmdb_ci_db) which is not an extension of cmdb_ci_appl, so when you asked "why would both the DB and the DB instance be recorded in the same cmdb_ci_app table" (correction: cmdb_ci_appl) the question is erroneous, as only the database instance is recorded in the cmdb_ci_appl table.  More accurately it will be recorded in the extended table which represents the database instance class for that database management platform.

And yes, all CI classes support the use of the model_id attribute, so conceivably the Application/Database Instance for a specific running instance of MySQL 5.3 could refer to the Software Model called "MySQL 5.3".  But out of box I don't believe it will do that automatically, even if a Software Installation for MySQL 5.3 was discovered on that Server.  Why?  Well first of all, unless you have SAM Professional, your Software Model likely doesn't exist.  The Software Installation record exists if you have Discovery or another Service Graph Connector, but that Software Installation record doesn't turn into a Software Model without further coaxing.  And second, even if you do have SAM Professional, and your Software Installation record gets mapped to a Software Model, last time I checked this Software Model did not get connected back to the Application CI in the model_id attribute, so some further coaxing may be required there as well.

[tsondreal]

What is the difference between Software Package (cmdb_ci_spkg) and Software Product Model (cmdb_software_product_model)?

[CMDB Whisperer]

@tsondreal Software Package is a legacy CI table that is currently only used if you are not running Software Asset Management, in which case Software Product and Software Product Model are used instead, and Software Package is deprecated.  Because it is a CI, the Software Package CI class doesn't do a good job of representing the software product.  Software Product Models are the correct choice for this, because they represent a piece of software that is developed, versioned, and manufactured/published (a product model), not the thing that is purchased (software asset) or installed (software installation/application CI).

[tsondreal]

@CMDB Whisperer Am I comparing the wrong things? Meaning I see a relationship between Business Application and Application Product Model, and Application Service and Software Product Model.  Should the question be what is the difference between Software Package and Software Asset or Software Product?

[CMDB Whisperer]

@tsondreal Not sure, but the bottom line is that Assets and CIs both reference a Model of some kind.  Software Packages are not models but given how they are created when discovering installed software (e.g. from SCCM or other Service Graph Connectors) they seem to try and represent Models, or something close to a model, like a Product (given that a model is a specific configuration of a Product -- something that currently only exists on Software, and only with SAM installed.)  Instead, Software Package is a CI, and as it is the current use case for it is inherently ambiguous.  One use case that comes up sometimes is that users who are having issues with software might want to track an Incident against that software, which you can't do if it is a Model or an Asset.  The argument against this is that a user should instead be logging an incident against the Computer that the software is installed on, which provides greater data to the support groups who are resolving the instance.  Perhaps there is something to be said for a middle ground where the Computer is the main CI, and the Software Package is affected CI, but it's a philosophical discussion people can and do differ on.  In any case, if you install SAM (including SAM Foundation, which is free by the way) then the Software Package class will no longer be populated by SCCM and other similar tools, thus leaving you to populate the CIs manually.  In my opinion this means that for all practical purposes the Software Package class seems to be on a path to deprecation.