Home
News
Trends
Hefte
Online-Artikel
Kommentare
Service-Angebote
Feedback
Abonnement
Wir-ueber-uns
Tipps
Impressum
Veranstaltungen


»manage it« als

E-Paper  11-12 2011
E-Paper  9-10 2011
E-Paper  5-6 2011
E-Paper  3-4 2011
E-Paper  1-2 2011
E-Paper  11-12 2010
E-Paper  9-10 2010

E-Paper  7-8 2010
E-Paper  5-6 2010
 



 




 

 


 




 


 


 

 

Sauberes Architekturkonzept, kompromissloses Qualitätsstreben und intensive Kommunikationskultur sind Erfolgsfaktoren

Herausforderung SOA-Einführung

Geschäftsprozessunterstützung auf Basis serviceorientierter Architekturen (SOA) funktioniert performant auch in hoch komplexen, hoch verfügbaren und hoch sicheren unternehmenskritischen Anwendungslandschaften.

 

E

s gibt noch gute Nachrichten. 125.000 Anwender, greifen täglich auf die SOA-basierten Systeme der Sparkassen Informatik mit über 1.000 bereitgestellten bankfachlichen Funktionen zu, und haben keine Probleme. Schon bald werden weitere 77 Sparkassen mit rund 58.000 Anwendern hinzukommen. Auf dem Weg zur stabilen SOA-basierten Geschäftsprozessunterstützung hat der IT-Dienstleister umfassende, strukturierte Vorarbeiten geleistet und weit reichendes Best-Practice-Wissen erworben. Das Resümee heute: Allein durch sorgfältige Planung, ein akribisches Qualitätsmanagement sowie ein neues Verständnis von Teamarbeit und Führungsverantwortung lässt sich bei einem derartigen Großprojekt gewährleisten, dass das Ziel am Ende erreicht wird.

Vor rund einem Jahr hat der größte IT-Dienstleister der deutschen Sparkassen das letzte von vier Altsystemen abgeschaltet, die er von seinen Vorgängerunternehmen übernommen hatte. Innerhalb von nicht einmal drei Jahren war es gelungen, sämtliche 229 betreute Sparkassen von den bestehenden Legacy-Systemen auf die prozessorientierte Gesamtbanklösung OSPlus (One System Plus) zu überführen. Das in Komponentenbauweise entwickelte System wird von rund der Hälfte der deutschen Sparkassen nicht nur zur Abwicklung hausinterner Prozesse genutzt. Mittels einer SOA ermöglicht es die funktionale Integration von Geschäftsprozessen zahlreicher Partner wie Versicherungen, Bausparkassen oder Wertpapierabwicklern. Rund 30 dieser Partner sind bereits an das Sparkassen-Frontend angebunden. Mitarbeiter können dadurch aus der ihnen vertrauten Anwendungsumgebung heraus direkt auf Funktionen von Verbundunternehmen zugreifen. Schon bald werden auch 77 bayerische Sparkassen auf die Gesamtbanklösung migrieren.

Neues Verständnis von Softwareentwicklung

Die Grundlage für die Umstellung der Anwendungs- und Systemlandschaft wurde im Jahr 1999 mit dem S-Buchen Projekt gelegt. Dabei wurde das vorhandene proprietäre Buchungssystem durch eine neue, komponentenbasierte Lösung abgelöst. Dessen Architektur und das in dem Projekt etablierte Vorgehen wurde konsequent fortgeschrieben und auch auf die Front-End-Systeme übertragen. Seit zwei Jahren hat der IT-Dienstleister nun vollständig auf eine Komponenten- und Repository-basierte Entwicklung umgestellt. Diese Umstellung hat bei Führungskräften und Teammitgliedern ein völlig verändertes Verständnis von Softwareentwicklung und Teamarbeit bewirkt. Ein ganz neues Denken war auch in der Anwendungsbereitstellung gefordert. Der innovative Architekturansatz führte dazu, dass Managementprinzipien, Methodik und Vorgehensweise konsequent hinterfragt und den veränderten Anforderungen angepasst wurden. Dass die Sparkassen Informatik heute schneller, effizienter und kostengünstiger arbeitet als in der Vergangenheit, ist daher das Resultat eines intensiven Prozesses, der alle Beteiligten stark gefordert hat. Die Umstellung auf eine SOA erfordert einen hohen Einsatz. Eine Abkürzung auf dem Weg gibt es nicht.

Es klingt bestechend einfach: Entwickler arbeiten nicht mehr an schwer überschaubaren Code-Monolithen, sondern stellen Services zur Verfügung, die einmal programmiert und beliebig oft wieder verwendet werden. Die komfortable Wiederverwendung von Komponenten hat jedoch eine Kehrseite: Fehler in einem einzelnen Funktionsbaustein potenzieren sich mit der Anzahl der Geschäftprozesse, in welche dieser eingebunden ist. Damit wächst die Verantwortung eines jeden am Entwicklungsprozess Beteiligten für die Gesamtanwendung in überproportionalem Maße. Präzision und Sorgfalt – bereits in der klassischen Programmierung Kardinaltugenden – gewinnen daher nochmals erheblich an Bedeutung.

