Geschäftslogik erhalten statt neu schreiben

Was Geschäftslogik wirklich bedeutet

Wenn von Geschäftslogik die Rede ist, klingt das abstrakt. Gemeint ist aber etwas sehr Konkretes: die Regeln, nach denen Ihre Software arbeitet. Wie werden Preise berechnet? Welcher Kunde bekommt welchen Rabatt? Wann wird eine Bestellung automatisch freigegeben und wann nicht?

Diese Regeln bilden ab, wie Ihr Unternehmen funktioniert. Nicht auf dem Papier, sondern in der Praxis. Jede Wenn-Dann-Bedingung im Code entspricht einer Entscheidung, die irgendwann jemand getroffen hat — oft aus gutem Grund.

Das Problem: Viele dieser Entscheidungen liegen Jahre zurück. Der Entwickler, der sie umgesetzt hat, ist längst woanders. Die Fachabteilung, die den Wunsch hatte, erinnert sich vielleicht noch an das Ergebnis — aber nicht an die Ausnahmen. Und genau in den Ausnahmen steckt der eigentliche Wert.

Geschäftslogik ist kein Feature, das man einfach „wieder einbauen" kann. Sie ist das akkumulierte Wissen Ihres Unternehmens, übersetzt in Software. Wer sie wegwirft, wirft Erfahrung weg.

Versteckte Regeln: Sonderfälle, Ausnahmen, gewachsene Prozesse

Die offensichtlichen Funktionen Ihrer Software kennen Sie. Die Rechnung wird erstellt, der Lieferschein gedruckt, die Bestellung an das Lager weitergeleitet. Das steht auch in jedem Lastenheft.

Was dort nicht steht, sind die Sonderfälle. Ein konkretes Beispiel aus unserer Praxis: Ein mittelständischer Händler hatte in seiner Auftragsverwaltung eine Regel, die bei Bestellungen über einem bestimmten Betrag automatisch eine andere Zahlungsbedingung aktivierte — aber nur für Kunden aus einer bestimmten Region und nur bei bestimmten Produktgruppen. Diese Regel war nirgends dokumentiert. Sie existierte ausschließlich im Code.

Der damalige Entwickler hatte sie auf Wunsch des Vertriebsleiters eingebaut. Der Vertriebsleiter war inzwischen in Rente. Niemand im Unternehmen wusste, dass diese Regel existierte — bis sie bei einem Testlauf des neuen Systems plötzlich fehlte und die ersten Rechnungen falsch rauskamen.

Solche versteckten Regeln gibt es in jeder gewachsenen Software. Nicht eine oder zwei, sondern Dutzende. Sie betreffen:

• Preisberechnungen mit Staffeln, Rabatten und Sonderkonditionen
• Freigabeprozesse, die von Beträgen, Kunden oder Produktkategorien abhängen
• Rundungslogiken bei Steuern und Währungsumrechnungen
• Ausnahmebehandlungen für bestimmte Lieferanten oder Regionen
• Plausibilitätsprüfungen, die fehlerhafte Eingaben abfangen
• Schnittstellen-Anpassungen an die Eigenheiten bestimmter Partner-Systeme

Jede einzelne dieser Regeln löst ein reales Problem. Sie ist die Antwort auf eine Situation, die irgendwann aufgetreten ist. Wer die Software neu baut, entdeckt diese Situationen erst wieder, wenn sie eintreten — also im Produktivbetrieb, beim echten Kunden, mit echtem Geld.

Warum Neubau die gleichen Fehler wiederholt

Die Idee klingt verlockend: Wir fangen sauber von vorn an. Neue Technologie, neue Architektur, alles richtig machen. In der Theorie ist das überzeugend. In der Praxis scheitert es regelmäßig — nicht an der Technik, sondern am Wissen.

Ein Neubau beginnt mit einem Lastenheft. Darin steht, was die Software können soll. Aber ein Lastenheft beschreibt immer nur den Idealfall. Es beschreibt nicht die 47 Sonderfälle, die über Jahre in die bestehende Software eingeflossen sind. Weil niemand mehr weiß, dass es sie gibt.

Das Ergebnis: Die neue Software wird fertig, sieht gut aus, hat eine moderne Oberfläche — und produziert am ersten Tag falsche Rechnungen. Oder die Schnittstelle zum Steuerberater funktioniert nicht mehr richtig. Oder Stammkunden bekommen plötzlich andere Konditionen. Nicht weil die Entwickler schlechte Arbeit machen, sondern weil ihnen Informationen fehlen, die nur im alten Code stecken.

Es gibt eine bekannte Faustregel in der Softwarebranche: Ein Neubau dauert mindestens doppelt so lang und kostet mindestens doppelt so viel wie geplant. Dafür gibt es einen einfachen Grund — die versteckte Komplexität taucht erst während der Entwicklung auf, nicht vorher.

