SDLC und Business Rules
Ich gehe regelmässig am Blog von Rajgo vorbei. Sein Business Decisions in a Digital Enterprise ist eine wahre Fundgrube, wenn es um das praktische Umsetzen von Business Rules Management geht. Kein Wunder, der Mann ist Produktmanager bei Yaso Technologies und zeichnet für QuickRules.NET verantwortlich.
Seit etwa 12 Tagen studiere ich aufmerksam ein neues, sehr praxisorientieres Thema - das Einbinden der Business Rules in den System Development Life Cycle (SDLC). Sein Modell eines generischen SDLC -Prozesses fand ich ideal zum hier abbilden.
Und jetzt die gute Frage, in welchen Stadien ein Projektes würde sinnvollerweise die Ableitung der Geschäftsregeln erfolgen. Die ersten Regeln tauchen ja sicher schon während der Phase des Requirements auf. Dazu hatte ich ein paar Worte verloren. Dann müssen sie für die Implementation gleichfalls vordefiniert sein. Aber wie wo wann genau - ist nicht immer gleich und richtet sich oft nach den Anforderungen und Bedingungen der Unternehmen.
Und dann folgen dieser Einleitung ein paar wirklich gute Postings. Denn die Frage, an welchen Stellen im Prozess Business Rules definiert und entwickelt werden sollten, ist doch nicht ganz so einfach zu beantworten. Er holt dazu richtig gut aus und beschreibt aus seiner praktischen Erfahrung wichtige Schritte im SDLC-Prozess, die ich mal zusammenfassen möchte.
Die Requirements kamen ja schon zur Sprache. Die Zusammenfassung von Rajgo:
- Business Rules sind keine Requirements
- Software Requirements verweisen (zwingend) auf die Business Rules, und niemals umgekehrt.
- Business Rules entstehen unabhängig von den Requirements
- Änderungen der Geschäftsregeln werden vom Business verantwortet und angetrieben, nicht von IT.
- Regeln werden nicht mit herkömmlichen Werkzeugen für die Verwaltung der Requirements entwickelt. Es braucht dafür ein Business Rules Management System.
Zum System- bzw. Application Design fasst er klar zusammen, worum es geht. Entscheidend während der gesamten Entwicklungsphase ist, nie aus den Augen zu verlieren, für wen die Applikation entwickelt wird. Es geht es allererst um Effektivität, die effizient umgesetzt wird. Und das es für den Entwicklungsprozess unerlässlich ein Business Rule Management System braucht. (Mal abgesehen davon, dass er das schreiben muss, immerhin produziert er ja ein genau solches <G>).
Die Implementierungsphase handelt Rajgo detaillierte ab und ist deshalb extrem spannend zu verfolgen. In einer der nächsten Posts möchte ich das gern näher untersuchen und vor allem herzlich dazu einladen, vielleicht mal mitzudiskutieren. Er bezeichnet die Entwicklung der Regeln als komplexen Prozess - als Business Rule Development Lifecycle - und unterteilt ihn wichtige, voneinander getrennte Teilschritte:
- Requirements, Goals
- Rule Capturing - Sie ist vor allem nötig, wenn noch keine Regeln definiert bzw. extrahiert sind.
- Verifizierung und Verbesserung - Während der Verfeinerung der Regeln werden auch die erforderlichen Tests identifiziert.
- Regelimplemenntierung
- Testing
Für diese Entwicklungsphase ist wichtig festzuhalten, das die Entwicklung und Implementierung der Regeln parallel zur System- bzw. Applikationsentwicklung verläuft.
Das bereits entwickelte Testkonzept wird jetzt angewandt und verfolgt dabei grundsätzlich zwei Ziele:
1. Sind die Regeln korrekt entwickelt und umgesetzt worden?
2. Erfüllen die entwickelten Geschäftsregeln Ihren Zweck - den der Effektivität?
Zum Schluss noch ein treffendes Zitat, das in seiner punktgenauen Landung einfach nicht besser zu übersetzen ist.
You should aim to design a highly Efficient software system that will take very Effective Business Decisions.
