Erik Gfesser, Principalarkitekt for datasammenhengen i SPR – Intervju-serie

Erik ble medlem av datasammenhengen i SPR‘s Emerging Technology Group som Principalarkitekt i 2018.

Erik ble spesialisert på data, åpen kildeutvikling med Java, og praktisk bedriftsarkitektur, inkludert bygging av PoC, prototyper og MVP.

Hva var det som først tiltalte deg til maskinlæring?

Evnen til å kontinuerlig lære. Jeg startet min utviklerkarriere som senior dataanalytiker med SPSS i et globalt markedssøkefirma, og senere inkorporerte jeg bruk av en forretningsregel-motor kalt Drools i applikasjoner jeg bygde for kunder, men utgangen for all denne arbeidet var essensielt statisk.

Jeg arbeidet senere gjennom prosessforbedringsopplæring, under hvilken tid instruktører demonstrerte i detalj hvordan de kunne forbedre, gjennom statistikk og andre metoder, forretningsprosesser brukt av deres kunder, men her igjen var utgangen hovedsakelig fokusert på punkter i tid. Min erfaring med å forbedre et helseprodukt jeg og mine kolleger bygde under denne samme tiden, viste meg hvorfor kontinuerlig læring er nødvendig for slike tiltak, men ressursene som nå er tilgjengelige, eksisterte ikke da.

Interessant nok, min tiltrekning til maskinlæring har kommet full sirkel, da min masterveileder advarte meg mot en spesialisering i det som da ble kalt kunstig intelligens, på grunn av AI-vinteren på den tiden. Jeg valgte å bruke begreper som ML fordi disse har færre konnotasjoner, og fordi selv AWS anerkjenner at deres AI-tjenester er bygget på toppen av deres ML-tjenester. Mens en del av ML-hypen der ute er urimelig, gir den kraftige muligheter fra utviklerens perspektiv, så lenge disse samme praktikerne anerkjenner faktum at verdien ML gir, er bare så god som dataene som prosesseres av den.

Du er en stor forkjemper for åpen kilde, kunne du diskutere hvorfor åpen kilde er så viktig?

En aspekt om åpen kilde som jeg har måttet forklare til ledere over årene, er at den primære fordelen med åpen kilde ikke er at bruk av slik programvare er tilgjengelig uten monetær kostnad, men at kildekoden er tilgjengelig fritt.

I tillegg kan utviklere som bruker denne kildekoden modifisere den for deres eget bruk, og hvis foreslåtte endringer godkjennes, gjøre disse endringene tilgjengelige for andre utviklere som bruker den. Faktisk startet bevegelsen bak åpen kildeprogramvare på grunn av at utviklere ventet lenge på at kommersielle firmaer skulle gjøre endringer i produktene de lisenserte, så utviklere tok det på seg å skrive programvare med samme funksjonalitet, åpnet den opp for å bli forbedret av andre utviklere.

Kommersiell åpen kilde tar fordel av disse fordelene, virkeligheten er at mange moderne produkter bruker åpen kilde under dekke, selv om kommersielle varianter av slik programvare vanligvis gir ekstra komponenter som ikke er tilgjengelige som en del av en gitt åpen kilde-utgave, og gir differensieringer samt støtte hvis dette er nødvendig.

Mine første erfaringer med åpen kilde skjedde mens jeg bygde et helseprodukt jeg nevnte tidligere, og brukte verktøy som Apache Ant, brukt til å bygge programvare, og en tidlig DevOps-produkt på den tiden kalt Hudson (kodebasen til dette ble senere Jenkins). Den primære grunnen til våre beslutninger om å bruke disse åpen kildeproduktene, var at disse enten ga bedre løsninger enn kommersielle alternativer, eller var innovative løsninger som ikke ble tilbudt av kommersielle enheter, ikke til å nevne at kommersiell lisensiering av noen av produktene vi hadde brukt var overhodet restriktiv, og ledet til unødvendig byråkrati når det var nødvendig å få flere lisenser, på grunn av kostnadene involvert.