Während sauberes Arbeiten für Softwareentwickler zumindest nichts grundsätzlich Neues ist, so fordert das SOA-Prinzip zusätzlich eine Schlüsselqualifikation, die nicht unbedingt im Berufsbild des Informatikers verankert ist: Eine ausgeprägte Fähigkeit und Bereitschaft zur Kommunikation im Team. Denn Funktionen ändern sich und unter Umständen wirken sich diese Änderungen auf das große Ganze aus. Entwickler müssen daher informieren und informiert sein; das Wissen über die Abhängigkeiten zwischen Komponenten muss strukturiert dokumentiert werden – es reicht nicht mehr aus, wenn jeder lediglich über die von ihm programmierten Services Bescheid weiß.

Wer nicht mehr gleichartigen Funktionen wiederholt für verschiedene Applikationen entwickelt, gewinnt Zeit. Diese wird in einer intensiven Abstimmung mit den anderen Teammitgliedern sinnvoll genutzt. Viele klassische Entwickler mit viel Erfahrung betreten damit Neuland und haben anfangs ihre Schwierigkeiten. Diese sind jedoch überwindbar. Für Softwareentwickler, die ihre Zukunft in der SOA sehen, empfiehlt es sich, frühzeitig an den eigenen kommunikativen Fähigkeiten zu arbeiten und das Abstrahieren und Strukturieren von Aufgabenstellungen zu verinnerlichen.

Der Abstimmungsaufwand sinkt schließlich in dem Maße, in dem eine lebendige Kommunikationskultur und strukturierte Dokumentation in den Entwicklungsteams entsteht. Diese zu etablieren ist eine Führungsaufgabe. Insgesamt ändert sich mit der Serviceorientierung nicht nur die tägliche Entwicklungsarbeit. Auch Führungskräfte sehen sich mit neuen Anforderungen und Rahmenbedingungen konfrontiert. So wächst hier zunächst einmal die Abhängigkeit vom Team und einer professionellen Spezifikation der Aufgabe. Denn Änderungen oder Erweiterungen an Services können nicht immer aus eigener Kraft durchgeführt werden. Gesetzte Termine sind von allen Teammitgliedern auf Grund der wechselseitigen Abhängigkeiten unbedingt einzuhalten, wenn das Gesamtprojekt nicht in Verzug geraten soll. Eine vorrangige Aufgabe des Managements liegt daher in der Schaffung einer strukturierten Informationsbasis, in der Verantwortlichkeiten festgelegt, Prozesse definiert und Informationsflüsse klar geregelt sind. Diese bildet die Grundlage für sämtliche Vorgänge, welche die Entwicklung oder Änderung von Komponenten und die damit verbundenen Abstimmungsprozesse betreffen.

Null Toleranz für Qualitätsmängel

Wird die Komplexität einer serviceorientierten Architektur unterschätzt, entsteht ein Nährboden für Fehler. Daher ist ein äußerst systematisches Qualitätsmanagement unumgänglich. Gerade zu Anfang ist die Qualitätssicherung ausgesprochen zeitintensiv, so dass die durch Mehrfachverwendung von Komponenten eingesparten Entwicklerkapazitäten in weiten Teilen wieder abgezogen werden.

Um eine erstklassige Qualität dauerhaft zu gewährleisten bedarf es einer sauberen Definition aller entwickelten Komponenten und einer wirkungsvollen, intelligenten Testautomatisierung. Diese beschleunigt Testabläufe nicht nur erheblich, sondern bringt durch einen gestiegenen Abdeckungsgrad des Softwaretestings auch einen erheblichen Qualitätsgewinn. Gelingt es, leistungsfähige Testroutinen mit einem intelligenten Automatisierungskonzept zu kombinieren, zahlt sich die anfängliche Investition in die Testautomation in recht kurzer Zeit durch schnellere Testläufe und geringere Fehlerquoten wieder aus. In der Praxis der Sparkassen Informatik konnte beispielsweise der Zeitbedarf für umfassende Testläufe geschäftskritischer Anwendungen auf wenige Stunden reduziert werden. Das entspricht einem Bruchteil des früher betriebenen Aufwands, bei einem um ein vielfaches erhöhten Abdeckungsgrad. Auch die Dokumentation konnte durch den Einsatz eines zentralen Repositorys, das alle fachlichen Informationen zu den einzelnen Komponenten in strukturierter Form und der jeweils aktuellen Fassung verwaltet, weitgehend automatisiert werden. Gleichzeitig dient das Repository als Reportumgebung für die Testautomation.

Tragfähige Architektur, solides Fundament

