Was sind fachliche Schulden in der Software-Entwicklung? Simpel gesprochen handelt es sich bei fachlichen Schulden um mangelhafte fachliche Festlegungen, die in der Konsequenz zu falschen oder aufwändigen Implementierungen führen.
Wenn zum Beispiel die Einkaufs- und Vertriebs-Organisationen innerhalb einer Firmengruppe nicht aufeinander abgestimmt sind, können Bestellungen nicht konsolidiert werden, was die Software-Entwicklung erheblich teurer macht. Wie bei echten (finanziellen) Schulden, haben wir auch hier in der Vergangenheit einen Kredit aufgenommen, indem wir uns einfach den Aufwand für die Konsolidierungsfähigkeit geschenkt haben. Jetzt werden laufend Zinsen dafür fällig, überraschenderweise auch in Form von Mehrkosten bei Software-Projekten. Das wird so lange weitergehen, bis der Kredit getilgt ist, d.h. in unserem Beispiel die Konsolidierungsfähigkeit hergestellt ist.
Redensarten wie “das wissen wir schon, aber die Geschäftsführung hat das damals so entschieden” sind kein Grund, die falschen Entscheidungen nicht nochmals zu hinterfragen. Vor allem den Entscheidern sind unterschiedliche Betrachtungsweisen und die Konsequenzen einer Entscheidung offen darzulegen.
Entscheidungen dürfen nicht nur auf eine fachliche Perspektive reduziert werden, weil damit oft der Gesamtkontext unzureichend dargestellt wird. Wenn zum Beispiel die Frage gestellt wird, “Sollen wir Kosten sparen indem wir die Verpackungseinheit für ein Brettspiel auf 10 erhöhen und somit die Kartongröße optimal ausfüllen?”, dann wird niemand mit “Nein” antworten. Hätten wir jedoch erwähnt, dass die durchschnittliche Bestell- oder Verkaufs-Menge von diesem Artikel bei 4 liegt, dann wäre die Antwort anders ausgefallen.
Gründe für die Zunahme von fachlichen Schulden sind unter anderem:
Übertragen auf den Software-Entwicklungsprozess benötigen wir also bereits bei der Anforderungserhebung eine fachlich qualifizierte Validierung. Hier muss eingeschätzt werden, ob die Anforderungen auf offenen fachlichen Schulden basieren. Ist das der Fall, dann müssen zuerst Schulden abgebaut werden, damit die Software auf einem fachlich fundierten Hintergrund entwickelt werden kann.
Entscheidend ist, dass allen Projektbeteiligten, auch den Entwicklern, der fachliche Kontext bewusst ist. Denn Entwickler neigen dazu, Konzepte und Modelle aus dem Kontext einer fachlichen Domäne unkritisch auch auf andere Domänen zu übertragen, was zu inadäquaten Abstraktionen führen kann. Dann manifestieren sich (möglicherweise fehlgeleitete) Hunderttausend-Euro-Entscheidungen in Code, der nicht an Geschäftszielen ausgerichtet ist. In der Konsequenz sind Nachbesserungen unausweichlich.
Es gibt durchaus wirksame Methoden, um fachliche Schulden zu identifizieren oder ganz zu verhindern. Der erste Schritt ist eine strikte Trennung von Funktionen unter fachlichen Gesichtspunkten, also ein “sauberer” Fachdomänen-Schnitt. Das bedeutet, dass die Geschäftsprozesse und Funktionen der Fachdomäne zugeordnet werden, die auch die Fähigkeiten hat, diese zu bewerkstelligen.
Zum Beispiel gehört die Verantwortung für gesteuerte Paketbeilagen in den Fachbereich Vertrieb, weil nur bestimmte Kundengruppen diese Beilagen erhalten sollen. Beispiel: Ein Versandhändler für Tierbedarf wird eine Beilage mit Hundefutterwerbung primär an Besteller von Hundezubehör schicken wollen. Eine ungesteuerte Paketbeilage (Beispiel: Sparkassenwerbung) kann jedoch der Fachbereich Lagerlogistik einfach allen Paketen beilegen, da sie ja nicht speziell für eine bestimmte Kundengruppe gedacht ist.
“Unsaubere” fachliche Schnitte führen zu unnötiger Komplexität, weil einige Funktionen aus dem einen Kontext auf einen anderen zugreifen müssen. Sauber abgegrenzte fachliche Kontexte trennen auch die Anwendbarkeit eines Domänenmodells klar und deutlich von anderen Kontexten. Ein großes Problem dieser Abgrenzung ist allerdings, dass das fachliche Vokabular oftmals nur kontextbezogen eindeutig ist. In einem Kontext ist eine “Bestellung” eine Lieferantenbestellung, in einem anderen Kontext ist eine “Bestellung” der Kundenauftrag. Daher ist es auch notwendig, verständliche Namenskonventionen zu etablieren und diese übergreifend anzuwenden – von der Anforderungserhebung über die Dokumentation bis in den Code.
Die Verhinderung und Verringerung von fachlichen Schulden ist die Verantwortung aller Beteiligten einer Organisation. Der erste Schritt dahin ist es, Fragen zu stellen, wenn Zusammenhänge nicht klar sind. Nur wer den Kontext einfach erklären kann, wird auch verstanden und schuldenfrei umgesetzt!
Christoph Lefkes