Inhalt Die Anforderungen Das Architekturkonzept

Präsentation zum Thema: "Inhalt Die Anforderungen Das Architekturkonzept"—  Präsentation transkript:

0 Stefan Knuth, Stefan Vocke
Kernel StandardRating Ein Architekturkonzept für die Plattform-unabhängige Realisierung der Geschäftslogik komplexer Anwendungen Stefan Knuth, Stefan Vocke

1 Inhalt Die Anforderungen Das Architekturkonzept
Die technische Umsetzung Der Mainframe Fazit und Rückblick © PPI AG

2 Die Anforderungen Ausgangslage
Ein Verband von Kreditinstituten entwickelt verschiedene Verfahren für die Umsetzung der Richtlinien des Baseler Akkords (Basel II) Mitglieder des Verbandes sind ca. 500 Kreditinstitute, damit werden ca. 30% des deutschen Bankenmarktes abgedeckt Teil der Umsetzung sind mehrere Rating-Verfahren Rating: Verfahren für die Berechnung und Klassifizierung der Ausfallwahrscheinlichkeit von Kreditnehmern Eines dieser Verfahren betrifft das Standardkreditgeschäft mit Firmenkunden („Standardrating“) Komplexes Verfahren: über 30 verschiedene Geschäftsegmente, über 1000 Attribute Ergebnis des bankfachlichen Projektes ist eine Verfahrensdokumentation und ein Prototyp (Excel, Visual Basic) Aufgabe ist nun, das Verfahren in produktreife Anwendungssoftware umzusetzen und diese in die Fläche zu bringen © PPI AG

3 Die Anforderungen Die IT-Organisation
Die Versorgung der Gruppe mit IT-Dienstleistungen ist organisatorisch sehr heterogen Mehrere große Rechenzentren, die eine weitgehende Komplettversorgung ihrer Institute betreiben Mittelgroße IT-Dienstleister, die ein oder mehrere Institute mit speziellen Dienstleistungen versorgen (z.B. Software, IT-Betrieb, Application Service Providing, ...) „Selbstversorger“: Institute mit eigenen IT-Abteilungen © PPI AG

4 Die Anforderungen Die IT-Technik
Die Versorgung der Gruppe mit IT-Dienstleistungen ist technisch sehr heterogen Die IT-Dienstleister haben unterschiedliche IT-Strategien und Technologien im Einsatz Die Durchdringung mit moderner Technologie ist sehr unterschiedlich weit fortgeschritten Diskutierte Ansätze zur Umsetzung des Verfahrens in Informatik-Anwendungen CICS-Transaktionen, Cobol, DB/2 3-Schichten-Anwendung: Server: „Started Task“ im z/OS, Middle Tier: BEA Weblogic, Client: Fat Client in C++ Web-Anwendung, HTML-Oberflächen, Java-Server, J2EE Client/Server: Java, Swing-GUI ... und noch weitere © PPI AG

5 Die Anforderungen Herausforderung
Verfahren muss von der Bankenaufsicht abgenommen werden Hohe Qualitäts- und Dokumentationsanforderungen Fachliche Einheitlichkeit muss sicher gestellt sein - sonst Einzelprüfungen in 500 Instituten! Also: Zur Erreichung der Ziele muss so viel Software wie möglich zentral entwickelt und wiederverwendet werden. Gleichzeitig muss jedoch den einzelnen IT-Strategien Rechnung getragen werden d.h. eine Anwendung für alle geht nicht. © PPI AG

6 Das Architekturkonzept Der Lösungsansatz: Rating-Kernel
Realisierung der Geschäftslogik des Verfahrens in einer Funktionsbibliothek, die in die unterschiedlichen IT-Strategien eingebunden werden kann: StandardRating-Kernel Leitsätze: In den Kernel gehört alles, was zur Sicherstellung der fachlichen Einheitlichkeit erforderlich ist Nicht in den Kernel gehört alles, was mit Benutzerdialogen, Druck und sonstigem I/O, Datenhaltung und Anwendungssteuerung zu tun hat © PPI AG

7 Das Architekturkonzept Im Überblick
Architekturbild Rating-Anwendung GUI Rating-Kernel Aufrufschnittstelle Callback-Schnittstelle Datenhaltung © PPI AG