Over tid har jeg sett åpen kilde-tilbudene fortsette å utvikle seg, og gi nødvendig innovasjon. For eksempel, mange av problemene mine kolleger og jeg kjempet med å bygge dette helseproduktet, ble senere løst av en innovativ åpen kilde-Java-produkt vi begynte å bruke kalt Spring Framework, som fortsatt er aktiv etter mer enn et tiår, og økosystemet rundt dette strekker seg langt utenfor noen av innovasjonene det først ga, nå sett på som vanlig, som avhengighetsinjeksjon.

Du har brukt åpen kilde til bygging av PoC, prototyper og MVP. Kunde du dele din reise bak noen av disse produktene?

Som forklart i en av de ledende prinsippene jeg presenterte for en nylig klient, skal bygginger for dataplatformen vi bygde for dem, fortsette å bli iterativt gjennomført etter behov over tid. Komponentene bygget for denne plattformen bør ikke forventes å forbli statiske, ettersom behov endrer seg og nye komponenter og komponentfunksjoner vil bli tilgjengelige over tid.

Når du bygger ut plattformfunksjonalitet, start alltid med det som er minst mulig før du legger til unødvendige klokker og fløyter, som i noen tilfeller også inkluderer konfigurasjon. Start med det som er funksjonelt, sikre deg at du forstår det, og deretter utvikle det. Ikke kaste bort tid og penger på å bygge det som har lav sannsynlighet for å bli brukt, men gjør en innsats for å komme før fremtidige behov.

MVP-en vi bygde for dette produktet, måtte uttrykkelig bygges slik at ytterligere bruksområder kunne bygges på toppen av det, selv om det kom pakket med implementering av ett enkelt bruksområde, for utgiftsanomalideteksjon. I motsetning til denne klienten, hadde et tidligere produkt jeg bygde en historie bak det før min ankomst. I dette tilfelle, hadde interessenter diskutert i tre år (!) hvordan de skulle tilnærme seg et produkt de ønsket å bygge. En klientdirektør forklarte at en av grunnene han brakte meg inn, var å hjelpe firmaet å komme over noen av disse interne debattene, spesielt fordi produktet han ønsket å bygge, måtte tilfredsstille hierarkiet av organisasjoner involvert.

Jeg fant ut at disse territoriekrigene hovedsakelig var forbundet med data eid av klienten, dets datterselskaper og eksterne kunder, så i dette tilfelle hele produktbaklogen dreide seg om hvordan denne dataen skulle inntas, lagres, sikres og forbrukes for ett enkelt bruksområde som genererer nettverk av helsepersonell for kostnadsanalyser.

Tidligere i min karriere, kom jeg til å forstå at en arkitekturkvalitet kalt “brukervennlighet” ikke bare var begrenset til sluttbrukere, men også programvareutviklere selv. Grunnen til dette er at koden som skrives, må være brukervennlig, likeså som brukergrensesnitt må være brukervennlig for sluttbrukere. For at et produkt skal bli brukervennlig, må bevis for konsept bygges for å demonstrere at utviklere skal kunne gjøre det de har satt seg fore, spesielt når det gjelder de spesifikke teknologi-valgene de gjør. Men bevis for konsept er bare begynnelsen, ettersom produkter er best når de utvikles over tid. Ifølge min mening, skal grunnlaget for en MVP bygges på prototyper som viser en viss stabilitet, så utviklere kan fortsette å utvikle det.

Mens du gjennomgikk boken “Maskinlæring på bedriftsnivå”, sa du at “bruk av åpen kilde-produkter, rammer og språk sammen med en smidig arkitektur bestående av en blanding av åpen kilde- og kommersielle komponenter, gir smidigheten som mange firmaer trenger, men ikke umiddelbart innser fra starten”. Kunde du gå inn i noen detaljer om hvorfor du mener at firmaer som bruker åpen kilde er mer smidige?

Mange kommersielle dataprodukter bruker nøkkel-åpen kilde-komponenter under dekke, og muliggjør at utviklere kan bruke populære programmeringsspråk som Python. Firmaene som bygger disse produktene, vet at de åpen kilde-komponentene de har valgt å inkorporere, gir dem et sprang i forhold til å starte, når disse allerede er vidt brukt av samfunnet.

