Erik Gfesser, Principal Architect for Data Practice of SPR – Intervju-serie

Erik ble med i data-praksisen til SPRs Emerging Technology Group som Principal Architect i 2018.

Erik ble spesialisert i data, åpen kildekode-utvikling med Java, og praktisk bedriftsarkitektur, inkludert bygging av PoC, prototyper og MVP.

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

Evnen til å lære kontinuerlig. 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 applikasjonene jeg bygde for kunder, men utgangen for all denne arbeidet var i hovedsak statisk.

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

Interessant nok, har min tiltrekning til maskinlæring kommet fullstendig på plass, da min master-veileder advarte meg mot å spesialisere meg i hva som da ble kalt kunstig intelligens, på grunn av AI-vinteren på den tiden. Jeg valgte å bruke uttrykk 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 urealistisk, gir den kraftfulle muligheter fra utviklernes perspektiv, så lenge disse samme praktikerne anerkjenner faktum at verdien som ML gir, er bare like god som dataene som prosesseres av den.

Du er en stor tilhenger av åpen kildekode, kan du diskutere hvorfor åpen kildekode er så viktig?

En aspekt om åpen kildekode som jeg har måttet forklare til ledere over årene, er at den primære fordelen med åpen kildekode 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 kildekode-programvare på grunn av at utviklere ventet lenge på at kommersielle selskaper skulle gjøre endringer i produktene de lisensiert, så utviklere tok det på seg å skrive programvare med samme funksjonalitet, åpnet den opp for å bli forbedret av andre utviklere.

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

Mine første erfaringer med åpen kildekode skjedde mens jeg bygde et helseprodukt jeg nevnte tidligere, og brukte verktøy som Apache Ant, som ble brukt til å bygge programvare, og en tidlig DevOps-produkt på den tiden kalt Hudson (kodebasen til hvilket senere ble Jenkins). Den primære grunnen til våre beslutninger om å bruke disse åpne kildekode-produktene 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 overordnet restruktiv, 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 kildekode-tilbud 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 kildekode-Java-produkt vi startet å bruke kalt Spring Framework, som fortsatt er aktiv etter mer enn et tiår, og økosystemet til dette strekker seg langt utenfor noen av innovasjonene det opprinnelig ga, nå sett på som vanlig, som avhengighetsinjeksjon.

Du har brukt åpen kildekode for bygging av PoC, prototyper og MVP. Kan 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 over tid. Komponentene som ble 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 kast bort tid og penger på å bygge det som har lav sannsynlighet for å bli brukt, men gjør en innsats for å komme i forkant av fremtidige behov.

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

Jeg kom til å forstå at disse territoriekrigene i hovedsak 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 innhentes, lagres, sikres og konsumeres for en enkelt brukstilfelle 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, like 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 å gjøre, spesielt når det gjelder de spesifikke teknologi-valg de tar. Men bevis for konsept er bare begynnelsen, ettersom produkter er best når de utvikles over tid. Ifølge min mening bør grunnlaget for en MVP bygges på prototyper som viser en viss stabilitet, så utviklere skal kunne fortsette å utvikle det.

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

Mange kommersielle data-produkter bruker nøkkel-åpen kildekode-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 kildekode-komponentene de har valgt å inkorporere, gir dem et løft når disse allerede er vidt brukt av samfunnet.

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

I tillegg er dokumentasjon for slike komponenter i hovedsak ikke tilgjengelig offentlig, og tvinger utviklerne til å fortsette å være avhengige av disse firmaene. Når vidt aksepterte åpen kildekode-komponenter som Apache Spark er i fokus, som med produkter som Databricks Unified Analytics Platform, er mange av disse elementene allerede tilgjengelige i samfunnet, og minimerer de delene utviklingslagene må være avhengige av kommersielle enheter for å gjøre jobben sin.

I tillegg, fordi komponenter som Apache Spark er bredt akseptert som de facto industri-standard-verktøy, kan kode også enklere migreres over kommersielle implementeringer av slike produkter. Firmaer vil alltid være tilbøyelige til å inkorporere det de ser på som konkurranseforskjell, 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 sine produkter med kundens forventning om at støtte vil bli levert på en rimelig måte. Jeg har hatt erfaringen med å sende en pull-forespørsel til et åpen kildekode-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 kildekode 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 kildekode-produkt kan nå inn i hundredtusener. Adopsjonsrater peker ikke nødvendigvis til samfunnets styrke, men er en god indikator på at dette er tilfelle, på grunn av deres tendens til å produsere dyderige 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 senior utvikler 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 til å være, men om utviklingslagene som skal adoptere disse, om disse er en god passform for økosystemet som utvikles, hva veikartet ser ut til å være, 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 nettsted, er det tre bøker 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, er gjort fritt tilgjengelige for meg, enten via teknologinyhetsbrev jeg abonnerer på, forfattere og publicister som når ut til meg, eller de Amazon sender meg. For eksempel, sendte Amazon meg en pre-publikations-ukorrektur av “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 arbeidsbyrder som spenner over spekteret fra OLTP på den ene siden, til analyser på den andre siden, med operasjonelle og forretningsintelligens-arbeidsbyrder 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 enkeltkrav, enten disse er transaksjonelle, analytiske eller en blanding av disse to. I tillegg er forfatterens dekning av “database-pendelen” i de siste årene særlig godt gjort.

