Erik Gfesser, Arhitect Principal pentru practica de date a SPR – Seria de interviuri

Erik s-a alăturat practicii de date a grupului de tehnologie emergentă SPR ca Arhitect Principal în 2018.

Erik s-a specializat în date, dezvoltare open source utilizând Java și arhitectură de întreprindere practică, inclusiv construirea de prototipuri, produse minime viabile și modele de produs.

Ce v-a atras inițial la învățarea automată?

Capacitatea sa de a permite aplicațiilor să învețe continuu. Am început cariera mea de dezvoltator ca analist de date senior utilizând SPSS la o firmă de cercetare de piață globală și, ulterior, am incorporat utilizarea unui motor de reguli de afaceri numit Drools în aplicațiile pe care le-am construit pentru clienți, dar rezultatul tuturor acestor lucrări a fost esențialmente static.

Ulterior, am lucrat la îmbunătățirea proceselor, în timpul căreia instructorii au demonstrat în detaliu cum au putut îmbunătăți, prin statistici și alte metode, procesele de afaceri utilizate de clienții lor, dar și aici rezultatul a fost în mare măsură concentrat pe puncte în timp. Experiența mea de a lucra la îmbunătățirea unui produs de sănătate pe care l-am construit împreună cu colegii mei în aceeași perioadă este cea care mi-a arătat de ce învățarea continuă este necesară pentru astfel de eforturi, dar resursele disponibile atunci nu existau.

Interesant, atracția mea către învățarea automată a venit pe o cale circulară, deoarece consilierul meu de la facultate m-a avertizat împotriva unei specializări în ceea ce se numea atunci inteligență artificială, din cauza iernii IA din acea perioadă. Am ales să utilizez termeni precum ML, deoarece aceștia au mai puține conotații și pentru că chiar și AWS recunoaște că stratul său de servicii AI este de fapt o abstracție de nivel superior construită pe baza serviciilor sale ML. Deși o parte din hype-ul din jurul ML este nerealist, oferă capacități puternice din perspectiva dezvoltatorilor, atâta timp cât acești practicieni recunosc faptul că valoarea pe care o oferă ML este la fel de bună ca și datele procesate de acesta.

Sunteți un mare susținător al open source, puteți discuta de ce este atât de important open source?

Un aspect despre open source pe care l-am trebuit să explic executivilor de-a lungul anilor este că beneficiul principal al open source nu constă în faptul că utilizarea unui astfel de software este disponibilă fără costuri monetare, ci în faptul că codul sursă este disponibil gratuit.

În plus, dezvoltatorii care utilizează acest cod sursă îl pot modifica pentru uzul propriu și, dacă modificările sugerate sunt aprobate, pot face aceste modificări disponibile altor dezvoltatori care îl utilizează. De fapt, mișcarea din spatele software-ului open source a început din cauza faptului că dezvoltatorii au așteptat mult timp ca firmele comerciale să facă modificări la produsele pe care le-au licențiat, astfel încât dezvoltatorii au decis să scrie software cu aceeași funcționalitate, deschizându-l pentru a fi îmbunătățit de alți dezvoltatori.

Open source comercial profită de aceste beneficii, realitatea fiind că multe produse moderne utilizează open source sub forma lor inițială, chiar dacă variantele comerciale ale acestor software de obicei oferă componente suplimentare care nu sunt disponibile ca parte a unei anumite lansări open source, oferind diferențiatori, precum și suport dacă acesta este necesar.

Prima mea experiență cu open source a avut loc în timp ce construiam produsul de sănătate menționat anterior, utilizând instrumente precum Apache Ant, utilizate pentru a construi software, și un produs DevOps timpuriu numit Hudson (baza de cod a căruia a devenit ulterior Jenkins). Motivul principal din spatele deciziilor noastre de a utiliza aceste produse open source a fost că acestea ofereau soluții mai bune decât alternativele comerciale sau erau soluții inovatoare care nu erau oferite de entități comerciale, pentru a nu mai menționa că licențierea comercială a unor dintre produsele pe care le utilizam era excesiv de restrictivă, conducând la birocrație excesivă atunci când era necesară obținerea de licențe suplimentare, din cauza costurilor implicate.