Åpen kilde-komponenter med sterke samfunn er lettere å selge, på grunn av den bekjentskap disse bringer til bordet. Kommersielt tilgjengelige produkter som består hovedsakelig av lukket kilde, eller selv åpen kilde som i stor grad bare brukes av spesifikke kommersielle produkter, ofte krever enten opplæring av disse leverandørene, eller lisenser for å bruke programvaren.

I tillegg er dokumentasjon for slike komponenter hovedsakelig ikke gjort offentlig tilgjengelig, og tvinger fortsatt avhengighet av utviklere på disse firmaene til å gjøre arbeidet sitt. Når vidt aksepterte åpen kilde-komponenter som Apache Spark er sentrale fokus, som med produkter som Databricks Unified Analytics Platform, er mange av disse elementene allerede gjort tilgjengelige i samfunnet, og minimerer de delene utviklingsteamene må avhenge av kommersielle enheter for å gjøre arbeidet sitt.

I tillegg, fordi komponenter som Apache Spark er bredt akseptert som de facto industri-standard verktøy, kan kode også lettere migreres over kommersielle implementeringer av slike produkter. Firmaer vil alltid være tilbøyelige til å inkorporere det de ser på som konkurransefordel, men mange utviklere ønsker ikke å bruke produkter som er fullstendig nye, fordi dette viser seg å være utfordrende å flytte mellom firmaer, og tenderer til å kutte deres bånd med de sterke samfunnene de har kommet til å forvente.

Fra personlig erfaring, har jeg arbeidet med slike produkter tidligere, og det kan være utfordrende å få kompetent støtte. Og dette er ironisk, gitt at slike firmaer selger produktene sine med kundens forventning om at støtte skal bli levert på en rimelig måte. Jeg har hatt erfaringen med å sende en pull-forespørsel til et åpen kilde-prosjekt, med fikset inkorporert i bygget samme dag, men kan ikke si det samme om noen kommersielt prosjekt jeg har arbeidet med.

Noe annet du mener om åpen kilde er at det gir “tilgang til sterke utviklersamfunn”. Hvor store er noen av disse samfunnene, og hva gjør dem så effektive?

Utviklersamfunn rundt et gitt åpen kilde-produkt kan nå inn i hundredtusener. Adopsjonsrater peker ikke nødvendigvis til samfunnsstyrke, men er en god indikator på at dette er tilfelle, på grunn av deres tendens til å produsere virtuose sykluser. Jeg betrakter samfunn som sterke når disse produserer sunn diskusjon og effektiv dokumentasjon, og hvor aktiv utvikling finner sted.

Når en arkitekt eller seniorutvikler arbeider gjennom prosessen med å velge hvilke slike produkter å inkorporere i det de bygger, kommer mange faktorer vanligvis inn i spill, ikke bare om produktet selv og hva samfunnet ser ut som, men også om utviklingsteamene som skal adoptere disse, om de er en god passform for økosystemet som utvikles, hva veikartet ser ut som, og i noen tilfeller om kommersiell støtte kan finnes hvis dette er nødvendig. Men mange av disse aspektene faller bort i fravær av sterke utviklersamfunn.

Du har anmeldt hundrevis av bøker på din nettside, er det tre du kunne anbefale til våre lesere?

Disse dagene leser jeg svært få programmeringsbøker, og mens det er unntak, er realiteten at disse vanligvis er foreldet svært raskt, og utviklersamfunnet vanligvis gir bedre alternativer via diskusjonsforum og dokumentasjon. Mange av bøkene jeg nå leser, blir gjort fritt tilgjengelige for meg, enten via teknologinyhetsbrev jeg abonnerer på, forfattere og publicister som når ut til meg, eller de Amazon (AMZN ) sender til meg. For eksempel, Amazon sendte meg en pre-publisert, ukorrigert bevis på “The Lean Startup” for min anmeldelse i 2011, og introduserte meg til konseptet MVP, og nylig sendte meg en kopi av “Julia for Beginners”.

