Geschäftsentscheidungen als APIs

Geschäftsentscheidungen ändern sich schneller als Anwendungscode.

Die meisten Anwendungen hängen von Preisentscheidungen, Validierungsregeln, Klassifikationen, Freigabeprozessen, Workflow-Routing und dem Verhalten von Benutzeroberflächen ab. Die Herausforderung besteht selten darin, diese Entscheidungen zu definieren. Die eigentliche Herausforderung besteht darin, dieselbe Entscheidung konsistent in ERP-Systemen, Portalen, Webanwendungen, Integrationen und Individualsoftware bereitzustellen.

CLE stellt dafür eine REST-basierte Decision Engine API bereit.

Anwendungen übergeben Business-Objekte als JSON. CLE wertet das Entscheidungsmodell aus und liefert das Ergebnis zurück.

Die Anwendung besitzt die Daten.
Der Fachbereich besitzt die Entscheidungen.
CLE stellt Entscheidungen über APIs bereit.

Was ist eine Decision Engine API?

Eine Decision Engine API ist ein Service, der Geschäftsentscheidungen auswertet und die Ergebnisse an konsumierende Anwendungen zurückliefert.

Anstatt Geschäftslogik direkt im Anwendungscode zu implementieren, delegieren Anwendungen Entscheidungen an einen zentralen Entscheidungsservice.

Typische Entscheidungsarten sind:

  • Preisentscheidungen
  • Produktklassifikationen
  • Validierungsentscheidungen
  • Workflow-Entscheidungen
  • Freigabeentscheidungen
  • Entscheidungen für Benutzeroberflächen
  • Produktanreicherung
  • Naming- und Beschreibungslogik

Die Anwendung bleibt verantwortlich für Daten, Benutzer, Integrationen und Prozesse.

CLE übernimmt die Ausführung des Entscheidungsmodells. Die Decision Engine API stellt das Ergebnis den Anwendungen zur Verfügung.

Das Problem hart codierter Geschäftslogik

Geschäftslogik bleibt selten an einem Ort.

  • Preisregeln befinden sich im ERP-System.
  • Validierungslogik steckt im Portal.
  • Klassifikationsregeln leben im PIM.
  • Freigabeentscheidungen werden in Workflow-Systemen umgesetzt.

Dieselben Entscheidungen werden häufig mehrfach in unterschiedlichen Systemen implementiert.

Die Folgen:

  • Regeln werden dupliziert.
  • Systeme liefern unterschiedliche Ergebnisse.
  • Änderungen erfordern Software-Releases.
  • Fachbereiche verlieren die Kontrolle über Entscheidungslogik.
  • Technische Schulden wachsen.
  • Software-Upgrades werden komplexer.

Das Problem ist nicht die Anwendung.

Das Problem ist, dieselbe Geschäftsentscheidung an mehreren Stellen auszuführen.

So funktioniert CLE

CLE trennt Geschäftsentscheidungen vom Anwendungscode.

  1. Fachbereiche modellieren Entscheidungen in Excel.
  2. CLE kompiliert das Entscheidungsmodell in einen ausführbaren Dependency Graph.
  3. Anwendungen rufen die Decision Engine API auf.
  4. CLE wertet das Modell aus und liefert das Ergebnis zurück.
flowchart TD

    MODEL["Excel Entscheidungsmodell"]
    COMPILE["Kompilieren"]
    GRAPH["Ausführbarer Dependency Graph"]

    JSONIN["Geschäftsobjekt (JSON)"]
    API["CLE Decision Runtime<br/>Decision Engine API"]
    JSONOUT["Angereichertes Geschäftsobjekt<br/>Entscheidungsergebnis (JSON)"]

    MODEL --> COMPILE
    COMPILE --> GRAPH

    JSONIN --> API
    GRAPH --> API
    API --> JSONOUT

    classDef model fill:#FFF9C4,stroke:#D4AF37,color:#000;
    classDef api fill:#FFDFE5,stroke:#FF5978,color:#8E2236;
    classDef data fill:#E3F2FD,stroke:#1976D2,color:#0D47A1;

    class MODEL,COMPILE,GRAPH model;
    class API api;
    class JSONIN,JSONOUT data;

