Business Rules Come First

Vor kurzem sprachen Kollegen und ich mit dem Chef-Softwareentwickler einer großen Kundenorganisation über den Fortschritt einer umfassenden Umgestaltung. Unsere Sorge war, ob die Mitglieder des Projektteams eine Frist von etwa neun Monaten für die Lieferung eines großformatigen Prototyps einhalten konnten. Wir hatten gerade mehrere intensive Monate damit verbracht, ein umfassendes Geschäftsmodell zu entwickeln, und sie hatten noch einige Monate Systemdesign vor sich.

Dieser Chefentwickler ist sehr scharfsinnig — keiner, der sich leichtfertig auf irgendeine Antwort einlässt. Lange Zeit sagte er nichts, in Gedanken versunken. Schließlich beäugte er die detaillierten Geschäftsdiagramme, die überall an den Wänden verputzt waren, und sagte: “Wenn wir bereits mit dem Codieren begonnen hätten, würde ich sagen, dass wir überhaupt keine Chance hatten. Aber da wir noch nicht mit dem Codieren begonnen haben, würde ich sagen, dass die Chancen ziemlich gut stehen.”

Ich musste das mehrmals in meinem Kopf durchgehen, bevor ich seine Bedeutung erfasste. “Wenn wir bereits mit dem Codieren begonnen hätten, würde ich sagen, dass wir überhaupt keine Chance hatten.”

Ich wusste, dass er dachte, dass die Anwendungscodierung selbst ziemlich schwierig sein würde. Es würde die Verwendung einer Regel-Engine, eines weltweiten Vertriebsnetzes, grafischer Benutzeroberflächen und einiger bedeutender Middleware beinhalten.

Er sagte, wenn sie alle geschäftlichen Probleme beim Codieren lösen müssten, würden sie es nie rechtzeitig schaffen — oder wahrscheinlich jemals. Da das Projektteam jedoch die schwierigen Geschäftsprobleme im Voraus anpackte (einschließlich der Angabe der Geschäftsregeln), dachte er, dass sie eine ziemlich gute Chance hatten, den Code bis zum Zieldatum abzuschließen.

Im großen und Ganzen geht es beim Business Rule-Ansatz einfach darum, den richtigen Leuten die richtigen Fragen zu stellen. Es gibt nur einen Weg, eine Frist ehrlich einzuhalten — und zwar zuerst das Geschäftsproblem zu lösen.

Geschäftsorientierte IT

In den frühen Tagen des Aufbaus von Geschäftssystemen konnte sich die Geschäftsseite im Wesentlichen zurücklehnen und sie einfach geschehen lassen. Die Vorteile der Automatisierung waren so überzeugend, dass man praktisch nichts falsch machen konnte. Für alle praktischen Zwecke sind Business und IT untrennbar miteinander verbunden. Bei der Durchführung von Projekten wäre es dann der logische Schritt, nahtlose Business / IT-Projektteams zusammenzustellen und diese bei der Entwicklung von Anforderungen einen geschäftsorientierten Ansatz verfolgen zu lassen. Doch viele Unternehmen sind nicht annähernd in der Lage, dies heute zu tun.

Allzu oft produziert die Geschäftsseite immer noch unscharfe, schlecht fokussierte “Anforderungen”, und die IT-Seite macht “Anforderungen” nur ein oder zwei Stufen über der Programmierung. Wie kann diese Kluft zwischen Business-Profis und IT-Profis bei der Entwicklung von Anforderungen beseitigt werden?

Die Antwort ist relativ einfach. Das Unternehmen benötigt einen organisierten Ansatz, der es Geschäftsleuten ermöglicht, die Entwicklung von Anforderungen voranzutreiben. Dieser Ansatz muss eine Roadmap liefern, die zeigt, wie man die richtigen Fragen zu den richtigen Dingen zur richtigen Zeit stellt. Was benötigt wird, ist ein geschäftsorientierter Ansatz.

