Question about SN scoped application mapping within CSDM 5
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello, you would have a ServiceNow Business Application right? In that case I would think it would make sense to build this new tool as an Application Service under your main ServiceNow Business App. That is what we do for scoped apps and OOTB applications (Change, Inc, CMDB, etc.) as they all have different owners than the main support team of the full platform.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Austin, thanks for your reply. Sounds reasonable, I was hesitating if we should be creating App Services that do not have a 1:1 corresponding Business App, but seems like connecting it to platform-level BA might be okay.
So you decided in your org not to have Incident, Change etc. represented as Business Apps? Do you just have 1 platform-level ServiceNow BA or do you have 1 platform BA and some other module-level BAs under it? Just curious.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
We currently only have one level of Business Apps. So we just have the one platform ServiceNow BA and all of the apps/modules are app services. I don't think there is a right/wrong way to do it, just whatever makes sense for your organization. However, i dont think the scoped apps would be Tech Services/Offerings.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
If this "app" has a distinct development path with a feature roadmap, could be subject to ITSM (Inc, Prb, Chg), can be deployed in multiple environments and could have competing and potential replacement Business Applications then it may be better as a Business Application. When it comes to ServiceNow I recommend all the major process areas are separate Business Applications because they fulfil Business Capabilities and Business Processes and can be (and are) developed upon independently. We don't need more than one level of hierarchy - they all run on the parent ServiceNow Business Application Platform Host
If however it is considered an integration utility that as you say will not draw the attention of the EA capability, then consider this under the umbrella of microservices and APIs and if you have Enterprise Architecture, use Digital Integration Management. This could be considered the enabler of an integration or the actual interface between Applications.
I hope this helps!
Mat
