2 Questions on CSDM view for Service Mapping

Lucky1
Tera Guru

Hello all,

 

Good day!!

I am working with Service Mapping currently and I have 2 questions to get clarified.

Lucky1_0-1757514907464.png

 

So, while configuring the business application, we are considering the "Architecture type" field on it, 

If the Architecture type selected is Platform Application, then "Platform Host" field is visible and mandatory. (oob feature). So, if we select a platform Host, then under that Platform Host, the Business Application with Architecture type "Platform Application" will be shown up. (like in the pic I have shown)

Question:1)

So, is it really needed for every business application there should be platform Host to be shown on the top of it?

If there are two business applications or more than that, then showing all of them under a platform Host is fine. But If we have only one business application then is it really required to map it with platform host and showcase that also? 

 

Question:2)

The infrastructure (like Servers, Databases, VMs),

So, should these be mapped with Native application (cmdb_ci_appl) or can be directly mapped to Application Services itself?????

 

 

Our current CSDM design is:

Business Application (Platform Host - hosted on server) ------ > Business Application (Platform Application) ------> Application Service (Mapped Application Service) ------> Application -------> Infrastructure (Linux, VMs etc).

The Technical and Business Service Offerings are connected with Application Services.

 

 

Please make me understand on these two questions.

 

 

 

Regards,

Lucky

 

6 REPLIES 6

Geri1
Tera Contributor

Hi Lucky -

 

Regarding the architecture, not every application needs a platform host. ServiceNow is a platform host and if you choose, you could model platform applications for ServiceNow, such as ITSM, HR Management, or ITOM. Salesforce is similarly a platform host and you could model platform applications for Salesforce such as Talkdesk or nCino.  Docusign is not a platform host or a platform application. It is SaaS/PaaS that runs on a cloud infrastructure.

 

I hope that answers your question.

Mathew Hillyard
Mega Sage

Hi @Lucky1 

Question 1 has been answered by @Geri1.

Question 2 : how many services are accessed directly through hardware? Very few, if any. We consume just about everything through software. A service map should where possible reflect the practical reality of how a user accesses the service, typically via a web front end app running on a server. As an App Service (now Service Instance) expresses everything beneath it and is a logical rather than physical CI, this is why we create a dummy application CI for SaaS products, even when we have no access to the app code or the host it runs on.

 

I hope this helps!
Mat

Hello Mathew,

 

Thank you for your response.

So, let me know if my understanding is correct from your response.

We need to have Application (cmdb_ci_appl) into CSDM mapping, where in reality the softwares and other Database instances and Schemas and not less the Infra servers, would be getting connected to Applications. 

Am I right?

 

And Just adding Question-3 here:

Question:3)

While raising an Incident or a change request, is it a good practice that we select Application Service (cmdb_ci_service) in the Configuration Item field?

I guess No, because we already have a unique field for it. "Service" and "Service Offering".

 

Please guide me here as well.

 

 

Thanks in advance.

 

 

 

Regards,

Lucky

Hi @Lucky1,

Yes (I think). The entry point for an app service almost always point to an app CI, and then typically som form of web- or app-server host and then other relationships (database, storage, networking etc.)

 

For Incident and Change, the forms contain Service, Service offering and Configuration item fields OOTB. However, there is no official guidance on what to do in the CSDM white paper. The leading practice is

  1. Make the Service field read-only.
  2. Make the Service offering and Configuration item fields read-only
  3. if the Service Offering is empty and you enter a CI, use CSDM relationships to automatically populate the Service offering and (Business/Technology Management) Service (as long as the CI is connected to only one Service).
  4. If the CI field is empty and you enter a Service offering, auto populate the Service and filter the CI field to only those CIs connected to that Service offering via CSDM relationships.

This gives users the flexibility to enter either a CI or an App Service/Service Instance in the CI field and CSDM relationships do the rest. This also supports population of impacted service, service offering and business application related lists. For Change, the CI you enter is the entry point for the change and drives the initial population of impacted (business, technology management and application) Services. 

 

This article contains more info: https://www.servicenow.com/community/itsm-articles/how-to-configure-incident-management-to-align-wit...

 

You will find there is no client-side logic to manage this configuration, or to manage CSDM relationships in general. You may find this Script Include I built to manage CSDM relationships: https://www.servicenow.com/community/developer-blog/csdm-script-include-to-traverse-ci-relationships...


I hope this helps!

Mat