La domanda «build versus buy» si presenta a quasi ogni team dati che vuole modernizzare il proprio stack. Il team Data Platform di Autodesk, che fornisce insight a centinaia di utenti interni, ci era arrivato spinto da problemi concreti: limiti di concorrenza sullo storage, troppe query in parallelo che rallentavano il sistema e un limite di capacità finito. Come sintetizza Mark Kidwell, Chief Data Architect di Autodesk, «il fatto di poter scrivere codice custom per l’integrazione dei dati non significa che si debba farlo, soprattutto per analytics business-critical». La decisione, racconta, si è ridotta a quattro criteri.
1. Costo-efficacia rispetto al data warehouse
Poiché l’efficienza dei costi era il driver principale del passaggio al cloud, è rimasta il criterio guida anche per gli altri strumenti. Autodesk ha adottato Snowflake come cloud data warehouse per aumentare capacità e scalabilità in modo economico: se una funzionalità rientra bene nell’ecosistema esistente e in Snowflake in modo economico, l’opzione «buy» è preferita.
2. Ingestion no-code o low-code
Man mano che il footprint dei dati cresce tra app SaaS, eventi, database e file, serve un modo rapido per aggiungere nuove sorgenti. Autodesk preferisce un percorso no-code o low-code: come dice Kidwell, «non dovremmo costruire noi queste cose, dovremmo lavorare su problemi che aggiungono valore di business». Il beneficio collaterale è rendere il movimento dei dati più self-service, togliendo l’IT dal collo di bottiglia.
3. Tempo speso su problemi a valore
Comprare invece di costruire porta time-to-value più rapido, meno manutenzione e nessun bisogno di rincorrere le API delle sorgenti. Autodesk ha ridotto la manutenzione delle pipeline dal 5 percento a meno dell’1 percento del tempo degli analisti, e ha ridotto del 68 percento i tempi di esecuzione delle trasformazioni, liberando tempo per progetti più strategici. «Si possono costruire ottimi strumenti internamente, ma è uno sforzo enorme: serve un team dedicato, perché non stai costruendo una soluzione una tantum ma una piattaforma».
4. Allineamento con lo stack esistente
Nel valutare uno strumento contano fattori come il supporto per sorgenti e destinazioni, l’estensibilità verso orchestrazione e trasformazione, la normalizzazione automatica degli schemi, l’approccio zero-touch e fully managed, l’automazione (schema migration automatica, adattamento ai cambi di API, scheduling continuo) e l’integrazione via API per i deployment enterprise.
Come per tutti i contenuti di questo tipo, va ricordato che l’articolo è firmato dal vendor e cita i propri prodotti; i criteri decisionali, però, restano applicabili a qualsiasi valutazione build vs. buy.
- La decisione build vs. buy ruota intorno a costo, semplicità d’uso, valore di business e integrazione.
- Autodesk ha ridotto la manutenzione delle pipeline dal 5 percento a meno dell’1 percento del tempo degli analisti.
- I tempi di esecuzione delle trasformazioni sono calati del 68 percento, liberando tempo per attività più strategiche.
Fonte: Build vs. buy data pipeline: Four factors Autodesk considers — https://www.fivetran.com/blog/build-vs-buy-data-pipeline-four-factors-autodesk-considers
Hai qualcosa da aggiungere? Unisciti alla discussione.