Architekturzentrierte Software-Entwicklung – elitäre Technik-Disziplin oder ökonomische Notwendigkeit?
Arno Schott
Zentralbereich Anwendungsservices ALTE LEIPZIGER Lebensversicherung a.G.
Alte Leipziger-Platz 1 61440 Oberursel SchottA@Alte-Leipziger.de
Abstract: Der folgende Beitrag berichtet über Erfahrungen in der Nutzung einer Softwarearchitektur beim Aufbau neuer Anwendungssysteme in einer Versiche- rung. Nach kurzer Vorstellung der Architektur wird unter Betrachtung eines mehrjährigen Projektportfolios der „business case“ für die getätigten Architektur- Investitionen dargestellt.
1 Ausgangssituation
Um deutliche Reduzierungen der Geschäftsprozess-Bearbeitungszeiten sowie eine Ver- kürzung der Zeitspanne zur Einführung neuer Produkte zu erzielen, entschied sich die ALTE LEIPZIGER Lebensversicherung a.G. Mitte der 1990er Jahre dazu, ihre überal- terten Backoffice-Systeme nicht mehr weiter zu entwickeln und durch eine neue Soft- ware zu ersetzen.
Die Kern-Funktionalität einer solchen Anwendungslandschaft besteht in der juristisch und versicherungstechnisch korrekten Abwicklung von Kunden- & Vertragsdatenän- derungen. Nach eingehender Analyse des Marktes für solche Bestandsführungslösungen wurde der Einsatz einer Standard-Software verworfen und die Entscheidung für eine In- dividualentwicklung unter Einbindung zugekaufter Teilsysteme (make & buy) getroffen.
Damit stand die interne Software-Entwicklungsabteilung – im Weiteren als Anwen- dungsentwicklung (kurz: AE) bezeichnet – vor folgenden Herausforderungen:
(1) Zusätzliches Projektziel war der Wechsel der technischen Infrastruktur. Die besteh- ende BS2000-Großrechnerwelt sollte durch eine Client/Server-Umgebung mit Windows-Clients sowie OS/390 (für Eigenentwicklungen) und Unix (ggf. für zuge- kaufte Teilsysteme) als Anwendungs- und Datenbank-Server ersetzt werden.
(2) Ungeachtet der Tatsache, dass praktisch keine Erfahrungen in der Neuentwicklung großer Systeme vorlagen, blieb der AE ziemlich genau ein Jahr Zeit für die Erstel- lung einer ersten produktiven Systemversion.
Innerhalb des IT-Managements bestand sehr schnell Einigkeit darüber, dass neben der Einführung eines Release-getriebenen Vorgehensmodells die Vorgabe und Unterstütz- ung einer Softwarearchitektur erfolgskritisch ist, um zu einer produktivitätssteigernden Arbeitsteilung im Projekt sowie einer Zentralisierung technischer Systemaspekte für die AE zu kommen.
2 Elemente der Softwarearchitektur
Mit Beginn dieser Projektierung arbeitet die AE in unserem Hause mit den folgenden drei Architektur-Sichten:
2.1 Technische Anwendungsarchitektur (TAA)
Ähnlich zu Quasar, der Softwarearchitektur von sd&m [SD00], werden ausgehend von einem klassischen Schichtenmodell die Zuständigkeiten der einzelnen Softwareschichten detailliert sowie deren Schnittstellen standardisiert.
Abbildung 1: Modularisierungsschema der TAA
Zunächst sind technische Aufgaben, wie etwa Modulkommunikation, Workspacemana- gement, Transaktionierung, Fehlerhandling etc., die wiederkehrend von jeder Anwen- dung zu lösen sind, durch vorgefertigte Module (TAA-Runtime) zentralisiert. Es handelt sich dabei im Sinne der Quasar-Softwareblutgruppen um reine T(echnik)-Software.
A-Software – also die fachliche Logik des Systems – wird zerlegt in Interaktionslogik, reine Fachfunktionen („prüfen & rechnen“) sowie Steuerungsmodule, deren Aufgabe die
„Choreografie“ aller übrigen Komponenten zu Geschäftsabläufen ist. Auf diese Soft- wareschichten beschränken sich die wesentlichen Realisierungstätigkeiten der AE.
Die Datenverwaltungsschicht ist verantwortlich für die „tRansformation“ der fachlichen Anwendungsobjekte in Repräsentationen der Datenbank und besitzt folglich den Cha- rakter von R-Software. Die Kommunikation mit der Datenbank über SQL liegt aus- schließlich in der Zuständigkeit von Datenzugriffsmodulen, welche direkt aus Datenmo- dellen generiert werden.
Steuerungen
TAA-Runtime (Container)
Funktionen Interaktionen
Technische Infrastruktur TAA-Runtime (Broker)
Datenzugriffe
A-Software R-Software T-Software
UI-Framework Daten-
verwalter
AR-Software
Mit diesem Modularisierungskonzept wurde es der AE erstmalig ermöglicht, mit Hilfe von Werkzeugen ein von der konkreten technischen Infrastruktur unabhängiges Anwen- dungsdesign zu erstellen. Diese Entwurfsergebnisse erlauben bereits zu einem sehr frü- hen Zeitpunkt eine vollständige vertikale Integration über alle Softwareschichten hinweg und damit ein plattformunabhängiges Prototyping auf Entwurfsebene. Das TAA-Modell besitzt somit viele Eigenschaften einer proprietären Model Driven Architecture.
2.2 Datenarchitektur
Ergänzend zur Anwendung grundlegender Softwareentwurfs-Prinzipien wie separation of concerns und dem Denken in Komponenten und Schnittstellen ist die Modellierung der fachlichen Daten auf unterschiedlichen Betrachtungsebenen eine weitere wichtige Methode, um zu stabilen Anwendungsstrukturen zu kommen.
Um hohe Flexibilität in die Datenstrukturen zu konstruieren, sind konsequent Generali- sierungs- und Spezialisierungsprinzipien in der Entity-Relationship-Modellierung anzu- wenden. Unterstützung bei diesem Prozess bieten existierende Branchen-Referenzmo- delle wie die VersicherungsAnwendungsArchitektur des Gesamtverbandes der deutschen Versicherungswirtschaft oder auch die Insurance Application Architecture von IBM1, die den gesamten Informationsbedarf einer Versicherung in allgemeingültiger Form ab- bilden und eine entsprechende Strukturierung in fachliche Domänen vorschlagen.
2.3 Fachliche Anwendungsarchitektur (FAA)
Schließlich ist festzulegen, aus welchen eigenständigen Softwarekomponenten ein An- wendungssystem fachlich zusammengesetzt wird. Hier sind Fragen folgender Art zu be- antworten:
(1) Welche Geschäftsprozesse sind durch die Anwendung zu unterstützen? Soll der Be- nutzer im Management seiner Geschäftsprozesse aktiv unterstützt werden?
(2) Werden langlaufende Transaktionen und damit fachliches Sperren von A-Entitäten sowie deren Speicherung in unterschiedlichen Zuständen (z.B. „schwebend“ vs.
„inkraft“) benötigt? Sind darüber hinaus Wirksamkeitszeiträume für A-Entitäten zu verwalten?
(3) Welche Anwendungskomponenten müssen zusammenwirken, um die Geschäftspro- zesse abzuwickeln? Welche dieser Komponenten stehen als wiederverwendbare Services zur Verfügung und können vertikal integriert werden? Welche bestehenden Systeme sind zusätzlich horizontal – d.h. lose – zu integrieren?
1 siehe hierzu unter http://www-1.ibm.com/industries/financialservices/doc/content/solution/278918203.html und http://www.gdv-online.de/vaa
Viele der hier erwähnten Aspekte können ebenfalls in Form vorproduzierter Architektur- komponenten abgedeckt werden, so etwa (1) durch Workflowmanagement-Funktionen oder (2) durch ein Zeitraummanagement als Bestandteil der Datenzugriffsschicht. Fol- gende Abbildung zeigt exemplarisch die fachliche Komponenten-Architektur des neuer- stellten Bestandsführungssystems für Lebensversicherungen:
Abbildung 2: FAA Bestandsführung Leben
3 Betrachtungen zur Wirtschaftlichkeit
3.1 Kosten der Architektur
Innerhalb der AE-Organisation werden sämtliche Architekturaufgaben durch eine zen- trale Software-Engineering-Gruppe wahrgenommen. Dieses Aufgabenpaket umfasst ne- ben der Weiterentwicklung und Wartung zentraler vorgefertigter Komponenten sowie Werkzeugen zur Unterstützung von Softwaredesign, -generierung und Konfigurations- management auch die Durchführung des Datenbankmanagements sowie Build & Deploy produktiver Anwendungen. Ergänzend wird eine Beratung und Unterstützung von AE und Betrieb im Einsatz der Architektur geleistet.
Seit 1996 wurden sämtliche Neu-Projektierungen zur operativen Systemwelt in einem Umfang von etwa 500 Personenjahren auf Basis der dargestellten Architektur durchge- führt. Mit Beginn dieser Entwicklung umfassten die jährlichen Personal- und Sachkosten für Architektur immer zwischen 15-20% des AE-Gesamtbudgets. Dabei fließen seit 3 Jahren stabil ca. 70% in Wartung und Betrieb derselben.
3.2 Nutzen der Architektur
Eine wirksame Softwarearchitektur sollte zunächst Entwicklungsprojekte mit A- und R- Änderungen durch Wiederverwendung von Komponenten und Musterlösungen be- schleunigen. Zum anderen ist zu erwarten, dass sich der durch T-Änderungen verursach- te Wartungsaufwand aufgrund der Trennung der Anwendungslogik von technischen As- pekten verringert.
Änderung Leistung Fort-
schreibung Zugang …
Produkt
versicherungstechnische Bestandsführung
Risiko- prüfung Bestandsführung Leben
Partner Workflow Dokumente
(Archiv)
Schriftgut Berechtigung
Geschäftsprozesse
Anwendungskern
spartenspezifische Komponenten
wiederverwendbare
Services integrierte
Kaufsoftware In-/Exkasso
Provision
Um diese Hypothesen mit harten Daten zu überprüfen, wird seit 2000 für Projektstich- proben nachträglich die AE-Produktivität ermittelt, d.h. es erfolgt eine Gegenüberstel- lung der fachlichen Systemgröße in Function-Points (kurz: FP) zum eingesetzten AE- Aufwand für Entwurf, Implementierung und Test.
System Wartungsquote3 [PT/kFP]
Bf-Leben, 2003 29,0
Bf-Sach, 2003 24,0
Benchmark4 60,0
Tabelle 1: Messergebnisse
AE-Produktivität und Wartungsquote Bf = Bestandsführung
PoS = Point of Sale eB = e-Business
Die Kennzahlen in Tabelle 1 zeigen, dass in allen gemessenen Neu- und Weiterentwick- lungsprojekten mindestens eine AE-Aufwandsreduzierung um ein Drittel gelang und die jährlichen Wartungsaufwände für die neuen Vertragsverwaltungssysteme nur ca. 50%
des Vergleichswertes erreichen. Übertragen auf die AE-Kapazitätsplanungen für 2004 mit etwa 12.500 PT’s für Neu- und Weiterentwicklung sowie 3.500 PT’s für Wartung entsteht damit ein Kapazitätseffekt von 9.750 PT’s. Saldiert mit den Architekturinvesti- tionen ergibt sich dadurch ein positiver jährlicher Netto-Effekt von ca. 1,5 Mio ¼
4 Fazit
Architekturgetriebene Software-Entwicklungsprozesse sind eine wirksame Vorgehens- weise, um das „engineering gap“ zwischen fachlicher Spezifikation und technischer Im- plementierung zu verkleinern. Dies ist aus Sicht des Autors nicht nur ein notwendiger Schritt, um die Risiken großer Individualentwicklungen beherrschbar zu machen, son- dern in mittel- bis langfristiger Perspektive auch wirtschaftlich.
Literaturverzeichnis
[SD00] Siedersleben, J.; Denert, E.: Wie baut man Informationssysteme? Überlegungen zur Standardarchitektur, Informatik-Spektrum, Heft 4, Band 23, 2000, S. 247-257.
2 Als Vergleichswert dient hier der Mittelwert über alle Versicherungsprojekte des ISBSG-Benchmark Release 6, April 2000.
3 Entspricht dem jährlichen betriebserhaltenden Aufwand (für technische Anpassungen und Fehlerbehebungen) in Relation zur Größe des Gesamtsystems.
4 Vergleichswert auf Basis der QPeP-Benchmark-Datenbank der QuantiMetrics GmbH, die auch sämtliche FP- Schätzungen durchgeführt hat.
Projekt Produktivität [h/FP]
Bf-Leben Basis, 2000 5,2 Bf-Leben Release, 2003 5,7 Bf-Sach Basis, 2000 8,2 Bf-Sach Release, 2003 4,1 PoS-Sach Basis, 2002 6,8 PoS-Sach Release, 2003 4,6 eB-Portal Basis, 2002 7,4 eB-Portal Release, 2003 5,8
Benchmark2 12,3
