Das Ende des Software-Release-Zyklus?

BRM-Services lohnen sich tatsächlich dort, wo eine große Menge an Regeln technisch unabhängig von umgebender IT-Software ins Geschehen eintritt. Rules sind also keine klassische Lösung für die Konfiguration von IP-Adressen und Ports oder das Parsen von verschlüsselten Daten oder Logiken zur Erzeugung von Check-Summen. Business Rules sind Geschäftsregeln, weil es genau die Regeln sind, die sich gerne in Prosatexten mit Entscheidungstabellen wiederfinden oder als „undokumentierbare“ oder sogar politisch oftmals „geheime“ Logiken beschrieben werden, die man dem artfremden IT-Dienstleister eigentlich nur ungern offenbaren will – non-disclosure agreement hin oder her. Somit finden wir hier oftmals Marketinginstrumente wie Filterung oder Sortierungen von Angebotslisten zur Unterstützung von Topsellern und Superpreisangeboten. Wir reden über Preiskalkulationsmodelle zur Optimierung von Angebot und Nachfrage, wir sprechen über Risiko- und Tarifermittlungsmodelle für den Verkauf von Dienstleistungen. Wir finden Marktanalysen und Produktoptimierungen beispielsweise in allen Bereichen des Dienstleistungssektors von Großbanken und Versicherungen bis hin zu kleineren Webportalen und Internetanbietern. In diesen Fällen identifizieren Kunden mit dem IT-Berater ihre „Hotspots“ hoher Dynamik und lassen sich vom IT-Dienstleister dedizierte Services innerhalb ihrer SOA schaffen, die ihnen unmittelbaren Zugang zu diesen Logiken innerhalb des Geschäftsprozesses verschaffen.

Im Falle einer Software wie Visual Rules kann es bedeuten, sich nach kurzer Analyse und einem Vorgespräch, gemeinsam an die Modellierung von Regeln in einer clientseitigen Eclipse-Umgebung zu machen und dort in Regelbäumen die eigenen Entscheidungsschritte niederzulegen. Testskripte und Dokumentationsmöglichkeiten heben den daraus generierten Java- oder beispielsweise COBOL-Code auf eine Stufe der Testsicherung und Dokumentationsqualität wie sie innerhalb der reinen Programmierung selten mit Javadoc und JUnit-Tests erreichbar sind bzw. praktiziert werden. In wenigen Knopfdrucken ist die neue Implementierung hinter der Web-Service-Schnittstelle auf einen Server deployt und bereits auf Wunsch einsatzbereit.

Das Ende des Software-Release-Zyklus?

Der klassische Software-Release-Zyklus von Konzeption, Realisierung, Test mit begleitender Qualitätssicherung und Dokumentation ändert sich wie wir gesehen haben beim Einsatz eines BRM Systems. Die Konzeptionsphase wird deutlich verkürzt, da direkt mit der Tool-gestü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 – was insbesondere bei komplexen Regeln unverzichtbar ist -, sondern bildet auch die Grundlage für die automatisierten Testverfahren im TQM. Die Codierung der Geschäftsregeln entfällt komplett, und damit auch die Abstimmungsschleifen zwischen Fachbereich und IT, die benötigt werden, bis die Geschäftsregeln fehlerfrei implementiert sind. Statt eines traditionellen Release-Verfahrens kommen wir so zu einem dynamischen, kontinuierlichen Lebenszyklusmanagement der Geschäftsregeln.

Schneller ROI oder Marketinggag?

Natürlich gehört es sich auch bei BRMS wie bei jeder Produktlinie und Geschäftsentscheidung, Kosten und Nutzen gegenüber zu stellen. Sprich: haben wir ein tatsächliches Problem, das mit einem solchen Tool gelöst werden kann oder meinen wir, ein solches bei uns entdecken zu können, weil uns eine Produktbroschüre Probleme beschreibt, die wir assoziativ auf unseren Kontext übertragen und damit bei uns auch scheinbar vorliegen?

