Warum technische Schulden in Dynamics 365 entstehen

Technische Schulden klingen nach Nachlässigkeit. Sie entstehen aus Entscheidungen welche im Moment ihrer Entstehung vernünftig waren und aus dem Umstand, dass niemand sie später noch einmal anfasst oder in Frage stellt.

Die erste Quelle: der schnelle Weg unter Zeitdruck

Ein Kunde braucht kurzfristig ein zusätzliches Feld auf dem Formular. Es wird angelegt ohne Beschreibung mit dem Standardpräfix das gerade aktiv ist. Das dauert 2 Minuten statt 4 und funktioniert einwandfrei.

Zwei Jahre später sitzt jemand anderes vor einer Tabelle mit 80 Feldern, von denen 75 keine Beschreibung haben. Welche davon noch benutzt werden lässt sich nur auf einem Weg beantworten: Man muss jede einzeln durch (mit Hilfe der Abhängigkeiten anzeigen) Funktion durch Formulare, Views, Business Rules oder Flows verfolgen. Problematisch werden dabei allerdings Feldverwendungen in Javascripts oder anderem Code. Hier bleibt nur Code Analyse. Genau das ist die Zinszahlung auf die eingesparten 2 Minuten pro Feld.

Die zweite Quelle: Personalwechsel ohne Übergabe

Dataverse-Umgebungen überleben die Teams die sie gebaut haben. Ein externer Dienstleister setzt die Lösung auf, ein interner Mitarbeiter übernimmt sie. Dieses wechselt die Stelle und ein neuer Dienstleister kommt dazu.

Jeder Wechsel kostet Wissen das nirgends dokumentiert war. Was bleibt ist die technische Umsetzung ohne die Begründung dahinter. Die Frage „warum ist das so gebaut“ hat dann keinen Adressaten mehr. Im Zweifel traut sich niemand etwas zu entfernen.

Die dritte Quelle: Anpassungen die überleben - obwohl ihr Anlass verschwunden ist

Ein JavaScript blendet ein Feld aus weil ein Prozess das damals erforderte. Der Prozess wurde später umgestellt und das Skript blieb. Eine Business Rule setzt einen Standardwert den heute schon ein Flow setzt. Beide laufen weiter.

Solche Reste sind einzeln harmlos. In der Summe führen sie dazu, dass Änderungen unvorhersehbar werden. Wer ein Feld anfasst weiß nicht mehr welche Stellen darauf reagieren.

Die vierte Quelle: Technologiewechsel der Plattform

Microsoft entwickelt die Plattform weiter. Was vor fünf Jahren die empfohlene Vorgehensweise war ist heute abgelöst. Klassische Workflows wurden von Power Automate Flows abgelöst. Das alte Objektmodell im JavaScript wurde durch die aktuelle Client-API ersetzt. Der Common-Data-Service-Connector wurde durch den Dataverse-Connector abgelöst.

Nichts davon hört von einem Tag auf den anderen auf zu funktionieren. Und weil kein Moment den Umbau erzwingt passiert er nicht. Bis er unter Zeitdruck passieren muss.

Woran Sie den Zustand ablesen können

Einige Kennzahlen lassen sich aus einem Solution-Export ermitteln und sie ergeben ein erstaunlich klares Bild.

• Dokumentationsgrad: Welcher Anteil der eigenen Felder, Tabellen und Prozesse hat eine Beschreibung? Eine Faustregel aus der Praxis: Unter zwanzig Prozent wird eine Übernahme durch ein neues Team teurer.
• Präfixkonsistenz: Ein dominantes Namenspräfix oder mehrere mit ähnlichem Anteil aus vielen kleinen Splitterlösungen?
• Anteil abgelöster Technologien: Wie viele klassische Workflows laufen noch oder wie viele Skripte hängen am alten Objektmodell?
• Verwaiste Komponenten: Auf welche Web-Ressourcen zeigt kein Formular und kein Ribbon mehr?

Keine dieser Zahlen ist für sich genommen ein Urteil. Zusammen zeigen sie ob eine Lösung gepflegt wurde oder nur gewachsen ist.

Was sich davon lohnt anzugehen

Nicht alles. Technische Schulden abzutragen kostet Zeit die an anderer Stelle fehlt. Manche Altlast wird nie wieder angefasst.

Der Rückstand lässt sich auch im Alltag abtragen ohne ein eigenes Projekt dafür zu beantragen. Wie das geht steht unter Solution-Hygiene.

Bei sehr altem Bestand lohnt vorab die Frage ob Modernisierung im Bestand oder Neuaufbau günstiger ist.

Priorität haben zwei Kategorien. Erstens alles was Sicherheit oder Datenverlust berührt: zu weit gefasste Löschrechte oder kaskadierende Löschregeln an unerwarteten Stellen. Zweitens alles was einen anstehenden Schritt blockiert. Wer migrieren will muss abgelöste Technologien anfassen, ob er will oder nicht.

Der Rest ist eine Frage der Gelegenheit. Wer eine Tabelle ohnehin umbaut dokumentiert dabei die Felder mit. Das ist deutlich billiger als eine separate Aufräumaktion für die niemand Budget freigeben wird.