8 Technische Umsetzung Der Kernel
StandardRating-Kernel: Funktionsbibliothek in ANSI-C Schnittstelle: C-Funktionsaufrufe und C-Callback-Funktionen Anwendung (beim Kunden): Aufruf der C-Funktionen Implementierung der Callback-Funktionen Entwickelt wird bei PPI unter Linux Auf die folgenden Zielplattformen wird der Kernel portiert Windows (C-Kernel – Java-Anwendung) Solaris (C-Kernel – Java-Anwendung) z/OS (C-Kernel – C++ und Cobol-Anwendung) AIX (Java-Kernel – Java-Anwendung) Auf allen Plattformen wird automatisiert getestet © PPI AG

9 Technische Umsetzung Aufgaben im Projekt
Programmierung des Kernels in ANSI-C auf Linux Erzeugung der html-Schnittstellen-Spezifikation auf Linux Programmierung des Java-Wrappers und der Java-Test-Suite auf Linux Erstellung der Testfälle auf Linux Portierung auf die Plattformen Build auf den Plattformen Test auf den Plattformen © PPI AG

10 Der Mainframe Vorarbeiten unter Linux
Programmierung des Kernels in ANSI-C Eclipse CVS Shell-Skripte gmake mit gcc Programmierung der Test-Suite (Pendant zur Anwendung) Java Java-Wrapper mit JNI-Interface Erstellung der Testdaten Transfer der Sourcen zum Mainframe via ftp makefile.hmk (h-make – Portierung von gmake nach z/OS) *.c, *.h (Einspielung in die DATASETs unter z/OS) Bereitstellen der Quelltexte des Wrappers für direkten Zugriff © PPI AG

11 Der Mainframe z/OS UNIX System Services (USS)
Transfer der Test-Suite und der Testdaten NFS (Mount der Linux-Platten) Binär oder konvertiert von ASCII in EBCDIC JAR-Dateien (also die kompilierten Klassen) Testdaten Erstellen des Wrappers gmake wie unter Linux Zugriff auf Linux-Verzeichnisse (NFS) shared library für die Test-Suite s.o. Sidedecks des Wrappers für den Kernel Im link-Schritt wird auf das Sidedeck des Rating-Kernels (z/OS) referenziert © PPI AG

12 Der Mainframe TSO (Time-Sharing Option)
Build des Kernels (Compile und Link) hmake mit Makefile (makefile.hmk) Erstellung der DLL (z/OS-Kernel, wir auch von der Test-Suite benutzt) und einem Sidedeck (Liste der nutzbaren Schnittstellen des z/OS-Kernels) Aufruf des Kernel-Tests JCL (Job Control Language - Steuersprache für Stapelverarbeitungen) Ergebnisse in USS Ausliefern über eine sichere Datenverbindung von Host zu Host © PPI AG

13 Der Mainframe TSO (Time-Sharing Option)
Linux: Programmierung des Kernels Linux: Pflege der Testumgebung Linux: Transfer der Sourcen zum Mainframe USS: Transfer der Test-Suite und der Testdaten TSO: Build des Kernels USS: Erstellen des Wrappers TSO: Aufruf des Kernel-Tests USS: Analyse der Testergebnisse TSO: Auslieferung © PPI AG

14 Rückblick und Fazit Zahlen und Fakten
Seit 2002 in Produktion Abdeckung in der Finanzgruppe: nahezu 100% der Institute Bis zu fünf Anwendungen integrieren den Kernel Davon 2 Mainframe-basiert Prozentsatz der Institute mit Mainframe-Lösungen: etwa 50% Sechs Hauptreleases, mehrere größere Erweiterungen Gesamtvolumen IT-Umsetzung bei allen Beteiligten: mehrere 10 Mio Euro Nur Kernel: Mehr als 5000 Entwicklertage 910 Funktionsschnittstellen insgesamt, mit 82 aufrufbaren Funktionen Kernel: LOC Erreichte Synergie: etwa 60 bis 70% Bei der Umsetzung eines Releases können mittlerweile etwa zwei Drittel der Anforderungen innerhalb des Kernels (und damit zentral) umgesetzt werden Aufwand für die Plattform-Unterstützung: etwa 5 % der Entwicklungsaufwände © PPI AG

15 Rückblick und Fazit Zahlen und Fakten
Unter anderem zeigt die Geschichte des Kernels StandardRating eines: Der Mainframe ist keine exotische Welt, in der Software anders entwickelt wird als auf anderen Plattformen [na ja, ein bisschen schon!], anders aussieht [ich habe den Kernel bisher nur in Datasets gesehen!] als auf anderen Plattformen und die natürlich überhaupt nicht portabel ist. Vielmehr ist es möglich, portable (Server-)Software zu entwickeln, die mit geringen Kosten auf verschiedenen Plattformen und auch auf dem Mainframe gut läuft. © PPI AG