In informatica, i termini “greenfield” e “brownfield” si riferiscono a due approcci diversi per la realizzazione di nuovi progetti o lo sviluppo di software.
Un progetto “greenfield” è un progetto completamente nuovo, che parte da zero. In altre parole, non ci sono precedenti, niente codice esistente e nessun sistema preesistente da integrare. Si parte con una tela bianca e si sviluppa tutto da zero. Questo tipo di progetto offre la massima flessibilità, ma richiede anche un grande impegno in termini di tempo e risorse.
Un progetto “brownfield”, invece, parte da un sistema esistente. Ciò significa che si dovrà lavorare su una base preesistente, utilizzando un codice già presente e magari integrandolo con nuove funzionalità o tecnologie. Questo tipo di progetto è più rapido da sviluppare rispetto ad un progetto “greenfield”, in quanto non richiede la creazione di tutto da zero. Tuttavia, può essere più complesso da gestire e ci sono maggiori rischi di errori e problemi di integrazione. Entrambi gli approcci possono riguardare molti tipi di progetti IT, come uno strumento software, un’app, un sito Web, una rete o una struttura IT.
In uno sviluppo brownfield , l’attività potrebbe essere l’aggiunta di un nuovo modulo di gestione all’attuale CRM, l’integrazione di nuove funzionalità in un CMS di Collaborazione o l’aumento delle prestazioni di un’app esistente.
I progetti greenfield di solito consentono maggiore flessibilità e innovazione, il che, d’altra parte, significa che devi comprendere a fondo i tuoi obiettivi di business e impostare un chiaro percorso di sviluppo per non perdere la portata.
Per gestire questo rischio, è meglio utilizzare la metodologia AGILE, perché consente una comunicazione costante e la capacità di cogliere i piccoli errori prima che si trasformino in grandi errori. I progetti Brownfield di solito presentano alcuni vincoli e limitazioni, ma in questo caso gran parte del lavoro è già stato svolto. In questo articolo apriamo un focus sui pro e i contro di entrambi gli approcci.
Vantaggi e Svantaggi dei progetti Greenfield
I vantaggi dei progetti greenfield derivano direttamente dalla loro natura.
Il primo è la flessibilità . Possono adattarsi alle esigenze aziendali come un guanto, perché sono costruiti esattamente per soddisfare tali esigenze e fornire tutte le soluzioni personalizzate che si possano immaginare. Per gli stessi motivi, le soluzioni software costruite in modo greenfield possono essere altamente scalabili . La maggiore flessibilità significa anche minori costi di manutenzione, poiché non ci sono funzioni inutilizzate o duplicate ereditate dal vecchio software. I progetti IT greenfield possono essere più a prova di futuro , perché non sono limitati dai vincoli di tecnologie obsolete e sono privi di dipendenze ridondanti di vecchi sistemi. Tutto è allo stato dell’arte e appena implementato, quindi nessun applicativo o infrastruttura Legacy è coinvolta.
Rischi nello sviluppo Greenfield
Costruire tutto da zero significa che il time-to-market è più lungo e il rischio aziendale è maggiore perché non c’è un percorso precostituito da seguire. Va pianificato tutto partendo dalle esigenze aziendali alla scelta della tecnologia, dell’architettura del sistema, dell’interfaccia utente e così via. Ci sono molte decisioni da prendere lungo il percorso, che possono rallentare o addirittura fermare il processo di sviluppo. Non c’è da stupirsi, quindi, che il costo sia solitamente anche più alto. I progetti greenfield richiedono nuove competenze tecnologiche che potrebbero essere scarse sul mercato e anche gli utenti finali avranno la loro giusta quota di apprendimento , spesso con l’aiuto di consulenti esterni.
Massima flessibilità nel Design e Sviluppo
Maggiore Customizzazione
Opportunità di utilizzare le tecnologie più recenti e avanzate
Alta Scalabilità
Minori Costi di manutenzione
Un maggiore Time-To-Market
Alti rischi di business
Richiede un grande impegno in termini di tempo e risorse
Maggiori decisioni da prendere
Maggiori rischi di ritardi e costi elevati
Alti costi di sviluppo
Necessità di acquisire Know-How
Vantaggi e Svantaggi dei progetti Brownfield
A differenza dei progetti greenfield, quelli brownfield hanno una direzione di sviluppo già predeterminata e il vecchio codice può essere riutilizzato per rispondere a nuove esigenze. Comporta anche un tempo di commercializzazione più breve e, in alcuni casi, costi inferiori (questi non sono sempre veri, come spiegheremo tra un momento). Il rischio aziendale è mitigato perché il progetto iniziale è solitamente già stato provato sul mercato e utilizzato dai suoi utenti in molti modi diversi, quindi tutte le potenziali insidie sono già note, analizzate e mitigate.
D’altra parte, l’approccio brownfield può essere molto limitante. Gli sviluppatori devono fare i conti con il vecchio codice e la funzionalità non è sempre adattata alle esigenze degli utenti. Un’altra cosa importante è il fatto che gli sviluppatori devono conoscere il sistema attuale in ogni dettaglio . Se in effetti non fossero coinvolti nella sua costruzione, potrebbe essere molto difficile capire il vecchio codice, soprattutto se la sua qualità è scadente e non c’è (quasi) documentazione. E, in alcuni casi, il risultato finale non vale davvero lo sforzo di provare a riprogettare il vecchio software con nuove funzionalità e il progetto potrebbe alla fine richiedere molto tempo e risorse .
Risparmio di tempo e costi rispetto a un progetto greenfield
Maggiore stabilità e affidabilità grazie all’utilizzo di codice già testato
Sviluppi in una determinata direzione
Minore Time-To-Market
Mitigati Rischi di Business
Limitazioni dovute alle tecnologie e ai sistemi preesistenti
Funzionalità datate
Rischi di una cattiva documentazione di progetto
Consumo di Risorse
Maggiore complessità e rischi di problemi di integrazione
Maggiore difficoltà nel mantenere
Lo sviluppo di un progetto Greenfield
Un progetto greenfield ti offre il vantaggio di un nuovo inizio e di una creatività illimitata, che è un’opportunità ma anche una sfida altrettanto grande.
Un progetto greenfield presenta molte aree incognite, tutte le fasi preparatorie che precedono la fase di codifica sono cruciali. Che aspetto ha questo processo? Analizziamolo in diversi passaggi.
1 – Analisi
In questa fase, che può anche essere definita fase di progettazione del prodotto , dobbiamo rispondere ad alcune importanti domande riguardanti il software progettato. Questi riguardano un problema che il prodotto risolverà, i personaggi dell’utente, gli obiettivi e le ragioni di esistenza del software in primo luogo. Questa è più un’analisi commerciale e di marketing, quindi questa fase deve coinvolgere specialisti di queste aree: workshop con sessioni di brainstorming con dipendenti dell’agenzia e del cliente sono molto utili in questa fase. Puoi anche fare qualche ricerca di mercato e sulla concorrenza se le risposte alle domande di cui sopra non sembrano facili.
2 – Strategia
Dopo aver analizzato tutto, dovremmo decidere l’esatto modello di business (inclusi i metodi di monetizzazione e determinazione dei costi) e un modello di sviluppo per il software (inclusa la scelta dell’approccio giusto, come ad esempio Jamstack e uno specifico stack tecnologico) . La strategia collega questioni orientate al business e allo sviluppo, generando un’idea razionale per ogni aspetto del prodotto da sviluppare, insieme ai modi per implementarlo.
Come fa quindi l’approccio Jamstack a migliorare le performance? Semplicemente prende i contenuti dinamici del sito da delle API (es. WordPress) e li unisce a dei template, generando quindi dei file .html che contengono js e css. Tutto quello che deve essere dinamico all’interno del sito e non influisce lato Seo può essere ottenuto attraverso la chiamata di altre API. A questo punto, i nostri contenuti saranno disponibili all’utente in tempi fino a 6 volte minori rispetto a un sito dinamico che interagisce in tempo reale con un database, come ad esempio succede in un sito sviluppato su WordPress. La buona notizia è che, se abbiamo già un sito web su WordPress, possiamo utilizzarlo in modalità headless, ovvero raccogliendo i contenuti tramite le API. Quindi, se si ha intenzione di ottimizzare il proprio sito in quest’ottica, gli interventi su WordPress saranno minimi: basterà creare un template e utilizzare un framework che supporti l’approccio Jamstack.
Per utilizzare WordPress con un approccio JAMstack, si possono utilizzare alcune soluzioni di terze parti, come ad esempio il plugin GatsbyWP. Questo plugin consente di utilizzare Gatsby, un generatore di siti statici basato su React, per generare il markup del sito a partire dai contenuti di WordPress.
In questo modo, WordPress viene utilizzato come CMS per la gestione dei contenuti, mentre Gatsby viene utilizzato per la generazione di pagine statiche basate sui contenuti di WordPress. Questo approccio può migliorare le prestazioni del sito web, poiché le pagine statiche sono più veloci da caricare rispetto a quelle dinamiche generate al volo.
Inoltre, utilizzando un approccio JAMstack con WordPress, si possono beneficiare di alcune delle funzionalità avanzate di WordPress, come ad esempio la gestione degli utenti, la gestione dei commenti, la gestione dei contenuti multilingue e molte altre, mentre si ottengono anche i vantaggi dell’approccio JAMstack, come ad esempio la scalabilità e la sicurezza.
3 – Progetto
Una volta che abbiamo messo in atto una strategia, dobbiamo progettare il prodotto. Durante questa fase, la collaborazione tra il cliente e il team di sviluppo dovrebbe essere molto stretta. Il design collega i problemi logici, UX e grafici e tutte queste aree sono interconnesse , quindi lavorare su di esse può essere simultaneo. Dovremmo pensare ai percorsi degli utenti e tradurli in passaggi successivi riflessi nel design finale. Un’altra parte vitale del processo di progettazione è la prototipazione , che può aiutare a determinare l’esperienza utente ottimale e testare tutte le idee. Il prototipo creato dovrebbe essere rivisto, perfezionato e iterato in base alle esigenze.
4 – Sviluppo
La fase finale è lo sviluppo. L’agenzia prepara un flusso di lavoro, crea un team IT di progetto composto da varie figure professionali e decide se impegnare anche un eventuale coinvolgimento di un fornitore esterno e stabilisce un’agenda. Il prodotto viene solitamente creato negli sprint, il che crea spazio per le iterazioni e il perfezionamento all’interno di questa fase. Una buona pratica qui è creare un MVP (a minimum viable product) , ovvero una versione semplificata del software finale che presenta solo le funzioni più basilari necessarie per immetterlo sul mercato.
Ecco come appare approssimativamente il processo nel caso di un progetto greenfield:
Business Analysis –>>Strategy Definition–>>Project Design–>>Development & Test
Lo sviluppo di un progetto Brownfield
Nel caso dei progetti brownfield, il percorso è leggermente diverso.
Il software su cui dobbiamo costruire può essere abbandonato (creato qualche tempo fa e attualmente non utilizzato) o incompleto (sviluppato solo parzialmente e contenente software non finito). La prima cosa importante è chiedersi perché il cliente vuole in primo luogo perseguire un progetto brownfield. Di solito pensano che il costo sarà inferiore e il tempo più breve, ma come abbiamo detto prima, non è sempre così. Dopo un’analisi iniziale del codice esistente e dei requisiti del nuovo prodotto, potrebbe risultare che il prodotto richiederà meno tempo e sarà solo più economico nell’approccio greenfield. Ma supponiamo di aver analizzato tutti i pro ei contro e di aver deciso che un progetto brownfield sarà il modo più ragionevole per raggiungere il nostro obiettivo.
1 – Analisi del progetto esistente (AsIs Analysis)
Il codice esistente può riservare molte sorprese, quindi deve essere analizzato a fondo, individuando tutti i punti deboli e gli elementi obsoleti. Potrebbe essere ragionevole riutilizzare solo una parte della soluzione esistente e buttare via il resto. Va anche analizzata la storia del progetto sulla base delle testimonianze e della documentazione degli sviluppatori originali, i fallimenti passati e i gli obiettivi iniziali, confrontandoli con quelli nuovi. Questa fase richiede molto tempo ed è abbastanza noiosa. A volte può anche sembrare un lavoro investigativo, ma se fatto bene rende le altre fasi più brevi e più facili. Il risultato dovrebbe essere un quadro completo di tutti i vincoli tecnici, umani e organizzativi del sistema che vi accingete ad implementare.
2 – Analisi degli scostamenti (GAP Analysis)
In questa fase, vanno definite le attività per colmare il divario tra il software iniziale e finale, e quello desiderato. Le domande che dovremmo porci in questa fase ci permettono di definire meglio il problema. È un problema con l’usabilità, le prestazioni, la conformità, la sicurezza o l’aspetto?
Vanno anche confrontati i requisiti nuovi a fronte degli originali e verificare quanto è stato già risolto.
3 – Definizione del piano di Progetto (Build Project RoadMap)
Dopo aver aggiornato i requisiti, va definita una tabella di marcia del progetto, che ci dice quali sono le caratteristiche più importanti e dovrebbero essere implementate per prime e quali possono attendere di essere affrontate successivamente. Quindi, dovremmo suddividere l’ordine del giorno in compiti specifici. Non cadere nella trappola di riscrivere tutto per funzionare meglio: ricorda che hai scelto un progetto dismesso per un motivo in primo luogo. Inoltre, la riscrittura del codice può portare a problemi tecnici, perché potrebbe non essere conforme alle parti precedenti. Alcune attività potrebbero sembrare più difficili di quanto sembravano inizialmente, quindi dovresti considerare un margine di tempo e budget nel tuo piano.
4 – Implementazione del Piano di Sviluppo e Test
La fase finale, come nel caso di un progetto greenfield, è lo sviluppo in accordo al piano prestabilito. E’ mandatorio in questa fase sempre di coinvolgere tutte le parti interessate nel progetto, e questo vale anche per i progetti Greenfield, perché senza di loro, il piano potrebbe andare incontro a problemi importanti. Queste dovrebbero prendere parte a tutte le varie fasi del progetto dalla raccolta dei requisiti, alla prototipazione, alla definizione della Solution Design alle demo di fine sprint e alle fasi dei vari test da quelli di integrazione delle varie componenti ai test di modulo agli UAT (User Acceptance Test).
Ecco come appare approssimativamente il processo nel caso di un progetto Brownfield:
AsIs Analysis–>>Gap Analysis–>>Project RoadMap–>>Development & Test
C’è un tema trasversale ai due approcci: La SICUREZZA
Qualunque sia la scelta, sia essa Greenfield che Brownfield c’è un grande tema che aleggia sempre piu importante, la sicurezza. Le infrastrutture siano esse On Cloud che On Premise sono sempre più oggetto di attacchi ostili da parte di soggetti singoli che organizzazioni maleintenzionati le quali dispongono di competenze informatiche di altissimo livello dalle quali ci dobbiamo difendere predisponendo barriere semre più sofisticate confrontandoci in una lotta senza fine e senza esclusione di colpi.
Al netto delle tipiche impostazioni dell’infrastruttura ancillare (VPN, SSH, Strong Authentication a doppio fattore, SSO, Firewall.) Anche la parte applicativa deve fare la sua parte.
Un sito WordPress sviluppato con approccio JAMstack può essere più sicuro rispetto ad un sito WordPress tradizionale per diverse ragioni:
- Nessun server-side rendering: In un sito JAMstack, le pagine vengono pre-generate come file HTML statici e poi serviti ai visitatori, senza eseguire codice server-side. Ciò significa che non c’è alcuna esecuzione di codice lato server, il che rende il sito meno vulnerabile agli attacchi hacker che sfruttano falle di sicurezza lato server.
- Sicurezza del server: Un sito JAMstack non richiede un server web tradizionale per eseguire codice PHP o altre tecnologie lato server, il che significa che il sito è meno vulnerabile ad attacchi diretti al server web.
- Distribuzione tramite CDN: Un sito JAMstack può essere distribuito tramite una CDN (Content Delivery Network), che consente di fornire i file del sito a una rete globale di server, rendendo il sito più veloce e sicuro. Una CDN può inoltre fornire protezione contro attacchi DDoS (Distributed Denial of Service).
- Meno dipendenze: Un sito JAMstack è composto principalmente da file statici, che non richiedono molte dipendenze da software terzi. Ciò significa che ci sono meno punti di ingresso per gli hacker per sfruttare le vulnerabilità del software di terze parti.
In generale, un sito WordPress sviluppato con approccio JAMstack può essere più sicuro grazie alla separazione dei componenti, alla distribuzione su CDN e alla minore complessità delle dipendenze software. Tuttavia, è importante sottolineare che la sicurezza di un sito dipende anche da molti altri fattori, come ad esempio l’attualità del software, l’utilizzo di password sicure, l’adozione di buone pratiche di sicurezza e l’implementazione di meccanismi di autenticazione e autorizzazione adeguati.
Conclusione: Ergo Greenfield o Brownfield ?
Alla luce delle analisi fatte quanto, probabilmente sarai curioso di capire quando dovresti scegliere un approccio greenfield e quando un brownfield sarà l’opzione migliore.
La risposta purtroppo non è facile, perché tutto dipende dalla situazione specifica, e questo dovrebbe essere analizzato tra tutte le parti interessate fin dall’inizio – coinvolgendo il cliente e la componente IT sia essa interna (SW Factory) che esterna (Fornitore).
Possiamo dire che: se vuoi solo aggiornare il tuo software con nuove funzioni e il vecchio sistema funziona generalmente bene, ha un codice pulito, ben documentato ed è dotato di soluzioni a prova di futuro, opta per la soluzione brownfield.
Se desideri un software su misura che risponda alle esigenze specifiche dell’azienda e degli utenti, o se la tua soluzione esistente è obsoleta e e sviluppata in modo disordinato, dovresti assolutamente prendere in considerazione l’approccio greenfield.