Quanto software c’è davvero dentro un software?

Quando si sviluppa una piattaforma software, il codice creato appositamente per quel sistema rappresenta solo una parte della tecnologia che ne permette il funzionamento.

Alla base possono esserci framework, librerie, pacchetti, database, API e altri componenti che svolgono funzioni diverse, dall’autenticazione e dallo scambio di dati fino al logging e alla sicurezza.

È così che viene sviluppato il software moderno. I team si affidano a tecnologie consolidate e componenti esistenti, invece di sviluppare ogni funzionalità da zero.

Ma con l’aumentare della complessità di un sistema, diventa sempre più importante porsi un’altra domanda: sappiamo esattamente su cosa si basa?

È qui che entra in gioco la Software Supply Chain.

Ogni componente diventa parte del sistema

In un progetto software, la scelta di una libreria o di un framework può sembrare una decisione relativamente semplice. In realtà, quel componente entra a far parte del ciclo di vita del sistema.

Ha una propria versione, delle dipendenze, aggiornamenti di sicurezza e un proprio ciclo di manutenzione. Nel tempo può essere aggiornato, modificato o arrivare alla fine del supporto.

Per sistemi progettati per funzionare ed evolvere nel corso degli anni, questi aspetti sono importanti.

In ALSoft, lo sviluppo di un sistema non viene considerato esclusivamente dal punto di vista delle funzionalità da realizzare. L’architettura deve tenere conto anche delle tecnologie e delle dipendenze su cui il sistema farà affidamento durante tutto il suo ciclo di vita.

Perché una scelta tecnica fatta oggi influenzerà il modo in cui il sistema verrà gestito e mantenuto domani.

Ogni componente amplia l’ecosistema del sistema

Un componente di terze parti può rappresentare solo una piccola parte di un’applicazione, ma dal momento in cui viene integrato entra a far parte dell’ecosistema tecnologico che deve essere gestito nel tempo.

Le versioni cambiano, vengono rilasciati aggiornamenti, emergono nuove vulnerabilità e alcune tecnologie, con il tempo, devono essere sostituite. Inoltre, un componente può dipendere a sua volta da altri componenti, creando diversi livelli di dipendenze all’interno dello stesso sistema.

Nei sistemi complessi, quindi, non conta soltanto scegliere le tecnologie più adatte, ma anche comprendere chiaramente come sono collegate tra loro e quali dipendenze esistono.

Questa visibilità consente anche di gestire meglio l’evoluzione del sistema. Quando un componente viene aggiornato, modificato o interessato da un problema di sicurezza, è possibile valutarne con maggiore precisione il potenziale impatto sulle altre parti del sistema.

In questo modo, la gestione delle dipendenze diventa parte integrante dell’architettura, della sicurezza e dell’affidabilità del software nel lungo periodo.

La Software Supply Chain va oltre le librerie

Il codice che arriva all’interno dell’applicazione rappresenta soltanto un elemento della catena.

Prima di raggiungere l’ambiente di produzione, il software passa attraverso repository del codice sorgente, sistemi di build, ambienti di test, registri di pacchetti e pipeline CI/CD.

L’integrità del sistema dipende quindi anche dal modo in cui il software viene costruito e distribuito.

Per un team di engineering, mantenere il controllo su questo processo significa sapere non solo quale codice viene distribuito, ma anche quali componenti contiene, quali versioni vengono utilizzate e attraverso quali processi è passato.

È a questo livello che la Software Supply Chain supera il solo ambito della sicurezza e diventa parte di un concetto più ampio di software governance.

I sistemi progettati per durare richiedono un controllo a lungo termine

Una piattaforma può rimanere operativa per molti anni, mentre le tecnologie che la compongono continuano a evolversi.

Vengono rilasciate nuove versioni. Le dipendenze vengono aggiornate. Vengono individuate nuove vulnerabilità. Alcune tecnologie raggiungono la fine del proprio ciclo di supporto e devono essere sostituite.

Per questo motivo, l’architettura dei sistemi enterprise e delle piattaforme complesse deve essere progettata tenendo conto anche di questa evoluzione.

In ALSoft, questo approccio riflette un principio più ampio di software engineering: un sistema deve essere ben progettato al momento del deployment e, allo stesso tempo, rimanere comprensibile, gestibile e manutenibile durante tutto il suo ciclo di vita.

Come sintetizza Ermal Beqiri, fondatore di ALSoft:

«Ogni sistema porta con sé la storia delle scelte tecnologiche su cui è stato costruito. Comprendere e gestire queste scelte nel tempo fa parte della responsabilità di costruire software che rimanga affidabile mentre la tecnologia che lo circonda continua a evolversi.»

In questa prospettiva, la Software Supply Chain significa mantenere il controllo su ciò che costruiamo, sulle tecnologie da cui i nostri sistemi dipendono e sul modo in cui possono continuare a evolversi in maniera sicura e affidabile.