Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

API-Economy bei Financial Services – Kein Stein bleibt auf dem anderen

33 vues

Publié le

Im Zuge der voranschreitenden Digitalisierung werden Projekte im Umfeld der API-Economy immer wichtiger. Die Umsetzung solcher Projekte hat in der Regel enorme Auswirkungen auf das gesamte Unternehmen. Vor allem vor dem Hintergrund, dass es im Grunde in jedem Unternehmen sog. Legacy-Systeme gibt, die integriert werden müssen, denn kaum ein Unternehmen im Bereich der Financial Services hat den Vorteil, auf der grünen Wiese starten zu können.

Durch den Schwenk von Legacy-Systemen, die eher monolithisch aufgebaut sind, hin zu Microservices kommen weitere Herausforderungen auf die Projekte zu. Die weitreichenden Auswirkungen erstrecken sich von technischen Herausforderungen verbunden mit der Neuausrichtungen der Softwarearchitektur bis hin zu Konsequenzen bzgl. Betriebsführung und organisatorischen Veränderungen. Im Grunde bleibt hier im Unternehmen kein Stein auf dem anderen.

Wir wollen in dieser Session zeigen, welche Fragestellungen exemplarisch auftreten können und welche Lösungsalternativen diskutiert werden müssen. Dabei werden wir auf die organisatorischen und die technischen Problemfelder in Verbindung mit der veränderten Softwarearchitektur genauer eingehen. Am Ende der Session sollten die Teilnehmer ein Gespür dafür bekommen, wo die Herausforderungen bei solchen Projekten liegen.

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

API-Economy bei Financial Services – Kein Stein bleibt auf dem anderen

  1. 1. API-Economy bei Financial Services Kein Stein bleibt auf dem anderen Michael Hofmann Hofmann-IT Consulting Robert Runggatscher Allgemeines Rechenzentrum GmbH
  2. 2. Warum APIs? Information Marktdominanz Unternehmen als Markt
  3. 3. Und die Finanzbranche? Fintecs Regulatorik Wandel Öffnung
  4. 4. Core Banking System  Entstanden im „letzten Jahrtausend“  Mehrere 100 bzw. 1000 PT  Ältere Architektur-Paradigmen  Kein Fokus auf API (Bank-Mitarbeiter)  Einstellige Anzahl Releases/Jahr
  5. 5. Architektur-Paradigmen von damals  Client-Server, Mainframe (Batch, Online)  Monolith  Starre Laufzeitumgebung  Enge Kopplung (verteilte Transaktionen)  Stateful Server  Coarse-Grained Interfaces  Role Based Access Control (RBAC)
  6. 6. Vergangenheits-Bewältigung  Neuschreiben CBS: unwirtschaftlich!  Variante 1: CBS implementiert API  Variante 2: API-System vor CBS setzen
  7. 7. Vorhandene APIs im CBS  SOAP  Technische API  viele Parameter  funktions-orientiert  Expertenwissen beim Aufrufer vorhanden  Keine REST API  Konsequenz: neue APIs!
  8. 8. Agil werden Schnell reagieren 2-Speed-IT Agil adaptieren ITIL / COBIT
  9. 9. Und doch nicht agil sein „gil“ DevOps Auftraggeber Budget
  10. 10. Beschleunigung & Große Würfe Zu langsam, Zeit verloren Zukunft sichern Maximum Viable Product
  11. 11. Silos Fachliche Strukturen API Schnittstelle zum CBS Keine Landscape Interne Abläufe
  12. 12. Crossfunktionalität Fach Know-How Verfügbarkeit von Spezialisten Volatile Teams 2-Speed-People
  13. 13. Prozesse FeedbackRelease Betrieb Abnahme Support
  14. 14. Öffnung Compliance Chancen Billing Support
  15. 15. Menschliches Arbeitsplatz Macht Blockieren Zukunft Skills
  16. 16. Open Banking Open minds Kreativität Technologie als Treiber
  17. 17. Neue Anforderungen  APIs nicht (nur) für Bank-Mitarbeiter  Verfügbarkeit 7x24  Geändertes Lastverhalten  Time to Market  Sandbox
  18. 18. Neue Architektur-Paradigmen  REST  Verteilte Systeme  Lose Kopplung  Kleine Deployment-Einheiten  Stateless  Elastische Laufzeitumgebung  Cloud First
  19. 19. „Alter“ des CBS  Liste der technischen Schulden  Klassische Findings  Business Logik im Client Layer (JSF, Struts, MVC) fehlt somit im REST-Endpoint  Business Logik mit Variationen mehrfach vorhanden  Eigene Implementierungen die Marktstandards verhindern  Höhere Release-Frequenz möglich?
  20. 20. CBS und neue Architektur  CBS Schnittstellen  Funktionsorientiert  ohne Unterteilung  eigene Datenelemente  keine HTTP Status Codes  Fehlertexte (Datenschutz)  Idempotenz  Stateless  Verteilte Transaktionen  GUI-Layer und REST-Layer
  21. 21. CBS und API Anforderungen  Verändertes Lastverhalten  Anbindung API an CBS: synchron/asynchron  PaaS / Cloud  Templating (Produktkatalog)  Zwischenspeicherung  Orchestrierung oder Choreografie
  22. 22. CBS und API Anforderungen  Neue Systeme  API Gateway  Service Registry  PaaS  ...  Security  Access Control List  OAuth/OpenId Connect  Security Propagation  Zugriffsrechte (CBS vs. API Layer)
  23. 23. CBS und API Anforderungen  Verteiltes System  Service Mesh (Istio)  Konfiguration der Services  Resilienz  Traceability  Health  Metrics
  24. 24. REAL CHANGE only happens when you WANT IT, and WANT IT A LOT MORE THAN YOU FEAR IT, and want it a lot more than you FEAR STAYING RIGHT WHERE YOU ARE NOW. Until then, you will only commit to the level of DIPPING YOUR TOE in the deep end of the „CHANGE POOL“ and lie to yourself that this PROVES you are at least TRYING TO CHANGE. NO, YOU ARE NOT! Der Change als Herzstück fitbeliever.tumbler.com Scott Abel

×