How to use Application Product Models?

Tobias
Tera Contributor

Hi, 

The idea is to use Application Product Model table to store list of all applications (version agnostic). Having the specific versions as "children" in Software Product Model table. 

Until now we have used Business Application table for non-desktop-installed applications - as a list of what (Business) Applications we have. Meaning not only Business User facing applications, but also including things like 'Orion', 'MS Intune', 'SAP Solution Manager'.

These non-business-user facing applications would be removed from Business Application table and instead reside in Application Product Model table - the Application Service instances would reference the Software Product Models. 

 

This would cleanup Business Application table - being true to the definition of Business Application'

Application Product Model table would then comprise of non-business applications (e.g. Orion) as well as "classic" Business Applications (e.g. Salesforce). Thus Saleforce would exist in both tables. 

 

What are your thoughts on this? How have you approached Application Product Models? 

 

/Tobias 

 

 

 

 

 

 

 

 

 

 

 

 

1 ACCEPTED SOLUTION

EricDohr
ServiceNow Employee
ServiceNow Employee

I would recommend against this.  

If you adopt APM, you will want Business Application records to be used to rationalize your environment and be able to depict a relationship with one or many Business Capabilities.  There are many assessments in APM that roll up to a Business Application record and not the product model at this time.  

From a user experience, it could be confusing when you go to a Business Application versus a Product Model.  Different fields and usage.

Do not treat IT Business Applications different than Business facing Business Applications in the APM world.  For instance, if you only use ServiceNow for IT, you would still want the following

  • Corresponding Business Application(s) such as ServiceNow Platform (Platform Host) and other records that would be Platform Applications (depending on your maturity)
  • Application Services for your environments
  • Underlying Configuration Items for MID Servers
  • Technical Services and Service Offerings that are applicable
  • Business Services and Service Offerings that are applicable
  • With APM, you would want Software Models connected to the Application Services via a related list for Technology Portfolio Management

You also do not associate one or many Application Services to a Product Model at this time through a CI Relationship, but a Business Application.  

 

Application Product models have multiple use cases including Agile and is incredibly important as part of a Digital Product. 

 

As you can see with CSDM 4.0, there is a lot of planning and foundation being set for the concepts of Digital Products.  

View solution in original post

9 REPLIES 9

SteveMac1
Mega Guru

Tobias,

I would highly advise against this idea. The company I work for does a lot of projects in bringing customers back to out of the box setups, and these are the types of issues that can cause the most problems. Using a field / table for something that it is not intended for can be worse than creating your own custom fields or tables, because there may be functionality built on top of these re-purposed objects that will break or cause unexpected issues. In addition, ServiceNow may add more functionality around the the re-purposed objects that goes unnoticed during an upgrade. 

To this specific idea, I'd say that the problem with managing these 'non-Business' Business Applications is that there is functionality built around the Business Application table that will be unavailable to those CIs that you move to the Product Model tables. If you use (now or in the future) IRM/GRC, APM, PPM, those are built using the Business Application table as well, and you'll lose connections to the 'non-Business' Business Applications. 

In regards to 'being true to the definition of Business Application': while some frameworks may have definitions that explicitly exclude non-Business applications, the CSDM does not.

From the CSDM White Paper: 

A business application represents all software and infrastructure (For example catalog of titles) configured to provide business functionality.

From the APM documentation for Business Applications:

Use the ServiceNow® Application Portfolio Management (APM) application to gain a comprehensive understanding of the applications used in your organization so you can identify redundancies, and decrease budgetary costs.

Steve

Tobias
Tera Contributor

Hi @SteveMac 

Thanks for your input! 

I understand your point regarding using the tables for what they were meant for - which I guess is very much tied to how Business Application is defined. 

My concern is also if this is a good way to use Application Product Model table. As mentioned in reply below my thinking is that in most cases Business Applications would also "have" an Application Product model. But I can see that the Application Product Model table would also contain "software" applications, so it would become a mix of both. 

 

Stefan K_
Tera Expert

"The idea is to use Application Product Model table to store list of all applications (version agnostic)."?

What is the source of this statement? In my understanding, this is a definition of a business application. 

Tobias
Tera Contributor

Hi Stefan, 

 

I don't believe it's directly stated like that anywhere. There is a mention of the application product model being version agnostic in the CSDM 4.0 draft. This is also discussed in this video: https://www.youtube.com/watch?v=TfRv1VTRsgM

My thinking was that in most cases Business Applications would also "have" an Application Product model. An Application Service would thus reference a Business Application (when applicable) and the specific Software Product Model.