Business-Logik von Code trennen: Warum Regeln-Engines oft scheitern

Jedes Quartal ändern sich Rabattbedingungen, Compliance-Vorgaben oder Betrugserkennungs-Thresholds – doch wenn diese Logik im Anwendungscode fest verankert ist, wird jede Anpassung zur Hürde. Entwickler müssen die Regeln im Code prüfen, Code-Reviews durchführen und Deployment-Prozesse durchlaufen. Plötzlich wird aus einer einfachen Preisanpassung ein mehrwöchiges Projekt. Die Konsequenz: Business-Teams verzichten auf Optimierungen, weil sie den Aufwand scheuen. Doch es gibt einen Ausweg – wenn technische und organisatorische Trennung Hand in Hand gehen.

Warum Business-Regeln-Engines oft das falsche Versprechen geben

Ein Business-Regeln-Engine (BRE) soll die starre Kopplung zwischen Anwendungscode und Geschäftslogik lösen. Statt einer Bedingung wie if (kunde.stufe === 'gold' && warenkorb.wert > 500) rabattAnwenden(0.15) direkt im Bestelldienst zu hinterlegen, wird die Regel extern verwaltet. Die Anwendung fragt den Engine: „Soll dieser Bestellung einen Rabatt erhalten?“ – und erhält eine klare Antwort. Das klingt nach der perfekten Lösung.

Doch die Realität sieht anders aus. Open-Source-Engines wie Drools, Camunda oder Easy Rules externalisieren zwar die Regeln aus dem Code. Aber sie lösen nicht das eigentliche Problem: Wer darf die Regeln ändern – und wie schnell?

• Drools speichert Regeln in .drl-Dateien, die technisch getrennt sind – aber nur von Entwicklern bearbeitet werden können.
• Camunda nutzt BPMN-Diagramme, die zwar visuell sind, aber für Business-Teams ohne Schulung unzugänglich bleiben.
• Easy Rules vereinfacht die Syntax, landet aber wieder bei Code-ähnlichen Definitionen, die Entwickler verwalten müssen.

Die technische Trennung ist gelungen. Die organisatorische Hürde bleibt.

Die unsichtbaren Kosten hartkodierter Logik

Der Schaden durch festverdrahtete Regeln zeigt sich erst bei wachsender Komplexität. Drei Bedingungen sind noch überschaubar. Bei dreißig Bedingungen, verteilt auf vier Teams und mit unklaren Abhängigkeiten, beginnt das Chaos.

1. Verlorene Verantwortung: Niemand weiß mehr, wer die Eligibilitätsregeln für Premium-Kunden ursprünglich geschrieben hat. Der letzte Entwickler verließ das Team vor acht Monaten. Die Regeln funktionieren – aber niemand traut sich, sie anzufassen.

1. Geschäftsnutzer geben auf: Business-Teams lernen schnell, dass jede Regeländerung zwei Wochen Wartezeit bedeutet. Statt die Regeln zu verbessern, werden Ausnahmen in Excel-Tabellen manuell verwaltet – und das Risiko steigt.

1. Schulden wachsen exponentiell: Jede „zu riskante“ Refaktorierung führt zu neuen Bedingungen, die an bestehende Logik angehängt werden. Irgendwann reicht niemand mehr die komplexen if-Ketten vollständig durch.

Dieses Muster wiederholt sich unabhängig von der Teamgröße. Selbst bei Unternehmen mit Hunderten von Entwicklern wird Business-Logik zum Bremsklotz.

Open-Source-Engines: Was sie richtig machen – und wo sie scheitern

Die Open-Source-Community hat das Problem ernst genommen. Werkzeuge wie Drools, Easy Rules oder OpenL Tablets bieten echte Lösungsansätze – mit klaren Stärken und Schwächen.

| Engine | Stärken | Schwächen | |--------|---------|-----------| | Drools | Externe .drl-Dateien, Versionierung, Audit-Trails | Syntax erfordert Entwickler-Kenntnisse; komplexe Regeln schwer wartbar | | Easy Rules | Einfache API, gute Integration in Java | Regeln werden als Code definiert; Verantwortung bleibt bei Entwicklern | | OpenL Tablets | Excel als Frontend für Business-Teams | Hoher Betriebsaufwand; Versionierung von Excel-Dateien problematisch | | Camunda | Visuelle Prozessmodellierung | BPMN-Diagramme für Business-Teams oft zu abstrakt |

Die größte Gemeinsamkeit: Sie lösen das technische Problem der Externalisierung – aber nicht das organisatorische der Verantwortung.

