Regelwerk

Vor einigen Tagen fand ich einen Artikel, der auf sehr anschauliche Weise erklärte, weshalb der Business-Rules-Ansatz so wichtig ist. Es sind immer noch wenige Experten, die von jener Relevanz des Business Rules Managements (BRM) ausgehen. Drei entscheidende Fragen werden sich all jene stellen, die ernsthaft über einen Einsatz von BRM sprich automatisierbaren Geschäftsregeln nachdenken:

1. Was sind die Vorteile von Business Rules, die ein zusätzliches Investment rechtfertigen?
2. Warum sollte man nicht nur die Regeln codieren?
3. Werden die Regeln verlässlich funktionieren und vor allem sich reibungslos in das System integrieren lassen?

Chris Berg von ILOG zählt folgende, knapp zusammengefasste Vorteile für den Einsatz von BRE auf: Verkapselung (technische Separation einzelner Geschäftsvorgänge deren Herauslösung aus dem Software-Code der operativen Systeme), Vereinfachung der Abläufe, Sichtbarkeit der Prozesse, verbesserte Zusammenarbeit und mehr Flexibiltitä durch die verteilte Ausführung. Dieser Zusammenfassung fügt James Taylor in seinem interessanten Blogeintrag noch einige Anmerkungen hinzu, die die Sache noch deutlicher auf den Punkt bringen.

• Die Trennung der Entscheidungslogik von den “mechanischer Umsetzung” gibt dem Business (und seinen Verantwortlichen) endlich ihre Flexibilität für die täglichen Anforderungen zurück. Änderungen in den Geschäftsprozessen haben nur noch geringen bis gar keinen Einfluss auf das IT-System selbst.
• Geschäftsregeln sind im Normalfall für Businessverantwortliche viel verständlicher - es ist quasi ja ihre Alltagssprache. Dieses verbesserte Verständnis hat natürlich Auswirkungen auf die Kommunikation zwischen Business und IT. Es gibt weniger Missverständnisse, die FehliInterpretationen befördern. Alles in allem lassen sich Projekte reibungsloser und ergo schneller umsetzen.
• Geschäftsregeln kann man leicht aufsplitten für verschiedene Gruppen mit einem jeweils anderen Fokus auf das Business. Damit werden auch die Rollen für die einzelnen Geschäftsprozesse transparenter.
• BRM-Systeme führen interaktive Tests und Simulationen im laufenden Betrieb durch, für die Entwicklung und Dokumentation stehen unterstütztend Flussdiagramme, Verweiswerkzeuge und Reporting-Funktionen zur Verfügung
• BRM-Systeme verfügen über vordefinierte Funktionen für den Austausch von Regeln, um Änderungen im laufenden Betrieb, sprich ohne Unterbrechungen durchführen zu können.
• Business Rules sind sehr einfach terminierbar. Sie können sozusagen mit dem Kalender geplant und ausgeführt werden.
• Vorlagen für die Administration der Regeln können die einzelnen Anwender / Owner übersichtlich selbst erstellen, einsehen oder ändern.
• Die Rule Engine - das Kraftwerk eines BRM-Systems - kann aus einer Fülle von Regeln sehr schnell die geeignete, fallbezogene Regel herausfinden.

Man sollte nun allerdings nicht annehmen, wie es nach Aussagen von James Taylor wohl nicht wenige glauben, dass Business Rules Management ohne Entwickler auskämen. BRM ist eine Gemeinschaftsarbeit von Business-Anwendern, die ihr Geschäft kennen und es anpassen wollen und IT-Entwicklern, die immer noch dafür sorgen müssen, dass die Systeme ohne Einschränkungen funktionieren. Auch wenn die Regeln nicht mehr selbst in den Systemen fixiert sind. Das, was durch die Business Rules ausgelöst wird, ist immer noch in und durch Software realisiert.
BRM erlaubt es, dass Entscheide und Regeln aus unterschiedlichen Perspektiven betrachtet werden. Es gibt immer noch eine technische Komponente darin - auch wenn der Fokus sich in Richtung Business-Perspektive verschoben hat. Notwendig wurde das durch in den letzten Jahren forschreitende Entwicklung von komplexen System-Monolithen in der IT. Bei geringfügigen Änderungen in den Abläufen oder ihren Bedingungen mussten ganze Heerscharen von Programmieren begezogen werden. Hier setzt BRM an. Es gilt Entscheidungsgrundlagen aus dem Code herauszulösen, um eine den Märkten angemessene Flexibilität in den Chefetagen zurückzugewinnen. Ein Business-Rules-Ansatz entschärft die Differenz von Business- und IT-Perspektive, denn beide Seiten können ihre Perspektive der jeweils anderen nur schlecht vermitteln. Taylor fasst das super zusammen:

Business users are at the mercy of regulations, court rulings and business policies that must be enforced. They must also respond to an ever-changing business and competitive environment. This often means they can’t stabilize their requirements or explain them easily to developers – legal or business jargon does not always map well to Java code! Meanwhile the developers typically don’t understand the regulations or business environment well enough and so can’t develop necessary applications, systems and updates fast enough.

In der Regel gibt es ein Problem, dass man aus zwei verschiedenen Perspektiven betrachtet. Eben aus IT- oder Business-Sicht. BRM hat sich zum Ziel gesetzt, für dieses eine Problem eine Lösung zu finden, die aus beiden Perspektiven sinnvoll ist. Der Einsatz eines BRM-System bedeutet, die Businesslogik so abzubilden, dass das Business sie jederzeit modifizieren kann - immer hautnah am tagespolitiischen Geschehen. Doch wie teilen sich die beiden Parteien sinnvoll ihre Verantwortlichkeiten?

• Businessanwender müssen folgende Dinge nicht können: Objekte oder Schnittstellen des bestehenden Systems verwalten oder Programmcode bereitstellen. - Das ist immer noch und unbestritten Sache der IT.
• IT schreibt die technisch komplexen Regeln in einer Syntax, die von Businessanwendern überprüfbar ist.
• Kompetente Anwender schreiben die Vorschriften als Regeln in einer verständlichen, nicht technischen Sprache.
• Die IT entwickelt Vorlagen um Regeln einzuschränken, damit sie von Businessanwendern geändert werden können. Diese Vorlagen schränken Probleme ein und erhöhen die Flexibiltät für das Business.
• IT gwährleistet eine flexible Systemarchitektur, um die durch Regeln entstehenden Anwendungen einfach ins System integrieren zu können.
• Businessanwender sind nunmehr für die Pflege und Wartung der Regeln verantwortlich. Das entlastet die IT von kurzfristigen Systemupdates. Damit hat die IT wieder mehr Zeit für die Entwicklung.

Fazit: Business Rules bieten sowohl Entwicklern als auch den Managern Vorteile in gleichem Masse. Anwender ohne technischen Hintergrund haben mit ihnen endlich die Möglichkeit, sich am Design der für sie gedachten Applikationen zu beteiligen. Auf der anderen Seite ist es für Entwickler einfacher, Anwendungen zu bauen, die ihre Benutzer in die Selbständigkeit entlassen. Die haben dann endlich auch Zeit für die wichtigen Dinge des Tages.