Erik Gfesser, Architetto Principale 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 Architetto Principale nel 2018.

Erik è diventato specializzato in dati, sviluppo open source utilizzando Java e architettura aziendale pratica, compresa la costruzione di prove di concetto, prototipi e MVP.

Cosa ti ha inizialmente attirato verso il machine learning?

La sua capacità di abilitare le applicazioni a imparare continuamente. Avevo iniziato la mia carriera di sviluppo come analista di dati senior utilizzando SPSS in 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.

In seguito, ho lavorato alla formazione per il miglioramento dei processi, durante la quale gli istruttori hanno dimostrato in dettaglio come fossero 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 nel lavorare per migliorare un prodotto sanitario che i miei colleghi e io avevamo costruito durante questo 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 consigliere 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 servizio AI è essenzialmente una maggiore astrazione costruita sopra il suo livello di servizio ML. Sebbene alcune delle iperboli del ML là fuori siano irrealistiche, fornisce potenti capacità 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 principale beneficio 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 perché gli sviluppatori aspettavano a lungo che le società commerciali apportassero modifiche ai prodotti che avevano licenziato, quindi gli sviluppatori hanno deciso di scrivere software con la stessa funzionalità, aprendolo per essere migliorato da altri sviluppatori.

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

Le mie prime esperienze con l’open source risalgono al periodo in cui ho costruito 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 sorgente è poi diventato Jenkins). Il motivo principale dietro la nostra decisione di utilizzare questi prodotti open source era che questi fornivano soluzioni migliori rispetto alle alternative commerciali o erano soluzioni innovative non offerte da enti 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 ottenere ulteriori licenze a causa dei costi coinvolti.

Nel 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 ci siamo confrontati nella costruzione di 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 considerate comuni, come l’iniezione delle dipendenze.

Hai utilizzato l’open source per la costruzione di prove di concetto, 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 essere continuamente eseguita nel tempo. I componenti costruiti per questa piattaforma non dovrebbero essere considerati statici, poiché le esigenze cambiano e nuovi componenti e funzionalità saranno resi disponibili nel tempo.

Quando si costruisce la funzionalità della piattaforma, è sempre necessario iniziare con ciò che è minimamente fattibile prima di aggiungere campanelli e fischietti non necessari, che in alcuni casi includono anche la configurazione. Iniziare con ciò che è funzionale, assicurarsi di capirlo e poi evolverlo. Non sprecare tempo e denaro costruendo ciò che ha una bassa probabilità di essere utilizzato, ma cercare di stare un passo avanti rispetto alle esigenze future.

L’MVP che abbiamo costruito per questo prodotto doveva essere costruito in modo da poter continuare a costruire ulteriori casi d’uso 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 che ho costruito in precedenza aveva una storia alle spalle prima del mio arrivo. In questo caso, gli stakeholder avevano discusso per tre anni (!) su come avvicinarsi a un prodotto che stavano cercando di costruire. Un esecutivo del cliente mi ha spiegato che una delle ragioni per cui mi ha assunto era aiutare la società a superare alcune di queste discussioni interne, soprattutto perché il prodotto che stavano cercando di costruire doveva soddisfare la gerarchia delle organizzazioni coinvolte.

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

In precedenza nella mia carriera, ho capito che una qualità architettonica chiamata “usabilità” non era limitata solo agli utenti finali, ma anche agli sviluppatori di software. Il motivo per cui è così è che il codice scritto deve essere utilizzabile proprio come le interfacce utente devono essere utilizzabili dagli utenti finali. Affinché un prodotto diventi utilizzabile, è necessario costruire prove di concetto 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 le prove di concetto 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 mostrano una certa stabilità in modo che gli sviluppatori possano continuare a evolverlo.

Nel recensire il libro “Machine Learning a livello aziendale” 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à necessitano ma non si rendono immediatamente conto all’inizio”. Potresti entrare nei dettagli di perché ritieni che le società che utilizzano l’open source siano più agili?

Molti prodotti commerciali per i 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 iniziale poiché questi sono già ampiamente utilizzati dalla comunità.

I componenti open source con forti comunità sono più facili da vendere, grazie alla familiarità che questi portano con sé. I prodotti disponibili commercialmente 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 non è ampiamente disponibile pubblicamente, costringendo la continua dipendenza degli sviluppatori da queste società. Quando componenti open source ampiamente accettati come Apache Spark sono al centro dell’attenzione, 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 standard dell’industria, 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é ciò si rivela impegnativo per spostarsi tra società e tende a tagliare i loro legami con le forti comunità che si sono abituate ad aspettarsi.

Per esperienza personale, ho lavorato con tali prodotti in passato e può essere impegnativo ottenere un supporto competente. E questo è ironico, considerando 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 dato 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 del fatto che ciò sia 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 tipicamente entrano in gioco, non solo sul prodotto stesso e su cosa sembra la comunità, ma sui team di sviluppo che adotteranno questi, se questi sono un buon adattamento per l’ecosistema in via di sviluppo, cosa sembra la roadmap 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 nell’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, sebbene ci siano eccezioni, la realtà è che questi sono generalmente superati molto rapidamente e la comunità di sviluppatori di solito fornisce alternative migliori attraverso forum di discussione e documentazione. Molti dei libri che leggo attualmente mi vengono forniti gratuitamente, o tramite newsletter tecnologiche a cui sono iscritto, o da autori e pubblicisti che mi contattano, o quelli che Amazon (AMZN ) mi invia. Ad esempio, Amazon mi ha inviato una prova di stampa 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 per principianti”.

