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.

1. API-Economy bei Financial Services
Kein Stein bleibt auf dem anderen
Michael Hofmann
Hofmann-IT Consulting
Robert Runggatscher
Allgemeines Rechenzentrum GmbH

2. Warum APIs?
Information
Marktdominanz
Unternehmen als Markt

3. Und die Finanzbranche?
Fintecs
Regulatorik
Wandel
Öffnung

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. 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. Vergangenheits-Bewältigung
 Neuschreiben CBS: unwirtschaftlich!
 Variante 1: CBS implementiert API
 Variante 2: API-System vor CBS setzen

7. Vorhandene APIs im CBS

SOAP
 Technische API
 viele Parameter
 funktions-orientiert
 Expertenwissen beim Aufrufer vorhanden

Keine REST API

Konsequenz: neue APIs!

8. Agil werden
Schnell reagieren
2-Speed-IT
Agil adaptieren
ITIL / COBIT

9. Und doch nicht agil sein
„gil“
DevOps
Auftraggeber
Budget

10. Beschleunigung & Große Würfe
Zu langsam, Zeit verloren
Zukunft sichern
Maximum Viable Product

11. Silos
Fachliche Strukturen
API Schnittstelle zum CBS
Keine Landscape
Interne Abläufe

12. Crossfunktionalität
Fach Know-How
Verfügbarkeit von Spezialisten
Volatile Teams
2-Speed-People

13. Prozesse
FeedbackRelease
Betrieb
Abnahme
Support

14. Öffnung
Compliance
Chancen
Billing
Support

15. Menschliches
Arbeitsplatz
Macht
Blockieren
Zukunft
Skills

16. Open Banking
Open minds
Kreativität
Technologie als Treiber

17. Neue Anforderungen

APIs nicht (nur) für Bank-Mitarbeiter

Verfügbarkeit 7x24

Geändertes Lastverhalten

Time to Market

Sandbox

18. Neue Architektur-Paradigmen

REST

Verteilte Systeme

Lose Kopplung

Kleine Deployment-Einheiten

Stateless

Elastische Laufzeitumgebung

Cloud First

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. 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. CBS und API Anforderungen

Verändertes Lastverhalten
 Anbindung API an CBS: synchron/asynchron
 PaaS / Cloud

Templating (Produktkatalog)

Zwischenspeicherung

Orchestrierung oder Choreografie

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. CBS und API Anforderungen

Verteiltes System
 Service Mesh (Istio)
 Konfiguration der Services
 Resilienz
 Traceability
 Health
 Metrics

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