Nell’intervento Stefano Olivotto di Crédit Agricole Italia ha illustrato la sua esperienza nell’adozione di uno strumento di API management e di un processo di gestione delle API, con una particolare focalizzazione su metodologia di adozione, sulle principali sfide indirizzate e un verticale sul livello di automazione raggiunto mediante l’adozione di tecniche di DevOps. Per maggiori informazioni scrivi a sales@profesia.it

1. www.credit-agricole.it
API Transformation in Crédit Agricole Italia
12 Ottobre 2023
Stefano Olivotto
WSO2 Oxygenate 2023

2. CRÉDIT AGRICOLE
Chi siamo
2

3. 3
Il Gruppo Crédit Agricole nel mondo
U n G r u p p o i n t e r n a z i o n a l e c o n u n B u s i n e s s M o d e l u n i c o
52 milioni
Il Gruppo Crédit Agricole comprende
Crédit Agricole S.A. e le Casse Regionali.
È tra i primi 10 Gruppi Bancari
al mondo per Total Assets
Un modello unico di Banca di Prossimità Universale, sulla base
della complementarità tra le attività del Gruppo, in Francia, in Italia e nel mondo
PRESENZA NEL MONDO STRUTTURA E ORGANIZZAZIONE DEL GRUPPO
C L I E N T I
142 mila
C O L L A B O R AT O R I
48
PA E S I
11 mila
F I L I A L I
10,9 MLN
di azionisti
2410
Banche locali
39 Casse Regionali
in Francia
DETENGONO LA MAGGIORANZA DEL CAPITALE DI CA S.A (55,3%)
GESTIONE
DEL RISPARMIO
E ASSICURAZIONI
BANCA
DI PROSSIMITÀ
INTERNAZIONALE
SERVIZI
FINANZIARI
SPECIALIZZATI
GRANDI
CLIENTI
ATTIVITÀ
E FILIALI
SPECIALIZZATE

4. 4
Modello di business e posizionamento
I numeri chiave Giugno 2023
Modello di business pienamente realizzato in Italia, che rappresenta il
secondo mercato del Gruppo (dopo la Francia)
Ricavi 4,4 Md €
S1 ‘23: 2,4 Md (+20% a/a)
RN 1,1 Md €
S1 ‘23: 739 Mln (+29% a/a)
Operatore nel
Credito al Consumo
Top
2
Operatore nel
Risparmio Gestito
3°
Operatore in
Bancassicurazione
(Ramo Vita)
4°
Posizionamento
16.400
Dipendenti
329
Md€
Raccolta totale
1.230
Sportelli
97 Md€
Impieghi
*
5,9 Mln
clienti
Privati, professionisti,
imprese, corporate,
istituzioni
I numeri chiave 2022
e S1 2023 (var. a/a)
Il Gruppo Crédit Agricole in Italia
S i a m o p r e s e n t i c o n t u t t e l e l i n e e d i b u s i n e s s

5. API TRANSFORMATION
La nostra esperienza
5

6. 6
Contesto
Automazione
API & Microservizi
• Atomicità
• Riusabilità
• Flessibilità
• Disaccoppiamento
Containerizzazione
• Infrastructure as a code
• Scalabilità
• Architettura Cloud ready & native
• Elevata automazione & controllabilità
DevOps
• Agile
• DevOps as a Platform
Obiettivi Business
• Ridurre costi di sviluppo e gestione
• Consentire una migliore gestione della
compliance sui rischi e i requisiti normativi
• Ridurre il time-to-market

7. 7
Obiettivi IT4IT
… e traguardi IT abilitanti
Riduzione time to market
nello sviluppo di nuove soluzioni o
per adeguare le esistenti
Riduzione 10-30%
dell’elapsed progetti
Riduzione 30% TTM per
lancio nuovi prodotti/servizi
Digitalizzazione dell’offerta
sia nelle fasi di vendita che
post-vendita
Aumento di 15 p.p. del
livello di digitalizzazione
dell’offerta (vendita e post-
vendita)
Soddisfazione utenti
sia interni sia esterni (clienti)
Aumento di 10 p.p. del
livello di soddisfazione
interna sulle procedure
Contenimento crescita spese Run
rispetto al trend inerziale
Contenimento crescita
spesa Run (-40 bips)
KPI
Obiettivi banca …
Evoluzione architetturale, applicativa e infrastrutturale:
Migrazione del 15% del carico canali su Cloud
Livello di APIzzazione dei servizi tradizionali / obsoleti al
50%
Ripristino del disaster recovery immediato sul mondo
Mainframe
Modernizzazione del core-banking:
Riduzione del 35% del tempo passato dai gestori su
applicazioni legacy
Data centricity:
Completa dismissione piattaforme «dati» legacy a favore
del DataLake
Decommissioning costi «Run»:
Crescita zero componente MIPS bolletta mainframe
Contenimento crescita spesa Run (-40 bips)

