Salesforce Technical Debt: finden und gezielt abtragen

Kurze Antwort: Salesforce Technical Debt sind die aufgelaufenen Kosten jeder früheren Abkürzung, die noch in Ihrer Org steckt, in Klicks genauso wie in Code. Sie finden sie über ein vollständiges Metadaten-Inventar, verknüpft mit Nutzungsdaten. Und Sie tilgen sie in der Reihenfolge, die Ihre Roadmap verlangt, nicht von oben nach unten, denn Schulden, die nichts auf der Roadmap blockieren, können warten, manchmal unbefristet.

Was ist Salesforce Technical Debt?

Technical Debt ist die Mehrarbeit, die eine künftige Änderung kostet, weil früher anders entschieden wurde. Auf Salesforce wächst sie schneller als auf den meisten Stacks, aus zwei strukturellen Gründen: Eine Änderung ist einen Admin und fünf Klicks entfernt, und nichts auf der Plattform verfällt, wenn niemand es mehr nutzt.

Sie tritt in vier Formen auf:

• Automatisierungsschulden. Workflow Rules, Process-Builder-Prozesse und Flows mit überlappender Arbeit, in einer Ausführungsreihenfolge, die niemand ans Whiteboard zeichnen kann.
• Konfigurationsschulden. Felder, die seit zwei Jahren niemand füllt, Layouts für Rollen, die es nicht mehr gibt, Profile mit Rechten, die in Permission Sets gehören.
• Code-Schulden. Mehr als ein Trigger pro Objekt, Tests, die eine Coverage-Zahl erreichen statt Verhalten zu prüfen, fest kodierte IDs.
• Integrationsschulden. Aufrufer, die auf API-Versionen festhängen, die die Plattform nicht mehr bedient, und Middleware, deren Verantwortlicher das Unternehmen verlassen hat.

Nur die vierte Form bricht hörbar. Die anderen drei besteuern still jedes Projekt, das Sie starten.

Wo versteckt sie sich gerade?

Zwei datierte Punkte lohnen diese Woche einen Blick, weil die Plattform sich bewegt hat und die meisten Orgs nicht.

• Workflow Rules und Process Builder sind über das Ende des Supports hinaus. Salesforce hat dieses Datum auf den 31. Dezember 2025 gelegt. Was noch darauf läuft, läuft weiter, aber Fehler darin werden nicht mehr behoben, und neue lassen sich nicht anlegen. Das Werkzeug Migrate to Flow existiert genau dafür.
• Alte API-Versionen sind weg. Die Platform-API-Versionen 21.0 bis 30.0 für SOAP, REST und Bulk wurden im Summer '22 als veraltet markiert und mit Summer '25 abgeschaltet. Aufrufer erhalten jetzt 410 GONE bei REST, 500 UNSUPPORTED_API_VERSION bei SOAP und 400 InvalidVersion bei Bulk. Wenn ein alter Nachtjob verstummt ist, prüfen Sie das zuerst.

Wie inventarisiert man Schulden, ohne die Lieferung anzuhalten?

1. Salesforce Optimizer laufen lassen und exportieren. Kostenlos, im Setup vorhanden, und es liefert eine Startliste statt einer Meinung.
2. Die Org-Metadaten in die Versionsverwaltung holen. Selbst wenn Sie nie daraus deployen, haben Sie endlich etwas, das sich durchsuchen, vergleichen und zählen lässt.
3. Das Inventar mit der Nutzung verknüpfen. Feldhistorie, Abonnements von Berichten und Dashboards, Seitenaufrufe, Apex-Logs. Ein Feld ohne Lese- und Schreibzugriffe in zwölf Monaten ist ein Kandidat. Dasselbe Feld auf einem Objekt mit 400 weiteren ist eine Priorität.
4. Abhängigkeiten kartieren, bevor etwas gelöscht wird. Die Frage, wo etwas verwendet wird, ist der ganze Unterschied zwischen Aufräumen und Ausfall.
5. Pro Bereich einen Verantwortlichen benennen. Schulden ohne Verantwortlichen werden nie getilgt.

Für eine mittelgroße Org sind das zwei Wochen Arbeit, die neben einem normalen Sprint laufen. Das Ergebnis ist ein Register, kein Projektplan.

Wie ordnet man das Gefundene?

Hier laufen die meisten Schuldenprogramme schief. Nach Schweregrad zu sortieren ergibt eine Liste danach, wie schlimm etwas aussieht. Nach Aufwand zu sortieren ergibt eine Liste danach, wie leicht etwas geht. Keine von beiden ist eine Liste, die Ihr Unternehmen zweimal finanziert.

