Il problema
Un nostro cliente Finance ci ha chiesto di analizzare 3 richieste del GDPR che riguardano lo sviluppo di software applicativo su IBMi - AS400
- Privacy by Design e by Default
- Diritto all'oblio
- Accountability
Solo questi tre temi fanno tremare le solide costruzioni applicative di banche, assicurazioni, multinazionali.
Sono delle bombe innescate che richiedono immensi investimenti che poche aziende possono affrontare.
Mi esprimerò con parole semplici da sviluppatore software e non come un legale, quindi perdonate qualche imprecisione.
- Privacy by Design e by Default significa che il titolare del trattamento deve assicurarsi di mettere in atto “misure tecniche e organizzative adeguate per garantire che la progettazione software tenga conto per prima cosa della sicurezza dei dati personali. In questo caso possono entrare in gioco varie soluzioni di crittografia o di mascheratura dei dati per la pseudonimizzazione. “Tale obbligo vale per la quantità dei dati personali raccolti, la portata del trattamento, il periodo di conservazione e l’accessibilità.
- Diritto all'oblio significa che se per un qualsiasi motivo un contatto vuole che vengano cancellati i suoi dati dal vostro database voi dovete essere in grado di farlo su tutti i vostri sistemi, email, ecommerce, anagrafiche, ... salvo il caso in cui i dati debbano essere mantenuti per motivi fiscali
- Accountability ogni azione deve essere tracciata e dimostrabile
per fare questo Il nostro cliente doveva rivedere pesantemente il proprio sistema informativo,
Ai problemi posti dal GDPR si sommano altri non meno gravi:
- le applicazioni sono immense: milioni di righe di codice
- sono applicativi complessi RPG di n livelli II, III, IV, ILE o Cobol
- Ideale suddividerli in service program più piccoli e più comprensibili
- Han messo le mani generazioni di programmatori in 30+ anni
- Il team di sviluppo è di oltre 70 sviluppatori RPG e Cobol
- che usano stili diversi di programmazione
- alcuni prossimi alla pensione
- c'è poca documentazione
- pochi commenti dentro ai programmi
- i database non sono relazionali (non contengono le relazioni tra i file)
- non effettuare i dovuti test può comportare costi imprevedibili (dalle statistiche un errore risolto dopo costa 100 volte di più)
Migrare su un'altra piattaforma si è rivelata è una falsa soluzione infatti:
- lanciarsi in un progetto di migrazione senza conoscere approfonditamente le logiche esistenti che futuro può avere ?
La soluzione
Il nostro cliente ha trovato in 🔍X-Analysis e nei nostri servizi di consulenza una soluzione a molti dei suoi problemi in quanto con questo tools, dopo una breve formazione iniziale in totale autonomia ha potuto:
- analizzare tutti i propri mastodontici applicativi RPG-Cobol
- vedere le relazioni tra i file ricostruite automaticamente da X-A in base a come lavora il codice RPG cobol
- individuare regole di business in modo da ridurre la complessità di molti programmi
- creare documentazione approfondita
- tracciare e documentare ogni modifica applicativa
- modernizzare il database
- mascherare i dati di test
- individuare bug ed anomalie
- tracciare il comportamento di un campo
- predisporre test approfonditi
- ...
Chiaro che il processo di miglioramento di una mastodontica applicazione non si ottiene dalla sera alla mattina.
Ma attivando X-Analysis il nostro cliente ha dimostrato di avere messo in atto un processo di miglioramento e consolidamento del proprio applicativo.
Quindi si è reso:
- perfettamente aderente alle richieste del GDPR
- ed ha migliorato in modo significativo la propria attività di sviluppo software
Ha trasformato quello che era un costoso e tedioso obbligo di legge in un potente mezzo di miglioramento, consolidamento ed innovazione
