Managen von Geschäftsregeln und Prozessen in einer SOA
Eine SOA regelt das Zusammenspiel von Prozessen und Regeln neu. Bisher galt das von der Gartner Group aufgestellte Dogma, dass zwar Regeln und Prozesse strikt voneinander zu trennen sind, aber dass Prozessmaschinen und Regelmaschinen miteinander zu integrieren seien. In einer SOA geht man einen Schritt weiter. Statt einer Integration proprietärer BPM und BRM Technologien (BRM = Business Rules Management) fasst man im Sinne einer Service-Orientierung die Regeln als Services auf, die von der Prozessmaschine orchestriert werden. So erhält man Rule-Services als eine Kategorie von Services. Ein Rule-Service kann als Kapselung komplexer Regeln verstanden werden. Damit wird eine Regelmaschine zum Bestandteil einer SOA Infrastruktur und die Entscheidungslogik wird Teilmenge der Geschäftslogik. Regeln werden so in gleicher Weise wie auch andere Services durch die Prozessmaschine orchestriert. Das ist absolut konsequent und zeigt die Eleganz des SOA Ansatzes.
Business Rules Management (BRM) – Agilität schaffen und managen
Regeln müssen wie Prozesse gemanagt werden. BRM beschreibt, Regeln zu planen, zu modellieren, zu implementieren, zu überwachen und zu steuern. Hier kommt es besonders auf die Zusammenarbeit zwischen Fachabteilung und IT an. In der Vergangenheit lief die beim Ändern von Softwaresystemen release-getrieben ab. Die Fachabteilung stellte Anforderungen, die die IT mittels eines neuen Release umsetzte. Das ist selbst im BPM noch die Regel, wo heute typischerweise eine strenge Trennung zwischen dem fachlichen und technischen Design von Prozessmodellen gemacht wird. Hier ist man im BRM schon einen Schritt weiter in Richtung echter Kollaboration Business/IT. Führende BRM Systeme bieten Werkzeuge an, mit deren Hilfe Mitarbeiter aus den Fachabteilungen aktiv im kollaborativen Prozess von BRM mitwirken. Das macht man beispielsweise bei der PostFinance in der Anwendung des Geldwäschegesetzes beim Zahlungsverkehr in der Schweiz und bei einem Frühwarnsystem im Risikomanagement bei der HVB. In beiden Fällen werden Regeln tagesgenau durch die Fachabteilungen geändert, getestet und implementiert.
Das Ende des Software-Releasezyklus?
Der klassische Software-Releasezyklus von Konzeption, Realisierung, Test mit begleitender Qualitätssicherung und Dokumentation ändert sich im BRM. Die Konzeptionsphase wird deutlich verkürzt, da direkt mit der toolgestützten Modellierung der Geschäftsregeln begonnen wird. Bereits bei der Modellierung werden die Testdaten und erwarteten Referenzergebnisse definiert. Dieser Ansatz ermöglicht nicht nur ein iteratives Vorgehen bei der Definition der Geschäftsregeln, sondern bildet auch die Grundlage für automatisierte Testverfahren. Die Codierung der Geschäftsregeln entfällt komplett, und damit auch die zeitraubenden Abstimmungsschleifen zwischen Fachbereich und IT bis die Geschäftsregeln fehlerfrei implementiert sind.
Statt eines traditionellen Releaseverfahrens kommen wir so zu einem dynamischen, kontinuierlichen Lebenszyklus-Management der Geschäftsregeln. Interessanterweise entspricht dieses Verfahren einem der Grundprinzipien des Web 2.0. Eine der Thesen von Tim O’Reilly, der den Begriff geprägt hat, besagt ja: „End of the Software Release Cycle“ Mit unserem BRM Kollaborationsansatz erfüllen wir dieses neue Paradigma. Hier steckt enormes Nutzenpotential. Vom Managen des Lebenszyklus von Geschäftsregeln sollten wir nun im nächsten Schritt diesen Ansatz auf das Managen des Lebenszyklus von Geschäftsprozessen und von Services in einer SOA übertragen: Web 2.0 trifft SOA.
Dr. Wolfgang Martin
Wolfgang Martin Team – S.A.R.L. Martin, Annecy
Auf jeden Fall kann ich die Beobachtungen von Herrn Dr. Martin nur unterstützen. Als Implementierungspartner von salesforce.com sehen wir bei GMP hier jährlich zwischen 2-4 Releases mit oft deutlichen Verbesserungen. Für den Kunden hat diese insoweit nur Auswirkungen, dass er darüber nachdenken muss, was er denn davon zusätzlich nutzen will.
Bei all diesen Weiterentwicklungen bleiben seine individuellen Einstellungen, auch Schnittstellen zu anderen Systemen, stets unberührt. Somit bekommt der Kunde erstmalig das Gefühl, dass er Wissen um seine Prozesse kontinuierlich aufbauen und weiterentwickeln kann. Dies ohne der Sorge, mit einem Major-Release wieder quasi “zurück auf los” gehen zu müssen. Gerade diese Flexibilität wird in Zukunft ein “knock-out” Kriterium sein, wenn es um Entscheidungen zur Verbesserung der eigenen Prozesse geht.