Verbundene Anwendungen müssen die gemeinsame Entscheidungslogik weder implementieren noch pflegen. Sie konsumieren lediglich das Entscheidungsergebnis.

JSON rein. JSON raus.

Anwendungen kommunizieren mit CLE über bestehende Business-Objekte.

Beispiel:

POST /api/decision
Content-Type: application/json

[{
  "customerGroup": "Retail",
  "articleGroup": "Spare Parts",
  "quantity": 250,
  "purchasePrice": 85.50
}]

CLE wertet das Entscheidungsmodell aus und gibt das angereicherte Objekt zurück:

HTTP 200 OK

[{
  "customerGroup": "Retail",
  "articleGroup": "Spare Parts",
  "quantity": 250,
  "purchasePrice": 85.50,
  "pricingFactor": 1.80,
  "salesPrice": 153.90,
  "approvalRequired": false
}]

Die Struktur bleibt durch die Anwendung definiert.
CLE schreibt kein Datenmodell vor.
CLE bewertet das Entscheidungsmodell und liefert die Attribute zurück, die die Anwendung benötigt.

CLE verwendet ein Bulk-orientiertes API-Modell.

Anfragen enthalten immer eine Sammlung von Business Objects. Diese Sammlung kann aus einem einzelnen Objekt oder aus Tausenden gleichartiger Objekte bestehen. Unabhängig vom Umfang bleibt das API-Muster identisch.

Alle Objekte einer Anfrage werden durch dasselbe Entscheidungsmodell verarbeitet. Dadurch können komplette Produktkataloge, Aufträge, Validierungen oder Benutzeroberflächenentscheidungen effizient in einem einzigen API-Aufruf ausgeführt werden.

Ein API-Muster. Viele Entscheidungsarten.

Dasselbe Integrationsmuster eignet sich für sehr unterschiedliche Geschäftsentscheidungen.

Preisentscheidungen

Preise, Rabatte, Margen, Mengenstaffeln und kundenspezifische Konditionen berechnen.

→ Preislogik-APIs entdecken

Entscheidungen für Benutzeroberflächen

Sichtbarkeit von Feldern, Pflichtfelder, Bearbeitbarkeit und Workflow-Verhalten steuern.

→ Business Rules für Benutzeroberflächen entdecken

Produktklassifikation

Produktkategorien, Taxonomien und Klassifizierungsmerkmale bestimmen.

Validierungsentscheidungen

Vollständigkeit, Plausibilität und Geschäftsregeln prüfen.

Workflow-Entscheidungen

Freigabewege, Routing-Entscheidungen und Eskalationsregeln festlegen.

Produktanreicherung

Abgeleitete Attribute berechnen und Produktinformationen standardisieren.

Mehr als klassische Rule Engines

Traditionelle Rule Engines basieren häufig auf Bedingungen, Entscheidungstabellen und IF-THEN-Regeln.

Für viele Szenarien reicht das aus.

Reale Geschäftsentscheidungen kombinieren jedoch häufig:

  • Formeln
  • Lookup-Tabellen
  • Referenzdaten
  • Preis-Matrizen
  • Klassifikationen
  • Validierungen
  • Abhängigkeitsketten
  • Zwischenberechnungen

Ein Preismodell kann beispielsweise Mengenstaffeln, Kundengruppen, Lookup-Tabellen, Margenberechnungen und Währungsumrechnungen innerhalb einer einzigen Entscheidung kombinieren.

CLE verfolgt einen anderen Ansatz.

Fachbereiche modellieren vollständige Entscheidungsmodelle in Excel.

Diese Modelle können IF-Funktionen, mathematische Formeln, XLOOKUP, VLOOKUP, INDEX/MATCH, Aggregationen, Textfunktionen, Datumsberechnungen und eingebettete Entscheidungstabellen enthalten.

