Erik Gfesser, hlavný architekt pre dátovú prax SPR – Séria rozhovorov

Erik sa zapojil do dátovej praxe SPREmerging Technology Group ako hlavný architekt v roku 2018.

Erik sa stal špecialistom na dáta, open source vývoj pomocou Javy a praktickú podnikovú architektúru, vrátane budovania PoC, prototypov a MVP.

Čo ťa spočiatku priťahovalo k strojovému učeniu?

Jeho umožnenie aplikáciám neustále sa učiť. Svoju vývojovú kariéru som začal ako senior dátový analytik pomocou SPSS v spoločnosti, ktorá sa stala globálnou spoločnosťou na prieskum trhu, a neskôr som do aplikácií, ktoré som vytvoril pre klientov, začlenil využitie nástroja obchodných pravidiel s názvom Drools, ale výstupom celej tejto práce bol v podstate statické.

Neskôr som sa prepracoval na školeniach na zlepšovanie procesov, počas ktorých inštruktori podrobne demonštrovali, ako sa im pomocou štatistík a iných metód podarilo zlepšiť obchodné procesy používané ich klientmi, ale aj tu bol výstup z veľkej časti zameraný na časové body. Moja skúsenosť s prácou na zlepšení zdravotníckeho produktu, ktorú sme s kolegami vybudovali v rovnakom časovom období, mi ukázala, prečo je pre takéto úsilie potrebné neustále vzdelávanie, no dostupné zdroje vtedy ešte neexistovali.

Je zaujímavé, že moja príťažlivosť k strojovému učeniu sa uzavrela, keď ma môj absolventský poradca varoval pred špecializáciou v tom, čo sa vtedy nazývalo umelá inteligencia, kvôli vtedajšej zime AI. Rozhodol som sa namiesto toho použiť výrazy ako ML, pretože majú menej konotácií a pretože aj AWS uznáva, že jeho vrstva služieb AI je v skutočnosti len abstrakciou vyššej úrovne postavenou na vrstve služieb ML. Zatiaľ čo niektoré humbuky v oblasti ML sú nereálne, z pohľadu vývojárov poskytujú výkonné možnosti, pokiaľ tí istí odborníci uznávajú skutočnosť, že hodnota, ktorú poskytuje ML, je len taká dobrá, ako sú ním spracované údaje.

Ste veľkým zástancom open source, mohli by ste diskutovať o tom, prečo je open source taký dôležitý?

Jeden aspekt open source, ktorý som v priebehu rokov potreboval vysvetliť vedúcim pracovníkom, je, že primárna výhoda open source nespočíva v tom, že používanie takéhoto softvéru je dostupné bez peňažných nákladov, ale v tom, že zdrojový kód je voľne dostupný.

Okrem toho vývojári využívajúci tento zdrojový kód ho môžu upravovať pre vlastnú potrebu a ak budú navrhované zmeny schválené, sprístupniť tieto zmeny ostatným vývojárom, ktorí ho používajú. Hnutie za softvérom s otvoreným zdrojovým kódom sa začalo v dôsledku toho, že vývojári dlho čakali, kým komerčné firmy vykonajú zmeny v produktoch, na ktoré majú licenciu, takže vývojári sa rozhodli napísať softvér s rovnakou funkcionalitou a otvorili ho, aby ho mohli vylepšiť iné vývojárov.

Komercializovaný open source využíva tieto výhody, realita je taká, že mnoho moderných produktov využíva open source pod krytom, aj keď komerčné varianty takéhoto softvéru zvyčajne poskytujú dodatočné komponenty, ktoré nie sú dostupné ako súčasť daného open source vydania, čím poskytujú odlišnosti ako napr. ako aj podporu, ak je to potrebné.