Die Einführung einer SOA lässt sich mit dem Bau eines mehrstöckigen Hauses vergleichen. Anfangs ist eine hohe Investition in ein solides Fundament fällig. Ein unmittelbarer Mehrwert entsteht für den Investor nicht. Dieser lässt sich erst abschöpfen, wenn das Gebäude bewohnbar ist, vermietet oder verkauft werden kann. Je mehr Stockwerke das Fundament jedoch am Ende tragen kann, desto höher wird die Wertschöpfung. Wie tragfähig das Fundament ist, hängt entscheidend von der Sorgfalt des Bauplans und den ihm zu Grunde liegenden Berechnungen ab. Noch vor funktionalen und gestalterischen Merkmalen entscheidet dabei die Zuverlässigkeit der Statik über das Endresultat.

Nicht anders verhält es sich mit der SOA. Analog zur Statik entscheidet die Systemarchitektur über Stabilität und Tragfähigkeit des Gebäudes. Je größer dieses werden soll, desto höher ist die Anfangsinvestition in Planung und Fundament. Das selbe gilt auch für den Mehrwert. Je intensiver das Gebäude genutzt wird, je höher seine Lebensdauer ist, desto größer wird auf Dauer der Return on Investment (ROI) sein. Eine vorausschauende Planung muss dies von Anfang an berücksichtigen. Die fachlichen Anforderungen sind schließlich – um bei der Analogie zu bleiben – mit Funktionalität und Design gleichzusetzen. So wie diese in der klassischen Architektur mit der Statik in Einklang gebracht werden müssen, erfordert die SOA eine sorgfältige Abstimmung zwischen Anwendungs- und Systemarchitektur. Bei der Planung und Realisierung einer SOA liegen auf diesem Gebiet besondere Herausforderungen, wobei sich in der Praxis der Sparkassen Informatik der Mainframe als eine geeignete und in vielen Bereichen überlegene Technologieplattform erwiesen hat.

Es braucht einen langen Atem

Auch bei noch so sorgfältiger Planung sind bei der SOA-Einführung Überraschungen vorprogrammiert. In einer komplexen Gesamtarchitektur, bei der Funktionen flexibel miteinander verknüpft sind und somit zahlreiche wechselseitige Abhängigkeiten entstehen, sind Last- und Performanceprobleme nur schwer vorhersehbar. Die in den klassischen Produktionsumgebungen gewachsenen und etablierten Werkzeuge zur Systemüberwachung und Systemmanagement sind den neuen Technologien noch um einige Funktionen voraus. Sicher ist es nur eine Frage der Zeit, wann die Werkzeuge den gleichen Reifegrad wie in klassischen Umgebungen erreicht haben. Für die verantwortlichen IT-Manager bedeutet dies aber aktuell noch intelligente Überwachungs- und Eskalationsmechanismen zu etablieren um die Sicherheit, die Verfügbarkeit und die Performance gewährleisten zu können.

Die Sparkassen Informatik hat beispielsweise frühzeitig Warnschwellen implementiert, die zu einer sofortigen Eskalation führen, wenn ein Request länger als geplant läuft. Als eine weitere vorbeugende Maßnahme wurden Eskalationsmechanismen hinterlegt, welche die übermäßige Beanspruchung von Speicherressourcen bereits im Entwicklungsprozess melden. Derartige Routinen wurden im weiteren Verlauf des SOA-Betriebs konsequent ausgebaut und verfeinert, um eine umfassende Performance-Analyse in Echtzeit zu ermöglichen. Ergänzt wurde dies durch Konzepte zur Ausfallmengenreduzierung.

Resümee

Der immense Aufwand für die Einführung einer SOA muss sich im Endeffekt rechnen. Gerade zu Beginn sind Investitionen erforderlich. Ein IT-Dienstleister kann diese nicht ohne Mehrwert an seine Kunden weitergeben, denn niemand zahlt für einen reinen Architekturbuild. Der Mehrwert für Dienstleister und Kunden stellt sich im Laufe der Zeit ein. Steht die Anwendungsentwicklung auf einem soliden Fundament, wird sie schneller, effizienter und kostengünstiger. Interne und externe Anwendungen lassen sich funktional leicht integrieren und Geschäftsprozesse flexibel administrieren.

Selbst die Produktionsplanung und Preismodelle lassen sich bei einer gut durchdachten und funktionierenden Architektur präziser gestalten. Die Sparkassen Informatik ist beispielsweise heute in der Lage, die Kosten für einen Geschäftsprozess aufgrund der Repository-basierten Dokumentation, der definierten Preise pro Funktionsaufruf und der Belastung der Systemressourcen vorausschauend zu kalkulieren.

Detlev Klage

___________________________________________________________

Detlev Klage, Geschäftsbereichsleiter Multikanal Vertrieb , Sparkassen Informatik

 


Folgen Sie »manage it« auf Google+




 


 


 

 

 
Copyright © 2003-2012  ap Verlag GmbH