Provisioning auf SOA-Basis

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.