(1) Un libro di O’Reilly che ho consigliato è “In Search of Database Nirvana”. L’autore tratta in dettaglio le sfide per un motore di query di database per supportare carichi di lavoro che coprono lo spettro di OLTP da un lato a analisi dall’altro, con carichi di lavoro operativi e di business intelligence nel mezzo. Questo libro può essere utilizzato come guida per valutare un motore di database o una combinazione di motori di query e archiviazione, finalizzata a soddisfare i requisiti del carico di lavoro, siano essi transazionali, analitici o una combinazione di entrambi. Inoltre, la copertura dell’autore del “pendolo del database oscillante” negli ultimi anni è particolarmente ben fatta.

(2) Sebbene molto sia cambiato nello spazio dei dati negli ultimi anni, poiché continuano a essere introdotti nuovi prodotti di analisi dei dati, “Disruptive Analytics” presenta un approccio accessibile, una breve 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 di 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 di investire in tecnologia di 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 è “I limiti della strategia”, di un co-fondatore di Research Board (acquisito da Gartner), un think tank internazionale che indaga gli sviluppi nel mondo del computing e su come le società dovrebbero adattarsi. L’autore presenta note molto dettagliate da molte delle sue conversazioni con leader aziendali, fornendo analisi approfondite in tutto il testo sulle sue esperienze nella costruzione (con sua moglie) di un gruppo di clienti, grandi società che avevano bisogno di integrare le loro strategie con il mondo del computing in rapida espansione. 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 l’Architetto Principale 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, dalla sviluppo di software personalizzato, esperienza utente, dati e infrastruttura cloud, alla formazione DevOps, testing del software e gestione dei progetti.

Quali sono alcune delle tue responsabilità con SPR?

Come architetto principale, la mia responsabilità principale è guidare la consegna delle soluzioni per i clienti, dirigendo l’architettura e lo sviluppo dei progetti e ciò spesso significa indossare altri cappelli come proprietario del prodotto perché essere in grado di relazionarsi con come i prodotti vengono costruiti da una prospettiva pratica pesa molto nel modo in cui il lavoro dovrebbe essere prioritizzato, soprattutto quando si costruisce da zero. Vengo 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 gli incontri interni per così dire per quell’altra società coinvolgevano l’intera pratica tecnologica, non specifica per i dati.

Per la maggior parte della mia carriera, mi sono specializzato nello sviluppo open source utilizzando Java, eseguendo un crescente numero di lavori sui dati lungo la strada. In aggiunta a queste due specializzazioni, faccio anche ciò che i miei colleghi e io abbiamo iniziato a chiamare “architettura aziendale pratica” o “pragmatica”, 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 a vicenda e non sono mutuamente 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 sui dati non è più ben definita, in parte perché gli strumenti tra questi due spazi si sono convergenti e in parte perché, a causa di questa convergenza, il lavoro sui dati stesso è ampiamente diventato uno sforzo di sviluppo del software. Tuttavia, poiché i praticanti di dati tradizionali di solito non hanno background di sviluppo del software e viceversa, aiuto a colmare questo divario.

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

Recentemente, ho pubblicato il primo post in una serie di casi di studio multi-parti su una piattaforma di dati che il mio team e io abbiamo implementato su AWS da zero lo scorso anno per il CIO di una società di consulenza globale con sede a Chicago. Questa piattaforma consiste in pipeline di dati, laghi di dati, modelli di dati canonici, visualizzazioni e modelli di apprendimento automatico, 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 di dati e l’analisi dei dati in tutta la società 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 organizzazioni, nonché tra la società e i clienti esterni. Inoltre, le unità aziendali e le pratiche di consulenza erano diventate isolate, ognuna utilizzando processi e strumenti diversi. Quindi, oltre a centralizzare gli asset di dati e l’analisi dei dati, un altro obiettivo era implementare il concetto di proprietà dei dati e consentire la condivisione dei dati tra organizzazioni in modo sicuro e coerente.

C’è qualcos’altro che vorresti condividere sull’open source, SPR o un altro progetto su cui stai lavorando?

Un altro progetto (leggi qui e qui) che ho recentemente guidato ha comportato l’implementazione con successo di Databricks Unified Analytics Platform e la migrazione dell’esecuzione di modelli di apprendimento automatico su di esso da Azure HDInsight, una distribuzione Hadoop, per il direttore dell’ingegneria dei dati di una grande compagnia di assicurazioni.

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à aveva iniziato a utilizzare HDInsight. La sfida più grande è stata la scarsa qualità dei dati, ma altre sfide includevano la mancanza di versioning completo, conoscenza tribale e documentazione incompleta e immatura documentazione e supporto di Databricks per l’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 il versioning, la separazione delle preoccupazioni dei dati, la documentazione e l’allineamento necessario tra i team di dati, piattaforma e modellazione. Il nostro lavoro ha convinto un capo scienziato dei dati inizialmente molto scettico che Databricks è la strada da percorrere, con l’obiettivo dichiarato dopo la nostra partenza di migrare i restanti modelli su Databricks il più presto possibile.

Questa è stata una intervista affascinante che tocca 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 di SPR o il sito web di Erik Gfesser.