Sortieren Sie stattdessen gegen die Roadmap. Stellen Sie zu jedem Eintrag im Register eine Frage: Welches zugesagte Roadmap-Vorhaben wird dadurch langsamer, riskanter oder unmöglich? Diese eine Frage teilt das Register in drei Stufen.

• Blockierend. Das Vorhaben kann erst live gehen, wenn die Schuld getilgt ist. Erledigen Sie die Arbeit im Projekt, finanziert aus dessen Budget und Business Case.
• Belastend. Das Vorhaben geht trotzdem live, kostet aber mehr oder trägt ein Risiko, das es nicht tragen sollte. Erledigen Sie es im Sprint davor, eng geschnitten.
• Ruhend. Nichts auf der Roadmap berührt es. Erfassen, beobachten, nicht finanzieren.

Zwei Kategorien stechen diese Ordnung: alles mit Sicherheits- oder Compliance-Folge und alles, was in Produktion still fehlschlägt. Das wird unabhängig von der Roadmap behoben, weil sein Preis nicht in Lieferzeit bezahlt wird.

Warum scheitert das große Aufräumen?

Drei Gründe, und wir haben alle drei erlebt.

1. Kein sichtbares Ergebnis. Ein org-weites Aufräumen liefert weder Funktion noch Kennzahl, auf die ein Sponsor zeigen kann. Es verliert sein Budget bei der ersten Neupriorisierung.
2. Zurechnungsschaden. Man löscht Metadaten, die niemand beobachtet hat, ein Vorfall entsteht, der Vorfall wird dem Aufräumen zugeschrieben, und das nächste wird nie genehmigt.
3. Es konvergiert nie. Eine Org, die das ganze Jahr geliefert hat, hat neue Schulden, bevor der Durchgang fertig ist. Tilgung, die an Roadmap-Vorhaben hängt, konvergiert von selbst, weil sie endet, wenn das Vorhaben live geht.

Das Ziel ist keine saubere Org. Das Ziel ist eine Org, in der sich die nächsten zwölf Monate Roadmap zu vorhersehbaren Kosten liefern lassen.

Welcher Rhythmus funktioniert wirklich?

• Jeden Sprint. Ein fester Anteil der Kapazität, üblicherweise 10 bis 20%, für belastende Schulden in den Bereichen, die die nächsten Stories berühren.
• Jedes Salesforce-Release. Dreimal im Jahr Optimizer erneut laufen lassen, die Abkündigungen erneut lesen und die von Ihren Integrationen angeforderten API-Versionen erneut prüfen.
• Jedes Jahr. Das Inventar auffrischen und gegen die neue Roadmap neu ordnen. Einträge wechseln die Stufe, wenn Pläne sich ändern, und ruhende Schulden werden manchmal über Nacht blockierend.

Eine vorbeugende Maßnahme schlägt alle drei: aus der Versionsverwaltung deployen, damit der Org-Zustand reproduzierbar ist und jede Änderung mit Autor, Begründung und Test ankommt. Schulden, die man im Diff sieht, werden selten zu Schulden, die man im Vorfall entdeckt.

Wir führen dieses Inventar zu Beginn eines Projekts durch statt nach der ersten Überraschung, und das ist ein Grund, warum wir 20+ Organisationen produktiv auf Salesforce gebracht haben. Wenn Sie eine zweite Meinung zu Ihrer Org wollen, bevor Sie die Roadmap des nächsten Jahres zusagen, fangen Sie hier an.

FAQ

Woran erkenne ich, dass meine Org zu viele Technical Debts hat?

Messen Sie es an der Lieferung, nicht an Zahlen. Wenn Routineänderungen Regressionstests in unbeteiligten Bereichen erfordern oder niemand vorhersagen kann, was eine Änderung bricht, sind die Schulden bereits teuer.

Sollen wir ungenutzte Felder löschen?

Nur nach einer Abhängigkeitsprüfung und nur, wenn etwas auf der Roadmap davon profitiert. Ungenutzte Felder sind meist ruhende Schulden, und ruhende Schulden sind das Günstigste in Ihrer Org, das man in Ruhe lassen kann.

Reicht Salesforce Optimizer?

Es ist der richtige erste Schritt, nicht der letzte. Optimizer meldet Probleme auf Plattformebene, kann Ihnen aber nicht sagen, welche davon zwischen Ihnen und der Roadmap des nächsten Quartals stehen.

Müssen wir jetzt von Workflow Rules und Process Builder weg?

Sie laufen noch, aber der Support endete am 31. Dezember 2025, Fehler darin bleiben also offen. Migrieren Sie zuerst die Automatisierungen, die Ihre Roadmap berührt, nicht alle auf einmal.