8. 8
Architettura target
Cyber
Security
/
IAM
&
Web
Access
Manager
Channel
Agility
Layer
Data
layer
Presentation Layer
Infrastructure
layer
Touchpoint
Ecosistema
API Layer
Governance
&
Monitoring
Cross
Functional
RPA e
Intelligence
Automation
Data
Governance&
DataQuality
Core
Layer
Partner
Open
Banking
Fintech
DevOps
Core Banking
Mainframe
Master Data
Esposizione
servizi Backend
Open
Master Data
µS
µS
Infrastruttura
On-premises
Event Driven
Architecture
Master Data
Offloading
Big Data
Master Data
Advanced
Analytics & BI
µS
µS
AI & ML
Scrivania
Digitale
PaaS
IaaS
SaaS
Landing Zone
Orchestratore
(gestore
contesto)
Documentale
Data
Processing
Scheda
Cliente
Internet
& Mobile
Banking
MicroGateway
Presentation Layer: utilizzo del
pattern architetturale a Micro-
frontend per le nuove applicazioni
web
Landing Zone Multicloud: attivazione e abilitazione all’uso di soluzioni infrastrutturali su cloud pubblico
Orchestratore: gestione di tutti gli use case
in ottica omnicanale
Piattaforma IAM: altamente scalabile e capace di supportare la
federazione con applicazioni di terze parti
Documentale: integrato da tutte le applicazioni.
Event Driven Architecture:
modello di architettura che permette
di realizzare applicazioni altamente
scalabili.
Advanced Analytics & BI: ampliamento
degli use case ML in ambito marketing e
credito; facilità di accesso ai dati da parte di
utenti che hanno esigenze elaborative
semplici
Data Lake: alimentazione «batch» e «real
time/ad evento». Target ~95% dei dati
aziendali presenti nel DataLake e
integrazione con fonti dati esterne per utilizzo
AI
Data Governance & Data Quality: rendere
autonomi gli utenti «data owner» nelle attività
di competenza; ampliamento delle
funzionalità in ottica «Algo-Governance»
(governo degli algoritmi di intelligenza
artificiale in uso)
Scrivania Digitale: frontend unico
per gli use case di qualsiasi utente
CAI (gestori, cassieri, responsabili
di filiale, ecc.)

9. 9
API Transformation: approccio CAI
Tecnologia
Abilitare l’esposizione di servizi
solo su WSO2 (es. CWS, µS)
Processo
Inserirsi negli step di
processo/change già
esistenti
Cultura
Rendere l’APIzzazione
parte della cultura
tecnologica aziendale

10. 10
API Transformation: punti di attrito
Richiesta di
pubblicazione
Controllo della
richiesta
(documentazione,
nomenclatura,
autorizzazioni, ecc.)
Pubblicazione Richiesta di change
Controllo
autorizzazioni
Esecuzione change
• Resistenza al cambiamento
• Introduzione di una metodologia standard da rispettare che limita gli spazi di autonomia dei singoli
team applicativi
• Difficoltà ad inserire il nuovo processo nella routine progettuale degli applicativi e nella cultura
aziendale
• Potenziali step di rallentamento delle attività progettuali
• Gestione di un componente infrastrutturale con elevate implicazioni architetturali e impatti sul
change management

11. 11
API Transformation: soluzione individuate
Richiesta di
pubblicazione
Controllo della
richiesta
(documentazione,
nomenclatura,
autorizzazioni, ecc.)
Pubblicazione Richiesta di change
Controllo
autorizzazioni
Esecuzione change
• Creazione di webinar, documentazione, incontri O2O e di gruppo con applicativi e catena manageriale
• Sfruttare i punti esistenti di change management e gestione progettuale/applicativa:
• Disegno architetturale, certificazione utente, uso dei medesimi strumenti di change, ecc.
• Punti di controllo per valutare il corretto recepimento del nuovo processo
• Approccio «flessibile», evitando di bloccare le progettualità più urgenti ma dando comunque evidenza degli step richiesti
• Casella di supporto per assistenza su processo e problem solving su problematiche API
• Costituzione di un team multidisciplinare per gestire le differenti attività
• Automatizzare il più possibile per richiedere alle persone solamente le attività di controllo e a valore aggiunto
• Cultura di gestione dell’errore (timeout API, ecc.) al di là della reazione all’incident
• Diffondere i vantaggi di una gestione standard e centrale:
• Servizi documentati
• Compliance «automatica»
• Dati di produzione: sapere chi chiamo quali servizi, con quali volumi e tempi di risposta
• Controllo proattivo
• «Stupore» da parte dei colleghi per le capacità di analisi consentite da WSO2 e l’identificazione di potenziali problematiche prima che si verifichino
(sospensioni API, ecc.)

