Pubblichiamo su questo numero l’ottava parte della serie “DDD, microservizi e architetture evolutive: uno sguardo d’insieme” che, per un errore di impaginazione, non era stato pubblicato a tempo debito. È anche l’occasione per annunciare che, a fine mese, sarà disponibile un PDF che raccoglie, rielabora e presenta in maniera organica in un’unica pubblicazione i temi trattati in questa serie. Temi che, in un panorama in cui il ruolo dello sviluppatore/architetto software sta cambiando rapidamente con l’impatto dell’Intelligenza Artificiale, assumono ancora più importanza.

—————

La filosofia dell’architettura

L’idea che filosofia e architettura software possano essere collegate potrebbe sembrare un po’ stramba. Tuttavia, qualche mese fa ho avuto l’opportunità di partecipare a un corso sull’architettura del software veramente rivoluzionario, che mi ha aperto un nuovo mondo, e un nuovo modo di esplorare il software come supporto ai processi umani.

Nei precedenti articoli abbiamo già affrontato la differenza, e l’importanza, del Problem Space e del Solution Space. Quali sono le domande, implicite ed esplicite, che ci poniamo quando iniziamo un nuovo progetto? Definire cosa costituisce un problema e cosa consideriamo una soluzione implica una visione del mondo, che spesso è inconsapevolmente “filosofica”.

Sono certo che molti di voi, così come ho pensato io quando ho scoperto questo studio, stanno pensando come si fa a fare il lavoro che facciamo, ossia progettare architetture software, in un modo completamente diverso. La risposta è tanto semplice, quanto sbalorditiva: dobbiamo tornare al punto di partenza, porci domande del tipo “Come vedo il mondo?”, “Come risolvo problemi?”, “Cosa penso sia un problema?”, “Cosa pensiamo sia un problema e cosa pensiamo sia una soluzione?”. Be’, se cominciamo a pensarla in questo senso, un po’ di filosofia cominciamo a intravvederla…

Una rivoluzione nel pensiero sul design del software

Il corso è stato tenuto da Barry O’Reilly, che è l’autore di questa nuova interpretazione dell’architettura del software che porta il nome di Residuality Theory di cui potete trovare un interessante video [1] nei Riferimenti in fondo all’articolo. Ovviamente Residuality Theory non si occupa solamente di filosofia: ci sono delle solide basi matematiche a supporto del lavoro e vi invito a seguire il video.

Sistemi ordinati e disordinati

L’attuale modo di risolvere problemi e progettare architetture software evidenzia un forte distacco tra ciò che è scritto nei libri, la teoria, e ciò che realmente succede nel mondo, la pratica. Il software e il business appartengono a due diverse categorie di sistemi, il primo è un sistema ordinato, fatto di regole precise, matematiche, che devono essere rispettate affinché possa funzionare. Il secondo, il mondo del business, appartiene alla categoria dei sistemi disordinati, quelli che non seguono regole precise, ma soprattutto quello in cui le regole del gioco cambiano continuamente. Questo mi porta alla mente una frase che lessi tempo fa su una rivista di montagna, di cui non era riportato l’autore:

Ci sono almeno due tipi di giochi […] I giochi finiti e quelli infiniti. Un gioco finito si gioca per vincerlo, un gioco infinito per continuare a giocare. I partecipanti a un gioco finito giocano entro certi confini ben precisi, i partecipanti ad un gioco infinito giocano con i confini.

Il software appartiene decisamente alla tipologia dei giochi infiniti, proprio perché con il software noi cerchiamo di risolvere problemi di business, o almeno questo dovrebbe essere l’obiettivo!

Se la nostra soluzione è basata solo su principi tecnologici, che sono certamente importanti, ma non sufficienti, sarà una soluzione valida fintanto che il problema di business che dobbiamo risolvere resta immutato, ma nel momento in cui le esigenze di mercato, le nostre regole del gioco, cambieranno, se il nostro sistema non si saprà adeguare, allora sarà inutile.

Ci sono diversi esempi nella storia che dimostrano come una soluzione e una visione troppo rigide abbiamo fatto fallire colossi che sembravamo incrollabili. Blockbuster non ha saputo cogliere l’idea rivoluzionaria che sarà poi di Netflix, che abbatteva i costi aggiuntivi degli utenti che riconsegnavano le cassette in ritardo il lunedì, e quando ha visto le sue quote di mercato diminuire e ha cercato di copiare il modello di business, non ha fatto in tempo ed è fallita. Kodak è un altro esempio, e Nokia un altro ancora.

Processi decisionali nell’architettura del software