Bei traditionellen Entwicklungsansätzen geht in der Regel viel bei der Übersetzung von Upfront-Anforderungen in das tatsächlich laufende System verloren. Das Schreiben klarer Geschäftsregeln verbessert jedoch die Kommunikation zwischen der Geschäftsseite und der IT und schlägt eine Brücke zwischen Geschäftsanalyse und Systemdesign. Der Business-Rule-Ansatz hilft, die Anforderungslücke zwischen der Business-Seite und der IT-Seite zu schließen.

Was ist eine Geschäftsregel? Aus geschäftlicher Sicht handelt es sich um eine Richtlinie, die das Verhalten beeinflussen oder leiten soll. Geschäftsregeln sind buchstäblich das verschlüsselte Wissen über Ihre Geschäftspraktiken. Aus IT-Sicht ist eine Geschäftsregel ein atomares Stück wiederverwendbarer Geschäftslogik.

In gewisser Weise weiß jeder, was Geschäftsregeln sind — sie leiten Ihr Unternehmen bei der Ausführung seines täglichen Betriebs. Ohne Geschäftsregeln müssten Sie immer spontan Entscheidungen treffen und von Fall zu Fall zwischen Alternativen wählen. Dinge auf diese Weise zu tun, wäre sehr langsam.

Regeln sind uns allen im wirklichen Leben vertraut. Wir spielen nach Regeln, wir leben in einem Rechtssystem, das auf einer Reihe von Regeln basiert, und wir legen Regeln für unsere Kinder fest. Die Idee von Regeln in Geschäftssystemen ist den meisten IT-Fachleuten jedoch ironischerweise fremd. Sagen Sie “Regeln” und viele IT-Experten denken vage an Expertensysteme oder künstliche Intelligenz. Es gibt wenig Anerkennung dafür, wie zentrale Regeln tatsächlich für die grundlegenden, täglichen Abläufe des Unternehmens sind.

Nicht zufällig sind viele Mitarbeiter und Manager in der Geschäftswelt so gut in prozedurale Ansichten zur Entwicklung von Anforderungen indoktriniert, dass das Denken in Form von Regeln fremd oder abstrakt erscheinen mag. Praktisch jede Methodik ist in dieser Hinsicht anwendbar, sei es für das Business Process Re-Engineering, die Systementwicklung oder das Software-Design.

Dies ist aus zwei Gründen bedauerlich:

1. Das Nachdenken über organisierte Aktivitäten in Bezug auf Regeln ist eigentlich sehr natürlich. Stellen Sie sich zum Beispiel vor, Sie versuchen, ein Spiel wie Schach, Dame, Baseball oder Fußball zu erklären, ohne die Regeln zu erklären.

2. Business-Side-Arbeiter und Manager haben das Wissen, das es braucht, um gute Regeln zu schaffen.

Beispielregeln

Sehen Sie sich die folgenden Beispielregeln an und beachten Sie, wie jeder Aspekt der Betriebskontrolle in einem Geschäftssystem durch Regeln angesprochen werden kann:

• Einschränkungen: Ein Kunde darf nicht mehr als drei Eilaufträge aufgeben, die seinem Guthabenkonto belastet werden.

* Heuristik: Ein Kunde mit bevorzugtem Status sollte seine Bestellungen sofort ausführen lassen.

* Berechnungen: Das jährliche Auftragsvolumen eines Kunden muss als Gesamtumsatz berechnet werden, der während des Geschäftsjahres des Unternehmens abgeschlossen wurde.

* Schlussfolgerung: Ein Kunde muss als bevorzugt betrachtet werden, wenn der Kunde mehr als fünf Bestellungen über 1.000 USD aufgibt.

* Timing: Ein Kunde muss archiviert werden, wenn er 36 Monate in Folge keine Bestellungen aufgibt.

* Trigger: “Send advance notice” muss für eine Bestellung ausgeführt werden, wenn die Bestellung versendet wird.

Regeln bauen direkt auf Begriffen und Fakten auf. Begriffe — wie Kunde, Versand und Rechnung – sollten im Geschäft präzise und eindeutig definiert sein. Zum Beispiel könnte Kunde definiert werden als: “Eine Organisation oder Einzelperson, die in den letzten zwei Jahren mindestens eine bezahlte Bestellung aufgegeben hat.”

