Wo sich ServiceNow-Technical-Debt tatsächlich ansammelt
Jede einzelne Anpassung sah in Ordnung aus, als sie live ging. Die Schulden stecken in dem, was niemand noch einmal angeschaut hat.
Fünf Orte, an denen sich Schulden verstecken
Keiner davon sieht isoliert falsch aus. Die Kosten zeigen sich erst, wenn es Hunderte davon in einer Instanz gibt, die niemand vollständig kartiert hat.
Business Rules ohne Bedingung
Laufen bei jedem Insert oder Update auf einer stark genutzten Tabelle mit, meistens ohne etwas zu tun - und kosten jedes Mal einen Teil der Transaktionszeit.
Doppelte Logik über Script Includes hinweg
Dieselbe Validierung dreimal unterschiedlich, leicht inkonsistent geschrieben - eine Korrektur an einer Stelle behebt die anderen beiden nicht.
Veraltete API-Nutzung überlebt Upgrades
Muster, die heute technisch noch funktionieren, aber ein zukünftiges Plattform-Upgrade still und leise erschweren.
Hartcodierte sys_ids
Ein bestimmter Datensatz direkt im Skript verankert statt über ein echtes Lookup - bricht lautlos, sobald sich dieser Datensatz ändert oder neu angelegt wird.
Fehlende Fehlerbehandlung bei Integrationsaufrufen
Ein REST-Aufruf ohne Try/Catch - eine langsame oder fehlerhafte Antwort entfernt von einer hängenden Transaktion.
So wird es geprüft
Das meiste davon ist mechanisch prüfbar - es ist die Menge in einer echten Instanz, die es mühsam macht, nicht die Schwierigkeit einer einzelnen Prüfung.
Bedingungen von Business Rules lesen, nicht nur ihre Skripte
Ein schnelles Zählen, wie viele aktive Business Rules auf einer stark genutzten Tabelle ein leeres Bedingungsfeld haben, ist eines der schnellsten verfügbaren Signale - jede läuft bei jedem einzelnen Insert/Update mit, ob relevant oder nicht.
Nach hartcodierten sys_ids grep-en
Eine echte, mechanische Prüfung - eine 32-stellige Hex-Zeichenkette in einem Skript ist fast immer eine hartcodierte Referenz und fast immer eine echte Lookup wert.
Auf synchrone Aufrufe ohne Timeout oder Catch prüfen
Ein ausgehender REST- oder SOAP-Aufruf ohne Fehlerbehandlung riskiert nicht nur eine fehlgeschlagene Integration - er riskiert, dass die ganze Transaktion hängt, bis die Plattform selbst sie abbricht.
Schulden, die priorisiert werden sollten
- Business Rules mit leerem Bedingungsfeld auf stark genutzten Tabellen
- Script Includes mit nahezu identischen Funktionskörpern
- Jede
GlideRecord-Schleife ohnesetLimit() - Ausgehende Aufrufe ohne Try/Catch
- Anpassungen, zuletzt von jemandem bearbeitet, der nicht mehr im Unternehmen ist
Die manuelle Variante skaliert nicht
Ein echter Code-Review-Durchgang bedeutet, jede relevante Business Rule, jedes Script Include, jedes Client Script und jede UI Action zu lesen - nicht einmal beim Launch, sondern erneut nach jeder relevanten Änderung, für immer. Die meisten Teams tun das reaktiv, wenn etwas kaputtgeht, statt kontinuierlich - das heißt, die Schulden werden durch einen Incident entdeckt, nicht durch eine Prüfung.
Diese Prüfung läuft kontinuierlich, automatisch
Unsere eigene Plattform, neo.ai, prüft Business Rules, Script Includes, UI Actions und Client Scripts nach Zeitplan auf Korrektheit, Sicherheit und Best Practice - und zeigt nur, was wirklich handlungsrelevant ist. Das ist eine von sieben Kategorien, die sie auf einer ServiceNow-Instanz überwacht.