Architekturzentrierte Software-Entwicklung elitäre Technik-Disziplin oder ökonomische Notwendigkeit?

Transkript

1 Architekturzentrierte Software-Entwicklung elitäre Technik-Disziplin oder ökonomische Notwendigkeit? Arno Schott Zentralbereich Anwendungsservices ALTE LEIPZIGER Lebensversicherung a.g. Alte Leipziger-Platz Oberursel SchottA@Alte-Leipziger.de Abstract: Der folgende Beitrag berichtet über Erfahrungen in der Nutzung einer Softwarearchitektur beim Aufbau neuer Anwendungssysteme in einer Versicherung. 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 Verkürzung der Zeitspanne zur Einführung neuer Produkte zu erzielen, entschied sich die ALTE LEIPZIGER Lebensversicherung a.g. Mitte der 1990er Jahre dazu, ihre überalterten Backoffice-Systeme nicht mehr weiter zu entwickeln und durch eine neue Software zu ersetzen. Die Kern-Funktionalität einer solchen Anwendungslandschaft besteht in der juristisch und versicherungstechnisch korrekten Abwicklung von Kunden- & Vertragsdatenänderungen. Nach eingehender Analyse des Marktes für solche Bestandsführungslösungen wurde der Einsatz einer Standard-Software verworfen und die Entscheidung für eine Individualentwicklung unter Einbindung zugekaufter Teilsysteme (make & buy) getroffen. Damit stand die interne Software-Entwicklungsabteilung im Weiteren als Anwendungsentwicklung (kurz: AE) bezeichnet vor folgenden Herausforderungen: (1) Zusätzliches Projektziel war der Wechsel der technischen Infrastruktur. Die bestehende BS2000-Großrechnerwelt sollte durch eine Client/Server-Umgebung mit Windows-Clients sowie OS/390 (für Eigenentwicklungen) und Unix (ggf. für zugekaufte 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 Erstellung einer ersten produktiven Systemversion

2 Innerhalb des IT-Managements bestand sehr schnell Einigkeit darüber, dass neben der Einführung eines Release-getriebenen Vorgehensmodells die Vorgabe und Unterstützung 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. Steuerungen TAA-Runtime (Broker) A-Software R-Software AR-Software T-Software Datenverwalter Datenzugriffe Funktionen Interaktionen UI-Framework TAA-Runtime (Container) Technische Infrastruktur Abbildung 1: Modularisierungsschema der TAA Zunächst sind technische Aufgaben, wie etwa Modulkommunikation, Workspacemanagement, Transaktionierung, Fehlerhandling etc., die wiederkehrend von jeder Anwendung 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 Softwareschichten 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 Charakter von R-Software. Die Kommunikation mit der Datenbank über SQL liegt ausschließlich in der Zuständigkeit von Datenzugriffsmodulen, welche direkt aus Datenmodellen generiert werden

3 Mit diesem Modularisierungskonzept wurde es der AE erstmalig ermöglicht, mit Hilfe von Werkzeugen ein von der konkreten technischen Infrastruktur unabhängiges Anwendungsdesign 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 Generalisierungs- und Spezialisierungsprinzipien in der Entity-Relationship-Modellierung anzuwenden. Unterstützung bei diesem Prozess bieten existierende Branchen-Referenzmodelle wie die VersicherungsAnwendungsArchitektur des Gesamtverbandes der deutschen Versicherungswirtschaft oder auch die Insurance Application Architecture von IBM 1, die den gesamten Informationsbedarf einer Versicherung in allgemeingültiger Form abbilden und eine entsprechende Strukturierung in fachliche Domänen vorschlagen. 2.3 Fachliche Anwendungsarchitektur (FAA) Schließlich ist festzulegen, aus welchen eigenständigen Softwarekomponenten ein Anwendungssystem fachlich zusammengesetzt wird. Hier sind Fragen folgender Art zu beantworten: (1) Welche Geschäftsprozesse sind durch die Anwendung zu unterstützen? Soll der Benutzer 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äftsprozesse 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 und

4 Viele der hier erwähnten Aspekte können ebenfalls in Form vorproduzierter Architekturkomponenten abgedeckt werden, so etwa (1) durch Workflowmanagement-Funktionen oder (2) durch ein Zeitraummanagement als Bestandteil der Datenzugriffsschicht. Folgende Abbildung zeigt exemplarisch die fachliche Komponenten-Architektur des neuerstellten Bestandsführungssystems für Lebensversicherungen: Geschäftsprozesse Anwendungskern Zugang Änderung Leistung Fort- schreibung Bestandsführung Leben In-/Exkasso spartenspezifische Komponenten Produkt versicherungstechnische Bestandsführung Risikoprüfung Provision wiederverwendbare Services Partner Workflow Schriftgut Dokumente (Archiv) Berechtigung integrierte Kaufsoftware 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 zentrale Software-Engineering-Gruppe wahrgenommen. Dieses Aufgabenpaket umfasst neben der Weiterentwicklung und Wartung zentraler vorgefertigter Komponenten sowie Werkzeugen zur Unterstützung von Softwaredesign, -generierung und Konfigurationsmanagement 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 durchgefü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 beschleunigen. Zum anderen ist zu erwarten, dass sich der durch T-Änderungen verursachte Wartungsaufwand aufgrund der Trennung der Anwendungslogik von technischen Aspekten verringert

5 Um diese Hypothesen mit harten Daten zu überprüfen, wird seit 2000 für Projektstichproben nachträglich die AE-Produktivität ermittelt, d.h. es erfolgt eine Gegenüberstellung der fachlichen Systemgröße in Function-Points (kurz: FP) zum eingesetzten AE- Aufwand für Entwurf, Implementierung und Test. Projekt Produktivität [h/fp] Bf-Leben Basis, ,2 Bf-Leben Release, ,7 Bf-Sach Basis, ,2 Bf-Sach Release, ,1 PoS-Sach Basis, ,8 PoS-Sach Release, ,6 eb-portal Basis, ,4 eb-portal Release, ,8 Benchmark 2 12,3 System Wartungsquote 3 [PT/kFP] Bf-Leben, ,0 Bf-Sach, ,0 Benchmark 4 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 Weiterentwicklungsprojekten 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 PT s für Neu- und Weiterentwicklung sowie PT s für Wartung entsteht damit ein Kapazitätseffekt von PT s. Saldiert mit den Architekturinvestitionen ergibt sich dadurch ein positiver jährlicher Netto-Effekt von ca. 1,5 Mio ¼ 4 Fazit Architekturgetriebene Software-Entwicklungsprozesse sind eine wirksame Vorgehensweise, um das engineering gap zwischen fachlicher Spezifikation und technischer Implementierung zu verkleinern. Dies ist aus Sicht des Autors nicht nur ein notwendiger Schritt, um die Risiken großer Individualentwicklungen beherrschbar zu machen, sondern 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 Als Vergleichswert dient hier der Mittelwert über alle Versicherungsprojekte des ISBSG-Benchmark Release 6, April 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