Adding fields to the Business Application table
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 hours ago
Hello! I am the process lead for our Application Portfolio Management (APM) practice at my company. Core to this is our use of ServiceNow's Enterprise Architecture module. We have our entire application inventory (well...most of it 🙂 in EA and we have matured to the point where lots of people in the org are using this as the definitive list of business applications in the company. This is a GOOD THING!!! However... This is also leading to numerous people coming to us saying things like "I used to maintain my own list of applications because I needed to track XYZ about them. Can we add that into APM?" Now... I've been around IT for a lot of years and have a healthy pessimism around "customizing" SaaS applications. I mean, I KNOW we CAN add more fields... I'm just trying to establish some guardrails around when it's ok to do so and when it's not. In addition, I have to work through the ServiceNow platform team to make those kinds of changes. And they (rightfully so) want to ensure that we don't do anything that will mess up upgrades, patches and the like.
So... I know that we DO NOT want to touch the OOB fields. And I'm totally cool with that. What I am wondering is this: Is there a concern with adding custom fields to the cmdb_ci_business_app table? Obviously within reason (i.e., I don't want to have to deal with 100 custom fields). But there seem to be cases where it's just simply the easiest and best way to add a field to track something else about our applications.
Here's an example: We do Threat Modeling for certain applications. These must be reviewed annually. I'm contemplating adding a custom date field called something like "Threat Model Last Reviewed Date". And then when it gets reviewed we'd update the date. I can easily create dashboards or reports that show these apps, show which are coming due for review, etc. We might also want a "Threat Model Last Review By" field to accompany that.
So...dumb idea to add custom fields like this? Why or why not? Are there specific guidleines you follow?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 hours ago
This question comes up a lot, not just for Business Applications, but across the platform for all different tables and processes.
In reviewing this, the first question to ask is whether this data already lives somewhere else, either on platform or somewhere that can be accessed by integration. The next question, or maybe the real first one, is what questions are we trying to answer. Can this be done via a report/dashboard, bringing together related data and not having to duplicate the storage of it.
For your example, I would ask where is the Threat Modeling information stored? Does the information live on the instance or in another system as the source of truth? Is there information available from that source to indicate when the last review was completed?
You could also utilize the Assessment functionality on Platform against the Business Application and assign it to the team responsible for the review. That assessment could be schedule annually and triggered by attributes of the Business Application so you can catch new ones that get added. The Assessment history can be viewed on a Business Application from the Related Records, and could also be used as part of Scoring Profile if desired.
Other options might be utilizing Products under our GRC suite for Governance and Oversight.
Long answer short, adding a field seems easy, but the long term management of that and how it correlates to a process need to be reviewed. Can you improve a process by utilizing functionality available on the platform and set yourself up for long term success?