Ein Beispiel: Drools erlaubt zwar die Trennung der Regeln vom Code, aber die .drl-Dateien müssen trotzdem von Entwicklern gepflegt werden. Das Ergebnis? Die Regeln sind technisch extern – aber fachlich weiterhin eine Entwickler-Domäne.

OpenL Tablets geht einen Schritt weiter, indem es Excel als Eingabemasken nutzt. Das ist ein cleverer Ansatz, um Business-Teams direkten Zugriff zu geben. Doch die Operationalisierung bleibt aufwendig: Excel-Dateien müssen in Versionierungssysteme eingebunden, Regeln auf Konsistenz geprüft und Server betrieben werden – ein Format, das nie für diese Zwecke designed wurde.

Drei Architektur-Muster, die tatsächlich funktionieren

Erfolgreiche Regeln-Engines haben eines gemeinsam: Sie kombinieren technische Trennung mit klaren Verantwortlichkeiten. Drei Muster haben sich in der Praxis bewährt.

1. Externe Regeln-Engine mit visueller Oberfläche

Ein externer Dienst wie Nected oder Decisions bietet eine grafische Oberfläche, in der Business-Teams Regeln als Flussdiagramme oder Tabellen definieren können. Die Engine läuft als eigenständiger Service und antwortet auf API-Aufrufe.

{
  "regelId": "premium_rabatt",
  "name": "Premium-Kunden-Rabatt",
  "bedingungen": [
    {"typ": "kunde.stufe", "operator": "==", "wert": "gold"},
    {"typ": "bestell.wert", "operator": ">", "wert": 500}
  ],
  "aktion": {"typ": "rabatt", "wert": 15}
}

Vorteile:

• Business-Teams können Regeln ohne Code-Änderungen anpassen.
• Vollständige Audit-History zeigt, wer wann welche Entscheidung getroffen hat.
• Keine Abhängigkeit von Entwickler-Ressourcen für Routineanpassungen.

Nachteile:

• Externe Abhängigkeit zum Regeln-Service.
• Schulung für Business-Teams erforderlich.

2. Regeln als Datenbank-Tabellen

Ein einfacher, aber effektiver Ansatz: Regeln werden in einer Datenbank gespeichert und zur Laufzeit gelesen. Eine Anwendung wie Rules Engine for SQL oder eine selbstgebaute Lösung liest die Regeln aus der Datenbank und wendet sie an.

SELECT * FROM geschäftsregeln 
WHERE typ = 'rabatt' 
  AND aktiv = true
  AND (kunde_stufe = 'gold' OR warenkorb_wert > 500);

Vorteile:

• Keine zusätzliche Engine nötig; Regeln liegen direkt in der Infrastruktur.
• Änderungen wirken sofort nach Datenbank-Update.
• Geringe Lernkurve für Business-Teams mit SQL-Kenntnissen.

Nachteile:

• Performance-Overhead bei komplexen Abfragen.
• Keine visuelle Oberfläche für Nicht-Techniker.

3. Hybrid-Ansatz: Regeln als Code + Meta-Ebene

Hier werden Regeln in einer vereinfachten Syntax definiert, die sowohl von Entwicklern als auch von Business-Teams verstanden wird. Tools wie JSON Logic oder YAML-basierte Regeln ermöglichen eine klare Trennung.

# rules/premium_rabatt.yml
name: Premium-Kunden-Rabatt
bedingungen:
  - kunde.stufe == 'gold'
  - bestell.wert > 500
aktion:
  rabatt: 0.15

Vorteile:

• Einfache Syntax, die für beide Seiten verständlich ist.
• Regeln liegen in Versionierungssystemen (Git) und sind auditierbar.
• Entwickler können bei Bedarf komplexe Logik hinzufügen.

Nachteile:

• Business-Teams müssen sich an die Syntax gewöhnen.
• Keine visuelle Oberfläche (außer bei zusätzlichen Tools).

Fazit: Die Lösung liegt in der Kombination

Ein Regeln-Engine allein löst nicht das Problem der Business-Logik-Verwaltung. Entscheidend ist die organisatorische Frage: Wer darf die Regeln ändern – und wie schnell? Technische Lösungen wie Drools oder Camunda externalisieren zwar die Regeln, aber ohne klare Verantwortungsverteilung bleiben sie eine Entwickler-Domäne.

Erfolgreiche Teams kombinieren:

• Eine externe Regeln-Engine mit visueller Oberfläche für Business-Teams.
• Ein Audit-System, das jede Regeländerung dokumentiert.
• Klare Verantwortlichkeiten, die festlegen, wer Regeln anpassen darf.

Nur so wird Business-Logik zur flexiblen Ressource – statt zum starren Korsett, das Innovationen bremst. Die nächsten Jahre werden zeigen, welche Engines diese Balance am besten meistern.