(2) Mens mye har endret seg i data-rommet de siste årene, ettersom nye data-analyseprodukter fortsetter å bli introdusert, presenterer “Disruptive Analytics” en tilnærming til 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-verdi-kjeden, og industri-disruptiv innovasjon ved 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 deres organisasjoner, kan en vent-og-se-tilnærming være meningsfull, fordi teknologier som er i fare for disruptivt er risikable investeringer på grunn av forkortede nyttige levetid.

(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 bedrifter bør tilpasse seg. Forfatteren presenterer svært detaljerte notater fra mange av hans samtaler med forretningsledere, og gir innsiktsfulle analyser gjennom hele boken om hans erfaringer med å bygge (med sin kone) en gruppe kunder, store firmaer som trengte å sammenføye deres strategier med den eksploderende verden av datamaskiner og hvordan bedrifter bør tilpasse seg. Som jeg kommenterte i min anmeldelse, er det som skiller denne boken fra andre lignende fremtredende, to åpenbart motsatte egenskaper: industriell bredde og intimitet som bare er tilgjengelig gjennom ansikt-til-ansikt-interaksjon.

Du er Principal Architect for data-praksisen til SPR. Kan du beskrive hva SPR gjør?

SPR er en digital teknologi-konsulentbasert i Chicago-området, som leverer teknologiprojekter for en rekke kunder, fra Fortune 1000-bedrifter til lokale startups. Vi bygger helhetlige digitale opplevelser med 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 principal-arkitekt, er min hovedansvar å drive løsning-leveranse for kunder, ledelse av arkitektur og utvikling for prosjekter, og dette betyr 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 skal prioriteres, spesielt når det bygges fra scratch. Jeg blir også trukket inn i samtaler med potensielle kunder når min ekspertise er nødvendig, og firmaet har nylig bedt meg om å starte en pågående serie møter med med-arkitekter i data-praksisen 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 så å si for dette andre firmaet inkluderte hele teknologipraksisen, ikke bare data-arbeid.

For størsteparten av min karriere har jeg spesialisert meg i åpen kildekode-utvikling med Java, og utfører 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 betyr å 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 den linjen som hadde blitt tradisjonelt tegnet av teknologi-industrien mellom programvareutvikling og data-arbeid, er ikke lenger godt definert, delvis fordi verktøyet mellom disse to rommene har konvergert, og delvis fordi, som et resultat av denne konvergensen, data-arbeid i seg selv har i stor grad blitt et programvareutviklingsinnsats. Men siden tradisjonelle data-praktikere vanligvis ikke har programvareutviklingsbakgrunn, og omvendt, hjelper jeg med å møte dette gapet.

Hva er et interessant prosjekt du for tiden arbeider med hos SPR?

Nettopp har jeg publisert den første posten i en flerdelt case-studie-serie om den tidligere nevnte dataplatformen mine kolleger og jeg implementerte i AWS fra scratch i fjor for CIO-en i en Chicago-basert global konsulent. Denne plattformen består av data-pipelines, data-sjø, kanoniske data-modeller, visualiseringer og maskinlæringsmodeller, som skal brukes av korporative avdelinger, praksis og sluttbrukere av klienten. Mens kjerne-plattformen 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 å bygge på toppen av den en felles arkitektur.

Som med mange etablerte firmaer, var bruk av Microsoft Excel vanlig, med regneark som vanligvis ble distribuert innenfor og over organisasjoner, samt mellom firmaet og eksterne kunder. I tillegg hadde forretningsenheter og konsulentpraksis blitt isolert, 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 på tvers av organisasjoner på en trygg og konsistent måte.

Er det noe annet du ønsker å dele om åpen kildekode, 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 kjøringen av maskinlæringsmodeller til dette fra Azure HDInsight, en Hadoop-distribusjon, for direktøren for data-engineering 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 flyttet til å bruke HDInsight. Den største utfordringen var dårlig datakvalitet, men andre utfordringer inkluderte manglende komprehensive versjoner, 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 bare blitt gjort generelt tilgjengelig noen måneder før dette prosjektet).

For å møte disse nøkkel-utfordringene, ga jeg anbefalinger om automatisering, konfigurasjon og versjon, adskillelse av data-bekymringer, dokumentasjon og nødvendig justering på tvers av deres data-, plattform- og modellerteams. Vårt arbeid overbeviste en opprinnelig svært skeptisk Chief Data Scientist 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 kildekode. Lesere som kan ønske å lære mer, kan besøke SPR-bedriftsnettstedet eller Erik Gfessers nettsted.