Einer IDC-Studie zufolge werden immerhin 9% der Geschäftsregeln täglich, immerhin weitere 17% wöchentlich und nochmals 17% monatlich geändert – soweit das denn auch geht. Somit haben wir schon gut 45% der Regeln, die sich innerhalb eines angenommenen Release-Zyklus von Software von mindestens einem Monat ändern würden. Klar ist auch, was viele beim Thema Software selbst erfahren: die Dokumente und die vom Kunden beschriebenen Logiken sind umso überholter, je mehr Zeit zwischen Analyse und In-Produktionsnahme vergeht. Release-Zykluslänge und Menge der Änderungen sind also essenzielle Gegenspieler von Flexibilität im Geschäft.

Wichtig ist hier der Einsatz von Business Rules, SOA und Regeln dort ansetzen zu lassen, wo auch der häufigste Änderungsaufwand entsteht bzw. der Return-on-Investment auf Grund der kürzeren Release-Zyklen und des schnelleren Time-to-Market der eigenen Firmenphilosophie und -strategie auch wirklich sichtbar wird. Wir sprechen hier auch von „Continuous Integration“ als Vorgehensmodell: Regeln lassen sich kurzfristig ergänzen und modifizieren; Tägliche Releases ermöglichen kontinuierliche Weiterentwicklung; Codegenerierung, Dokumentation und Deployment werden automatisiert. Ein falsch oder nicht angewandtes Tool bringt natürlich auch keinen strategischen Vorteil.

Ein hoher Grad an Automatisierung ist aber – und da muss man letztendlich natürlich Realist bleiben – nur dann möglich, wenn der Anwender die Regelmaschine optimal zum Einsatz bringen kann. Bei komplexen Szenarien und neuen Produktteilen bedeutet das ggf. Consulting-Support beim „Laufen lernen“ und eine klare Etablierung von Geschäftsprozessen, Aufgabenträgern und Release-Zyklus-Entscheidungen. Denn schnell ist zu Beginn auf diese Art und Weise auch mal unbedachte Logik in Produktion gebracht, die der zuvor aufwändigere und althergebrachte Release-Zyklus-Prozess durch die Menge der beteiligten und reviewenden Personen manchmal verhinderte. Somit bleiben auch Fallstricke bei diesem vollständig anderen Umgang mit Software. Ist die erste Hürde und Eingewöhnung mit optimaler Unterstützung aber genommen, werden ggf. schnell hohe Einsparungspotenziale durch die engere Zusammenarbeit aufgedeckt.

Innovations veröffentlichte 2007 Informationen von vier ihrer international operierenden Kunden, die in verschiedenen Szenarien zwischen 25% und 70% Einsparung diagnostizierten. Wenig überraschend findet sich das größte Potenzial bei Änderungsaktivitäten und deren Implementierung, die mit den klassischen Datenbankschaltern und Property-Files zur Konfiguration der Software nur noch wenig gemeinsam haben.

Abb. 2: Gehobene Einsparungspotenziale

Wer der Überzeugung ist, auch solche Stellen in seiner Software identifiziert zu haben, die es Wert sind flexibler und dynamischer gestaltet zu werden, hat mit einem Business-Rules-Management-System nicht nur im Kontext einer SOA eine Chance, wirtschaftliche Potenziale zu heben. Selbst wer unsicher ist, den Test ist es allemal wert.

BRMS rationalisiert zudem den klassischen Entwickler nicht etwa weg, sondern gibt dem IT-Dienstleister die Möglichkeit, seinem Fachbereich optimalere und agilere Entwicklungsprozesse anzubieten, um Wettbewerbsvorteile zu erringen und bestehende Software und Modifikationen besser und schneller zu harmonisieren. Er stärkt damit seine eigene Position und die seiner Kunden im Markt.

Dr. Wolfgang Martin ist unabhängiger Analyst und europäischer Experte in den Bereichen BI/CPM, Business Integration, SOA und CRM. Er ist Koautor und Herausgeber von Büchern und Fachartikeln zu den genannten Themen.
Thomas Cotic ist Gründungsmitglied und Geschäftsführer der Innovations Softwaretechnologie GmbH, die u.a. Beratung zum Thema BRM und den Einsatz ihres Produktes Visual Rules anbietet.
Lars Wunderlich ist Systemarchitekt im B2B-Bereich der TUI InfoTec GmbH und beschäftigt sich mit der Umsetzung von Architekturen im Java-Enterprise-Umfeld. Er ist Autor zahlreicher Publikationen im Bereich Java.
Kommentare

Schreibe einen Kommentar

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