Regelwerk

Im zweiten Posting versuche ich an einem Beispiel zu erklären, worum es uns mit dem Blog künftig geht.
Wir schreiben das Jahr 2007 und hantieren vorrangig mit folgenden Stichworten (subjektive Auswahl):

regelbasierte Geschäftsprozesse, Businesslogik, variable Vergütung, oder
business rules, Business Rules Management, rule engine usw.

Ein besonders anschauliches Beispiel für das, was z. B. eine rule engine leisten soll, habe ich im The Disco Blog gefunden. Reduzierte Komplexität. Soziologisch ist das von Niklas Luhmann durchgerechnet worden, vor 20 Jahren. Technologisch wird jetzt allerorten nachgezogen. Hier soll es das Beispiel eines Bierhändlers sein, der die Effizienz seines Online-Verkaufs steigern möchte. Mittel dazu soll ihm ein Verkaufsassistent sein. Beispielaufgabe hier: Assistiere dem kaufwilligen Biertrinker bei der Auswahl seines Getränkes. Und das geht laut Disco Blog so:

Do you like a light beer or a dark beer?

 if light beer:

  Do you like crisp, smooth beers or more prefer a more hoppy one?

   if crisp:

    then Pils

   else:

    Do you like light hops or more aggressive hops?

      if light:

       then Pale Ale

      else:

       IPA

else:

  Do you like the taste of coffee?

   if yes:

     Chocolate Stout

   else:

     Do you like spiciness?

       if yes:

         try Winter Ale

       else:

          Do you like high alcohol content?

            if yes:

              try an Eisbock

            else:

              try a Lager

Sieht einfach aus. Sollte es auch. Doch was passiert, wenn eines der Biere ausgeht oder die Marke aus dem Angebot genommen wird oder die Zahl von 10 Produkten deutlich überschritten wird? Die Wenn-Dann-Beziehungen würden immer verschachtelter. Je mehr Angebote, desto komplexer die Beziehungen und Regeln. Und zusätzlich sind bei all der ansteigenden Komplexität die Verkäufer zumeist keine technisch versierten Entwickler bzw. Programmierer.
Genau an dieser Stelle offenbaren sich die Vorzüge regelbasierter Ansätze für die Abbildung von Geschäftsprozessen - in dem Fall zum Beispiel für den Absatzleiter.

Die Java-Technolgie erlaubt eine grundsätzlich andere Herangehensweise für die Aufstellung von Regeln: es werden Klassifizierungen (an den Produkten) vorgenommen, die ein Verkäufer nachvollziehen kann. Im Beispiel des Bierabsatzes werden nur drei Kategorien von Attributen abgeleitet. Es gibt helles oder dunkles Bier, verschiedene Geschmacksarten und jeweils ein unterschiedlich hoher Alkoholgehalt. Jedes Bier (Objekt) wird auf diese Weise beschrieben und unter bestimmten Bedingungen, die erfüllt (oder nicht) sein müssen - als Empfehlung behandelt. Das sieht dann für das (mir unbekannte) Bier mit dem klangvollen Namen Mendocino White Hawk IPA so aus:

rule "Mendocino White Hawk IPA Rule"

 when

   $beer: BeerPreference(color == Color.LIGHT,

   tastes contains Taste.HOPPY,

   tastes contains Taste.AGGRESSIVE_HOPS,

   tastes excludes Taste.SPICY,

   tastes excludes Taste.COFFEE)

then

   $beer.setRecommendedBeer("Mendocino White Hawk IPA");

end

Die Ausgabe einer Regel geschieht sozusagen wie von der anderen Seite aufgezogen. Nicht die Beziehungen werden definiert, sondern die Objekte.
Der Einsatz einer Rules-Engine reduziert nicht wirkliche Komplexität, sondern erlaubt alltagssprachliches Definieren und den Einsatz flexibler Regeln vor allem für Nichtprogrammierer. Sie sind dann extrem effizient, wenn Dinge sich sehr häufig und/oder schnell ändern.

Den recht unterhaltsamen Artikel vor allem mit weiterführender technische Tiefe kann man hier Curtail complexity with a rules engine nachlesen.