Proviamo ad esaminare il processo decisionale di un ingegnere del software quando deve prendere decisioni architetturali. Ala fonte ci sono tre problemi.

• Il problema tecnico: come scalerà il mio sistema, quanto sarà resiliente, quanto tempo ho a disposizione per portare a termine la prima versione, e altre domande simili. Un libro che consiglio a questo proposito è Fundamentals of Software Architecture [2].
• Il problema del team: che tipo di team abbiamo a disposizione? È un team cross funzionale indipendente, oppure abbiamo dipendenze da Team esterni?
• Il problema aziendale del cliente: Come fa questo progetto a generare valore per l’azienda che ce lo ha commissionato? Perché è questo che dobbiamo prima capire, e poi risolvere.

Tutti noi prendiamo continuamente decisioni su questi aspetti, ma non ci poniamo mai la domanda “Perché pensi che questa decisione sia giusta?”. Se leggiamo il libro Software Architecture: The Hard Parts [3], scopriamo che non esiste la risposta giusta ma che si tratta sempre di un compromesso fra diverse soluzioni possibili, tutte ugualmente giuste e sbagliate.

Secondo Barry, è proprio qui che interviene la filosofia. Quando ci poniamo queste domande, stiamo chiedendo a noi stessi “Come funziona il mondo?”. E questa è filosofia. Quindi, quando pensiamo alla filosofia in termini di architettura del software, stiamo riflettendo su “Qual è la nostra filosofia di progettazione?”, “Qual è la tua filosofia di team?” e, ancora, “Qual è la tua filosofia per creare valore al cliente?”.

La filosofia nell’architettura del software

Da un recente corso di filosofia a cui ho partecipato, ho imparato che in filosofia non è tanto importante ciò che pensi sia vero, quanto perché pensi che sia vero. Questo è assolutamente in linea con quanto scritto anche nei libri sopra citati, che ci trasmettono due leggi fondamentali riguardo l’architettura del software

• Prima legge: Tutto è un compromesso! Corollario: “Se pensi di aver trovato una soluzione che non ha compromessi, semplicemente non hai ancora scoperto il compromesso”.
• Seconda legge: Il perché è più importante del come!

Quindi, quando parliamo di architettura del software, stiamo veramente parlando di come crediamo che i sistemi dovrebbero essere progettati, cosa intendiamo per lavoro di team e cosa intendiamo per consegnare valore, perché, quello che conta è che il nostro software deve, o almeno dovrebbe, consegnare valore, per avere successo.

Ciò che rende affascinante l’architettura del software, almeno per quelli come noi che la masticano tutti i giorni, è che non riguarda solo la scrittura di codice — per quello ormai abbiamo Copilot, o tanti altri strumenti simili — ma si tratta di prendere decisioni, fare compromessi e comprendere come queste decisioni influenzeranno l’intero sistema che stiamo progettando.

Una delle cose che ho imparato da questo breve corso di filosofia è che ci sono sempre prospettive diverse, o modi differenti, di guardare allo stesso problema. Dobbiamo imparare a traslare questo modo di pensare nel nostro lavoro quotidiano perché, se riusciamo a comprendere queste diverse prospettive, e come queste interagiscono fra loro, potremo progettare sistemi migliori.

Proviamo a pensare alla Prima Legge dell’architettura software. Ogni decisione che prendiamo è un compromesso. Se decidiamo di ottimizzare le prestazioni, sacrifichiamo la semplicità, ma anche il tempo di consegna. Se scegliamo una soluzione semplice, ma poco scalabile, terminiamo prima. Quindi microservizi o monolite? Ogni decisione che prendiamo come architetti riguarda questi compromessi, e dobbiamo essere consapevoli di cosa stiamo sacrificando e di cosa stiamo guadagnando, per noi stessi, ma soprattutto per chiarezza nei confronti di chi ci ha commissionato il lavoro.

La filosofia, a tal riguardo, ci insegna che non si tratta tanto di trovare la risposta giusta, ma anzitutto di porre le domande giuste. Non vi ricorda qualcosa? Già Eric Evans, nel suo iconico libro blu, sosteneva l’importanza di trovare un linguaggio e un modello comune fra tecnici ed esperti del business su cui porre domande che fossero comprensibili a tutti. Quando parliamo di architettura del software, non si tratta di identifica il miglior design, la soluzione migliore, ma di trovare le domande migliori che possiamo porci, e possiamo porre, per comprendere il problema ed esplorare lo spazio delle soluzioni. La filosofia ci aiuta a migliorare noi stessi nel formulare queste domande e nell’esplorare le diverse possibilità. Ci insegna a migliorare nella comprensione dei problemi e nell’esplorare i diversi modi in cui possiamo affrontarli.