Moje prvé skúsenosti s open source sa udiali pri vytváraní zdravotníckeho produktu, ktorý som už spomínal, s využitím nástrojov, ako je Apache Ant, ktorý sa používal na vytváranie softvéru, a skorý produkt DevOps v tom čase s názvom Hudson (ktorého základom kódu sa neskôr stal Jenkins ). Hlavným dôvodom našich rozhodnutí použiť tieto produkty s otvoreným zdrojovým kódom bolo, že buď poskytovali lepšie riešenia komerčným alternatívam, alebo išlo o inovatívne riešenia, ktoré ani komerčné subjekty neponúkali, nehovoriac o tom, že komerčné licencovanie niektorých produktov, ktoré sme používali bol príliš reštriktívny, čo viedlo k nadmernej byrokracii, keď prišiel čas na potrebu ďalších licencií z dôvodu súvisiacich nákladov.

Postupom času som videl, ako sa ponuky s otvoreným zdrojovým kódom neustále vyvíjajú a poskytujú tak potrebné inovácie. Napríklad mnohé z problémov, s ktorými sme s kolegami zápasili pri budovaní tohto zdravotníckeho produktu, boli neskôr vyriešené inovatívnym open source Java produktom, ktorý sme začali používať, s názvom Spring Framework, ktorý je stále silný aj po viac ako desaťročí, ktorého ekosystém teraz siaha ďaleko za niektoré inovácie, ktoré pôvodne poskytoval, teraz sa považuje za samozrejmosť, ako je napríklad vstrekovanie závislosti.

Použili ste open source na vytváranie PoC, prototypov a MVP. Mohli by ste sa podeliť o svoju cestu za niektorými z týchto produktov?

Ako je vysvetlené v jednom z hlavných princípov, ktoré som predstavil nedávnemu klientovi, zostavovanie dátovej platformy, ktorú sme pre neho vytvorili, by sa malo v priebehu času aj naďalej vykonávať opakovane podľa potreby. Od komponentov vytvorených pre túto platformu by sa nemalo očakávať, že zostanú statické, pretože potreby sa menia a nové komponenty a funkcie komponentov budú k dispozícii v priebehu času.

Pri budovaní funkčnosti platformy vždy začnite s tým, čo je minimálne realizovateľné, a až potom pridajte nepotrebné zvončeky a píšťalky, čo v niektorých prípadoch dokonca zahŕňa konfiguráciu. Začnite s tým, čo je funkčné, uistite sa, že tomu rozumiete, a potom to rozvíjajte. Nestrácajte čas a peniaze budovaním toho, čo má nízku pravdepodobnosť použitia, ale snažte sa predbehnúť budúce potreby.

MVP, ktorý sme vytvorili pre tento produkt, bolo vyslovene potrebné vybudovať tak, aby sa na ňom mohli naďalej stavať ďalšie prípady použitia, aj keď bol dodávaný s implementáciou jedného prípadu použitia na detekciu anomálií nákladov. Na rozdiel od tohto klienta mal predchádzajúci produkt, ktorý som vytvoril, pred mojím príchodom nejakú históriu. V tomto prípade zainteresované strany tri roky (!) diskutovali o tom, ako by mali pristupovať k produktu, ktorý chceli vytvoriť. Vedúci klienta vysvetlil, že jedným z dôvodov, prečo ma priviedol, bolo pomôcť firme prekonať niektoré z týchto interných diskusií, najmä preto, že produkt, ktorý chcel vytvoriť, musel uspokojiť hierarchiu zainteresovaných organizácií.

Zistil som, že tieto turf wars boli do značnej miery spojené s údajmi, ktoré vlastnil klient, jeho dcérske spoločnosti a jeho externí zákazníci, takže v tomto prípade sa celý produktový backlog točil okolo toho, ako budú tieto údaje prijímané, ukladané, zabezpečené a spotrebované. pre jeden prípad použitia vytvárajúci priebežné siete poskytovateľov zdravotnej starostlivosti na analýzy nákladov.

