Erik Gfesser, Principal Architect per la pratica dei dati di SPR – Serie di interviste

Erik si è unito alla pratica dei dati del gruppo di tecnologie emergenti di SPR come Principal Architect nel 2018.

Erik si è specializzato nei dati, nello sviluppo open source con Java e nell’architettura aziendale pratica, compresa la creazione di proof of concept, prototipi e MVP.

Cosa ti ha inizialmente attirato verso il machine learning?

La sua capacità di consentire alle applicazioni di imparare continuamente. Avevo iniziato la mia carriera di sviluppo come senior data analyst utilizzando SPSS in quella che sarebbe diventata una società di ricerca di mercato globale, e successivamente ho incorporato l’uso di un motore di regole aziendali chiamato Drools nelle applicazioni che ho costruito per i clienti, ma l’output di tutto questo lavoro era essenzialmente statico.

Ho successivamente lavorato attraverso la formazione per il miglioramento dei processi, durante la quale gli istruttori hanno dimostrato in dettaglio come sono stati in grado di migliorare, attraverso statistiche e altri metodi, i processi aziendali utilizzati dai loro clienti, ma anche qui l’output era largamente focalizzato su punti nel tempo. La mia esperienza lavorativa per migliorare un prodotto sanitario che i miei colleghi e io abbiamo costruito durante lo stesso periodo è ciò che mi ha mostrato perché l’apprendimento continuo è necessario per tali sforzi, ma le risorse disponibili all’epoca non esistevano.

Interessantemente, la mia attrazione per il machine learning è tornata full circle, poiché il mio relatore di laurea mi aveva messo in guardia contro una specializzazione in ciò che all’epoca era chiamato intelligenza artificiale, a causa dell’inverno dell’AI di allora. Ho scelto di utilizzare invece termini come ML perché questi hanno meno connotazioni, e perché anche AWS riconosce che il suo livello di servizi AI è essenzialmente una astrazione di livello superiore costruita sopra il suo livello di servizi ML. Mentre alcune delle iperboli sul ML là fuori sono irrealistiche, fornisce capacità potenti dal punto di vista degli sviluppatori, a condizione che questi stessi praticanti riconoscano il fatto che il valore che il ML fornisce è solo buono come i dati elaborati da esso.

Sei un grande sostenitore dell’open source, potresti discutere perché l’open source è così importante?

Un aspetto dell’open source che ho dovuto spiegare agli executive negli anni è che il beneficio principale dell’open source non è che l’uso di tale software è disponibile senza costi monetari, ma che il codice sorgente è disponibile gratuitamente.

Inoltre, gli sviluppatori che utilizzano questo codice sorgente possono modificarlo per il loro uso e, se le modifiche suggerite vengono approvate, renderle disponibili ad altri sviluppatori che lo utilizzano. In realtà, il movimento dietro il software open source è iniziato a causa degli sviluppatori che aspettavano a lungo che le società commerciali apportassero modifiche ai prodotti che avevano licenziato, quindi gli sviluppatori hanno preso l’iniziativa di scrivere software con la stessa funzionalità, aprendolo per essere migliorato da altri sviluppatori.

L’open source commercializzato sfrutta questi benefici, la realtà essendo che molti prodotti moderni utilizzano l’open source sotto il cofano, anche se le varianti commerciali di tale software di solito forniscono componenti aggiuntivi non disponibili come parte di una determinata versione open source, fornendo differenziazioni e supporto se necessario.

Le mie prime esperienze con l’open source si sono verificate mentre costruivo il prodotto sanitario che ho menzionato in precedenza, utilizzando strumenti come Apache Ant, utilizzato per costruire software, e un prodotto DevOps precoce chiamato Hudson (il cui codice base è successivamente diventato Jenkins). Il motivo principale dietro le nostre decisioni di utilizzare questi prodotti open source era che questi fornivano soluzioni migliori rispetto alle alternative commerciali, o erano soluzioni innovative non offerte da entità commerciali, per non parlare del fatto che la licenza commerciale di alcuni dei prodotti che stavamo utilizzando era eccessivamente restrittiva, portando a eccessiva burocrazia quando si trattava di avere bisogno di ulteriori licenze, a causa dei costi coinvolti.