Fakten werden durch einfache, deklarative Sätze gegeben, die die Begriffe mit einem Verb oder einer Verbphrase verbinden, z. B. “Kunde bestellt.”

Ein “Faktenmodell” ist eine Reihe von Faktenaussagen, die die Ergebnisse eines Geschäftsbetriebs beschreiben. Ein Faktenmodell sollte als erste Blaupause für ein Datenmodell dienen, aber sein Hauptzweck besteht darin, Wissen über das Unternehmen in strukturierter Form zu erfassen, destilliert von den geschäftsseitigen Mitarbeitern und Managern, die es besitzen.

Regeln fügen im Wesentlichen den Sinn der Wörter muss oder darf nicht zu den Bedingungen und Fakten, wie in “Bestellungen auf Kredit über $ 1.000 dürfen nicht ohne Bonitätsprüfung akzeptiert werden.”

Regeln sollten in klarem, eindeutigem, gut strukturiertem Geschäftsenglisch ausgedrückt werden, beginnend mit einem expliziten Thema. Regeln sollten keinen Flaum und keine fehlenden Fakten haben. Regeln können qualifiziert werden, wie in “Eine Sendung muss versichert sein, wenn der Sendungswert mehr als 500 US-Dollar beträgt.” Und Regeln können Zeitkriterien enthalten, wie in “Ein Student muss bis zum Ende der Registrierung in mindestens zwei Kursen eingeschrieben sein.”

Regelunabhängigkeit

Ein Unternehmen ist einem menschlichen Körper sehr ähnlich. Die Wissensstruktur (Begriff und Tatsache) ist wie das Skelett; Die Prozesse sind die mächtigen Muskeln; und die Regeln sind das Nervensystem, das die beiden anderen kontrolliert. Alle drei sind essentiell und miteinander verbunden. Geschäftsregeln sollten jedoch von den beiden anderen getrennt sein. Ein Grundprinzip dieses Ansatzes ist, dass Regeln unabhängig von Prozessen und Verfahren sind. Ein Nebeneffekt dieser “Regelunabhängigkeit” ist eine enorme Vereinfachung der Prozesse.

Das Ergebnis ist ein “dünner Prozess”, ein langjähriges Ziel vieler IT-Experten. Indem Sie die Regeln aus den Prozessen herausnehmen, können Sie Prozesse erstellen, die relativ einfach sind und bei Bedarf geändert werden können.

Wenn in der National Football League ein Spiel für ein Team nicht funktioniert, wird es innerhalb weniger Spiele aus dem Spielbuch entfernt. Die Stücke sind im Wesentlichen Wegwerf. Ebenso müssen Unternehmen ihre eigenen Verfahren als Wegwerfprodukte betrachten – billig genug, um sie zu entsorgen und zu ersetzen, wenn die Verfahren nicht mehr gut funktionieren.

Wegwerfverfahren sind ein Muss für das Unternehmen, um anpassungsfähig und wettbewerbsfähig zu sein. Diese täuschend einfache Idee – ermöglicht durch den Geschäftsregelansatz — kann die Art und Weise, wie Arbeit geleistet und Systeme entworfen werden, revolutionieren.

Nachdruck mit Genehmigung von Principles of the Business Rule Approach, von Ronald G. Ross (Addison-Wesley, 2003). Ross ist Mitbegründer und Principal von Business Rule Solutions LLC und Executive Editor der Website BRCommunity.com.

Library Fact Model
Dieses Diagramm zeigt ein grafisches Faktenmodell für eine Bibliothek. Der Wortlaut der Regel basiert direkt auf dem Faktenmodell, einem Diagramm grundlegender Geschäftskonzepte – einer Wissensstruktur. Ein Faktenmodell kann und sollte einen ersten Entwurf dafür liefern, wie Daten letztendlich in einer Datenbank organisiert werden. REGEL: Ein Bibliotheksausweis darf nur dann zum Auschecken eines Buches verwendet werden, wenn sich das Buch im Besitz einer Bibliothek befindet, für die der Ausweis autorisiert ist.