Už skôr vo svojej kariére som pochopil, že architektonická kvalita nazývaná „použiteľnosť“ sa neobmedzuje len na koncových používateľov, ale na samotných vývojárov softvéru. Dôvodom je to, že napísaný kód musí byť použiteľný rovnako ako používateľské rozhrania musia byť použiteľné koncovými používateľmi. Aby sa produkt stal použiteľným, je potrebné vytvoriť dôkazy koncepcie, ktoré demonštrujú, že vývojári budú schopní urobiť to, čo si zaumienili, najmä pokiaľ ide o konkrétne technologické rozhodnutia, ktoré robia. Dôkazy koncepcie sú však len začiatok, pretože produkty sú najlepšie, keď sa časom vyvíjajú. Podľa môjho názoru by však základ pre MVP mal byť v ideálnom prípade postavený na prototypoch vykazujúcich určitú stabilitu, aby ich vývojári mohli naďalej rozvíjať.

Zatiaľ čo recenzovanie knihy „Machine Learning at Enterprise Scale“ uviedli ste, že „používanie produktov s otvoreným zdrojovým kódom, rámcov a jazykov spolu s agilnou architektúrou zloženou zo zmesi open source a komerčných komponentov poskytuje obratnosť, ktorú mnohé firmy potrebujú, ale hneď na začiatku si to neuvedomujú“. Mohli by ste ísť do niektorých detailov, prečo si myslíte, že firmy, ktoré používajú open source, sú svižnejšie?

Mnoho komerčných dátových produktov používa kľúčové open source komponenty pod krytom a umožňuje vývojárom používať populárne programovacie jazyky, ako je Python. Spoločnosti, ktoré vyrábajú tieto produkty, vedia, že komponenty s otvoreným zdrojovým kódom, ktoré sa rozhodli začleniť, im umožňujú začať, keď sú už komunitou široko používané.

Komponenty s otvoreným zdrojovým kódom so silnými komunitami sa predávajú ľahšie, pretože tieto komponenty sú známe. Komerčne dostupné produkty, ktoré pozostávajú hlavne z uzavretého zdroja, alebo dokonca z otvoreného zdroja, ktorý vo veľkej miere používajú iba špecifické komerčné produkty, často vyžadujú buď školenie od týchto predajcov, alebo licencie, aby mohli softvér používať.

Okrem toho dokumentácia k takýmto komponentom nie je z veľkej časti verejne dostupná, čo núti vývojárov k trvalej závislosti na týchto firmách. Keď sú široko akceptované komponenty s otvoreným zdrojovým kódom, ako je Apache Spark, stredobodom záujmu, ako napríklad pri produktoch, ako je platforma Databricks Unified Analytics Platform, mnohé z týchto položiek sú už sprístupnené v komunite, čím sa minimalizujú časti, na ktorých musia vývojové tímy závisieť od komerčných subjektov. robiť svoju prácu.

Okrem toho, pretože komponenty ako Apache Spark sú všeobecne akceptované ako de facto štandardné nástroje v priemysle, kód možno tiež ľahšie migrovať cez komerčné implementácie takýchto produktov. Firmy budú vždy inklinovať k tomu, aby začlenili to, čo považujú za konkurenčné odlišovače, ale mnohí vývojári nechcú používať produkty, ktoré sú úplne nové, pretože sa ukazuje ako náročné pohybovať sa medzi firmami a má tendenciu prerušovať svoje väzby so silnými komunitami, do ktorých prišli. očakávať.

Z osobnej skúsenosti som v minulosti s takýmito produktmi pracoval a môže byť náročné získať kompetentnú podporu. A to je ironické, keďže takéto firmy predávajú svoje produkty s očakávaním zákazníkov, že podpora bude poskytnutá včas. Mal som skúsenosť s odoslaním žiadosti o stiahnutie do projektu s otvoreným zdrojovým kódom, pričom oprava bola začlenená do zostavy v ten istý deň, ale nemôžem povedať to isté o žiadnom komerčnom projekte, s ktorým som pracoval.