12. 12
Microgateway
• Assenza di portali di
gestione/amministrazione
• Nessun catalogo API
• Le configurazioni vanno fatte a livello
di build, codice, file di conf, ecc.
• Modifiche «a caldo» complicate e
limitate
• Pod molto leggeri (riavvio <1min)
• Infrastruttura self-contained (no DB,
no NFS, ecc.)
• Predisposto all’automazione (build,
deploy, ecc.)
• Possibilità di dedicare un microgw per
ogni applicazione chiamante
• Interfaccia intuitiva e di facile
utilizzo
• Utilizzabile da chiunque come
catalogo per le API e la
documentazione
• Dipendenza da componenti
esterne (DB, NFS, ecc.)
• Riavvio pod in circa 15 min
• Potenziali SPOF in quanto gestisce
tutto il traffico API
Microgateway WSO2 standard
Adottare il meglio di entrambe le piattaforme. Usare WSO2 standard come catalogo API e master delle informazioni per API
pubblicate e sottoscritte (swagger, endpoint, ecc.), buildare il microgw a partire dalle informazioni su WSO2 standard e
utilizzarlo per la sola erogazione del servizio a un insieme selezionato di applicazioni critiche
Soluzione CAI

13. 13
Focus su automazione: i benefici
Sicurezza
• L’uso di componenti standard aumenta
la sicurezza grazie all’uso policy di
sicurezza standard
• Integrazione di DevSecOps
(SonarQube, Checkmarx, Image
Scanning, etc.)
Green IT
Automazione e container consentono
di adattare facilmente le risorse al
carico, evitando così lo spreco di
risorse
Container & Cloud
• Rilasciabile in 10 minuti VS 1h di una VM
• Alta scalabilità per supportare il workload
• Facile da aggiornare: 20 minute per il
download della nuova immagine container
aggiornata
• Consentire architettura/applicazioni cloud
native
API
Tempo di deployment da 2
giorni a 20 minuti
DevOps
Riduzione dell’80% di e-mail
e allegati per UAT
Osservabilità
Tutti gli elementi sono
standardizzati,
monitorati e memorizzati
in repository

14. 14
Rilascio di un microservizio
Creazione
Work Item
Sviluppo del
microservizio
Pubblicazione
e
sottoscrizione
API
Creazione
(build) del
microgateway
Rilascio del
microgateway
Uso dell’API
tramite
microgateway
Richiesta di
nuovo
microservizio
Contratto
infrastrutturale
40
minuti

15. 15
Ciclo di vita API
Pubblicazione
API/richiesta di change
• Work Item Azure
DevOps
Richiesta approvata
• Work Item
approvato
Deployment
automatizzato su WSO2
• Pipeline Jenkins
• Repository GIT
Vecchio processo Nuovo processo
4 attori
E-mail, form, documenti
Configurazioni manuali
2 giorni in media
2 attori
Work item Azure
Completamente
automatizzato
20 minuti in media

16. 16
Rilascio microgateway
Build microgateway
•Pipeline Jenkins
•Push su DTR
Deploy microgateway
•Pipeline Jenkins
5 minuti

17. 17
Volumi mensili chiamate API
0
200
400
600
800
1.000
1.200
m
a
r
-
2
1
m
a
g
-
2
1
l
u
g
-
2
1
s
e
t
-
2
1
n
o
v
-
2
1
g
e
n
-
2
2
m
a
r
-
2
2
m
a
g
-
2
2
l
u
g
-
2
2
s
e
t
-
2
2
n
o
v
-
2
2
g
e
n
-
2
3
m
a
r
-
2
3
m
a
g
-
2
3
l
u
g
-
2
3
s
e
t
-
2
3
Milioni
WSO2 standard Totali

18. 18
API pubblicate
0
100
200
300
400
500
600
a
p
r
-
2
0
g
i
u
-
2
0
a
g
o
-
2
0
o
t
t
-
2
0
d
i
c
-
2
0
f
e
b
-
2
1
a
p
r
-
2
1
g
i
u
-
2
1
a
g
o
-
2
1
o
t
t
-
2
1
d
i
c
-
2
1
f
e
b
-
2
2
a
p
r
-
2
2
g
i
u
-
2
2
a
g
o
-
2
2
o
t
t
-
2
2
d
i
c
-
2
2
f
e
b
-
2
3
a
p
r
-
2
3
g
i
u
-
2
3

19. GRAZIE PER L’ATTENZIONE!
19