De-a lungul timpului, am văzut ofertele open source continuând să evolueze, oferind inovații mult necesare. De exemplu, multe dintre problemele cu care colegii mei și eu ne-am confruntat la construirea acestui produs de sănătate au fost ulterior rezolvate de un produs open source inovator pe care am început să îl utilizăm, numit Spring Framework, care este încă puternic după mai mult de un deceniu, ecosistemul său extinzându-se mult dincolo de unele dintre inovațiile pe care le-a oferit inițial, considerate acum obișnuite, cum ar fi injecția de dependențe.

Ați utilizat open source pentru construirea de prototipuri, produse minime viabile și modele de produs. Puteți împărtăși experiența dvs. din spatele unor astfel de produse?

După cum am explicat în una dintre principiile directoare pe care le-am prezentat unui client recent, construirea platformei de date pe care am construit-o pentru ei ar trebui să continue să fie realizată iterativ pe măsură ce este necesar, în timp ce componentele construite pentru această platformă nu ar trebui să fie considerate statice, deoarece nevoile se schimbă și noi componente și funcționalități ale componentelor vor fi disponibile în timp.

Când se construiește funcționalitatea platformei, se începe întotdeauna cu ceea ce este minim viabil înainte de a adăuga clopote și fluierători inutile, care în unele cazuri includ chiar și configurarea. Se începe cu ceea ce este funcțional, se asigură că se înțelege și apoi se evoluează. Nu se irosesc timp și bani construind ceea ce are o mică probabilitate de a fi utilizat, dar se face efortul de a anticipa nevoile viitoare.

Produsul minim viabil pe care l-am construit pentru acest client a trebuit să fie construit astfel încât să poată fi construite ulterior și alte cazuri de utilizare pe baza acestuia, chiar dacă a venit împachetat cu implementarea unui singur caz de utilizare, și anume detectarea anomaliilor de cheltuieli. În contrast, un produs pe care l-am construit anterior avea o istorie înainte de a ajunge la mine. În acest caz, stakeholderii dezbătuseră timp de trei ani (!) cum ar trebui să abordeze produsul pe care îl doreau să îl construiască. Un executiv al clientului mi-a explicat că una dintre motivele pentru care m-a adus a fost să ajute firma să depășească unele dintre aceste dezbateri interne, mai ales pentru că produsul pe care dorea să îl construiască trebuia să satisfacă ierarhia organizațiilor implicate.

Am descoperit că aceste războaie de teritoriu erau în mare măsură asociate cu datele deținute de client, filialele sale și clienții săi externi, astfel încât în acest caz întregul backlog al produsului s-a învârtit în jurul modului în care aceste date urmau să fie ingerate, stocate, securizate și consumate pentru un singur caz de utilizare care generează rețele de furnizori de sănătate pentru analize de cost.

La începutul carierei mele, am ajuns să înțeleg că o calitate arhitecturală numită “utilizabilitate” nu se limitează doar la utilizatorii finali, ci și la dezvoltatorii de software înșiși. Motivul pentru aceasta este că codul scris trebuie să fie utilizabil, la fel cum interfețele cu utilizatorul trebuie să fie utilizabile de către utilizatorii finali. Pentru ca un produs să devină utilizabil, trebuie construite prototipuri pentru a demonstra că dezvoltatorii vor putea face ceea ce și-au propus, mai ales atunci când este legat de alegerile specifice de tehnologie pe care le fac. Dar prototipurile sunt doar începutul, deoarece produsele sunt mai bune atunci când sunt evoluate în timp. În opinia mea, baza pentru un produs minim viabil ar trebui să fie construită pe prototipuri care prezintă o anumită stabilitate, astfel încât dezvoltatorii să poată continua să o evolueze.

În timp ce revizionați cartea “Învățarea automată la scară întreprindere”, ați afirmat că “utilizarea produselor, cadrelor și limbajelor open source, alături de o arhitectură agilă compusă dintr-un amestec de componente open source și comerciale, oferă agilitatea de care multe firme au nevoie, dar nu realizează imediat de la început”. Puteți intra în detalii despre de ce credeți că firmele care utilizează open source sunt mai agile?

Multe produse comerciale de date utilizează componente open source importante sub forma lor inițială și permit dezvoltatorilor să utilizeze limbaje de programare populare, cum ar fi Python. Firmele care construiesc aceste produse știu că componentele open source pe care le-au ales să le incorporeze le oferă un avans atunci când acestea sunt deja utilizate pe scară largă de comunitate.

