Software für das Management von Business Rules gibt klare Anweisungen an Applikationssoftware
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 Anforderungen 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 (siehe Tabelle "Herstellervielfalt"). Neuerdings hat auch Microsoft mit seiner Integrationssoftware "Biztalk Server 2004" ein Framework für die Definition von Regeln vorgestellt. Die Produkte weisen zum Teil erhebliche Unterschiede auf, insbesondere was die Eingabe (Spreadsheet, GUI, Shell), die Formulierung 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 und Angebotserstellung von Kreditanträgen, 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 gab jetzt 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 benö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 Laut Sacha Strathmann, Principal Consultant bei der Entory 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 aber 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.
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 250 000 bis 750 000 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.