Find your people. Pick a challenge. Ship something real. The CreatorCon Hackathon is coming to the Community Pavilion for one epic night. Every skill level, every role welcome. Join us on May 5th and learn more here.

Question about SN scoped application mapping within CSDM 5

Tom Sienkiewicz
Giga Sage

Hi SMEs,

 

I am thinking how to best handle the below scenario:

- We've built a scoped app in SN to manage/configure integrations more easily.

- I would not consider this to be a Business App. It does not fulfill any major business capability, EA will not be interested in rationalizing this, it is basically a "utility". It does not have a business/it owner.

- We would like to be able to raise incidents for this utility directly.

- We would like to potentially be creating demands for this utility as well.

How would you recommend to represent this in CSDM 5? My thoughts so far:

1. Just add this as a Technical Offering, then make this available both on INC and Demand. TSO would be connected to platform-level App service and Business App.

2. Add this both as TSO and also create a Product for this (here the issue is, there will not be a Business App to connect this product to).

3. Tried to look into Software Component Models but I don't quite see how this could work. In the end it would still be another Product type.

 

Do you have similar use cases and how do you deal with those?

 

EDIT: forgot to add, hoping for real human replies, not AI.

 

5 REPLIES 5

CMDB Whisperer
Mega Sage

Any application is represented by several facets, it's not a question of whether it's one or the other class based on fuzzy conditions about how it's used.  It's about what concept, or facet of the application, you are trying to represent.

Business Application - The product that was bought or built to provide some capability (it doesn't matter how big that capability is or whether it is "business facing", just that it provides some capability) -- and in this case it would be a Platform Application that his hosted on another Business Application called "ServiceNow"

SDLC Component - The individually developed component (a ServiceNow hosted solution could be comprised of multiple scoped applications that work together, each with its own development pipeline)

Application Service - This is the specific deployment of that scoped application on a specific ServiceNow instance.  And it would have a relationship to that ServiceNow instance, which would be a different Application Service, as well as to the SDLC Components (if applicable).  There could be multiple application services for each scoped application that is part of the Business Application.

Service Offering - The Production Application Service for that scoped application would be tied to a Service Offering that represent the specific service outcomes that people would be calling in to enter an incident about.  What is the "thing" that users are needing to "get" from using your application.  That service offering represents that "thing" and how it's "gotten."  If that thing is technical in nature then it's a Tech Offering, and if it is Business in nature it is a Business Offering.

I'm not telling you whether you should do all of these things.  That depends on what your app is doing and whether it's worth it to you to manage it fully.  But this is how it should be represented in ServiceNow from a CSDM perspective.  And I would argue that if it's important enough to put it through the Service Desk for tracking incidents, then it may be important enough to manage it as a Business Application.

Hope this helps.


The opinions expressed here are the opinions of the author.