In informatica, i termini “greenfield” e “brownfield” si riferiscono a due approcci diversi per la realizzazione di nuovi progetti o lo sviluppo di software.<\/p>\n\n\n\n
Un progetto “greenfield” \u00e8 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\u00e0, ma richiede anche un grande impegno in termini di tempo e risorse.<\/p>\n\n\n\n
Un progetto “brownfield”, invece, parte da un sistema esistente. Ci\u00f2 significa che si dovr\u00e0 lavorare su una base preesistente, utilizzando un codice gi\u00e0 presente e magari integrandolo con nuove funzionalit\u00e0 o tecnologie. Questo tipo di progetto \u00e8 pi\u00f9 rapido da sviluppare rispetto ad un progetto “greenfield”, in quanto non richiede la creazione di tutto da zero. Tuttavia, pu\u00f2 essere pi\u00f9 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.<\/p>\n\n\n\n
In uno sviluppo brownfield<\/strong> , l’attivit\u00e0 potrebbe essere l’aggiunta di un nuovo modulo di gestione all’attuale CRM, l’integrazione di nuove funzionalit\u00e0 in un CMS di Collaborazione o l’aumento delle prestazioni di un’app esistente.<\/p>\n\n\n\n I progetti greenfield<\/strong> di solito consentono maggiore flessibilit\u00e0 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.<\/p>\n\n\n\n Per gestire questo rischio, \u00e8 meglio utilizzare la metodologia AGILE<\/strong>, perch\u00e9 consente una comunicazione costante e la capacit\u00e0 di cogliere i piccoli errori prima che si trasformino in grandi errori. I progetti Brownfield <\/strong>di solito presentano alcuni vincoli e limitazioni, ma in questo caso gran parte del lavoro \u00e8 gi\u00e0 stato svolto. In questo articolo apriamo un focus sui pro e i contro di entrambi gli approcci.<\/p>\n\n\n\n I vantaggi dei progetti greenfield derivano direttamente dalla loro natura.<\/p>\n\n\n\n Il primo \u00e8 la flessibilit\u00e0<\/strong> . Possono adattarsi alle esigenze aziendali come un guanto, perch\u00e9 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<\/strong> . La maggiore flessibilit\u00e0 significa anche minori costi di manutenzione<\/strong>, poich\u00e9 non ci sono funzioni inutilizzate o duplicate ereditate dal vecchio software. I progetti IT greenfield possono essere pi\u00f9 a prova di futuro , perch\u00e9 non sono limitati dai vincoli di tecnologie obsolete e sono privi di dipendenze ridondanti di vecchi sistemi. Tutto \u00e8 allo stato dell’arte e appena implementato, quindi nessun applicativo o infrastruttura Legacy \u00e8 coinvolta.<\/p>\n\n\n\n Costruire tutto da zero significa che il time-to-market \u00e8 pi\u00f9 lungo e il rischio aziendale \u00e8 maggiore perch\u00e9 non c’\u00e8 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\u00ec via. Ci sono molte decisioni da prendere lungo il percorso, che possono rallentare o addirittura fermare il processo di sviluppo. Non c’\u00e8 da stupirsi, quindi, che il costo sia solitamente anche pi\u00f9 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. A differenza dei progetti greenfield, quelli brownfield hanno una d<\/strong>irezione di sviluppo gi\u00e0 predeterminata e il vecchio codice pu\u00f2 essere riutilizzato per rispondere a nuove esigenze. Comporta anche un tempo di commercializzazione pi\u00f9 breve e, in alcuni casi, costi inferiori (questi non sono sempre veri, come spiegheremo tra un momento). Il rischio aziendale \u00e8 mitigato perch\u00e9 il progetto iniziale \u00e8 solitamente gi\u00e0 stato provato sul mercato e utilizzato dai suoi utenti in molti modi diversi, quindi tutte le potenziali insidie sono gi\u00e0 note, analizzate e mitigate.<\/p>\n\n\n\n D’altra parte, l’approccio brownfield pu\u00f2 essere molto limitante. Gli sviluppatori devono fare i conti con il vecchio codice e la funzionalit\u00e0 non \u00e8 sempre adattata alle esigenze degli utenti. Un’altra cosa importante \u00e8 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\u00e0 \u00e8 scadente e non c’\u00e8 (quasi) documentazione. E, in alcuni casi, il risultato finale non vale davvero lo sforzo di provare a riprogettare il vecchio software con nuove funzionalit\u00e0 e il progetto potrebbe alla fine richiedere molto tempo e risorse . Un progetto greenfield ti offre il vantaggio di un nuovo inizio e di una creativit\u00e0 illimitata, che \u00e8 un’opportunit\u00e0 ma anche una sfida altrettanto grande.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n In questa fase, che pu\u00f2 anche essere definita fase di progettazione del prodotto<\/strong> , dobbiamo rispondere ad alcune importanti domande riguardanti il software progettato. Questi riguardano un problema che il prodotto risolver\u00e0, i personaggi dell’utente, gli obiettivi e le ragioni di esistenza del software in primo luogo. Questa \u00e8 pi\u00f9 un’analisi commerciale e di marketing, quindi questa fase deve coinvolgere specialisti di queste aree: workshop con sessioni di brainstorming<\/strong> con dipendenti dell’agenzia e del cliente sono molto utili in questa fase. Puoi anche fare qualche ricerca di mercato e sulla concorrenza<\/strong> se le risposte alle domande di cui sopra non sembrano facili.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019interno del sito e non influisce lato Seo pu\u00f2 essere ottenuto attraverso la chiamata di altre API. A questo punto, i nostri contenuti saranno disponibili all\u2019utente 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 \u00e8 che, se abbiamo gi\u00e0 un sito web su WordPress, possiamo utilizzarlo in modalit\u00e0 headless<\/strong>, ovvero raccogliendo i contenuti tramite le API. Quindi, se si ha intenzione di ottimizzare il proprio sito in quest\u2019ottica, gli interventi su WordPress saranno minimi: baster\u00e0 creare un template e utilizzare un framework che supporti l\u2019approccio Jamstack<\/strong>.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u00f2 migliorare le prestazioni del sito web, poich\u00e9 le pagine statiche sono pi\u00f9 veloci da caricare rispetto a quelle dinamiche generate al volo.<\/p>\n\n\n\n Inoltre, utilizzando un approccio JAMstack con WordPress, si possono beneficiare di alcune delle funzionalit\u00e0 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\u00e0 e la sicurezza.<\/p>\n\n\n\n <\/div><\/div>\n\n\n\n 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<\/strong> , quindi lavorare su di esse pu\u00f2 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 \u00e8 la prototipazione<\/strong> , che pu\u00f2 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.<\/p>\n\n\n\n La fase finale \u00e8 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 \u00e8 creare un MVP (a minimum viable product)<\/strong> , ovvero una versione semplificata del software finale che presenta solo le funzioni pi\u00f9 basilari necessarie per immetterlo sul mercato.<\/p>\n\n\n\n Ecco come appare approssimativamente il processo nel caso di un progetto greenfield:<\/p>\n\n\n\n <\/p>\n\n\n\n Nel caso dei progetti brownfield, il percorso \u00e8 leggermente diverso.<\/p>\n\n\n\n Il software su cui dobbiamo costruire pu\u00f2 essere abbandonato<\/strong> (creato qualche tempo fa e attualmente non utilizzato) o incompleto<\/strong> (sviluppato solo parzialmente e contenente software non finito). La prima cosa importante \u00e8 chiedersi perch\u00e9 il cliente vuole in primo luogo perseguire un progetto brownfield. Di solito pensano che il costo sar\u00e0 inferiore e il tempo pi\u00f9 breve, ma come abbiamo detto prima, non \u00e8 sempre cos\u00ec.<\/strong> Dopo un’analisi iniziale del codice esistente e dei requisiti del nuovo prodotto, potrebbe risultare che il prodotto richieder\u00e0 meno tempo e sar\u00e0 solo pi\u00f9 economico nell’approccio greenfield. Ma supponiamo di aver analizzato tutti i pro ei contro e di aver deciso che un progetto brownfield sar\u00e0 il modo pi\u00f9 ragionevole per raggiungere il nostro obiettivo.<\/p>\n\n\n\n Il codice esistente pu\u00f2 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 \u00e8 abbastanza noiosa. A volte pu\u00f2 anche sembrare un lavoro investigativo, ma se fatto bene rende le altre fasi pi\u00f9 brevi e pi\u00f9 facili. Il risultato dovrebbe essere un quadro completo di tutti i vincoli tecnici, umani e organizzativi del sistema che vi accingete ad implementare.<\/p>\n\n\n\n In questa fase, vanno definite le attivit\u00e0 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. \u00c8 un problema con l’usabilit\u00e0, le prestazioni, la conformit\u00e0, la sicurezza o l’aspetto? Dopo aver aggiornato i requisiti, va definita una tabella di marcia del progetto, che ci dice quali sono le caratteristiche pi\u00f9 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\u00f2 portare a problemi tecnici, perch\u00e9 potrebbe non essere conforme alle parti precedenti. Alcune attivit\u00e0 potrebbero sembrare pi\u00f9 difficili di quanto sembravano inizialmente, quindi dovresti considerare un margine di tempo e budget nel tuo piano.<\/p>\n\n\n\n La fase finale, come nel caso di un progetto greenfield, \u00e8 lo sviluppo in accordo al piano prestabilito. E’ mandatorio in questa fase sempre di coinvolgere tutte le parti interessate<\/strong> nel progetto, e questo vale anche per i progetti Greenfield, perch\u00e9 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).<\/p>\n\n\n\n Ecco come appare approssimativamente il processo nel caso di un progetto Brownfield:<\/p>\n\n\n\n Qualunque sia la scelta, sia essa Greenfield che Brownfield c’\u00e8 un grande tema che aleggia sempre piu importante, la sicurezza. Le infrastrutture siano esse On Cloud che On Premise sono sempre pi\u00f9 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\u00f9 sofisticate confrontandoci in una lotta senza fine e senza esclusione di colpi. <\/p>\n\n\n\n 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.<\/p>\n\n\n\n Un sito WordPress sviluppato con approccio JAMstack pu\u00f2 essere pi\u00f9 sicuro rispetto ad un sito WordPress tradizionale per diverse ragioni:<\/p>\n\n\n\n In generale, un sito WordPress sviluppato con approccio JAMstack pu\u00f2 essere pi\u00f9 sicuro grazie alla separazione dei componenti, alla distribuzione su CDN e alla minore complessit\u00e0 delle dipendenze software. Tuttavia, \u00e8 importante sottolineare che la sicurezza di un sito dipende anche da molti altri fattori, come ad esempio l’attualit\u00e0 del software, l’utilizzo di password sicure, l’adozione di buone pratiche di sicurezza e l’implementazione di meccanismi di autenticazione e autorizzazione adeguati.<\/p>\n\n\n\n Alla luce delle analisi fatte quanto, probabilmente sarai curioso di capire quando dovresti scegliere un approccio greenfield e quando un brownfield sar\u00e0 l’opzione migliore.<\/p>\n\n\n\n La risposta purtroppo non \u00e8 facile, perch\u00e9 tutto dipende dalla situazione specifica, e questo dovrebbe essere analizzato tra tutte le parti interessate fin dall’inizio \u2013 coinvolgendo il cliente e la componente IT sia essa interna (SW Factory) che esterna (Fornitore).<\/strong><\/p>\n\n\n\n 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 \u00e8 dotato di soluzioni a prova di futuro, opta per la soluzione brownfield.<\/p>\n\n\n\n Se desideri un software su misura che risponda alle esigenze specifiche dell’azienda e degli utenti, o se la tua soluzione esistente \u00e8 obsoleta e e sviluppata in modo disordinato, dovresti assolutamente prendere in considerazione l’approccio greenfield.<\/p>\n","protected":false},"excerpt":{"rendered":" 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” \u00e8 un progetto […]<\/p>\n","protected":false},"author":4,"featured_media":3997,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[5,86,110],"tags":[163,162],"class_list":["post-3916","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-gcportal-links","category-guide-tutorial","category-informatica","tag-brownfield","tag-greenfield"],"_links":{"self":[{"href":"https:\/\/www.gcportal.com\/wordpress\/wp-json\/wp\/v2\/posts\/3916","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gcportal.com\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gcportal.com\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gcportal.com\/wordpress\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gcportal.com\/wordpress\/wp-json\/wp\/v2\/comments?post=3916"}],"version-history":[{"count":56,"href":"https:\/\/www.gcportal.com\/wordpress\/wp-json\/wp\/v2\/posts\/3916\/revisions"}],"predecessor-version":[{"id":6556,"href":"https:\/\/www.gcportal.com\/wordpress\/wp-json\/wp\/v2\/posts\/3916\/revisions\/6556"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gcportal.com\/wordpress\/wp-json\/wp\/v2\/media\/3997"}],"wp:attachment":[{"href":"https:\/\/www.gcportal.com\/wordpress\/wp-json\/wp\/v2\/media?parent=3916"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gcportal.com\/wordpress\/wp-json\/wp\/v2\/categories?post=3916"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gcportal.com\/wordpress\/wp-json\/wp\/v2\/tags?post=3916"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Vantaggi e Svantaggi dei progetti Greenfield<\/h2>\n\n\n\n
Rischi nello sviluppo Greenfield<\/h2>\n\n\n\n
Massima flessibilit\u00e0 nel Design e Sviluppo
Maggiore Customizzazione
Opportunit\u00e0 di utilizzare le tecnologie pi\u00f9 recenti e avanzate
Alta Scalabilit\u00e0
Minori Costi di manutenzione<\/div><\/div>
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\u00e0 di acquisire Know-How<\/div><\/div>\n\n\n\nVantaggi e Svantaggi dei progetti Brownfield<\/h2>\n\n\n\n
Risparmio di tempo e costi rispetto a un progetto greenfield
Maggiore stabilit\u00e0 e affidabilit\u00e0 grazie all’utilizzo di codice gi\u00e0 testato
Sviluppi in una determinata direzione
Minore Time-To-Market
Mitigati Rischi di Business<\/div><\/div>
Limitazioni dovute alle tecnologie e ai sistemi preesistenti
Funzionalit\u00e0 datate
Rischi di una cattiva documentazione di progetto
Consumo di Risorse
Maggiore complessit\u00e0 e rischi di problemi di integrazione
Maggiore difficolt\u00e0 nel mantenere<\/div><\/div>\n\n\n\nLo sviluppo di un progetto Greenfield<\/h2>\n\n\n\n
1 – Analisi<\/h3>\n\n\n\n
2 – Strategia<\/h3>\n\n\n\n
3 – Progetto<\/h3>\n\n\n\n
4 – Sviluppo<\/h3>\n\n\n\n
Business Analysis<\/mark> –>><\/mark>Strategy Definition<\/mark>–>><\/mark>Project Design<\/mark>–>><\/mark>Development & Test<\/mark><\/h4>\n\n\n\n
Lo sviluppo di un progetto Brownfield<\/h2>\n\n\n\n
1 – Analisi del progetto esistente (AsIs Analysis)<\/h3>\n\n\n\n
2 – Analisi degli scostamenti (GAP Analysis)<\/h3>\n\n\n\n
Vanno anche confrontati i requisiti nuovi a fronte degli originali e verificare quanto \u00e8 stato gi\u00e0 risolto.<\/p>\n\n\n\n3 – Definizione del piano di Progetto (Build Project RoadMap)<\/h3>\n\n\n\n
4 – Implementazione del Piano di Sviluppo e Test<\/h3>\n\n\n\n
AsIs Analysis<\/mark><\/mark>–>><\/mark>Gap Analysis<\/mark><\/mark>–>><\/mark>Project RoadMap<\/mark><\/mark>–>><\/mark>Development & Test<\/mark><\/mark><\/h4>\n\n\n\n
C’\u00e8 un tema trasversale ai due approcci: La SICUREZZA<\/h2>\n\n\n\n
\n
Conclusione: Ergo Greenfield<\/strong><\/mark> o Brownfield<\/mark><\/strong> ?<\/h2>\n\n\n\n