Componentele open source cu comunități puternice sunt mai ușor de vândut, datorită familiarității pe care o aduc la masa negocierilor. Produsele comercialmente disponibile care constau în mare parte din cod închis sau chiar open source care este utilizat în mare parte doar de produse comerciale specifice, adesea necesită fie training de la acești furnizori, fie licențe pentru a utiliza software-ul.

În plus, documentația pentru astfel de componente nu este în mare parte disponibilă public, forțând dezvoltatorii să depindă în continuare de aceste firme. Atunci când componente open source larg acceptate, cum ar fi Apache Spark, sunt în centrul atenției, cum ar fi produsele Databricks Unified Analytics Platform, multe dintre aceste articole sunt deja disponibile în comunitate, minimizând porțiunile pe care echipele de dezvoltare trebuie să depindă de entități comerciale pentru a-și face treaba.

În plus, deoarece componente precum Apache Spark sunt în general acceptate ca instrumente standard de industrie, codul poate fi de asemenea ușor migrat între implementări comerciale ale acestor produse. Firmele vor fi întotdeauna inclinate să incorporeze ceea ce consideră a fi diferențiatori competitivi, dar mulți dezvoltatori nu doresc să utilizeze produse care sunt complet noi, deoarece acest lucru se dovedește a fi o provocare pentru a trece de la o firmă la alta și are tendința de a rupe legăturile cu comunitățile puternice pe care au ajuns să le aștepte.

Din experiența mea personală, am lucrat cu astfel de produse în trecut și a fost o provocare să obțin suport competent. Și acest lucru este ironic, având în vedere că astfel de firme vând produsele lor cu așteptarea clienților că suportul va fi furnizat într-un mod prompt. Am avut experiența de a trimite o solicitare de extragere la un proiect open source, cu fixarea încorporată în construcția de aceeași zi, dar nu pot spune același lucru despre niciun proiect comercial cu care am lucrat.

Ceva mai mult despre open source pe care credeți că este important: oferă “acces la comunități puternice de dezvoltatori”. Cât de mari sunt unele dintre aceste comunități și ce le face atât de eficiente?

Comunitățile de dezvoltatori din jurul unui anumit produs open source pot ajunge la sute de mii de persoane. Ratele de adopție nu indică neapărat forța comunității, dar sunt un bun indicator că acesta este cazul, datorită tendinței lor de a produce cicluri virtuoase. Consider comunitățile puternice atunci când acestea produc discuții sănătoase și documentație eficientă și când are loc o dezvoltare activă.

Când un arhitect sau un dezvoltator senior lucrează pentru a alege care produse să incorporeze în ceea ce construiesc, multe factori vin în joc, nu doar despre produsul în sine și despre cum arată comunitatea, ci și despre echipele de dezvoltare care vor adopta acestea, dacă acestea sunt potrivite pentru ecosistemul care este dezvoltat, ce arată drumul și, în unele cazuri, dacă suportul comercial poate fi găsit în cazul în care acesta este necesar. Cu toate acestea, multe dintre aceste aspecte sunt lăsate deoparte în absența unor comunități puternice de dezvoltatori.

Ați recenzat sute de cărți pe site-ul dvs., puteți recomanda trei dintre ele cititorilor noștri?

În zilele noastre, citesc foarte puține cărți de programare și, deși există excepții, realitatea este că acestea sunt de obicei învechite foarte repede, iar comunitatea de dezvoltatori de obicei oferă alternative mai bune prin forumuri de discuții și documentație. Multe dintre cărțile pe care le citesc mi-au fost puse la dispoziție gratuit, fie prin buletine de știri tehnice la care mă abonez, fie prin autori și publiciști care mă contactează, fie prin cele pe care mi le trimite Amazon (AMZN ). De exemplu, Amazon mi-a trimis o dovadă de publicare necorectată a “The Lean Startup” pentru recenzia mea în 2011, introducându-mă în conceptul de produs minim viabil și, recent, mi-a trimis o copie a “Julia pentru începători”.