Nel corso del tempo, ho visto le offerte open source continuare a evolversi, fornendo la necessaria innovazione. Ad esempio, molti dei problemi con cui i miei colleghi e io abbiamo lottato costruendo questo prodotto sanitario sono stati successivamente risolti da un innovativo prodotto open source Java che abbiamo iniziato a utilizzare chiamato Spring Framework, che è ancora forte dopo più di un decennio, il cui ecosistema ora si estende ben oltre alcune delle innovazioni che ha inizialmente fornito, ora viste come comuni, come l’iniezione delle dipendenze.

Hai utilizzato l’open source per la costruzione di proof of concept, prototipi e MVP. Potresti condividere il tuo percorso dietro alcuni di questi prodotti?

Come spiegato in uno dei principi guida che ho presentato a un cliente recente, la costruzione della piattaforma dei dati che abbiamo costruito per loro dovrebbe continuare a essere eseguita in modo iterativo nel tempo. I componenti costruiti per questa piattaforma non dovrebbero essere considerati statici, poiché le esigenze cambiano e nuovi componenti e funzionalità dei componenti saranno resi disponibili nel tempo.

Quando si costruisce la funzionalità della piattaforma, si inizia sempre con ciò che è minimamente fattibile prima di aggiungere campanelli e fischietti non necessari, che in alcuni casi includono anche la configurazione. Si inizia con ciò che è funzionale, si assicura di capirlo e poi lo si evolve. Non si spreca tempo e denaro costruendo ciò che ha una bassa probabilità di essere utilizzato, ma si fa uno sforzo per stare un passo avanti rispetto alle esigenze future.

L’MVP che abbiamo costruito per questo prodotto doveva essere costruito in modo tale che ulteriori casi d’uso potessero continuare a essere costruiti su di esso, anche se è stato consegnato con l’implementazione di un singolo caso d’uso, per la rilevazione delle anomalie delle spese. A differenza di questo cliente, un prodotto precedente che ho costruito aveva una storia alle spalle prima del mio arrivo. In questo caso, gli stakeholder avevano discusso per tre anni (!) su come avrebbero dovuto affrontare un prodotto che stavano cercando di costruire. Un executive del cliente ha spiegato che una delle ragioni per cui mi ha portato era aiutare la società a superare alcune di queste discussioni interne, soprattutto perché il prodotto che stava cercando di costruire doveva soddisfare la gerarchia delle organizzazioni coinvolte.

Sono arrivato a scoprire che queste guerre di trincea erano in gran parte associate ai dati di proprietà del cliente, delle sue consociate e dei suoi clienti esterni, quindi in questo caso l’intero backlog del prodotto ruotava attorno a come questi dati sarebbero stati ingeriti, archiviati, protetti e consumati per un singolo caso d’uso che generava reti di fornitori di assistenza sanitaria per analisi dei costi.

All’inizio della mia carriera, ho capito che una qualità architettonica chiamata “usabilità” non era limitata solo agli utenti finali, ma anche agli stessi sviluppatori. Il motivo per cui è così è che il codice scritto deve essere utilizzabile come le interfacce utente devono essere utilizzabili dagli utenti finali. Affinché un prodotto diventi utilizzabile, è necessario costruire proof of concept per dimostrare che gli sviluppatori saranno in grado di fare ciò che si sono prefissati, soprattutto quando si tratta delle scelte tecnologiche specifiche che stanno facendo. Ma i proof of concept sono solo l’inizio, poiché i prodotti sono migliori quando evoluti nel tempo. A mio parere, la base per un MVP dovrebbe ideale essere costruita su prototipi che esibiscono una certa stabilità in modo che gli sviluppatori possano continuare a evolverlo.

Mentre revisionavi il libro ‘Machine Learning at Enterprise Scale’ hai affermato che ‘l’uso di prodotti, framework e linguaggi open source accanto a un’architettura agile composta da una miscela di componenti open source e commerciali fornisce l’agilità che molte società hanno bisogno ma non si rendono immediatamente conto all’inizio’. Potresti entrare nei dettagli su perché credi che le società che utilizzano l’open source siano più agili?

Molti prodotti commerciali dei dati utilizzano componenti open source chiave sotto il cofano, e consentono agli sviluppatori di utilizzare linguaggi di programmazione popolari come Python. Le società che costruiscono questi prodotti sanno che i componenti open source che hanno scelto di incorporare danno loro un vantaggio quando questi sono già ampiamente utilizzati dalla comunità.