Ešte niečo, čomu veríte v súvislosti s open source, je to, že vedie k „prístupu k silným komunitám vývojárov“. Aké veľké sú niektoré z týchto komunít a prečo sú také efektívne?

Komunity vývojárov okolo daného produktu s otvoreným zdrojovým kódom môžu dosiahnuť státisíce. Miera osvojenia nemusí nutne poukazovať na silu komunity, ale je dobrým indikátorom toho, že je to tak kvôli ich tendencii vytvárať cnostné cykly. Komunity považujem za silné, keď vytvárajú zdravú diskusiu a efektívnu dokumentáciu a kde prebieha aktívny rozvoj.

Keď architekt alebo starší vývojár pracuje na procese, aby si vybral, ktoré takéto produkty začlení do toho, čo stavia, zvyčajne vstupuje do hry veľa faktorov, nielen o samotnom produkte a o tom, ako vyzerá komunita, ale aj o vývojových tímoch, ktoré budú prijať tieto opatrenia, či sú vhodné pre vyvíjaný ekosystém, ako vyzerá plán a v niektorých prípadoch, či možno v prípade potreby nájsť komerčnú podporu. Mnohé z týchto aspektov sú však v neprítomnosti silných komunít vývojárov bokom.

Na svojom webe ste recenzovali 100 kníh, sú tri, ktoré by ste mohli odporučiť našim čitateľom?

V súčasnosti čítam veľmi málo kníh o programovaní, a hoci existujú výnimky, realita je taká, že tieto sú zvyčajne veľmi rýchlo zastarané a komunita vývojárov zvyčajne poskytuje lepšie alternatívy prostredníctvom diskusných fór a dokumentácie. Mnohé z kníh, ktoré momentálne čítam, sú mi voľne dostupné, či už prostredníctvom technologických bulletinov, ktoré odoberám, autorov a publicistov, ktorí ma oslovujú, alebo tých, ktoré mi posiela Amazon. Napríklad Amazon mi poslal pred zverejnením neopravený dôkaz „The Lean Startup“ na moju recenziu v roku 2011, v ktorom ma zoznámil s konceptom MVP, a len nedávno mi poslal kópiu „Julia pre začiatočníkov“.

(1) Jedna kniha od O'Reillyho, ktorú som odporučil, je „Pri hľadaní databázy Nirvana“. Autor sa podrobne zaoberá výzvami pre nástroj na dopytovanie údajov na podporu pracovných zaťažení pokrývajúcich spektrum OLTP na jednom konci až po analýzu na druhom konci, s prevádzkovými a business intelligence pracovnými zaťaženiami uprostred. Túto knihu možno použiť ako príručku na posúdenie databázového stroja alebo kombinácie dopytovacích a úložných strojov, zameraných na splnenie požiadaviek na pracovné zaťaženie, či už ide o transakčné, analytické alebo kombináciu týchto dvoch. Navyše, autorovo pokrytie „kyvadla kyvnej databázy“ v posledných rokoch je obzvlášť dobre urobené.

(2) Hoci sa za posledných niekoľko rokov v dátovom priestore veľa zmenilo, odkedy sa stále zavádzajú nové produkty na analýzu dát, „rušivá analýza“ predstavuje prístupnú, krátku históriu posledných 50 rokov inovácií v analytike, ktorú som inde nevidel, a pojednáva o dvoch typoch narušenia: prevratnej inovácii v rámci analytického hodnotového reťazca a narušení priemyslu inováciami v analytike. Z pohľadu startupov a analytikov je úspech umožnený narušením ich odvetví, pretože použitie analytiky na odlíšenie produktu je spôsob, ako vytvoriť prevratný obchodný model alebo vytvoriť nové trhy. Z hľadiska investovania do analytických technológií pre ich organizácie môže mať vyčkávací prístup zmysel, pretože technológie, ktorým hrozí prerušenie, sú riskantné investície z dôvodu skrátenej životnosti.

