Business Rules Management

Das Ende des Software-Release-Zyklus?

Dr. Wolfgang Martin, Thomas Cotic und Lars Wunderlich

Serviceorientierte Softwareentwicklung, Agilität, Industrialisierung, Softwarefabriken und Geschäftsregel-Modellierung sind Schlagwörter, zu denen man gerne greift, um seine moderne, technische IT-Landschaft zu präsentieren. Wie lässt sich dies nun mit den mehr fachlich orientierten Zielsetzungen schneller Anpassung an Marktbedürfnisse, Restrukturierung der Geschäftsprozesse und kurzen Entwicklungszeiten mit hohem Return-on-Investment in Einklang bringen? Wie man die Dynamik der Marktanforderungen und die Strategie des Unternehmens ohne lange Software-Release-Zyklen optimal aufeinander abstimmt, wird im Folgenden dargelegt.

Immer mehr Unternehmen bezeichnen sich heute als prozessorientiert. Prozessorientierung bedeutet ein konsequentes Denken in Geschäftsprozessen und Geschäftsregeln und damit eine optimale Adressierung der Kundenwünsche. Prozesse basieren auf einer gemeinsamen Steuerung, die die dem Geschäftsprozess-spezifische Logik, wie die Kontrolle des Ablaufs der Prozessaktivitäten, Einhalten von Deadlines und Ausnahmebehandlung, beschreibt. Sie werden softwareseitig, z.B. mittels eines entsprechenden Business Process Management (BPM), implementiert. Über Regeln beschreibt man die Entscheidungslogik, die die prozessübergreifenden Managementpolitiken und Prinzipien darstellt. Sie wird z.B. mit einer Regelmaschine im Rahmen von Business Rules Management (BRM) implementiert. Die Prozess- und die Regelmaschine dienen beide der Modellierung, Ausführung und Governance der entsprechenden Logiken.

Prozesse und Regeln sind zueinander komplementär, denn ein Prozess nutzt typischerweise mehrere Regeln, während eine Regel in verschiedenen Prozessen vorkommen kann. Man sagt, Prozesse stünden zu Regeln in einem Verhältnis von m:n. Daher muss man Prozesslogik und Entscheidungslogik strikt voneinander trennen. So erhält das Business eine transparente Modellierung und Darstellung der Abläufe, Politiken und Prinzipien im Unternehmen. Dies ist die Voraussetzung für Agilität und Industrialisierung.

Agilität bedeutet die Fähigkeit zur Innovation und die Anpassungsfähigkeit der eigenen Geschäftsmodelle. Schnelle Reaktionen sowie pro-aktive Initiativen begeistern und binden Kunden und verblüffen und schlagen Wettbewerber aus dem Feld. Eine immer höhere Marktdynamik und die Einhaltung von Vorschriften sind die treibenden Kräfte für Agilität. Dynamik bedeutet, dass der Lebenszyklus von Prozessen und Regeln immer kürzer wird, also Änderungen in immer schnelleren Zyklen notwendig sind.

Antriebskräfte der heutigen Softwarebranche sind die Forderung zu kontinuierlicher Optimierung und weiterer Kostenreduktion: Die Industrialisierung hilft dabei mittels Automatisierung und Standardisierung. So werden Durchlaufzeiten, Durchlaufvolumen und die Qualität u.a. durch Wiederverwendung gesteigert.

Agilität und Industrialisierung sind aus der Sicht der Implementierung von Prozessen und Regeln mittels Informationstechnologie (IT) eigentlich zwei widersprechende Anforderungen, jedoch wenn Prozesse und Regeln im Kontext einer serviceorientierten Architektur (SOA) gemanagt werden, dann bringt man beide Zielsetzungen mittels eines SOA-basierenden BPM und BRM zusammen. Denn eine SOA ist eine spezielle Architektur, die darauf abzielt, „Software for Change“ zu ermöglichen.

Prozesse und Regeln

Der Begriff der serviceorientierten Architektur geht in viele Richtungen und hat viele Propheten. Oft allerdings liegt einer Palette von omnipotenten Softwarelösungen wie Enterprise Service Bus, Java Business Interfaces, Web Services und Co. letztendlich aber ein einfacher und verständlicher Wunsch zu Grunde: Kunden wollen Wiederverwendung bestehender Softwarefunktionen, sie wünschen sich mehr Kontrolle und gleichzeitig mehr Flexibilität. Die bestehende Software ebenso leicht wie Unternehmensbereiche, Mitarbeiteraufgaben und Geschäftsprozesse umstrukturieren können, um sich besser am Markt auszurichten, ist aber mit statischen Codestrukturen schwer.