(1) O carte de la O’Reilly pe care am recomandat-o este “În căutarea Nirvanei bazei de date”. Autorul acoperă în detaliu provocările pe care le are un motor de interogare a bazei de date pentru a susține sarcini de lucru care se întind de la OLTP la analize, cu sarcini de lucru operaționale și de inteligență de afaceri în mijloc. Această carte poate fi utilizată ca un ghid pentru a evalua un motor de interogare a bazei de date sau o combinație de motoare de interogare și stocare, orientată spre a îndeplini cerințele de sarcin de lucru, fie că sunt tranzacționale, analitice sau o combinație a acestor două. În plus, acoperirea autorului a “pendulului bazei de date” în ultimii ani este deosebit de bine făcută.

(2) Deși multe s-au schimbat în spațiul de date în ultimii ani, deoarece produse noi de analize de date continuă să fie introduse, “Analize perturbatoare” prezintă o abordare istorică scurtă a ultimilor 50 de ani de inovație în analize pe care nu am văzut-o în altă parte și discută două tipuri de perturbări: inovație perturbatoare în lanțul de valoare al analizei și perturbarea industriei prin inovații în analize. Din perspectiva startup-urilor și a practicienilor de analize, succesul este facilitat de perturbarea industriilor lor, deoarece utilizarea analizei pentru a diferenția un produs este o modalitate de a crea un model de afaceri perturbator sau de a crea piețe noi. Din perspectiva investițiilor în tehnologia de analize pentru organizațiile lor, abordarea “așteaptă și vezi” poate avea sens, deoarece tehnologiile care sunt în pericol de a fi perturbate sunt investiții riscante din cauza duratei lor de viață utilă scurtă.

(3) Una dintre cele mai bune cărți de afaceri tehnice pe care le-am citit este “Limitările strategiei”, de un co-fondator al Research Board (achiziționat de Gartner), un think tank internațional care investighează dezvoltările din lumea calculatoarelor și modul în care corporațiile ar trebui să se adapteze. Autorul prezintă note foarte detaliate din multe dintre conversațiile sale cu lideri de afaceri, oferind analize insightuale pe tot parcursul despre experiențele sale de a construi (împreună cu soția sa) un grup de clienți, firme majore care aveau nevoie de a-și alinia strategiile cu lumea explozivă a calculatoarelor. Așa cum am comentat în recenzia mea, ceea ce face această carte distinctă de alte eforturi conexe este două caracteristici aparent opuse: lățimea pe scară largă a industriei și intimitatea care este disponibilă doar prin interacțiunea față în față.

Sunteți Arhitect Principal pentru practica de date a SPR. Puteți descrie ce face SPR?

SPR este o firmă de consultanță tehnologică digitală cu sediul în zona Chicago, care livrează proiecte tehnologice pentru o gamă de clienți, de la întreprinderi din Fortune 1000 la startup-uri locale. Construim experiențe digitale de la cap la coadă, utilizând o gamă de capacități tehnologice, de la dezvoltare de software personalizat, experiență utilizator, date și infrastructură cloud, la coaching DevOps, testare software și management de proiect.

Care sunt unele dintre responsabilitățile dvs. cu SPR?

Ca arhitect principal, responsabilitatea mea cheie este de a conduce livrarea de soluții pentru clienți, conducând arhitectura și dezvoltarea pentru proiecte și, adesea, acest lucru înseamnă purtarea altor pălării, cum ar fi proprietarul produsului, deoarece capacitatea de a relaționa cu modul în care produsele sunt construite dintr-o perspectivă practică cântărește greu în ceea ce privește modul în care ar trebui să fie prioritizată munca, mai ales atunci când se construiește de la zero. Sunt, de asemenea, implicat în discuții cu clienți potențiali atunci când este nevoie de expertiza mea și compania a solicitat recent să încep o serie în curs de desfășurare de sesiuni cu alți arhitecți din practica de date pentru a discuta proiecte ale clienților, proiecte laterale și ceea ce fac colegii mei pentru a rămâne la curent cu tehnologia, similar cu ceea ce am condus pentru o consultanță anterioară, deși întâlnirile interne pentru acea firmă au implicat întreaga practică de tehnologie, nu doar cea de date.

