Rules & Request Engine
Provisioning auf SOA-Basis
Die Kostenspirale dreht sich auch für IT-Serviceanbieter: Kunden fordern immer mehr Flexibilität, Agilität und Verfügbarkeit zu immer niedrigeren Preisen. Deshalb müssen Anbieter ein Geschäftsmodell nutzen, das sowohl Kosteneinsparungen erlaubt als auch die Kundenanforderungen erfüllt. Dazu müssen sie IT-Prozesse und IT-Services standardisieren, automatisieren, steuern und optimieren. Die Erfolgsformel: professionelles Prozessmanagement.
Oft herrscht hektische Betriebsamkeit, wenn Entwickler und Programmierer mit neuen
Regelanforderungen in einem Provisioning-System für IT-Services beauftragt sind. Der Grund: Die
Suche nach einem geeigneten Code beginnt. Lässt sich im eigenen System nichts finden, so müssen
nicht selten Programmbruchstücke aus dem Internet herhalten. Oft werden auf diese oder ähnliche
Weise die ersten 80 Prozent des Gesamtcodes aus funktionierenden Einzelstücken schnell und teils
durchaus effektiv zusammengestückelt – und dennoch teuer erkauft: Häufig führt diese "
Quick-and-dirty"-Methode dazu, dass die restlichen 20 Prozent des Programmiercodes vor allem in
größeren Entwicklungsumgebungen alle getroffenen Termin- und Budgetzusagen ad absurdum führen.
Denn häufig stellt sich früher oder später heraus, dass das Zusammenspiel der Versatzstücke
schlichtweg nicht wie erwartet funktioniert. Unterschiedliche Sprachen, Datentypfehler und andere
Inkompatibilitäten sind meist die Hauptursachen. Regeln brauchen Daten, die sie verarbeiten sollen.
Dementsprechend ist der kopierte Code oft um notwendige Felder zu erweitern, beispielsweise um die
Felder Domänenname, Servername, Ablagetypus oder User-Name. Woher aber kommen die Daten für die
soeben neu eingefügten Felder? Schnell werden deshalb noch Eingabeformulare erweitert oder
Suchroutinen erstellt – wiederum aus Versatzstücken. Das Resultat liegt auf der Hand: Erneute
Inkompatibilitäten, fehlende Daten, Syntaxfehler oder nicht deklarierte Variablen führen
schließlich zum programmiertechnischen GAU.
Zielsetzung Servicequalität
Die derartige Entwicklung einer Regelkette durch mehrere Programmierer offenbart oft klare
Defizite: Die Routine läuft nicht reibungslos durch, Fehler fallen auf, wertvolle Entwicklungszeit
verstreicht, Kosten steigen. Noch gravierender wirken sich Fehler aus, die unentdeckt bleiben. Dann
nämlich verlagert sich die Fehlerkette zum Kunden – mit der Konsequenz teurer Nachbesserungen und
Unzufriedenheit durch alle Instanzen bis hin zum Vertrauens- und Projektverlust. So wird
Prozessautomation zur Sisyphusarbeit und kann die Erwartungen vor allem in volatilen und/oder
komplexeren Umgebungen mit mehreren Mandanten und hohen Compliance-Anforderungen nicht
erfüllen.
Nur wer seine IT-Prozessregeln managen kann, wird seine Services beherrschen. Dies beginnt bei
der gewählten Architektur und endet beim Regelmanagement. Als sinnvoll und hilfreich hat sich in
diesem Zusammenhang ein SOA-basierter (Service-oriented Architecture) Ansatz bewährt, der eine
Trennung von Datenobjekten, Regelobjekten, Metadaten und Zielsystemobjekten vorsieht. Damit lässt
sich eine große Flexibilität in der Erstellung oder Adaption neuer Services, Regeln und Prozesse
sowie eine hohe Effizienz bei der Änderung bestehender Prozesse gewährleisten – und dies alles
revisionssicher.
Gespeichert sind die Regeln bei diesem Ansatz in einer Regelbibliothek (Rules Library), einer
separaten Datenbank neben der eigentlichen Prozessmaschine (Rules & Request Engine, RRE). Um
den Überblick zu bewahren, versieht man die Regeln mit Beschreibungen und kategorisiert sie
beispielsweise in einer Baumstruktur. Zusätzlich zu den einzelnen Regelkomponenten lassen sich in
der Library Beschreibungen von Prozessabläufen vorhalten, die die Regeln miteinander verketten und
beispielsweise nach IT-Services wie User-, Mail-, File- oder Print-Services getrennt vorliegen.
Ganz nach jeweiligem Bedarf lassen sich nun durch Referenzierung auf einzelne Regelkomponenten und
deren Verkettung Prozesse schnell und sicher erstellen. Aus Sicht der Regeln besteht so eine
1:n-Beziehung zu den Prozessen in der Engine und den dazugehörigen Metadaten. Dies reduziert die
Beziehungsdimensionalität zwischen den kommunizierenden Objekten deutlich, während sich die
Eigenschaften und Datenfelder der einzelnen Regeln leicht abfragen lassen. Die so erzielte
Einfachheit garantiert den Überblick auch in großen Umgebungen und gewährleistet die Verwaltbarkeit
der Regeln.
Baukastenprinzip
Wie aber müssen die Regelkomponenten selbst aussehen, um schnell und fehlerfrei kombinierbar zu
sein? Idealerweise nach dem Lego-Prinzip: als atomare Komponenten (Skript, DLL, Dotnet,
COM-Komponente) mit klar definierten Ein- und Ausgabewerten, einem festen Kommunikations-Interface
zum Beispiel in XML (Extensible Markup Lan- guage), in einer einheitlichen Programmierumgebung und
mit klaren Qualitätsstandards. Die Vorteile eines solchen "Lego-Kastens" für IT-Regeln sind
vielfältig: Einmal modelliert und implementiert stehen die Regeln verschiedenen Prozessen zur
Verfügung. Dies löst auch das Problem der Komplexität der Pflege und der Konsistenz von Regeln –
wie es etwa dann besteht, wenn Regeln fest in die Prozesse integriert oder per Codierung in den
Backend-Applikationen implementiert sind. Nach ausgiebigen Tests sind die Regelkomponenten
bedenkenlos wiederverwendbar. Zu jedem Eingabewert lässt sich leicht die zugehörige, vorgeschaltete
Ausgabekomponente finden. So entsteht rasch eine Regelkette.
Die 1:n-Beziehungen mit den Prozessen ermöglichen die Erstellung von Schaubildern, die zeigen,
welche Regel auf welche(n) Prozess(e) wirkt. Bei nachträglicher Veränderung einer Regel ist sofort
abzusehen, welche Prozesse dies betrifft. Damit sind auch die Auswirkungen auf Zielsysteme,
Datenobjekte und Metadaten klar erkenntlich. Dies schafft nebenbei auch die benötigte Transparenz
und Sicherheit vor geplanten Updates, da sich nun Prozesse und Regeln gegeneinander abprüfen
lassen. Programmierfehler bei der Regelerstellung sind auch hier generell nicht ausgeschlossen,
aber auf ein Minimum reduziert.
Erleichterter Betrieb
Der Vorteil dieser Architektur zeigt sich nicht nur im täglichen Betrieb, sondern vor allem in
der Steuerbarkeit und Planbarkeit der IT-Serviceprozesse: Über die zentrale Verwaltung der Regeln
in einem Baukastensystem lässt sich mit einem solchen Repository die Gover-nance, Versionierung,
Nachvollziehbarkeit und Wiederverwendbarkeit der Regeln unterstützen. Denn dieser Ansatz ermöglicht
ein Prozess- und Regel-Monitoring, ein einheitliches Reporting und Logging, revisionssichere
Protokollierung von Änderungen und Abläufen im Regelwerk, automatisiertes Testen sowie eine
Regelsimulation, um Fehler schon im Vorfeld abzufangen. Dies ist das Instrumentarium, um selbst
hochkomplexe Umgebungen mit mehreren tausend Anwendern und hunderten von Regeln zu beherrschen.
Der Clou des Baukastensystems: Visualisierbare Regel- und Prozessketten sind verfügbar, anhand
derer auch Nicht-Programmierer wie Administratoren und Operatoren automatisierte IT-Prozesse
erstellen oder ändern können. So ist selbst ein Zukunftsszenario vorstellbar, in dem ein
Unternehmen die Regelkomponenten gar nicht mehr selbst erstellt, sondern per Internet von einem
Lieferanten aus einer Regeldatenbank direkt bezieht.
Ähnliche Vorteile gelten nicht ausschließlich für die Regeln eines Entwicklungsprojekts. Auch
die Datenobjekte "profitieren", zumal das Baukastenprinzip sich ebenso auf die Architektur der
Content-Objekte und deren dynamische Metadaten übertragen lässt: Atomare Einheiten mit klarem
Kommunikations-Interface, die mit den Regelobjekten ein lose verbundenes System (Loosely Coupled
System) bilden und über klare Austauschformate wie XML kommunizieren. So entstehen ganze
Objekt-Libraries mit eindeutigen Referenzen (Eltern-Kind, 1:n?) zwischen den Objekten.
In einem nächsten Schritt sind die so erstellten Prozessketten in den einzelnen Zielsystemen
umzusetzen. Dies erfordert Zielsystemschnittstellen. So genannte Target Access Modules (TAMs), die
wiederum aus Gründen der einfacheren Verwaltung und Wiederverwendbarkeit ebenso atomar konzipiert
sein sollten, arbeiten selbstständig ihre Aufgabe in den Zielsystemen wie Active Directory,
Mainframe, Mail- oder File-Services ab – synchron oder asynchron, je nach Auftrag durch die
Prozessmaschine.
Nutzen für interne und externe Dienstleister
Interner und externe Dienstleister erfahren über den beschriebenen Ansatz unterschiedliche
Nutzenaspekte: Ein interner Dienstleister besitzt typischerweise nur einen Mandanten, jedoch
hunderte verschiedene, oft rollenbezogene Regeln. Seine Herausforderung besteht darin, immer wieder
neue Systeme in das bestehende Provisioning-System zu integrieren – rasch, reibungslos und
Compliance-konform. Dazu muss er eventuell neue Prozesse aufsetzen oder alte modifizieren
beziehungsweise dokumentieren. Seine Aufgabe umfasst also nicht nur neue Services, sondern auch
bestehende. Der Baukastenansatz garantiert, dass sich Abhängigkeiten in den Objekt-Libraries
erkennen und Zukunftsszenarien simulieren lassen. Das schafft Planungssicherheit und erleichtert
die Umsetzung sowie den Betrieb aller Services.
Ungleich anders lassen sich die Marktanforderungen eines externen Dienstleisters definieren. Er
muss über seine Systeme eine Vielzahl von Mandanten mit Standard-IT-Services versorgen und dabei
möglichst ein Höchstmaß an Individualisierung in Angebot und Business-Modell bieten. Seine tägliche
Herausforderung besteht darin, die angebotenen IT-Services mandantenfähig zu verwalten und sie auf
neue Kunden anzupassen. Jeder einzelne IT-Service, bei dem implizit schon fünf bis zehn Prozesse
anfallen, kann typischerweise 10 bis 25 unterschiedliche (Kunden-)Variationen besitzen.
Um Herr dieser Vielfalt zu bleiben und ständig neue, attraktive Angebote bieten zu können, ist
ein externer Serviceanbieter gezwungen, seine Prozesse und Regeln von zentraler Stelle über alle
Mandanten hinweg zu administrieren. Ohne die Transparenz und das Wissen um die Abhängigkeiten der
Loosely Coupled Systems ist dies eine aussichtslose Situation, bei der der Anbieter bei jedem
Update ein hohes Risiko eingeht. Vor allem bei Services für Finanzdienstleister sind die
Compliance-Anforderungen besonders hoch. Bei einer Prozessautomation sind sie mit erfüllt. Zusammen
mit dem Prozess-Monitoring und den visualisierbaren Prozessketten erhöht der Serviceanbieter seine
Marktchancen und deckt die rechtlichen Sicherheitsaspekte automatisch mit ab.
Regeln als Services
Regeln werden zu Services, die eine Prozessmaschine wie alle anderen Dienste in einer SOA
verwaltet. So erhält man ein Designprinzip, um Wiederverwendbarkeit zu identifizieren und zu
implementieren, sowie die Möglichkeit, Regeln intelligent zu verwalten. Dies ist die Voraussetzung
für die Industrialisierung – also die Standardisierung, Automation und kontinuierliche Verbesserung
– von IT-Prozessen und IT-Services.
Lesen Sie mehr zum Thema
