Salesforce Technical Debt: finden und gezielt abtragen

Kurze Antwort: Salesforce Technical Debt sind die aufgelaufenen Kosten jeder fruheren Abkurzung, die noch in Ihrer Org steckt, in Klicks genauso wie in Code. Sie finden sie uber ein vollstandiges Metadaten-Inventar, verknupft 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, konnen warten, manchmal unbefristet.

Was ist Salesforce Technical Debt?

Technical Debt ist die Mehrarbeit, die eine kunftige Anderung kostet, weil fruher anders entschieden wurde. Auf Salesforce wachst sie schneller als auf den meisten Stacks, aus zwei strukturellen Grunden: Eine Anderung ist einen Admin und funf Klicks entfernt, und nichts auf der Plattform verfallt, wenn niemand es mehr nutzt.

Sie tritt in vier Formen auf:

• Automatisierungsschulden. Workflow Rules, Process-Builder-Prozesse und Flows mit uberlappender Arbeit, in einer Ausfuhrungsreihenfolge, die niemand ans Whiteboard zeichnen kann.
• Konfigurationsschulden. Felder, die seit zwei Jahren niemand fullt, Layouts fur Rollen, die es nicht mehr gibt, Profile mit Rechten, die in Permission Sets gehoren.
• Code-Schulden. Mehr als ein Trigger pro Objekt, Tests, die eine Coverage-Zahl erreichen statt Verhalten zu prufen, fest kodierte IDs.
• Integrationsschulden. Aufrufer, die auf API-Versionen festhangen, die die Plattform nicht mehr bedient, und Middleware, deren Verantwortlicher das Unternehmen verlassen hat.

Nur die vierte Form bricht horbar. 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 uber das Ende des Supports hinaus. Salesforce hat dieses Datum auf den 31. Dezember 2025 gelegt. Was noch darauf lauft, lauft weiter, aber Fehler darin werden nicht mehr behoben, und neue lassen sich nicht anlegen. Das Werkzeug Migrate to Flow existiert genau dafur.
• Alte API-Versionen sind weg. Die Platform-API-Versionen 21.0 bis 30.0 fur 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, prufen 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 zahlen lasst.
3. Das Inventar mit der Nutzung verknupfen. Feldhistorie, Abonnements von Berichten und Dashboards, Seitenaufrufe, Apex-Logs. Ein Feld ohne Lese- und Schreibzugriffe in zwolf Monaten ist ein Kandidat. Dasselbe Feld auf einem Objekt mit 400 weiteren ist eine Prioritat.
4. Abhangigkeiten kartieren, bevor etwas geloscht wird. Die Frage, wo etwas verwendet wird, ist der ganze Unterschied zwischen Aufraumen und Ausfall.
5. Pro Bereich einen Verantwortlichen benennen. Schulden ohne Verantwortlichen werden nie getilgt.

Fur eine mittelgrosse 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 unmoglich? 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 tragt ein Risiko, das es nicht tragen sollte. Erledigen Sie es im Sprint davor, eng geschnitten.
• Ruhend. Nichts auf der Roadmap beruhrt es. Erfassen, beobachten, nicht finanzieren.

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

Warum scheitert das grosse Aufraumen?

Drei Grunde, und wir haben alle drei erlebt.

1. Kein sichtbares Ergebnis. Ein org-weites Aufraumen liefert weder Funktion noch Kennzahl, auf die ein Sponsor zeigen kann. Es verliert sein Budget bei der ersten Neupriorisierung.
2. Zurechnungsschaden. Man loscht Metadaten, die niemand beobachtet hat, ein Vorfall entsteht, der Vorfall wird dem Aufraumen zugeschrieben, und das nachste 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 hangt, 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 nachsten zwolf Monate Roadmap zu vorhersehbaren Kosten liefern lassen.

Welcher Rhythmus funktioniert wirklich?

• Jeden Sprint. Ein fester Anteil der Kapazitat, ublicherweise 10 bis 20%, fur belastende Schulden in den Bereichen, die die nachsten Stories beruhren.
• Jedes Salesforce-Release. Dreimal im Jahr Optimizer erneut laufen lassen, die Abkundigungen erneut lesen und die von Ihren Integrationen angeforderten API-Versionen erneut prufen.
• Jedes Jahr. Das Inventar auffrischen und gegen die neue Roadmap neu ordnen. Eintrage wechseln die Stufe, wenn Plane sich andern, und ruhende Schulden werden manchmal uber Nacht blockierend.

Eine vorbeugende Massnahme schlagt alle drei: aus der Versionsverwaltung deployen, damit der Org-Zustand reproduzierbar ist und jede Anderung mit Autor, Begrundung und Test ankommt. Schulden, die man im Diff sieht, werden selten zu Schulden, die man im Vorfall entdeckt.

Wir fuhren dieses Inventar zu Beginn eines Projekts durch statt nach der ersten Uberraschung, und das ist ein Grund, warum wir 16+ Organisationen produktiv auf Salesforce gebracht haben. Wenn Sie eine zweite Meinung zu Ihrer Org wollen, bevor Sie die Roadmap des nachsten 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 Routineanderungen Regressionstests in unbeteiligten Bereichen erfordern oder niemand vorhersagen kann, was eine Anderung bricht, sind die Schulden bereits teuer.

Sollen wir ungenutzte Felder loschen?

Nur nach einer Abhangigkeitsprufung und nur, wenn etwas auf der Roadmap davon profitiert. Ungenutzte Felder sind meist ruhende Schulden, und ruhende Schulden sind das Gunstigste 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 nachsten Quartals stehen.

Mussen 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 beruhrt, nicht alle auf einmal.