Der Kitt schwenkt zu Services zwischen den Anwendungen, gespickt mit technischen Kommunikationsprotokollen wie XML und die Middleware-Technologien, die uns Ausfallsicherheit, Clustersupport und Verschlüsselung bieten. Sind jedoch ohne „Gehirn“ faktisch nutzlos. Anstatt wie früher alle diese Systeme unter eine gemeinsame Kontrolle zu stellen, die allen vorangeschaltet die Überwachung übernimmt, begreifen wir heute die Regeln selbst – und ihre Anwendung als einen Service wie jeden anderen auch. Die Prozessmaschine orchestriert sie, führt also die Regeln mit anderen Services zu einem neuen Gesamtbild zusammen.
Rule-Services werden somit zu einer Art eigener Kategorie von Services. Ein Rule-Service kann als Kapselung komplexer Regeln verstanden werden. Mit anderen Worten, ein Rule-Service kann auch einen anderen Rule-Service in seiner Implementierung unabhängig von einer steuernden SOA aufrufen. Das ist analog dem Unterprozessprinzip im BPM. Damit wird eine Regelmaschine zum Bestandteil einer SOA-Infrastruktur und die Entscheidungslogik wird Teilmenge der Geschäftslogik. So haben die Regeln im Rahmen einer SOA ihre eigene Administration im Repository, in der Registrierung und in der Governance Infrastruktur und basieren auf dem gleichen Businessvokabular wie die Prozesse (Abb. 1).

Abb. 1: SOA-basierte Regeln

Die Verwendung von Regeln als Services zeigt die Eleganz des SOA Ansatzes. Regeln werden eben einmal modelliert und implementiert und stehen dann zur Verwendung in verschiedenen Prozessen zur Verfügung.

Business Rules Management – Agilität schaffen und managen

Der Gewinn der Anwendung eines Business-Rules-Management-Systems im Verhältnis zur traditionellen If-Then-Else-Programmierung ist zweifelsohne die Fähigkeit mit Kunden auf einer gemeinsamen Wellenlänge zu arbeiten und sich bei der Beschreibung von Geschäftslogiken weitgehend unabhängig von den Problemen wie Programmierschlüsselwörtern, Framework-Produkten, Compiles und Unit-Tests zu bewegen. Wir reden in dieser idealisierten Welt nicht mehr über Programmiersprachen und endlose Word-Dokumente mit Anforderungspapier, die zu reviewen und dann aufwändig in Source zu transformieren sind. Analyse, Prototyping, Modellierung, Ausführung und Test gehen fast nahtlos ineinander über. Mit einfach zu erstellenden Regelbäumen unter einer ansprechenden Oberfläche bildet beispielsweise Visual Rules von Innovations für den Endkunden leicht nachvollziehbare Entscheidungsgraphen ab, die in Testläufen dem Kunden bereits direkt nach der gemeinsamen Modellierung plastisch die Konsequenzen seiner Entscheidungen aufzeigen können. Andere Produkte bevorzugen textuelle „Wenn-Dann“-Sätze oder sogar noch niedere Formulierungen, die sehr programmiersprachennah sind.

Allen gemeinsam ist, dass der Kunde in die Lage versetzt werden soll, unmittelbar in der eigenen Wissensdomäne seine Kreativität und sein Know-how einzubringen und auszuleben, ggf. nach kurzer Einarbeitung ohne aktive Unterstützung eines Entwicklers. Der IT-Berater oder -Designer konzentriert seine Arbeit auf die Zurverfügungstellung einer architektonischen Basis und die Öffnung von Schnittstellen zu normalerweise arbeits-, kosten- und änderungsintensiven Bereichen der Applikation bzw. des Geschäftsprozesses. Der Business-Domain-Experte agiert ohne langen Entwicklungsprozess direkt in und an der Entscheidungslogik, die sein Geschäft bewegt. Auf psychologischer Ebene geben wir dem Kunden das Gefühl zurück, nahezu IT-unabhängig direkt auf Marktbedürfnisse reagieren und damit als Auftraggeber der Software auch die „Herrschaft“ über selbige zurückerlangen zu können, die wir ihm mit langen Release-Zyklen und veralteter Software oftmals nehmen.

Rein technisch gesehen, kommt der Rule Service auf Grund seiner Einbettung in die SOA oft als Web-Service-Angebot daher. Die Regeln sind z.B. als JAR verpackt und werden in einem http-Server aufrufbar gemacht.

Geschrieben von
Dr. Wolfgang Martin, Thomas Cotic und Lars Wunderlich
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.