Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Titel derPräsentationeingebenTitel derPräsentationeingebenIT in der Praxis- LPA –Aufgaben-stellungRingvorlesung IT in der ...
2ProblemstellungNächtliche Berechnung von 20.000 – 100.000 Finanzprodukten inmax. 8h inkl. Persistenz der Analyse-Ergebnis...
3Problemstellung
4System-ÜbersichtProdukt-DBCalculatorsMarket DataServerApp ServerClient
5Rahmenbedingungen InputInputdaten aus der Datenbank:• Daten zur Berechnung eines Geschäfts liegen in DB vor und müssenei...
6Überblick: DB-Struktur f. Produkt-Informationen
7Rahmenbedingungen InputExterne Informationen:• Zur Berechnung von Cashflow-Szenarien (zukünftige Verläufe werdenangenomm...
8Rahmenbedingungen BerechnungBerechnung:• Durchschnittlich benötigt die Berechnung eines Produktes ca. 10sec• Je nach Aus...
9Rahmenbedingungen OutputOutput-Daten in DB speichern:• Analyseergebnisse müssen pro Geschäft in DB abgelegt werden• Bei ...
10Überblick: DB-Struktur f. Berechnungsergebnisse(Ausschnitt)
11Überblick: DB-Inhalte f. Berechnungsergebnisse(Ausschnitt)
12Rahmenbedingungen Mengengerüst• Beispielhaft sollen die Produkte aus der DB „berechnet“ werden• Pro Produkt sollen für ...
13ZielsetzungErwartete Ergebnisse: Vorstellung einer Zielarchitektur, welche in der Lage sein soll, die gestelltenAnforde...
14QuellenEntwicklungsumgebung (z.B.):• Microsoft Visual Studio Express 2012 & C#http://www.microsoft.com/de-de/download/de...
15
Nächste SlideShare
Wird geladen in …5
×

Vorstellung der Aufgabenstellung der lpa GmbH im Rahmen der Ringvorlesung

834 Aufrufe

Veröffentlicht am

Veröffentlicht in: Business
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Vorstellung der Aufgabenstellung der lpa GmbH im Rahmen der Ringvorlesung

  1. 1. Titel derPräsentationeingebenTitel derPräsentationeingebenIT in der Praxis- LPA –Aufgaben-stellungRingvorlesung IT in der Praxis und IndustrieRedner: Stefan Utermark (head of software development)Datum: 24. April 2013
  2. 2. 2ProblemstellungNächtliche Berechnung von 20.000 – 100.000 Finanzprodukten inmax. 8h inkl. Persistenz der Analyse-Ergebnisse in eine DB Zur Analyse des aktuellen Gesamtbestandes aller relevanten Finanzgeschäfteeiner Bank, bspw. zur bankinternen Risiko-Steuerung (CVA) oderVertriebsunterstützung, müssen sämtliche Produkte mind. 1x täglichberechnet werden. Je nach Kunde und Geschäftsgruppe umfasst das Mengengerüst ca. 5.000 bismehrere 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. 3Problemstellung
  4. 4. 4System-ÜbersichtProdukt-DBCalculatorsMarket DataServerApp ServerClient
  5. 5. 5Rahmenbedingungen InputInputdaten aus der Datenbank:• Daten zur Berechnung eines Geschäfts liegen in DB vor und müsseneingelesen 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ügenHinweis zur Umsetzung: Zur Demonstration genügt es, die Daten aus der Datenbank zu laden, dieweitere Verwendung insbes. zur Berechnung kann angedeutet werden
  6. 6. 6Überblick: DB-Struktur f. Produkt-Informationen
  7. 7. 7Rahmenbedingungen InputExterne Informationen:• Zur Berechnung von Cashflow-Szenarien (zukünftige Verläufe werdenangenommen), müssen beispielsweise Indices (Euribor) auf Basis deraktuellen Marktdaten simuliert werden• Da alle Berechnungsergebnisse zueinander konsistent sein müssen, wirdjeweils ein Marktdaten-Set des Vortages - c(lose) o(f) b(usiness) – zurBerechnung 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ügunggestelltHinweis zur Umsetzung:• Zur Demonstration genügt es, einen geeigneten Caching-Mechanismusanzuwenden, der Mock-Daten in der Größenordnung für die einzelnenBerechnungen vorhält
  8. 8. 8Rahmenbedingungen BerechnungBerechnung:• 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) sollteso umgesetzt werden, das der Vorgang zufällig zw. 0,5-600sec und im Mittel10sec 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. 9Rahmenbedingungen OutputOutput-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-TabellenHinweis 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. 10Überblick: DB-Struktur f. Berechnungsergebnisse(Ausschnitt)
  11. 11. 11Überblick: DB-Inhalte f. Berechnungsergebnisse(Ausschnitt)
  12. 12. 12Rahmenbedingungen 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 mitwachsenden Geschäftsmengen umgehen zu können• täglich werden neue Geschäfte abgeschlossen (mehr) & bestehende Geschäfte laufenaus (weniger)Zielsetzung: Minimierung der Gesamtlaufzeit
  13. 13. 13ZielsetzungErwartete Ergebnisse: Vorstellung einer Zielarchitektur, welche in der Lage sein soll, die gestelltenAnforderungen bzgl. Laufzeit und Skalierbarkeit zu erfüllen Identifikation von Problemfeldern & Skizzierung von entsprechendenLö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-ngesteigert werden- Gesamtdauer- Dauer (Ø) von Laden aus DB, Generieren der Daten & Speichern in DBgruppiert nach #Kalkulatoren- Auslastung (Ø) f. CPU & RAM pro Kalkulator- Auslastung (Ø) f. CPU, RAM & I/O bei DB gruppiert nach #Kalkulatoren
  14. 14. 14QuellenEntwicklungsumgebung (z.B.):• Microsoft Visual Studio Express 2012 & C#http://www.microsoft.com/de-de/download/details.aspx?id=34673Datenbank:• Microsoft® SQL Server® 2012 Express bzw. LocalDBhttp://www.microsoft.com/de-de/download/details.aspx?id=29062Performance-Analyse:• Windows-Leistungsüberwachung (Übersicht)http://technet.microsoft.com/de-de/library/cc749154.aspx• MSDN Monitoring SQL Server Performance – MSDNhttp://msdn.microsoft.com/en-us/library/ee377023(v=bts.10).aspx
  15. 15. 15

×