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 folosind Java și arhitectură enterprise practică, inclusiv construirea de prototipuri, demonstrații de concept și produse minime viable (MVP).

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

Posibilitatea aplicațiilor de a învăța în mod continuu. Am început cariera mea de dezvoltator ca analist de date senior, folosind SPSS la ceea ce a devenit o firmă globală de cercetare de piață, și mai târziu 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.

Am lucrat ulterior la îmbunătățirea proceselor, în timpul cărora 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 aici, de asemenea, rezultatul a fost în mare măsură axat 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ă m-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 completă, deoarece consilierul meu de masterat 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ă folosesc în schimb termeni precum ML, deoarece aceștia au conotații mai puține, ș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 legat de ML din jurul nostru 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 avocat al open source, puteți discuta de ce open source este atât de important?

Un aspect despre open source pe care am trebuit să-l 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ă schimbările sugerate sunt aprobate, le pot face disponibile altor dezvoltatori care îl utilizează. De fapt, mișcarea din spatele software-ului open source a început din cauza faptului că dezvoltatorii așteptau mult timp ca firmele comerciale să facă schimbări în produsele pe care le-au licențiat, așa că 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 comercializează aceste beneficii, realitatea fiind că multe produse moderne utilizează open source sub copertă, chiar dacă variantele comerciale ale unui astfel de software oferă de obicei componente suplimentare care nu sunt disponibile ca parte a unei versiuni 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 mai devreme, folosind unelte precum Apache Ant, utilizat 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, fără a 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 nevoie de mai multe licențe, 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 eu și colegii mei ne-am luptat la construirea acestui produs de sănătate au fost ulterior rezolvate de un produs open source inovator pe Java pe care am început să-l utilizăm, numit Spring Framework, care este încă puternic după mai mult de un deceniu, ecosistemul acestuia extinzându-se mult dincolo de unele dintre inovațiile pe care le-a oferit inițial, acum considerate comună, cum ar fi injecția de dependențe.

Ați utilizat open source pentru construirea de prototipuri, demonstrații de concept și produse minime viable. Puteți împărtăși drumul dvs. din spatele unor astfel de produse?

Așa 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 parcursul timpului, după cum este necesar. Componentele construite pentru această platformă nu ar trebui să fie considerate statice, deoarece nevoile se schimbă și noi componente și caracteristici ale componentelor vor fi disponibile pe parcursul timpului.

Atunci când se construiește funcționalitatea platformei, întotdeauna începeți cu ceea ce este minim viable înainte de a adăuga clopote și fluiere inutile, ceea ce în unele cazuri include chiar și configurarea. Începeți cu ceea ce este funcțional, asigurați-vă că îl înțelegeți, și apoi evoluați-l. Nu pierdeți timp și bani construind ceea ce are o mică probabilitate de a fi utilizat, dar faceți eforturi pentru a fi înaintea nevoilor viitoare.

MVP-ul pe care l-am construit pentru acest produs a trebuit să fie construit astfel încât să poată fi construite suplimentar alte cazuri de utilizare pe baza acestuia, chiar dacă a fost livrat cu implementarea unui singur caz de utilizare, pentru detectarea anomaliilor de cheltuieli. Spre deosebire de acest client, un produs anterior pe care l-am construit avea o istorie înainte de a ajunge la mine. În acest caz, stakeholderii dezbătuseră timp de trei ani (!) cum ar trebui să abordeze un produs 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 compania 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 și clienții externi, așa că în acest caz întregul backlog al produsului s-a învârtit în jurul modului în care aceste date urmau să fie încorporate, 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 acest lucru este acela 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, demonstrații de concept trebuie să fie construite pentru a demonstra că dezvoltatorii vor putea face ceea ce și-au propus, mai ales atunci când este legat de alegerile tehnologice specifice pe care le fac. Dar demonstrațiile de concept sunt doar începutul, deoarece produsele sunt mai bune atunci când evoluează în timp. În opinia mea, fundația pentru un MVP 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 revizuiam cartea “Machine Learning la scară enterprise”, ați declarat că “utilizarea produselor, cadrului ș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 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 cheie sub copertă ș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. Produsele disponibile comercial 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 formare de la parte furnizorilor, 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 dependența continuă a dezvoltatorilor 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ă se bazeze pe entități comerciale pentru a-și face treaba.

În plus, deoarece componente precum Apache Spark sunt acceptate pe scară largă ca instrumente standard de industrie, codul poate fi de asemenea migrat mai ușor î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 dificil de mutat între firme și are tendința de a tăia legăturile cu comunitățile puternice pe care le-au ajuns să le aștepte.

Din experiența mea personală, am lucrat cu astfel de produse în trecut, și poate fi dificil să obțineți suport competent. Și acest lucru este ironic, având în vedere că astfel de firme vând produsele lor cu așteptarea clientului că suportul va fi furnizat în mod prompt. Am avut experiența de a trimite o solicitare de extragere la un proiect open source, cu fixarea incorporată în clădirea din aceeași zi, dar nu pot spune același lucru despre niciun proiect comercial cu care am lucrat.

Ceva altceva pe care credeți despre open source este că duce la “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. Rata de adoptare nu indică neapărat puterea comunității, dar este un bun indicator că acesta este cazul, datorită tendinței de a produce cicluri virtuoase. Consider că comunitățile sunt puternice atunci când produc discuții sănătoase și documentație eficientă, și atunci când are loc o dezvoltare activă.