L’architettura software è affascinante perché non riguarda solo la tecnologia, ma riguarda anche le persone, sia durante la progettazione, ma soprattutto dopo, quando consegniamo il lavoro. Nella prima fase dobbiamo pensare a come unire le persone, come allineare i diversi obiettivi, come aiutarle a lavorare insieme in modo efficace. La filosofia ci aiuta ad esplorare i diversi modi in cui possiamo unire le persone e favorire la loro collaborazione.

La filosofia ci insegna ad abbracciare la complessità. Ci insegna che il mondo non è semplice, che i problemi non sono semplici e che le soluzioni non sono semplici. Dobbiamo saper cogliere questa complessità quando progettiamo sistemi software, dobbiamo capire che non esistono risposte, e soluzioni, semplici, e che ogni decisione che prendiamo comporta compromessi. Non è sufficiente replicare la soluzione che abbiamo adottato in precedenza per un progetto simile! Dobbiamo farci guidare dalla filosofia nella comprensione, e nella gestione, della complessità.

Per concludere, la filosofia ci aiuta a riflettere, a porci domande, a renderci diversi da un qualsiasi Copilot! I nuovi strumenti di Intelligenza Artificiale scrivono codice migliore del nostro, in un tempo infinitamente inferiore, ma questo codice funziona solo se abbiamo posto le domande giuste al generatore di turno; altrimenti sarà soltanto un modo diverso, anche se più veloce, del solito “copy and paste from stackoverlow” con i risultati che tristemente conosciamo.

Filosofia e architettura: le radici del pensiero progettuale

La filosofia è un argomento che mi interessa da un po’ di tempo, quindi, quando ho visto un corso che univa l’architettura software con la filosofia, ho deciso di partecipare al corso di Barry O’Reilly. Attraverso il lavoro svolto per il suo dottorato in scienza della complessità e design del software, Barry O’Reilly propone un approccio innovativo che va oltre le metodologie tradizionali, sfidando le concezioni consolidate su come progettiamo i sistemi.

Il punto di partenza proposto è un aspetto sempre ignorato nello sviluppo del software, ossia le basi filosofiche che guidano le nostre decisioni. Quando affrontiamo un problema, ci poniamo implicitamente domande fondamentali

L’influenza del pensiero complesso

Il concetto di complessità è centrale quando si parla di architettura software, perché, come già detto più volte, scrivere software non significa semplicemente trovare soluzioni tecniche, ma coinvolge il modo in cui percepiamo e strutturiamo il mondo attorno a noi.

L’attuale approccio, che si concentra nella scomposizione del problema in parti più piccole, non è sempre sufficiente per affrontare i sistemi complessi e interconnessi di oggi. Serve, secondo Barry O’Reilly, una visione combinata di scienza della complessità e riflessione filosofica che ci permetta di vedere il software non come insieme di componenti isolati, ma come un sistema vivente. L’idea è quella ci creare strutture che possano evolvere in modo organico, adattandosi ai cambiamenti senza compromettere la stabilità.

Riformulare il ruolo dell’architetto software

Il lavoro di un software architect deve andare oltre la creazione di sistemi meramente tecnici; l’architetto deve diventare un pensatore strategico che lavora con modelli mentali complessi. Le decisioni architetturali non derivano solo dall’esperienza o dalle best practice, ma anche dal modo in cui l’architetto interpreta il contesto e bilancia diversi fattori come flessibilità, scalabilità e semplicità.

Conclusione: filosofia come strumento per il futuro del software

Il messaggio di O’Reilly è chiaro: per progettare sistemi migliori, dobbiamo esplorare le radici del nostro pensiero. Solo comprendendo il modo in cui percepiamo il mondo e prendiamo decisioni, possiamo creare architetture che non siano solo funzionali, ma anche sostenibili e pronte per il futuro.

La filosofia, quindi, non è un’aggiunta accessoria allo sviluppo software, ma una componente essenziale per affrontare le sfide di un mondo sempre più complesso. Attraverso un approccio che integra logica, intuizione e creatività, gli architetti del software possono ridefinire il loro ruolo e guidare il cambiamento.

Riferimenti

[1] An Introduction to Residuality Theory – Barry O’Reilly – NDC Oslo 2023 (video)
https://www.youtube.com/watch?v=0wcUG2EV-7E&t=773s

[2] Mark Richards – Neal Ford, Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media, 2020

[3] N. Ford – M. Richards – P. Sadalage – Z. Dehghani, Software Architecture: The Hard Parts. O’Reilly Media, 2021