(1) En bok fra O’Reilly som jeg har anbefalt, er “In Search of Database Nirvana”. Forfatteren dekker i detalj utfordringene for en database-spørringsmotor å støtte arbeidsbelastninger som spenner over spekteret av OLTP på den ene siden, til analyser på den andre siden, med operasjonell og forretningsinnsikt-arbeidsbelastninger i midten. Denne boken kan brukes som en guide til å vurdere en database-motor eller en kombinasjon av spørrings- og lagringsmotorer, rettet mot å møte en arbeidsbelastningskrav, enten dette er transaksjonelt, analytisk eller en blanding av disse to. I tillegg dekkes forfatterens behandling av “den svingende database-pendelen” i de siste årene, spesielt godt.

(2) Mens mye har endret seg i datasammenhengen de siste årene, siden nye data-analyseprodukter kontinuerlig blir introdusert, presenterer “Disruptive Analytics” en tilnærming, en kort historie over de siste 50 årene med innovasjon i analyser som jeg ikke har sett andre steder, og diskuterer to typer disruptiv innovasjon: disruptiv innovasjon innenfor analytics-verdikjeden, og bransje-disruptiv innovasjon gjennom innovasjoner i analyser. Fra perspektivet til startups og analytics-praktikere, blir suksess muliggjort ved å disrupte deres industrier, fordi å bruke analyser til å differensiere et produkt er en måte å skape en disruptiv forretningsmodell eller å skape nye markeder. Fra perspektivet til å investere i analytics-teknologi for sine organisasjoner, kan en vent-og-se-tilnærming være meningsfull, fordi teknologier som er i fare for disruptiv innovasjon, er risikable investeringer på grunn av forkortede nyttige levetider.

(3) En av de beste teknologi-forretnings-tekstene jeg har lest, er “The Limits of Strategy”, av en medgrunnlegger av Research Board (ervervet av Gartner), en internasjonal tenketank som undersøker utviklinger i dataverden og hvordan korporasjoner bør tilpasse seg. Forfatteren presenterer svært detaljerte notater fra mange av hans samtaler med forretningsledere, og gir innsiktsfull analyse gjennom hele boken om hans erfaringer med å bygge (sammen med hans kone) en gruppe klienter, store firmaer som trengte å sammenføye strategiene sine med den eksploderende verden av datamaskiner. Som jeg kommenterte i min anmeldelse, er det som skiller denne boken fra andre lignende forsøk, to åpenbart motsatte karakteristika: bransje-omfattende bredde, og intimitet som bare er tilgjengelig gjennom ansikt-til-ansikt-interaksjon.

Du er Principalarkitekt for datasammenhengen i SPR. Kunde du beskrive hva SPR gjør?

SPR er en digital teknologikonsulentbasert i Chicago-området, og leverer teknologiprojekter for en rekke kunder, fra Fortune 1000-bedrifter til lokale startups. Vi bygger end-to-end digitale opplevelser ved hjelp av en rekke teknologikapasiteter, alt fra tilpasset programvareutvikling, brukeropplevelse, data og sky-infrastruktur, til DevOps-coaching, programvaretesting og prosjektledelse.

Hva er noen av dine ansvarsområder med SPR?

Som principalarkitekt, er min hovedansvar å drive løsning-leveranse for kunder, og lede arkitektur og utvikling for prosjekter, og dette innebærer ofte å bære andre hatter, som produkt-eier, fordi evnen til å relatere til hvordan produkter bygges fra en hånd-til-hånd-perspektiv, veier tungt i forhold til hvordan arbeid bør prioriteres, spesielt når man bygger fra scratch. Jeg blir også trukket inn i diskusjoner med potensielle kunder når min ekspertise er nødvendig, og firmaet har nylig bedt meg om å starte en pågående serie sesjoner med medarbeidende arkitekter i datasammenhengen for å diskutere kunde-prosjekter, side-prosjekter og hva mine kolleger gjør for å holde seg oppdatert med teknologi, lignende det jeg hadde drevet for en tidligere konsulent, om enn de interne møtene for dette andre firmaet inkluderte hele teknologipraksisen, ikke bare datasammenhengen.

