1. Titel der
Präsentation
eingeben
Titel der
Präsentation
eingeben
IT in der Praxis
- LPA –
Aufgaben-
stellungRingvorlesung IT in der Praxis und Industrie
Redner: Stefan Utermark (head of software development)
Datum: 24. April 2013

2. 2
Problemstellung
Nächtliche Berechnung von 20.000 – 100.000 Finanzprodukten in
max. 8h inkl. Persistenz der Analyse-Ergebnisse in eine DB
 Zur Analyse des aktuellen Gesamtbestandes aller relevanten Finanzgeschäfte
einer Bank, bspw. zur bankinternen Risiko-Steuerung (CVA) oder
Vertriebsunterstützung, müssen sämtliche Produkte mind. 1x täglich
berechnet werden.
 Je nach Kunde und Geschäftsgruppe umfasst das Mengengerüst ca. 5.000 bis
mehrere 100.000 Produkte.
 Unter Berücksichtigung von Systemauslastung, Verfügbarkeits- und Backup-
Zeiten stehen für die Analyse in der Nacht ca. 4-8h zur Verfügung.

3. 3
Problemstellung

4. 4
System-Übersicht
Produkt-DB
Calculators
Market Data
Server
App ServerClient

5. 5
Rahmenbedingungen
 Input
Inputdaten aus der Datenbank:
• Daten zur Berechnung eines Geschäfts liegen in DB vor und müssen
eingelesen werden
• Notwendig sind u.a. Metadaten wie Geschäftsnummer und Produkttyp
• Die zu berechnenden Finanzprodukte werden in Form von XML-
Beschreibungen in der DB angelegt (Vgl. Demo_ProductFile_CapFloor.xml)
• Die Menge der Produktdaten ist in der Demo-DB hinzuzufügen
Hinweis zur Umsetzung:
 Zur Demonstration genügt es, die Daten aus der Datenbank zu laden, die
weitere Verwendung insbes. zur Berechnung kann angedeutet werden

6. 6
Überblick: DB-Struktur f. Produkt-Informationen

7. 7
Rahmenbedingungen
 Input
Externe Informationen:
• Zur Berechnung von Cashflow-Szenarien (zukünftige Verläufe werden
angenommen), müssen beispielsweise Indices (Euribor) auf Basis der
aktuellen Marktdaten simuliert werden
• Da alle Berechnungsergebnisse zueinander konsistent sein müssen, wird
jeweils ein Marktdaten-Set des Vortages - c(lose) o(f) b(usiness) – zur
Berechnung verwendet
• D.h. für alle Berechnung werden die gleichen Marktdaten verwendet
• Ein Marktdaten-Set hat ca. eine Größe von 3-4MB (XML)
• Die Daten werden über einen speziellen Marktdaten-Service zur Verfügung
gestellt
Hinweis zur Umsetzung:
• Zur Demonstration genügt es, einen geeigneten Caching-Mechanismus
anzuwenden, der Mock-Daten in der Größenordnung für die einzelnen
Berechnungen vorhält

8. 8
Rahmenbedingungen
 Berechnung
Berechnung:
• Durchschnittlich benötigt die Berechnung eines Produktes ca. 10sec
• Je nach Ausgestaltung der Produkte kann die Berechnung 0,5 – 600sec
• Treiber hierbei sind Laufzeit (n-Perioden) und Kündigungsrechte (Monte-Carlo-
Simulation im Modell [LMM])
Hinweis zur Umsetzung:
• Die „Berechnung“, sowie die Erzeugung der Ergebniswerte (Cashflows) sollte
so umgesetzt werden, das der Vorgang zufällig zw. 0,5-600sec und im Mittel
10sec dauert
• D.h. 1000 Produkte * 10sec = 2,7h Gesamtrechendauer + Laden & Speichern
• „Ergebnisse“ sollen simuliert erzeugt werden und im Prozess für eine
„gewisse“ Auslastung wären der Berechnungsdauer sorgen

9. 9
Rahmenbedingungen
 Output
Output-Daten in DB speichern:
• Analyseergebnisse müssen pro Geschäft in DB abgelegt werden
• Bei der Berechnung entstehen sowohl skalare Ergebnisse (NPV), als auch Datenreihen
(Cashflows)  d.h. es gibt mehrere Ergebnis-Tabellen
Hinweis zur Umsetzung:
• Pro Geschäft sollen Cashflows-Informationen in die Tabellen
• AnalysisCashflowStructures (1 Struktur),
• AnalysisCashflowPeriods (zufällig zw. 10 &240 Perioden)
• AnalysisCashflowScenarios (10 Szenario-Ergebnisse)

10. 10
Überblick: DB-Struktur f. Berechnungsergebnisse
(Ausschnitt)

11. 11
Überblick: DB-Inhalte f. Berechnungsergebnisse
(Ausschnitt)

12. 12
Rahmenbedingungen
 Mengengerüst
• Beispielhaft sollen die Produkte aus der DB „berechnet“ werden
• Pro Produkt sollen für 10 Szenarien Cashflow-Verläufe
• AnalysisCashflowStructures:
• 1000 Produkte = 1000 Einträge
• AnalysisCashflowPeriods:
• 1000 Produkte * 10-240 Perioden (zufällig & im Mittel 120 Perioden)
= ca. 120.000 Einträge
• AnalysisCashflowScenarios:
• 1000 Produkte * 10-240Perioden * 10 Szenarios = 1.200.000 Einträge
• Die Lösung muss skalierbar umgesetzt werden, sodass es möglich ist mit
wachsenden Geschäftsmengen umgehen zu können
• täglich werden neue Geschäfte abgeschlossen (mehr) & bestehende Geschäfte laufen
aus (weniger)
Zielsetzung: Minimierung der Gesamtlaufzeit

13. 13
Zielsetzung
Erwartete Ergebnisse:
 Vorstellung einer Zielarchitektur, welche in der Lage sein soll, die gestellten
Anforderungen bzgl. Laufzeit und Skalierbarkeit zu erfüllen
 Identifikation von Problemfeldern & Skizzierung von entsprechenden
Lösungsansätzen
 Prototypische Umsetzung der Berechnungskomponente inkl. DB-Interaktion
 Performanceanalyse f. 100, 1.000, 5.000 (& optional 20.000)
Produktergebnisse – die Anzahl der Kalkulatoren sollte dabei von 1-n
gesteigert werden
- Gesamtdauer
- Dauer (Ø) von Laden aus DB, Generieren der Daten & Speichern in DB
gruppiert nach #Kalkulatoren
- Auslastung (Ø) f. CPU & RAM pro Kalkulator
- Auslastung (Ø) f. CPU, RAM & I/O bei DB gruppiert nach #Kalkulatoren

14. 14
Quellen
Entwicklungsumgebung (z.B.):
• Microsoft Visual Studio Express 2012 & C#
http://www.microsoft.com/de-de/download/details.aspx?id=34673
Datenbank:
• Microsoft® SQL Server® 2012 Express bzw. LocalDB
http://www.microsoft.com/de-de/download/details.aspx?id=29062
Performance-Analyse:
• Windows-Leistungsüberwachung (Übersicht)
http://technet.microsoft.com/de-de/library/cc749154.aspx
• MSDN Monitoring SQL Server Performance – MSDN
http://msdn.microsoft.com/en-us/library/ee377023(v=bts.10).aspx

15. 15