Atunci când un arhitect sau un dezvoltator senior lucrează prin procesul de a alege care astfel de produse să incorporeze în ceea ce construiesc, mulți 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 un bun fit pentru ecosistemul care se dezvoltă, 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 cad în paragina lipsă de comunități puternice de dezvoltatori.

Ați revizuit sute de cărți pe site-ul dvs., există trei pe care le-ați putea recomanda 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, și 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 în prezent mi-au fost puse la dispoziție gratuit, fie prin buletinele tehnologice la care mă abonez, fie autori și publiciști care mă contactează, fie cele pe care mi le trimite Amazon. De exemplu, Amazon mi-a trimis o dovadă de publicare necorectată a “The Lean Startup” pentru revizuirea mea în 2011, introducându-mă în conceptul de MVP, ș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 pentru un motor de interogare a bazei de date pentru a suporta sarcini de lucru care se întind de la OLTP la un capăt, la analize la celălalt capăt, 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 bază de date sau o combinație de motoare de interogare și stocare, orientat spre îndeplinirea cerințelor de sarcină de lucru, fie acestea tranzacționale, analitice sau o combinație a acestor două. În plus, acoperirea autorului a “pendulei 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, “Analitica disruptivă” prezintă o abordare istorică a inovației în analize din ultimii 50 de ani, pe care nu am văzut-o în altă parte, și discută două tipuri de perturbare: inovația disruptivă în lanțul de valori 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 disruptiv sau de a crea piețe noi. Din perspectiva investițiilor în tehnologia analizei 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 de viață utilă scurtate.

(3) Una dintre cele mai bune texte de afaceri tehnologice 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 insight 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 să-și alinieze strategiile cu lumea explozivă a calculatoarelor. Așa cum am comentat în revizuirea mea, ceea ce diferențiază această carte de alte eforturi similare este două caracteristici aparent opuse: lățimea 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 companie de consultanță tehnologică digitală cu sediul în zona Chicago, care livrează proiecte tehnologice pentru o gamă largă de clienți, de la întreprinderi 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ță de utilizator, date și infrastructură cloud, la coaching DevOps, testare software și management de proiect.

Ce 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 acest lucru înseamnă adesea purtarea altor pălării, cum ar fi proprietar de produs, deoarece capacitatea de a relaționa cu modul în care produsele sunt construite dintr-o perspectivă practică cântărește mult î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 arhitecții din practica de date pentru a discuta proiecte de clienți, proiecte laterale și ceea ce colegii mei fac pentru a rămâne la curent cu tehnologia, similar cu ceea ce am condus pentru o altă firmă de consultanță, deși întâlnirile interne, pentru așa-numita firmă, implicau întreaga practică tehnologică, nu specifică muncii de date.

De-a lungul majorității carierei mele, m-am specializat în dezvoltare open source folosind Java, realizând o cantitate din ce în ce mai mare de muncă de date pe parcursul drumului. În plus față de aceste două specializări, fac și ceea ce eu și colegii mei am ajuns să numim “arhitectură enterprise practică” sau “pragmatică”, ceea ce înseamnă realizarea 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 una peste alta și nu sunt mutuale exclusive. Am explicat executivilor în ultimii ani că linia care a fost trasată în mod tradițional de industria tehnologică între dezvoltarea de software și munca de date nu mai este bine definită, parțial pentru că instrumentarul dintre aceste două spații a convergent, și parțial pentru că, ca urmare a acestei convergențe, munca de date în sine a devenit în mare măsură un efort de dezvoltare de software. Cu toate acestea, deoarece practicienii de date tradiționali nu au, de obicei, background în dezvoltare de software, și viceversa, ajut la îndeplinirea acestui decalaj.

Ce este un proiect interesant pe care îl lucrați în prezent cu SPR?

De curând, am publicat primul post dintr-o serie de studii de caz despre platforma de date menționată anterior pe care echipa mea și eu am implementat-o în AWS de la zero în acest an pentru directorul general al unei firme de consultanță globală 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 directorul general, 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 analizele de date pe întreaga companie, utilizând o arhitectură comună, construind pe baza acesteia pentru a satisface nevoile de cazuri de utilizare ale fiecărei organizații.

Așa cum se întâmplă adesea cu firmele stabilite, utilizarea Microsoft Excel era obișnuită, cu foi de calcul distribuite în interiorul și între organizații, precum și între firmă și clienți externi. În plus, unitățile de afaceri și practicile de consultanță au devenit izolate, utilizând procese și instrumente disparate. Așa că, pe lângă centralizarea activelor de date și a analizei de date, un alt scop 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.

Există ceva altceva pe care ați dori să-l împărtășiți despre open source, SPR sau un alt proiect pe care îl 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, pentru directorul de inginerie de date al unei asigurători mari.

Toate aceste modele migrate au fost destinate să prevadă nivelul de adoptare a consumatorilor care poate fi așteptat pentru diverse produse de asigurare, unele dintre acestea 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ă, și documentația și suportul imatur al Databricks cu privire la utilizarea R în momentul respectiv (implementarea Azure a Databricks a fost lansată cu doar câteva luni înainte de 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 preocupărilor legate de date, documentație și alinierea necesară pe echipele de date, platformă și modelare. Lucrarea noastră l-a convins pe un șef de date inițial foarte sceptic că Databricks este calea de urmat, cu scopul declarat de a-și muta toate modelele rămase în Databricks cât mai curând posibil.

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