I componenti open source con forti comunità sono più facili da vendere, a causa della familiarità che questi portano con sé. I prodotti commercialmente disponibili che consistono principalmente di codice chiuso, o anche open source che è ampiamente utilizzato solo da prodotti commerciali specifici, spesso richiedono una formazione da parte dei venditori o licenze per utilizzare il software.

Inoltre, la documentazione per tali componenti è ampiamente non disponibile pubblicamente, costringendo i team di sviluppo a continuare a dipendere da queste società. Quando ampiamente accettati componenti open source come Apache Spark sono il focus centrale, come con prodotti come Databricks Unified Analytics Platform, molti di questi elementi sono già disponibili nella comunità, minimizzando le parti su cui i team di sviluppo devono fare affidamento su entità commerciali per svolgere il loro lavoro.

Inoltre, poiché componenti come Apache Spark sono ampiamente accettati come strumenti di settore de facto, il codice può anche essere più facilmente migrato tra implementazioni commerciali di tali prodotti. Le società saranno sempre inclini a incorporare ciò che considerano differenziazioni competitive, ma molti sviluppatori non vogliono utilizzare prodotti che sono completamente nuovi perché questo si rivela difficile da spostare tra le società e tende a tagliare i loro legami con le forti comunità che sono abituate a vedere.

Dall’esperienza personale, ho lavorato con tali prodotti in passato e può essere difficile ottenere un supporto competente. E questo è ironico, dato che tali società vendono i loro prodotti con l’aspettativa del cliente che il supporto sarà fornito in modo tempestivo. Ho avuto l’esperienza di inviare una richiesta di pull a un progetto open source, con la correzione incorporata nella build lo stesso giorno, ma non posso dire lo stesso per qualsiasi progetto commerciale con cui ho lavorato.

Un’altra cosa che credi dell’open source è che porta ‘all’accesso a forti comunità di sviluppatori’. Quanto sono grandi alcune di queste comunità e cosa le rende così efficaci?

Le comunità di sviluppatori attorno a un determinato prodotto open source possono raggiungere le centinaia di migliaia. I tassi di adozione non puntano necessariamente alla forza della comunità, ma sono un buon indicatore che questo è il caso a causa della loro tendenza a produrre cicli virtuosi. Considero le comunità forti quando queste producono discussioni sane e documentazione efficace, e quando si verifica uno sviluppo attivo.

Quando un architetto o uno sviluppatore senior lavora attraverso il processo di scelta di quali prodotti incorporare in ciò che stanno costruendo, molti fattori di solito entrano in gioco, non solo riguardo al prodotto stesso e a cosa assomiglia la comunità, ma anche ai team di sviluppo che adotteranno questi, se questi sono un buon fit per l’ecosistema in via di sviluppo, cosa sembra il piano di sviluppo e, in alcuni casi, se il supporto commerciale può essere trovato nel caso in cui ciò possa essere necessario. Tuttavia, molti di questi aspetti cadono in disuso in assenza di forti comunità di sviluppatori.

Hai recensito centinaia di libri sul tuo sito web, ci sono tre che potresti consigliare ai nostri lettori?

Questi giorni leggo pochissimi libri di programmazione, e mentre ci sono eccezioni, la realtà è che questi sono di solito superati molto rapidamente, e la comunità degli sviluppatori di solito fornisce alternative migliori tramite forum di discussione e documentazione. Molti dei libri che leggo attualmente sono resi disponibili gratuitamente per me, o tramite newsletter tecnologiche a cui sono iscritto, o autori e pubblicisti che mi contattano, o quelli che Amazon mi invia. Ad esempio, Amazon mi ha inviato una bozza di pubblicazione non corretta di “The Lean Startup” per la mia recensione nel 2011, introducendomi al concetto di MVP, e recentemente mi ha inviato una copia di “Julia for Beginners”.