(3) Jeden z najlepších technologických obchodných textov, ktoré som čítal, je „Hranice stratégie“, od spoluzakladateľa Research Board (získaného spoločnosťou Gartner), medzinárodného think-tanku, ktorý skúma vývoj vo svete výpočtovej techniky a ako by sa mali korporácie prispôsobiť. Autor predkladá veľmi podrobné poznámky z mnohých svojich rozhovorov s vedúcimi podnikateľmi a poskytuje dôkladnú analýzu svojich skúseností s budovaním (s manželkou) skupiny klientov, veľkých firiem, ktoré potrebovali prepojiť svoje stratégie s explodujúcim svetom výpočtovej techniky. Ako som uviedol vo svojej recenzii, to, čo odlišuje túto knihu od iných súvisiacich snáh, sú dve zdanlivo protichodné charakteristiky: šírka v celom odvetví a intimita, ktorá je dostupná iba prostredníctvom osobnej interakcie.

Ste hlavným architektom pre dátovú prax SPR. Mohli by ste opísať, čo robí SPR?

SPR je konzultačná spoločnosť v oblasti digitálnych technológií so sídlom v oblasti Chicaga, ktorá poskytuje technologické projekty pre celý rad klientov, od podnikov z rebríčka Fortune 1000 až po miestne startupy. Vytvárame komplexné digitálne zážitky pomocou rôznych technologických možností, od vývoja softvéru na mieru, používateľského prostredia, údajov a cloudovej infraštruktúry až po koučovanie DevOps, testovanie softvéru a riadenie projektov.

Aké sú vaše povinnosti v súvislosti so SPR?

Ako hlavný architekt je mojou kľúčovou zodpovednosťou riadiť poskytovanie riešení pre klientov, viesť architektúru a vývoj projektov, čo často znamená nosiť iné klobúky, ako je napríklad vlastník produktu, pretože schopnosť porozumieť tomu, ako sa produkty vyrábajú z praktického hľadiska, zaváži. výrazne s ohľadom na to, ako by sa mala uprednostňovať práca, najmä pri stavbe od nuly. Som tiež zatiahnutý do diskusií s potenciálnymi klientmi, keď sú potrebné moje odborné znalosti, a spoločnosť nedávno požiadala, aby som začal prebiehajúcu sériu stretnutí s kolegami architektmi v oblasti dátovej praxe, aby som diskutoval o klientskych projektoch, vedľajších projektoch a o tom, čím sú moji kolegovia. robiť krok s technológiou, podobne ako som sa uchádzal o predchádzajúcu konzultáciu, hoci interné stretnutia takpovediac pre túto inú firmu zahŕňali celú ich technologickú prax, nie špecifickú pre prácu s údajmi.

Väčšinu svojej kariéry som sa špecializoval na vývoj open source pomocou Javy, pričom som popri tom vykonával čoraz väčšie množstvo práce s dátami. Okrem týchto dvoch špecializácií robím aj to, čo sme s kolegami nazvali „praktickou“ alebo „pragmatickou“ podnikovou architektúrou, čo znamená vykonávať architektonické úlohy v kontexte toho, čo sa má stavať, a vlastne to stavať. ako o tom len hovoriť alebo o tom kresliť schémy, samozrejme, uvedomujúc si, že aj tieto ďalšie úlohy sú dôležité.

Podľa môjho názoru sa tieto tri špecializácie navzájom prekrývajú a navzájom sa nevylučujú. V posledných rokoch som vedúcim pracovníkom vysvetlil, že línia, ktorú tradične kreslil technologický priemysel medzi vývojom softvéru a prácou s údajmi, už nie je dobre definovaná, čiastočne preto, že nástroje medzi týmito dvoma priestormi sa zblížili, a čiastočne preto, výsledkom tejto konvergencie sa samotná práca s údajmi stala z veľkej časti snahou o vývoj softvéru. Keďže však tradiční odborníci na údaje zvyčajne nemajú skúsenosti s vývojom softvéru a naopak, pomáham túto medzeru prekonať.