Das heißt nicht, dass ein Neubau nie sinnvoll ist. Es gibt Fälle, in denen die alte Architektur so kaputt ist, dass eine Modernisierung teurer käme. Aber das ist die Ausnahme, nicht die Regel. Und es lässt sich erst beurteilen, wenn jemand den bestehenden Code wirklich gelesen und verstanden hat.

Bestandsaufnahme: Code lesen, verstehen, dokumentieren

Bevor irgendeine Entscheidung Sinn ergibt — modernisieren, erweitern oder doch neu bauen — braucht es eine gründliche Bestandsaufnahme. Das bedeutet: Jemand muss sich in den vorhandenen Code einarbeiten, die Struktur verstehen und die Geschäftslogik identifizieren.

Das ist kein triviales Vorhaben. Fremden Code lesen ist eine eigene Disziplin. Besonders bei Software, die über Jahre gewachsen ist, von verschiedenen Entwicklern angefasst wurde und keine oder nur lückenhafte Dokumentation hat.

Wir gehen dabei systematisch vor:

1. Zunächst verschaffen wir uns einen Überblick über die Gesamtarchitektur — welche Komponenten gibt es, wie hängen sie zusammen?
2. Dann identifizieren wir die Kernbereiche: Wo sitzt die eigentliche Geschäftslogik? Wo werden Daten verarbeitet, berechnet, weitergeleitet?
3. Im dritten Schritt dokumentieren wir die gefundenen Regeln — in einer Sprache, die auch ohne Programmierkenntnisse verständlich ist.
4. Schließlich bewerten wir den Zustand: Was ist solide? Was ist fragil? Wo lauern Risiken?

Bei dieser Arbeit setzen wir heute auch KI-gestützte Werkzeuge ein, die uns helfen, große Codemengen schneller zu durchsuchen und Muster zu erkennen. Das beschleunigt den Prozess erheblich. Aber — und das ist entscheidend — die KI ersetzt nicht das menschliche Urteil. Sie kann Code zusammenfassen, aber nicht bewerten, ob eine Geschäftsregel noch korrekt ist. Dafür braucht es Erfahrung und das Gespräch mit Ihnen.

Das Ergebnis der Bestandsaufnahme ist eine klare Grundlage: Sie wissen, was in Ihrer Software steckt. Sie wissen, wo die Risiken liegen. Und Sie können eine fundierte Entscheidung treffen — nicht auf Basis von Bauchgefühl, sondern auf Basis von Fakten.

Mehr dazu, wie wir uns in fremden Code einarbeiten, finden Sie auf unserer Seite Code verstehen und portieren.

Schrittweise modernisieren statt alles auf einmal

Die Alternative zum Neubau ist nicht Stillstand. Die Alternative ist gezielte, schrittweise Modernisierung. Das bedeutet: Die bewährte Geschäftslogik bleibt erhalten, aber die Umgebung wird aktualisiert, Schwachstellen werden beseitigt und neue Anforderungen werden eingebaut.

Konkret kann das so aussehen:

• Die Software wird in eine geschützte Umgebung überführt, damit sie auf modernen Betriebssystemen sicher weiterläuft
• Eine neue Schnittstelle wird angebunden — etwa für E-Rechnung, einen neuen Zahlungsdienstleister oder ein ERP-System
• Kritische Codestellen werden überarbeitet, während der Rest unangetastet bleibt
• Die Dokumentation wird nachgezogen, damit das System auch in Zukunft wartbar ist

Der entscheidende Punkt: Jeder Schritt ist für sich abgeschlossen und testbar. Sie tauschen nicht das ganze System auf einen Schlag aus, sondern verbessern gezielt die Stellen, die es brauchen. Das reduziert das Risiko massiv.

Bei jedem einzelnen Schritt bleibt Ihre Software lauffähig. Es gibt keinen Tag X, an dem alles gleichzeitig umgestellt wird und Sie hoffen, dass nichts schiefgeht. Stattdessen gibt es viele kleine Verbesserungen, die jeweils geprüft und freigegeben werden.

Natürlich hat auch dieser Ansatz Grenzen. Wenn die Architektur der Software so veraltet ist, dass jede Änderung unkalkulierbare Seiteneffekte auslöst, wird schrittweises Modernisieren irgendwann unwirtschaftlich. Aber genau das zeigt die Bestandsaufnahme. Und selbst dann ist es sinnvoll, die vorhandene Geschäftslogik zuerst zu dokumentieren — bevor man sie in einem neuen System nachbaut.

Einen Überblick über unsere Herangehensweise bei Legacy-Software finden Sie auf der zugehörigen Übersichtsseite.

Schrittweise Modernisierung ist kein Kompromiss. Es ist der pragmatische Weg, der das schützt, was funktioniert — und das verbessert, was es braucht. Nicht mehr und nicht weniger.