(1) Un libro di O’Reilly che ho consigliato è “In Search of Database Nirvana”. L’autore copre nel dettaglio le sfide per un motore di query del database per supportare carichi di lavoro che spaziano dall’OLTP a un’estremità, all’analisi sull’altra estremità, con carichi di lavoro operativi e di business intelligence nel mezzo. Questo libro può essere utilizzato come guida per valutare un motore del database o una combinazione di motori di query e archiviazione, finalizzato a soddisfare i requisiti del carico di lavoro, sia esso transazionale, analitico o una combinazione di entrambi. Inoltre, la copertura dell’autore del “pendolo del database oscillante” negli ultimi anni è particolarmente ben fatta.

(2) Mentre molto è cambiato nello spazio dei dati negli ultimi anni, poiché continuano a essere introdotti nuovi prodotti di analisi dei dati, “Disruptive Analytics” presenta un approccio alla storia degli ultimi 50 anni di innovazione nell’analisi che non ho visto altrove, e discute due tipi di interruzioni: innovazione disruptiva all’interno della catena di valore dell’analisi e interruzione dell’industria attraverso innovazioni nell’analisi. Dal punto di vista delle startup e dei praticanti dell’analisi, il successo è consentito interrompendo le loro industrie, poiché l’uso dell’analisi per differenziare un prodotto è un modo per creare un modello di business disruptivo o per creare nuovi mercati. Dal punto di vista dell’investimento nella tecnologia dell’analisi per le loro organizzazioni, potrebbe avere senso adottare un approccio attendista, poiché le tecnologie a rischio di interruzione sono investimenti rischiosi a causa della loro vita utile abbreviata.

(3) Uno dei migliori testi di business tecnologici che ho letto è “The Limits of Strategy”, di un co-fondatore di Research Board (acquisito da Gartner), un think tank internazionale che indaga gli sviluppi nel mondo del computing e come le società dovrebbero adattarsi. L’autore presenta note molto dettagliate da molte delle sue conversazioni con leader aziendali, fornendo analisi approfondite in tutto ciò che riguarda le sue esperienze nella costruzione (con sua moglie) di un gruppo di clienti, società importanti che avevano bisogno di mescolare le loro strategie con il mondo esplosivo del computing. Come ho commentato nella mia recensione, ciò che distingue questo libro da altri sforzi correlati sono due caratteristiche apparentemente opposte: la larghezza di settore e l’intimità che è disponibile solo attraverso l’interazione faccia a faccia.

Sei il Principal Architect per la pratica dei dati di SPR. Potresti descrivere cosa fa SPR?

SPR è una società di consulenza tecnologica digitale con sede nell’area di Chicago, che consegna progetti tecnologici per una gamma di clienti, dalle società Fortune 1000 alle startup locali. Costruiamo esperienze digitali end-to-end utilizzando una gamma di capacità tecnologiche, tutto, dalla sviluppo di software personalizzato, all’esperienza utente, ai dati e all’infrastruttura cloud, al coaching DevOps, alla testing del software e alla gestione del progetto.

Quali sono alcune delle tue responsabilità con SPR?

Come principale architetto, la mia responsabilità principale è guidare la consegna della soluzione per i clienti, guidando l’architettura e lo sviluppo dei progetti, e ciò significa spesso indossare altri cappelli come il proprietario del prodotto perché essere in grado di relazionarsi con come i prodotti vengono costruiti da una prospettiva pratica pesa molto nel regardare come il lavoro dovrebbe essere prioritizzato, soprattutto quando si costruisce da zero. Sono anche coinvolto in discussioni con potenziali clienti quando la mia esperienza è necessaria, e la società ha recentemente richiesto che iniziassi una serie continua di sessioni con gli altri architetti della pratica dei dati per discutere progetti dei clienti, progetti laterali e cosa i miei colleghi stanno facendo per stare al passo con la tecnologia, simile a ciò che avevo gestito per una precedente società di consulenza, sebbene le riunioni interne per così dire per quest’altra società coinvolgevano l’intera pratica tecnologica, non specifica per il lavoro con i dati.

Per la maggior parte della mia carriera, mi sono specializzato nello sviluppo open source con Java, eseguendo un numero crescente di lavori con i dati lungo la strada. Oltre a queste due specializzazioni, faccio anche ciò che i miei colleghi e io abbiamo iniziato a chiamare “pratica” o “pragmatica” architettura aziendale, che significa eseguire attività di architettura nel contesto di ciò che deve essere costruito e costruendolo effettivamente, piuttosto che solo parlarne o disegnare diagrammi al riguardo, realizzando naturalmente che anche queste altre attività sono importanti.

