Scoped applications and technical debt

[Chaz_]

Hi,

When considering implementing scoped apps, I would like to know whether these can have the potential to cause performance issues and increase technical debt.

In one scenario, a plugin will be installed in its own scope and discovers network information. Yet, it will also introduce between 10-20 fields on the Incident, Problem and Change tables respectively and quite a large number across CMDB table, but remain part of its scope. 

Would the above scenario be a cause for concern from a technical debt and performance point of view? More specifically, the not all incidents will have this information populated. They would be when discovery information comes in. Would this affect the load time of the forms to display/hide a tab, and would it affect searches as the extra fields would be blank across the majority of incidents.

Thanks in advance for your input.

Chaz.

[Ryan Duce · Accepted solution]

Fields remain fields in the database even if they are part of an application scope. Any business logic, security rules, UI policies, filters etc must still be evaluated on them. So the large number of fields on the incident / problem tables won't cause any less of a performance impact because they are scoped, and in fact are likely to cause more as cross-scope privileges must also be evaluated on them since they sit on a global table. (Someone more technical than me might be able to confirm this guesstimate).

Scoped apps should be considered a way to manage technical debt and better understand / protect cross-scope interactions. The technical debt and performance overhead is still present.

What are the additional fields on the incident / problem tables designed to do? Is it all information that's specific to the incident / problem or can it be siphoned off to its own table that sits entirely within the app's scope? If you are worried about usability, you can set up the table to be dot-walkable to the incident / problem it references and build database views specific to your app to get the required UI / table joins. If you're worried about licensing custom tables you can consider extending exempt tables.

[saschawildg]

I challenge the use of the term "technical debt" in this context. If a feature is build and provides value to a customer - it is NOT "technical debt".

I recommend reading this: https://www.servicenow.com/community/developer-articles/technical-debt-management/ta-p/3265989

[Meghan Magee]

I would be careful with "If a feature is build and provides value to a customer - it is NOT "technical debt"." as that is not accurate according to the link that you just provided. The value being added doesn't impact the level of technical debt incurred. Technical debt is a function of ongoing operating cost required afterwards to support and maintain the feature, regardless of the value it is providing. The business decision made during good Governance is if the ROI for the value to the customer is worth the ongoing technical debt!

[saschawildg]

I mean: A feature that provides value to a customer is not automatically technical debt - JUST because it represents a customization. The term IMHO is often used to broadly by stating there is good configuration and bad customization (i.e. coding) - this would be too black-and-white / good-vs-evil and doesn't hit the nail on the head.