Scegliere un sistema per un'azienda significa partire dal lavoro da svolgere, non dal marchio o dalla piattaforma preferita. È il criterio che emerge dal confronto con InMarvinWeTrust, nel quale Marvin racconta come valuta le esigenze dei clienti.

La sua preferenza personale va all'open source, ma non diventa un obbligo da imporre a ogni progetto. La soluzione deve essere appropriata al contesto e alle dipendenze già presenti.

La prima domanda riguarda le funzioni

Il percorso comincia dal confronto con il cliente e con chi sviluppa il software. Bisogna capire che cosa il servizio debba fare, quali tecnologie utilizzi e in quale infrastruttura dovrà inserirsi.

Questo vale anche quando il cliente non è tecnico. Il bisogno può essere espresso come obiettivo operativo; tradurlo in requisiti è parte del lavoro professionale.

Le preferenze possono orientare una scelta tra alternative equivalenti. Non dovrebbero precedere l'analisi delle condizioni che rendono il progetto funzionante.

Due esempi con esigenze diverse

Marvin racconta il caso di un e-commerce realizzato con uno stack adatto a un ambiente GNU/Linux. In quella situazione propone un'infrastruttura coerente con le tecnologie dell'applicazione.

Porta poi un esempio differente: un progetto .NET con integrazioni e API legate a Windows. Pur riconoscendo la disponibilità di strumenti .NET anche su Linux, osserva che quelle dipendenze rendevano sensato restare nell'ambiente Windows.

La distinzione è decisiva: il nome del linguaggio o del framework non basta a determinare la portabilità dell'intero progetto. Bisogna guardare librerie, integrazioni e modalità di funzionamento effettive.

I costi fanno parte del progetto

Nel dialogo entrano anche licenze e investimenti già sostenuti. Un'infrastruttura può comprendere molte macchine e servizi: la valutazione non si limita quindi al costo di un singolo server.

Una decisione tecnica può comportare migrazione, formazione e nuove attività di gestione. Allo stesso tempo, aver già speso in una tecnologia non rende automaticamente conveniente mantenerla per sempre.

Il punto è confrontare le alternative nel loro contesto, con un orizzonte coerente con la vita del progetto.

L'esperienza non produce una ricetta unica

Marvin spiega di non incontrare infrastrutture perfettamente identiche nel proprio lavoro. Anche progetti simili possono avere vincoli differenti, e il suo contributo consiste nell'adattare la soluzione a quelli rilevanti.

Questo è il senso del passaggio che nella conversazione definiamo analisi funzionale: comprendere ciò che deve accadere prima di decidere con quali componenti realizzarlo.

L'open source rimane una scelta che Marvin tende a preferire quando non ci sono ostacoli specifici. La preferenza è dichiarata, senza sostituire la responsabilità verso il bisogno del cliente.

Il lavoro remoto come acceleratore, nel racconto di Marvin

Nella parte finale riflettiamo sul cloud e sul periodo del lockdown. Marvin racconta un forte aumento delle richieste di accesso remoto e digitalizzazione nella propria esperienza professionale.

È una testimonianza riferita ai clienti e al periodo vissuto, non una misura universale dell'intero mercato. Il passaggio mostra però come condizioni esterne possano cambiare rapidamente i requisiti di un'infrastruttura.

Il criterio conclusivo resta stabile: scegliere ciò che permette all'organizzazione di lavorare, documentando le ragioni e i compromessi della decisione.