For det meste av min karriere, har jeg spesialisert meg på åpen kilde-utvikling med Java, og utført en økende mengde data-arbeid underveis. I tillegg til disse to spesialiseringene, gjør jeg også det mine kolleger og jeg har kommet til å kalle “praktisk” eller “pragmatisk” bedriftsarkitektur, som innebærer å utføre arkitekt-oppgaver i sammenheng med hva som skal bygges, og faktisk bygge det, i stedet for bare å snakke om det eller tegne diagrammer om det, og innse at disse andre oppgavene også er viktige.

Ifølge min mening, overlapper disse tre spesialiseringene hverandre og er ikke gjensidig exclusive. Jeg har forklart til ledere de siste årene at linjen som hadde blitt tradisjonelt tegnet av teknologi-industrien mellom programvareutvikling og data-arbeid, ikke lenger er tydelig definert, delvis fordi verktøyet mellom disse to områdene har konvergert, og delvis fordi data-arbeid selv har blitt en programvareutviklingsinnsats, som et resultat av denne konvergensen. Imidlertid, siden tradisjonelle data-praktikere vanligvis ikke har programvareutviklingsbakgrunn, og omvendt, hjelper jeg med å møte dette gapet.

Hva er et interessant prosjekt du nå arbeider med i SPR?

For nylig, publiserte jeg den første posten i en multi-del case-studie-serie om dataplatformen min team og jeg implementerte i AWS fra scratch i fjor for CIO-en i en Chicago-basert global konsulent. Denne plattformen består av datapiper, datalake, kanoniske datamodeller, visualiseringer og maskinlæringsmodeller, som skal brukes av korporative avdelinger, praksiser og sluttbrukere av klienten. Mens kjerneplattformen skulle bygges av den korporative IT-organisasjonen drevet av CIO-en, var målet at denne plattformen skulle brukes av andre organisasjoner utenfor korporativ IT også, for å sentralisere data-aktiva og data-analyse over hele firmaet, ved hjelp av en felles arkitektur, og bygge på toppen av den for å møte bruksområdene til hver organisasjon.

Som med mange etablerte firmaer, var bruk av Microsoft Excel vanlig, med regneark som vanligvis ble distribuert innenfor og mellom organisasjoner, samt mellom firmaet og eksterne kunder. I tillegg hadde forretningsenheter og konsulentpraksiser blitt isolerte, hver med bruk av ulike prosesser og verktøy. Så, i tillegg til å sentralisere data-aktiva og data-analyse, var et annet mål å implementere konseptet data-eierskap, og å muliggjøre deling av data mellom organisasjoner på en sikker og konsekvent måte.

Er det noe annet du ønsker å dele om åpen kilde, SPR eller et annet prosjekt du arbeider med?

Et annet prosjekt (les om det her og her) som jeg nylig ledet, involverte suksessfull implementering av Databricks Unified Analytics Platform, og migrering av maskinlæringsmodellene til det fra Azure HDInsight, en Hadoop-distribusjon, for direktøren for dataingeniør i et stort forsikringsselskap.

Alle disse migrerte modellene var ment å forutsi nivået av forbruker-tilpasning som kan forventes for ulike forsikringsprodukter, med noen som hadde blitt migrert fra SAS for noen år siden, da selskapet gikk over til å bruke HDInsight. Den største utfordringen var dårlig datakvalitet, men andre utfordringer inkluderte mangel på omfattende versjonering, stamme-kunnskap og ufullstendig dokumentasjon, og umoden Databricks-dokumentasjon og støtte med hensyn til R-bruk på den tiden (Azure-implementeringen av Databricks hadde nettopp blitt gjort generelt tilgjengelig noen måneder før dette prosjektet).

For å møte disse nøkkelutfordringene, ga jeg anbefalinger rundt automatisering, konfigurasjon og versjonering, adskillelse av data-bekymringer, dokumentasjon og nødvendig justering over datateam, plattformteam og modellteam. Vår arbeid overbeviste en opprinnelig svært skeptisk sjef-data-vitenskapsmann om at Databricks er veien å gå, med deres uttalte mål etter vår avgang å migrere deres gjenværende modeller til Databricks så raskt som mulig.

Dette har vært et fascinerende intervju som berører mange emner, jeg føler at jeg har lært mye om åpen kilde. Lesere som ønsker å lære mer, kan besøke SPR sine nettsider eller Erik Gfessers nettside.