CLE kompiliert das Modell in einen ausführbaren Dependency Graph und stellt die resultierenden Entscheidungen über REST-APIs bereit.

CLE führt keine isolierten Regeln aus. CLE führt vollständige Geschäftsentscheidungsmodelle aus.

Warum eine Decision Engine API?

Konsistente Entscheidungen überall

Jede Anwendung erhält dieselbe Entscheidung.
Keine doppelte Logik.
Keine widersprüchlichen Implementierungen.

Schnellere fachliche Änderungen

Fachbereiche aktualisieren das Entscheidungsmodell.
Die Anwendungen nutzen weiterhin dieselbe API.
Nicht jede Regeländerung benötigt ein Software-Release.

Weniger technische Schulden

Geschäftslogik wird aus dem Anwendungscode ausgelagert.
Anwendungen werden einfacher und leichter wartbar.

Klare Verantwortlichkeiten

Fachbereiche pflegen Entscheidungen.
Entwickler entwickeln Anwendungen.
Verantwortlichkeiten werden sauber getrennt.

Nachvollziehbare Entscheidungen

Jede Entscheidung kann auf ihre Grundlage zurückgeführt werden:

  • Eingaben
  • Formeln
  • Lookup-Tabellen
  • Referenzdaten
  • Zwischenberechnungen
  • Entscheidungspfade

Entscheidungen bleiben transparent und auditierbar.

Unabhängige Weiterentwicklung

Anwendungen können sich unabhängig vom Entscheidungsmodell weiterentwickeln.
Entscheidungsmodelle können sich unabhängig von Anwendungen weiterentwickeln.
Dadurch wird die Kopplung zwischen Geschäftslogik und Software reduziert.

Excel als Modellierungssprache

In nahezu jedem Unternehmen existiert bereits umfangreiches Fachwissen in Excel.

  • Preislogik
  • Klassifikationslogik
  • Validierungsregeln
  • Freigabelogik
  • Berechnungsmodelle
  • Entscheidungstabellen

CLE ermöglicht es, dieses Wissen weiterzuverwenden.

Es besteht keine Notwendigkeit für:

  • proprietäre Regelsprachen
  • individuelle Skriptsprachen
  • Migrationsprojekte für Business Rules
  • neue Modellierungswerkzeuge

Excel bleibt die Modellierungsumgebung. Excel ist nicht die Runtime.

Die Excel-Datei ist der Source Code des Entscheidungsmodells.
Der ausführbare Dependency Graph ist das Runtime-Artefakt.

Ein Entscheidungsmodell. Viele Anwendungen.

Dasselbe Entscheidungsmodell kann Entscheidungen bereitstellen für:

  • ERP-Systeme
  • PIM-Systeme
  • CRM-Plattformen
  • CPQ-Lösungen
  • E-Commerce-Plattformen
  • Kundenportale
  • Produktkonfiguratoren
  • Mobile Anwendungen
  • Individualsoftware

Jede Anwendung erhält dieselbe Geschäftsentscheidung.
Keine doppelten Implementierungen.
Keine Synchronisationsprojekte.
Kein widersprüchliches Verhalten.

Die Anwendung besitzt die Daten. Der Fachbereich besitzt die Entscheidungen.

Anwendungen sollten Geschäftsentscheidungen nicht mehrfach implementieren müssen, wenn diese über mehrere Systeme hinweg konsistent bleiben sollen.

Die Anwendung besitzt die Daten.
Der Fachbereich besitzt die Entscheidungen.
CLE stellt Geschäftsentscheidungen über APIs bereit.

Behalten Sie die Anwendung. Ersetzen Sie die hart codierte Geschäftslogik.
Kontaktieren Sie uns und erfahren Sie, wie CLE Ihre Entscheidungsmodelle als APIs bereitstellen kann.

Kontakt aufnehmen

Nach oben scrollen