Na akom zaujímavom projekte momentálne so SPR pracujete?

Len nedávno som zverejnil prvý príspevok v sérii viacdielnych prípadových štúdií o už spomínanej dátovej platforme, ktorú sme s mojím tímom minulý rok od nuly implementovali do AWS pre CIO globálnej poradenskej spoločnosti so sídlom v Chicagu. Táto platforma pozostáva z dátových kanálov, dátového jazera, kanonických dátových modelov, vizualizácií a modelov strojového učenia, ktoré majú používať podnikové oddelenia, praktiky a koncoví zákazníci klienta. Zatiaľ čo základnú platformu mala vybudovať podniková IT organizácia riadená CIO, cieľom bolo, aby túto platformu používali aj iné organizácie mimo podnikového IT, ako aj na centralizáciu údajových aktív a analýzy údajov v celej spoločnosti pomocou spoločnej architektúry. stavať na ňom, aby vyhovovali potrebám prípadu použitia každej organizácie.

Ako v mnohých etablovaných firmách, používanie programu Microsoft Excel bolo samozrejmosťou, pričom tabuľky sa bežne distribuovali v rámci organizácií a medzi nimi, ako aj medzi firmou a externými klientmi. Navyše, obchodné jednotky a poradenské praktiky sa stali silami, pričom každá využívala odlišné procesy a nástroje. Takže okrem centralizácie dátových aktív a analýzy dát bolo ďalším cieľom implementovať koncept vlastníctva dát a umožniť zdieľanie dát medzi organizáciami bezpečným a konzistentným spôsobom.

Je ešte niečo, o čo by ste sa chceli podeliť o open source, SPR alebo inom projekte, na ktorom pracujete?  

Ďalší projekt (prečítajte si o ňom tu a tu), ktorú som nedávno viedol, zahŕňala úspešnú implementáciu platformy Databricks Unified Analytics Platform a migráciu vykonávania modelov strojového učenia z Azure HDInsight, distribúcie Hadoop, pre riaditeľa dátového inžinierstva veľkej poisťovne.

Všetky tieto migrované modely boli určené na predpovedanie úrovne osvojenia si spotrebiteľmi, ktoré možno očakávať pri rôznych poistných produktoch, pričom niektoré z nich boli migrované zo SAS niekoľko rokov predtým, kedy spoločnosť prešla na používanie HDInsight. Najväčšou výzvou bola nízka kvalita údajov, ale medzi ďalšie výzvy patril nedostatok komplexného vytvárania verzií, kmeňové znalosti a neúplná dokumentácia a nezrelá dokumentácia a podpora Databricks s ohľadom na používanie R v tom čase (implementácia Azure Databricks bola práve všeobecne dostupná a niekoľko mesiacov pred týmto projektom).

Na vyriešenie týchto kľúčových výziev som v nadväznosti na našu implementačnú prácu urobil odporúčania týkajúce sa automatizácie, konfigurácie a tvorby verzií, oddelenia problémov s údajmi, dokumentácie a potrebného zosúladenia ich dátových, platformových a modelovacích tímov. Naša práca presvedčila spočiatku veľmi skeptického hlavného vedca údajov, že Databricks je správna cesta, pričom ich stanoveným cieľom po našom odchode je čo najrýchlejšia migrácia ich zostávajúcich modelov na Databricks.

Toto bol fascinujúci rozhovor, ktorý sa dotýkal mnohých tém, mám pocit, že som sa veľa naučil o open source. Čitatelia, ktorí sa chcú dozvedieť viac, môžu navštíviť stránku SPR firemná stránka resp Webová stránka Erika Gfessera.