A mio parere, queste tre specializzazioni si sovrappongono l’una con l’altra e non sono mutualmente esclusive. Ho spiegato agli executive negli ultimi anni che la linea che era stata tradizionalmente tracciata dall’industria tecnologica tra lo sviluppo del software e il lavoro con i dati non è più ben definita, in parte perché gli strumenti tra questi due spazi sono convergenti e in parte perché, a causa di questa convergenza, il lavoro con i dati è ampiamente diventato uno sforzo di sviluppo del software. Tuttavia, poiché i praticanti dei dati tradizionali di solito non hanno background di sviluppo del software e viceversa, aiuto a colmare questa lacuna.

Qual è un progetto interessante su cui stai attualmente lavorando con SPR?

Solo recentemente, ho pubblicato il primo post in una serie di casi di studio su più parti riguardante la piattaforma dei dati che il mio team e io abbiamo implementato in AWS da zero lo scorso anno per il CIO di una società di consulenza globale con sede a Chicago. Questa piattaforma consiste in pipeline dei dati, data lake, modelli di dati canonici, visualizzazioni e modelli di machine learning, da utilizzare dai dipartimenti aziendali, dalle pratiche e dai clienti finali del cliente. Mentre la piattaforma principale doveva essere costruita dall’organizzazione IT aziendale gestita dal CIO, l’obiettivo era che questa piattaforma sarebbe stata utilizzata anche da altre organizzazioni al di fuori dell’IT aziendale per centralizzare gli asset dei dati e l’analisi dei dati in tutta l’azienda utilizzando un’architettura comune, costruendo su di essa per soddisfare le esigenze del caso d’uso di ogni organizzazione.

Come per molte società stabilite, l’uso di Microsoft Excel era comune, con fogli di calcolo comunemente distribuiti all’interno e tra le organizzazioni, nonché tra l’azienda e i clienti esterni. Inoltre, le unità aziendali e le pratiche di consulenza erano diventate isolate, ognuna utilizzando processi e strumenti disparati. Quindi, oltre a centralizzare gli asset dei dati e l’analisi dei dati, un altro obiettivo era implementare il concetto di proprietà dei dati e consentire la condivisione dei dati tra le organizzazioni in modo sicuro e coerente.

C’è qualcos’altro che ti piacerebbe condividere riguardo all’open source, SPR o un altro progetto su cui stai lavorando?

Un altro progetto (leggi di più qui e qui) che ho recentemente guidato ha coinvolto la implementazione con successo di Databricks Unified Analytics Platform e la migrazione dell’esecuzione di modelli di machine learning ad esso da Azure HDInsight, una distribuzione Hadoop, per il direttore dell’ingegneria dei dati di un grande assicuratore.

Tutti questi modelli migrati erano destinati a prevedere il livello di adozione dei consumatori che ci si può aspettare per vari prodotti assicurativi, alcuni dei quali erano stati migrati da SAS alcuni anni prima quando la società si è spostata sull’utilizzo di HDInsight. La sfida più grande è stata la scarsa qualità dei dati, ma altre sfide includevano la mancanza di una versione completa, la conoscenza tribale e la documentazione incompleta e la maturità della documentazione e del supporto di Databricks rispetto all’uso di R al momento (l’implementazione di Azure di Databricks era stata resa disponibile solo pochi mesi prima di questo progetto).

Per affrontare queste sfide chiave, come follow-up al nostro lavoro di implementazione, ho fornito raccomandazioni sull’automazione, la configurazione e la versione, la separazione delle preoccupazioni dei dati, la documentazione e l’allineamento necessario tra i loro team di dati, piattaforma e modellazione. Il nostro lavoro ha convinto un Chief Data Scientist inizialmente molto scettico che Databricks è la strada da percorrere, con l’obiettivo dichiarato dopo la nostra partenza di migrare i loro modelli rimanenti su Databricks il più presto possibile.

Questa è stata un’intervista affascinante che ha toccato molti argomenti, mi sento come se avessi imparato molto sull’open source. I lettori che potrebbero voler saperne di più possono visitare il sito web aziendale SPR o il sito web di Erik Gfesser.