Pe parcursul majorității carierei mele, m-am specializat în dezvoltare open source utilizând Java, efectuând o cantitate tot mai mare de muncă de date pe parcurs. În plus față de aceste două specializări, fac și ceea ce colegii mei și eu am ajuns să numim “arhitectură de întreprindere practică” sau “pragmatică”, ceea ce înseamnă efectuarea de sarcini de arhitectură în contextul a ceea ce urmează să fie construit și, de fapt, construindu-l, mai degrabă decât doar vorbind despre el sau desenând diagrame despre el, realizând, desigur, că aceste alte sarcini sunt, de asemenea, importante.

În opinia mea, aceste trei specializări se suprapun unele peste altele și nu sunt mutuale exclusive. Am explicat executivilor în ultimii ani că linia care a fost trasată în mod tradițional de industria tehnologiei între dezvoltarea de software și munca de date nu mai este bine definită, parțial pentru că instrumentarul dintre aceste două spații a convergit și parțial pentru că, ca urmare a acestei convergențe, munca de date în sine a devenit în mare măsură o muncă de dezvoltare de software. Cu toate acestea, deoarece practicienii de date tradiționali de obicei nu au fundaluri de dezvoltare de software și viceversa, ajut la îndeplinirea acestei lacune.

Ce proiect interesant lucrați în prezent cu SPR?

Recent, am publicat primul post dintr-o serie de studii de caz despre platforma de date pe care am implementat-o de la zero în AWS în acest an pentru CIO-ul unei consultanțe globale cu sediul în Chicago. Această platformă constă în conducte de date, lac de date, modele de date canonice, visualizări și modele de învățare automată, care urmează să fie utilizate de departamentele corporative, practicile și clienții finali ai clientului. În timp ce platforma de bază urma să fie construită de organizația IT corporativă condusă de CIO, scopul a fost ca această platformă să fie utilizată de alte organizații din afara IT-ului corporativ pentru a centraliza activele de date și analiza de date pe tot parcursul companiei, utilizând o arhitectură comună, construind pe baza acesteia pentru a îndeplini nevoile de cazuri de utilizare ale fiecărei organizații.

La fel ca multe firme stabilite, utilizarea Microsoft Excel era obișnuită, cu foi de calcul distribuite în interiorul și între organizații, precum și între firmă și clienții externi. În plus, unitățile de afaceri și practicile de consultanță au devenit izolate, utilizând procese și instrumente disparate. Astfel, pe lângă centralizarea activelor de date și a analizei de date, un alt obiectiv a fost să se implementeze conceptul de proprietate a datelor și să se permită partajarea datelor între organizații într-un mod securizat și consecvent.

Este ceva mai mult pe care ați dori să îl împărtășiți despre open source, SPR sau un alt proiect la care lucrați?

Un alt proiect (cititi despre el aici și aici) pe care l-am condus recent a implicat implementarea cu succes a platformei Databricks Unified Analytics și migrarea execuției modelelor de învățare automată de la Azure HDInsight, o distribuție Hadoop, la directorul de inginerie de date al unei asigurători mari.

Toate aceste modele migrate au fost destinate să prevadă nivelul de adoptare pe care se poate aștepta pentru diverse produse de asigurare, unele dintre ele fiind migrate de la SAS cu câțiva ani în urmă, în momentul în care compania a trecut la utilizarea HDInsight. Cea mai mare provocare a fost calitatea slabă a datelor, dar alte provocări au inclus lipsa de versionare cuprinzătoare, cunoașterea tribală și documentația incompletă, precum și documentația și suportul imatur al Databricks în ceea ce privește utilizarea R în momentul respectiv (implementarea Azure a Databricks a fost lansată cu doar câteva luni înainte de a începe acest proiect).

Pentru a aborda aceste provocări cheie, ca urmare a lucrării noastre de implementare, am făcut recomandări cu privire la automatizare, configurare și versionare, separarea problemelor de date, documentație și alinierea necesară între echipele lor de date, platformă și modelare. Lucrarea noastră i-a convins pe un șef de științific care a fost inițial foarte sceptic că Databricks este calea de urmat, cu obiectivul declarat de a-și muta modelele rămase în Databricks cât mai curând posibil după plecarea noastră.

Acesta a fost un interviu fascinant care a atins multe subiecte, simt că am învățat mult despre open source. Citiitorii care doresc să afle mai multe pot vizita site-ul corporativ SPR sau site-ul lui Erik Gfesser.