Neue Anforderungen, Richtlinien oder Strategien lassen sich nur dann schnell in den eigenen Anwendungen und Prozessen abbilden, wenn die beteiligten Systeme dies erlauben. Das ist jedoch oft nicht der Fall. Vielmehr finden sich die anzupassenden Geschäftsregeln "hart codiert" und meist verteilt in diverser Unternehmenssoftware und Datenbanklösungen wieder. Grund hierfür ist, dass Anwendungen über die Zeit meist für konkrete Anforderungen entstanden sind und viele, den Betrieb betreffende Geschäftsregeln nicht berücksichtigt oder während der Entwurfsphase noch nicht benötigt wurden. Durch diese Mängel sind Teile der Software immer wieder aufwändig anzupassen.
Die Problematik zeigt sich auch bei der Änderung von Geschäftsregeln in datenbankzentrierten Anwendungen. Der Administrator kann das Datenmodell modifizieren, Einschränkungen als Text oder Kommentar erfassen oder die neuen Anforderungen gleich an die Entwicklungsabteilung weiterleiten. Doch alle Optionen haben Nachteile. So zieht jede Änderung im Datenmodell in der Regel Änderungen der darauf zugreifenden Anwendung nach sich. Ebenso bedeutet eine Dokumentation der Einschränkung oder Regel noch lange nicht, dass sie in einer Anwendung oder einem Workflow befolgt wird. Soll gar neu entwickelt werden, wären die Regeln in jeder auf die Datenbank zugreifenden Anwendung zu berücksichtigen. Die Business-Logik läge damit wieder dezentral in den Applikationen und könnte nicht zentral verwaltet und gepflegt werden.
Mit den alternativ gepriesenen Ansätzen zur Flexibilisierung von Unternehmensanwendungen hat in den letzten zwei Jahren das Thema Business-Rules-Management (BRM) wieder auf die Agenda von IT-Projekten zurückgefunden. Ziel ist es, die Geschäftslogik von vornherein von der Datenzugriffs-, Prozess- und Präsentationsschicht zu isolieren und an zentraler Stelle jederzeit für neue Anforderungen und andere Anwendungen zur Verfügung zu stellen. Die Definition, Verwaltung und Ausführung der fachlichen Geschäftsregeln erfolgt mit Hilfe spezieller BRM-Software, die im Kern aus einer Business Rules Engine besteht, die die Regeln verarbeitet. Der typische Anwender ist nicht der Entwickler, sondern der geschulte Business-Analyst, der die Geschäftsprozesse kennt und seine Aufträge von den Fachabteilungen und dem Management erhält.
Neu ist dieser Ansatz nicht. Schon seit den 80er Jahren wurde mit Rules Engines, die damals vor allem aus Expertensystemen für künstliche Intelligenz hervorgingen, experimentiert und gearbeitet. Doch diese erste Produktgeneration benötigte teure Hardware, skalierte schlecht, war kaum in bestehende Anwendungen zu integrieren und stellte Entwickler und Analysten vor hochkomplexe Aufgaben. Die dabei entstehenden zahlreichen Regeln ließen sich kaum mehr verwalten. Erst ein 1993 von der IBM-Community gestartetes Projekt zur formalisierten Identifizierung und Beschreibung von Geschäftsregeln sowie die nachfolgende Gründung der Business Rules Group 1994 sollten der Auslöser für zahlreiche Produktentwicklungen und die Entstehung eines eigenen Markts für BRM-Software sein.
Viel Konkurrenz in der jungen Szene
Heute konkurrieren eine ganze Reihe kommerzieller Anbieter, Dienstleister und Open-Source-Projekte miteinander. Weitere Neuzugänge, aber auch erste Übernahmen sind zu verzeichnen. Zu den bekanntesten Herstellern zählen Ilog, Fair Issac, Computer Associates, Corticon, PST oder OPSJ. Die Produkte weisen zum Teil erhebliche Unterschiede auf, insbesondere was die Eingabe (Spreadsheet, GUI, Shell), die For- mulierung und die Verwaltung von Regeln (Test, Debugging) sowie die Performance bei großen Benutzerzahlen betrifft. Laut Wilfrid Vogel, Geschäftsführer von Ilog Deutschland, sollten sich zudem Regeln unbedingt im laufenden Betrieb einsetzen lassen, da manche Anwendungen ständig verfügbar sein müssten.
Die Analysen von Gartner halten die Regeltechnik grundsätzlich für ausgereift. Die Produkte verwenden Algorithmen wie "Rete" und unterstützen typische Verfahren zur Abfrage der Wissensbasis wie die Rückwärts- oder Vorwärtsverkettung. Rules Engines sind heute auf allen gängigen Plattformen zu finden, sind performant und leichter als ihre Vorgänger zu handhaben. Auch lassen sie sich über Schnittstellen mit Infrastrukturlösungen und Unternehmenssoftware kombinieren. Ebenso finden sich mittlerweile in manchen Angeboten umfangreiche Features für die Verwaltung und das Auditing von Geschäftsregeln. Produkte wie die von Ilog oder Fair Issac gestatten es zudem, Regeln alternativ zu spezieller Regelsyntax wie OPS oder Clips in einem Business-Jargon zu formulieren.
Projekt mit hoher strategischer Bedeutung
Immer mehr Unternehmen formulieren heute eine Strategie für den Umgang mit Geschäftsregeln. Vorreiter sind Finanzdienstleister und Versicherungen, aber auch TK-Unternehmen, Fluggesellschaften, Technologiekonzerne, Automobilhersteller, die öffentliche Hand und die Industriefertiger haben das Thema für sich entdeckt. Viele dieser Projekte sind indes aufgrund ihrer hohen strategischen Bedeutung nur ansatzweise in der Öffentlichkeit bekannt. Die meist umfangreichen Regelsysteme automatisieren dynamische und oft komplexe Prozesse wie beispielsweise die Prüfung von Kreditanträgen, die Kalkulation von Versicherungen, Flugreisen oder die Auftragsbearbeitung und Tarifkonfiguration im Mobilfunk. Oder sie kontrollieren den Aktienhandel, überwachen Netzwerke und helfen bei der Steuerung von Abläufen in Flughäfen oder in der Fertigung.
Für letzteren Anwendungsfall gibt die Dillinger Hütte ein Beispiel. Das Unternehmen fertigt Grobbleche, die beispielsweise im Stahlhochbau, Maschinen- und Schiffbau sowie bei der Konstruktion von Bohrinseln und Tunneln und in der Herstellung von Baggerschaufeln verwendet werden. Für die Fertigung der Bleche müssen jeden Monat dabei bis zu 1,5 Millionen Produktionsschritte koordiniert werden. Die dazugehörigen komplexen Regeln für die Fertigungsprozesse mussten hierbei bis dato von der IT in ein eigenes System zeitaufwändig einprogrammiert werden. Der Stahlerzeuger suchte daher nach einer flexibleren Lösung, um die Walzsysteme effektiver auszunutzen.
Die Wahl fiel auf das BRM-System "Jrules" von Ilog, das heute die wichtigsten Fertigungslinien im Walzwerk steuert. Prozesse und Produktionsschritte lassen sich nun in Echtzeit an geänderte Rahmenbedingungen anpassen und erlauben eine flexiblere Fertigungsplanung. Dabei werden neben Kundenanforderungen auch spezielle Qualitätsprüfungen und -prozesse, Änderungen an Maschinen und bestimmte Ausnahmefälle berücksichtigt. Die Geschäftsregeln würden laut Peter Zell, Projektleiter bei der Dillinger Hütte, in einem lesbaren Format dargestellt und seien daher leicht von den Experten in der Produktion und der Qualitätssicherung zu ändern. "Wir können jetzt schnell und flexibel unsere Fertigungsprozesse anpassen, sobald die Produktionsbedingungen sich ändern." Zudem konnte die Ausschussquote gesenkt und die Produktionszeit insgesamt verkürzt werden.
Die technischen Ausprägungen von BPM
Rules Engines lassen sich entweder als Teil von Entwicklungsprojekten oder als Erweiterung von Integrationslösungen für Business-Process-Management (BPM) implementieren. Bei der Entwicklung mit Rules Engines gibt es wiederum zwei Hauptausprägungen: "Stand alone" oder als Komponente. Erstere bringt alles mit, um eigenständig betrieben zu werden, während Rules-Engines der Gattung "Komponente" einen Applikations-Server für den Betrieb be- nötigen. Von anderen Anwendungen werden Rules Engines auf verschiedene Weisen angesprochen, so beispielsweise mittels Java-RMI (RMI = Remote Methode Invocation) innerhalb eines Applikations-Servers, wenn die Rules Engine als Komponente dort läuft. Ein Zugriff von außen kann beispielsweise durch Web-Services oder XML geschehen.
BPM-Produkte ihrerseits binden die Regeln als (Java-)Bibliothek ein oder greifen über eine Schnittstelle auf einen mit einer Rules Engine ausgestatteten Applikations-Server zu. Diese Kombination der beiden Produktkategorien hat Vorteile: "Ich glaube, dass jetzt auf Architekturebene langsam die Erkenntnis reift, dass man nicht alles mit einem grafischen Modellierungswerkzeug in einem BPM-Werkzeug darstellen kann, sondern aus Gründen der Flexibilität auch Regelsätze braucht", meint Sascha Strathmann, Principal Consultant bei der En- tory AG in Ettlingen. So könnten Regeln an bestimmten Knoten im Prozessmodell hinterlegt sein und quasi als Mikroprozess einem Geschäftsprozess eine andere Ausprägung und Granularität geben. "Ein Unternehmen kann beispielsweise ein neues Produkt einfügen, ohne die anderen Prozesse verändern zu müssen, und wird dadurch agiler." Zudem würden die bisherigen Prozessmodelle durch diese Gliederung übersichtlicher und für die Fachabteilung besser nachvollziehbar. Rules Engines helfen demnach, den Prozessfluss von den Entscheidungsregeln zu trennen. Sie ersetzen aber keine bisherigen Produkte für Workflow, BPM oder Enterprise Application Integration (EAI). Marktbeobachter rechnen jedoch damit, dass sich schon in den nächsten Jahren die Produktkategorien zunehmend überlappen. Schon heute gibt es zahlreiche Kooperationen zwischen den Lagern.
Für den Architekten ist die Definition von Regeln und (allgemeinen) Abläufen im Prozessmodell eine komplexe Aufgabe. So müssen beispielsweise die Regelsätze, die von verschiedenen Anwendungen in unterschiedlicher Anzahl stammen, kombiniert werden. Zugleich ist für die Arbeit mit Rules Engines Fachwissen zur Definition der Regeln und technisches Wissen für deren Implementierung notwendig. Das Fachwissen wird eher von den Analysten als von der Fachabteilung bereitgestellt, das technische Wissen steuert die IT bei. Beide Parteien müssen daher laut Strathmann zusammenarbeiten. Grundlage hierfür sind oft Excel-Sheets der Fachabteilung beziehungsweise der Analysten, da sich diese Form der Modellierung in Firmen erstaunlich großer Beliebtheit erfreut. "Wahrscheinlich spielt hier auch die schnelle und einfache Umsetzung mittels Excel eine große Rolle." Dann ist es Aufgabe der Experten (Analyst und IT-Fachmann), die Informationen in die neue Rules Engine zu übertragen.
Alternativ finden sich Rules Engines heute eingebettet in Standardsoftware für ERP, CRM oder SCM, ohne dass dies der Anwender immer weiß. Der Benutzer arbeitet dabei mit Masken, die sich je nach Eingabe verändern, während im Hintergrund die Regeln abgearbeitet werden. Allerdings beziehen sich die Regeln laut Strathmann nur auf die Funktionen und die Konfiguration der Standardsoftware und lassen sich nicht für andere Einsatzgebiete außerhalb dieser Umgebung nutzen.
Wann sich Produkte rechnen
Bleibt die Frage nach den Kosten, vor allem bei Eigenentwicklungen. Diese sind laut Ilog-Geschäftsführer Vogel aufgrund der Vielfalt der Szenarien und der unterschiedlichen Projektumfänge schwer zu berechnen. Anwender sollten sich aber auf Investitionen von durchschnittlich 250000 bis 750000 Euro einstellen. Grundsätzlich gebe der Einsatz von Rules Engines dann Sinn, wenn Regeln in größerer Zahl oft geändert werden müssen. "Häufig rechnet sich ein Produkt allein durch die Änderungsrate, Vielzahl der Regeln und Zahl der Transaktionen, die über die Engine laufen." Dennoch sind die Aufwandberechnungen nicht immer klar. Manchmal steht dies aber auch nicht im Vordergrund, vor allem wenn gesetzliche Auflagen schnell in den Anwendungen umzusetzen sind.
Business Rules
Laut der "Business Rules Group" gibt es zwei formale Definitionen: Aus der Geschäftssicht ist eine Business Rule eine Richtlinie, die das Geschäftsverhalten beeinflusst oder leitet, um damit die Geschäftsstrategie, die aus Opportunitäten, Gefahren, Stärken und Schwächen entstanden ist, zu unterstützen. Aus der IT-Sicht ist eine Business Rule eine Anweisung, die einen Aspekt des Geschäftes definiert oder bedingt; sie bezweckt, die Geschäftsstruktur durchzusetzen, das Geschäftsverhalten zu beeinflussen oder es zu kontrollieren.
Fazit
Immer mehr Unternehmen wollen dynamische Prozesse schneller und flexibler anpassen. Business Rules Engines bieten sich hierfür als Werkzeuge an. Sie erfordern zwar viel Know-how von Business-Analysten und IT, sind aber über die Jahre auch technisch gereift und heute leichter zu bedienen. Marktbeobachter erwarten, dass Rules Engines schon bald zum festen Bestandteil von Integrations- und Standardsoftware werden.
Fehlende Standards
Einheitliche Standards für die Formulierung und den Austausch von Business Rules sind bis heute nicht verfügbar. Alle Produkte verwenden daher letztlich einen proprietären Ansatz. Zu den wichtigsten Initiativen in der Industrie zählen die Busi- ness Rules Markup Language (BRML), die ein in XML beschriebenes, Engine-neutrales Austauschformat für Regeln definiert und aus den "Common-Rules"-Spezfikationen für E-Commerce der IBM hervorgegangen ist, sowie die Rule Markup Language (RuleML), die eine neutrale Beschreibung von Regeln mit Hilfe von XML anstrebt und derzeit in der Version 0.8 vorliegt.
Daneben gibt es mit dem Wortungetüm Defense Advanced Research Projects Agency Agent Markup Language (DAML) eine XML-Spezifikation, die sich vor allem mit der Einführung von Regelanweisungen als "Tags" in XML-Dokumenten beschäftigt, die sich von einer Rules Engine lesen lassen. Speziell für Finanzprodukte ist ferner die XML-basierende Sprache Financial Products Markup Language (FPML) vorgeschlagen worden. Eine wichtige Entwicklung im Java-Umfeld zeichnet sich schließlich mit dem Java Specification Request 94 (JSR 94) im Rahmen des Standardisierungsverfahrens ab. Die gebotenen Klassen javax.rules und javax.rules.admin sollen Teil des Java Development Kit werden und ein einheitliches API für die Einbindung von Rules Engines bieten. Momentan ist der Funktionsumfang jedoch noch beschränkt.
Unabhängig davon wurden im Industriekonsortium Object Management Group im letzten Jahr zwei weitere Initiativen gestartet. Markus Schacher, Gründer des IT-Dienstleisters Knowgravity in Zürich und Mitglied der Business Rules Group, geht es bei den Vorschlägen zum einen mit "Business Semantics of Business Rules" (BSBR) um die Entwicklung einer von der Implementierung unabhängigen einheitlichen Business-Semantik zur Formulierung von Regeln, die weit über Ansätze wie etwa bei Ilog hinausreichen. Außerdem steht mit "Production Rules" ein weiterer Vorschlag zur Diskussion, der laut Schacher jedoch mit Rule ML konkurriert.
Was der Markt bietet
Hersteller / Produkt / Eigenschaften
Acquire Intelligence / Acquire / BRMS*, das verschiedene Typen von Regeln unterstützt.
Computer Associates / Cleverpath Aion Business Rules Expert / Eines der ersten BRMS mit Spreadsheet-Interface für die Eingabe von Regeln.
Corticon / Corticon Decision Management Software / BRMS mit Spreadsheet-Interface und begrenzten Debugging-Features.
Exsys / Corvid / Produkt für die Wissensverwaltung, das ein BRMS enthält und eineBusiness-Sprache für die Regelbeschreibung bietet.
Fair Issac / Blaze Advisor / BRMS, das eine natürlichsprachliche Syntax verwendet und über zahlreiche Features für Unternehmensprojekte verfügt.
Gensym / G2 / BRMS vor allem für Echtzeitanwendungen, die ein Regelsystem sowieneuronale Netze verwenden sollen.
Haley / unter anderem Authorete, CIA Server, Rete++, Caferete / Authorete dient der Verwaltung und dem Monitoring von Rules, die mit der OPS-Syntax erstellt wurde, die anderen Produkte sind reine Rules Engines.
Ilog / Rules, Jrules / Auf C++ beziehungsweise Java basierendes BRMS, das die weit entwickelte "Business Action Language" verwendet, ein GUI für Analysten bietet undTools für Debugging und Optimierung enthält.
Microsoft / Biztalk 2004 / Software zur Anwendungsintegration, die ein Framework für die Entwicklung von Business-Rules-Anwendungen in "Visual Studio" enthält.
Pegasystems / Pegarules / BRMS, das Templates für die Entwicklung vertikaler Business-Rules- Anwendungen bietet.
Production Systems Technologies / Jess / Kostenlose Java-basierende Rules Engine und Skripting-Umgebung mit einigen Tools für Debugging und Optimierung. Besitzt große Community.
Semantec / IT-Dienstleister, der die Rules Engine des Anbieters ESI verwendet. / Entwicklung von Business-Rules-Anwendungen auf der Basis von Oracle-Datenbanken.
Teckknowledge / Tekportal / BRMS, das mit einer Portalsoftware kommt und sich an Finanzdienstleister richtet.
Versata / Versata Logic Suite / Laufzeit- und Entwicklungs-Framework für Java-Anwendungen, in dem sich Geschäftslogik als Regeln beschreiben lässt.
Tabelle erhebt keinen Anspruch auf Vollständigkeit.
*BRMS: Business-Rules-Management-System