Erik Gfesser, Principalarkitekt for Data Practice of SPR – Interviewserie

Erik sluttede sig til datapraksis i SPR’s Emerging Technology Group som principalarkitekt i 2018.

Erik blev specialiseret i data, open source-udvikling med Java og praktisk enterprise-arkitektur, herunder opbygning af PoC’er, prototyper og MVP’er.

Hvad var det, der oprindeligt tiltrak dig til maskinlæring?

Dets evne til at låse applikationer til at lære kontinuerligt. Jeg startede min udviklerkarriere som senior dataanalytiker med SPSS i et globalt markedsforskningsfirma, og senere inkorporerede jeg brug af en business-regel-motor kaldet Drools i applikationer, jeg byggede til kunder, men outputtet for alt dette arbejde var grundlæggende statisk.

Senere arbejdede jeg gennem procesforbedringskurser, under hvilke instruktørerne demonstrerede i detaljer, hvordan de kunne forbedre forretningsprocesser brugt af deres kunder gennem statistik og andre metoder, men her igen var outputtet overvejende fokuseret på bestemte tidspunkter. Min erfaring med at forbedre et sundhedsprodukt, som mine kolleger og jeg byggede under denne samme periode, viste mig, hvorfor kontinuerlig læring er nødvendig for sådanne bestræbelser, men ressourcerne, der nu er tilgængelige, eksisterede ikke dengang.

Interessant nok er min tiltrækning til maskinlæring kommet fuld cirkel, da min graduate-vejleder advarede mig mod at specialisere mig i, hvad der dengang blev kaldt kunstig intelligens, på grund af AI-vinteren på det tidspunkt. Jeg valgte i stedet at bruge begreber som ML, da disse har færre konnotationer, og fordi selv AWS anerkender, at deres AI-tjenester-lag er blot en højere niveau-abstraktion bygget oven på deres ML-tjenester-lag. Selvom noget af ML-hypen derude er urealistisk, giver det kraftfulde muligheder set fra udviklernes perspektiv, så længe disse praksisudøvere anerkender, at værdien, som ML giver, kun er så god som de data, der bearbejdes af det.

Du er en stor open source-tilhænger, kunne du diskutere, hvorfor open source er så vigtigt?

Et aspekt om open source, som jeg har behov for at forklare til chefer gennem årene, er, at den primære fordel ved open source ikke er, at brug af sådan software er tilgængelig uden monetrær omkostning, men at kildekoden er tilgængelig frit.

Dertil kan udviklere, der bruger denne kildekode, modificere den til deres eget brug, og hvis foreslåede ændringer er godkendt, kan de gøre disse ændringer tilgængelige for andre udviklere, der bruger den. Faktisk startede bevægelsen bag open source-software, fordi udviklere ventede længe på, at kommercielle firmaer skulle lave ændringer i produkter, de licenserede, så udviklerne tog det på sig selv at skrive software med samme funktionalitet og åbnede den op til forbedring af andre udviklere.

Kommercialiseret open source udnytter disse fordele, og virkeligheden er, at mange moderne produkter bruger open source under dække, selvom kommercielle varianter af sådan software typisk giver ekstra komponenter, der ikke er tilgængelige som en del af en given open source-udgave, og giver differentiering samt support, hvis dette er nødvendigt.

Mine første erfaringer med open source fandt sted, da jeg byggede sundhedsproduktet, jeg nævnte tidligere, og brugte værktøjer som Apache Ant, der blev brugt til at bygge software, og en tidlig DevOps-produkt på det tidspunkt kaldet Hudson (kildekoden til dette blev senere til Jenkins). Den primære grund til, at vi valgte at bruge disse open source-produkter, var, at de enten gav bedre løsninger end kommercielle alternativer eller var innovative løsninger, der ikke blev tilbudt af kommercielle enheder, og at kommerciel licensering af nogle af de produkter, vi havde brugt, var for restriktiv, hvilket førte til overmæssig bureaukrati, når det var nødvendigt at få flere licenser på grund af omkostningerne.

Over tid har jeg set, at open source-tilbud fortsætter med at udvikle sig og giver meget nødvendig innovation. For eksempel løste mange af de problemer, mine kolleger og jeg kæmpede med, da vi byggede sundhedsproduktet, senere en innovativ open source Java-produkt, vi begyndte at bruge kaldet Spring Framework, som stadig er stærk efter mere end et årti, og hvis økosystem nu strækker sig langt ud over nogle af de innovationer, det oprindeligt gav, nu set som almindelige, som afhængighedsinjektion.

Du har brugt open source til opbygning af PoC’er, prototyper og MVP’er. Kan du dele din rejse bag nogle af disse produkter?

Som forklaret i en af de vejledende principper, jeg præsenterede for en klient for nylig, skal bygge-ud af data-platformen vi byggede for dem fortsætte med at blive iterativt udført efter behov over tid. Komponenterne, der bygges til platformen, skal ikke forventes at forblive statiske, da behov ændrer sig, og nye komponenter og komponentfunktioner vil blive tilgængelige over tid.

Når man bygger platformfunktionalitet, skal man altid starte med, hvad der er minimally viable, før man tilføjer unødvendige klokker og fløjter, hvilket i nogle tilfælde endda inkluderer konfiguration. Start med, hvad der er funktionelt, sikre, at du forstår det, og udvikle det derefter. Spild ikke tid og penge på at bygge, hvad der har lav sandsynlighed for at blive brugt, men gør en indsats for at komme i forkøbet for fremtidige behov.

MVP’en, vi byggede til dette produkt, skulle udtrykkeligt bygges, således, at yderligere brugstilfælde kunne fortsætte med at bygges oven på den, selvom den kom pakket med implementering af et enkelt brugstilfælde, nemlig for udgifts-anomalidetektion. I modsætning hertil havde et tidligere produkt, jeg byggede, nogen historie bag sig, før min ankomst. I dette tilfælde havde interessenter diskuteret i tre år (!), hvordan de skulle tilgå et produkt, de ønskede at bygge. En klient-direktør forklarede, at en af grundene til, at han hyrede mig, var for at hjælpe firmaet med at komme ud over nogle af disse interne debatter, især fordi produktet, han ønskede at bygge, skulle tilfredsstille hierarkiet af organisationer, der var involveret.

Jeg fandt ud af, at disse territoriale kampe overvejende var forbundet med data, der ejedes af klienten, dets datterselskaber og dets eksterne kunder, så i dette tilfælde drejede hele produkt-backloggen sig om, hvordan disse data ville blive indtaget, gemt, sikret og forbrugt til et enkelt brugstilfælde, der genererede netværk af sundhedsydelere til omkostningsanalyser.

Tidligt i min karriere kom jeg til at forstå, at en arkitekturkvalitet kaldet “brugervenlighed” ikke blot var begrænset til slutbrugere, men også software-udviklere selv. Grunden til dette er, at den kode, der skrives, skal være brugervenlig ligesom brugergrænseflader skal være brugervenlige for slutbrugere. For at et produkt skal blive brugervenligt, skal beviser for koncepter bygges for at demonstrere, at udviklere kan gøre, hvad de har sat sig for at gøre, især når det relaterer til de specifikke teknologi-valg, de laver. Men beviser for koncepter er kun begyndelsen, da produkter er bedst, når de udvikles over tid. Ifølge min mening skal grundlaget for en MVP ideelt set bygges på prototyper, der viser nogen stabilitet, så udviklere kan fortsætte med at udvikle den.

Mens du gennemgik bogen “Machine Learning at Enterprise Scale”, sagde du, at “brug af open source-produkter, rammer og sprog sammen med en agil arkitektur bestående af en blanding af open source- og kommercielle komponenter giver den smidighed, som mange firmaer har brug for, men ikke straks erkender fra starten”. Kan du gå i detaljer om, hvorfor du mener, at firmaer, der bruger open source, er mere smidige?

Mange kommercielle data-produkter bruger nøgle-open source-komponenter under dække og giver udviklere mulighed for at bruge populære programmeringssprog som Python. Firmaerne, der bygger disse produkter, ved, at de open source-komponenter, de har valgt at inkorporere, giver dem et spring i forhold til, at disse allerede er bredt brugt af fællesskabet.

Open source-komponenter med stærke fællesskaber er lettere at sælge på grund af den bekendtskab, de bringer til bordet. Kommercielt tilgængelige produkter, der består hovedsageligt af lukket kildekode eller selv open source, der overvejende blot bruges af bestemte kommercielle produkter, kræver ofte enten træning af disse leverandører eller licenser for at bruge softwaren.

Dertil er dokumentation for sådanne komponenter overvejende ikke offentligt tilgængelig, hvilket tvinger udviklerne til at være afhængige af disse firmaer. Når bredt accepterede open source-komponenter som Apache Spark er i fokus, som med produkter som Databricks Unified Analytics Platform, er mange af disse elementer allerede tilgængelige i fællesskabet, hvilket minimiserer de dele, udviklingsteams behøver at afhænge af kommercielle enheder for at udføre deres arbejde.

Dertil kan kode også lettere migreres over kommercielle implementationer af sådanne produkter. Firmaer vil altid være tilbøjelige til at inkorporere, hvad de betragter som konkurrencedygtige differentieringer, men mange udviklere ønsker ikke at bruge produkter, der er helt nyt, fordi dette viser sig at være udfordrende at flytte mellem firmaer og tenderer til at afbryde deres bånd med de stærke fællesskaber, de er kommet til at forvente.

Ud fra personlig erfaring har jeg arbejdet med sådanne produkter tidligere, og det kan være udfordrende at få kompetent support. Og dette er ironisk, da disse firmaer sælger deres produkter med kundens forventning om, at support vil blive leveret på en tilfredsstillende måde. Jeg har oplevet at indsende en pull-anmodning til et open source-projekt, med ændringen inkorporeret i bygningen samme dag, men kan ikke sige det samme om noget kommercielt projekt, jeg har arbejdet med.

Noget andet, du mener om open source, er, at det giver “adgang til stærke udviklerfællesskaber”. Hvor store er nogle af disse fællesskaber, og hvad gør dem så effektive?

Udviklerfællesskaber omkring et givent open source-produkt kan nå op i hundredtusinder. Antagelsestakster peger ikke nødvendigvis på fællesskabsstyrke, men er en god indikator for, at dette er tilfældet på grund af deres tendens til at producere dyderige cykler. Jeg betragter fællesskaber som stærke, når de producerer sund diskussion og effektiv dokumentation, og hvor aktiv udvikling finder sted.

Når en arkitekt eller senior udvikler arbejder gennem processen med at vælge, hvilke sådanne produkter at inkorporere i, hvad de bygger, kommer mange faktorer typisk i spil, ikke kun om produktet selv og hvad fællesskabet ligner, men om udviklingsteams, der skal adoptere disse, om de er en god fit for det økosystem, der udvikles, hvad vejrkortet ligner, og i nogle tilfælde, om kommerciel support kan findes, hvis dette er nødvendigt. Men mange af disse aspekter falder til side, når der ikke er stærke udviklerfællesskaber.

Du har anmeldt hundredvis af bøger på din hjemmeside, er der tre, du kunne anbefale til vores læsere?

I disse dage læser jeg meget få programmeringsbøger, og selvom der er undtagelser, er virkeligheden, at disse typisk er forældede meget hurtigt, og udviklerfællesskabet giver ofte bedre alternativer via diskussionsfora og dokumentation. Mange af de bøger, jeg læser i øjeblikket, er tilgængelige gratis for mig, enten via teknologi-nyhedsbreve, jeg abonnerer på, forfattere og publicister, der kontakter mig, eller dem, Amazon (AMZN ) sender til mig. For eksempel sendte Amazon mig en pre-publication ukorrekt proof af “The Lean Startup” til min anmeldelse i 2011, hvilket introducerede mig til begrebet MVP, og lige for nylig sendte de mig en kopi af “Julia for Beginners”.

(1) En bog fra O’Reilly, jeg har anbefalet, er “In Search of Database Nirvana”. Forfatteren dækker i detaljer udfordringerne for en database-spørgsmålsmotor til at understøtte arbejdsbelastninger, der spænder over spektret af OLTP på den ene side til analytics på den anden side, med operationelle og forretningsmæssige intelligens-arbejdsbelastninger i midten. Denne bog kan bruges som en vejledning til at evaluere en database-motor eller en kombination af forespørgsel- og lagringsmotorer, rettet mod at imødekomme arbejdsbelastningskrav, enten det er transaktionsbaseret, analytisk eller en blanding af disse to. Dertil er forfatterens dækning af “den svingende database-pendul” i de seneste år særlig godt udført.

(2) Selvom meget er ændret i data-rummet over de seneste år, og nye data-analyseprodukter fortsætter med at blive introduceret, præsenterer “Disruptive Analytics” en tilgængelig, kort historie over de sidste 50 års innovation i analytics, som jeg ikke har set andre steder, og diskuterer to typer disruption: disruptiv innovation inden for analytics-værdikæden og industrien disruption ved innovation i analytics. Set fra startups og analytics-praktikeres perspektiv er succes muliggjort ved at disrupte deres industrier, fordi brug af analytics til at differentiere et produkt er en måde at skabe en disruptiv forretningsmodel eller at skabe nye markeder. Set fra investering i analytics-teknologi for deres organisationer kan en vent-og-se-adfærd måske have mening, fordi teknologier, der er i fare for at blive disrupteret, er risikable investeringer på grund af deres forkortede nyttige levetid.

(3) En af de bedste teknologi-forretnings-tekster, jeg har læst, er “The Limits of Strategy” af en medstifter af Research Board (opkøbt af Gartner), en international tænketank, der undersøger udviklinger i computerverdenen og hvordan virksomheder skal tilpasse sig. Forfatteren præsenterer meget detaljerede noter fra mange af sine samtaler med forretningsledere, og giver indsigtfuld analyse hele vejen igennem om sine erfaringer med at bygge (med sin kone) en gruppe af kunder, store firmaer, der havde brug for at sammenføje deres strategier med den eksploderende verden af computing. Som jeg kommenterede i min anmeldelse, er det, der adskiller denne bog fra andre relaterede bestræbelser, to åbenbart modsatrettede karakteristika: industrien bredde og intimitet, der kun er tilgængelig gennem ansigt-til-ansigt-interaktion.

Du er Principalarkitekt for data-praksis i SPR. Kan du beskrive, hvad SPR gør?

SPR er en digital teknologi-konsulentvirksomhed baseret i Chicago-området, der leverer teknologi-projekter for en række kunder, fra Fortune 1000-virksomheder til lokale startups. Vi bygger end-to-end digitale oplevelser med en række teknologi-kapaciteter, alt fra brugerdefineret software-udvikling, brugeroplevelse, data og sky-infrastruktur til DevOps-coaching, software-test og projektstyring.

Hvad er nogle af dine ansvarsområder med SPR?

Som principalarkitekt er min vigtigste ansvar at drive løsningslevering for kunder, lede arkitektur og udvikling for projekter, og dette indebærer ofte at bære andre hattesomme, såsom produkt-ejer, fordi evnen til at relatere til, hvordan produkter bygges fra en hånd-til-hånd-perspektiv, vejer tungt i forhold til, hvordan arbejdet skal prioriteres, især når man bygger fra bunden.

Jeg er også indkaldt til diskussioner med potentielle kunder, når min ekspertise er nødvendig, og firmaet har nylig bedt mig om at starte en løbende række sessioner med med-arkitekter i data-praksis for at diskutere kunde-projekter, side-projekter og hvad mine kolleger gør for at holde sig ajour med teknologi, lignende det, jeg havde kørt for en tidligere konsulent, selvom de interne møder, så at sige, for dette andet firma omfattede hele deres teknologi-praksis, ikke kun data-arbejde.

For det meste af min karriere har jeg specialiseret mig i open source-udvikling med Java og udført en stigende mængde data-arbejde undervejs. Ud over disse to specialiseringer gør jeg også, hvad mine kolleger og jeg kalder “praktisk” eller “pragmatisk” enterprise-arkitektur, hvilket indebærer at udføre arkitekt-opgaver i sammenhæng med, hvad der skal bygges, og faktisk bygge det, snarere end blot at tale om det eller tegne diagrammer om det, mens man erkender, at disse andre opgaver også er vigtige.

Ifølge min mening overlapper disse tre specialiseringer hinanden og er ikke gensidigt udelukkende. Jeg har forklaret chefer de seneste år, at den linje, der traditionelt er trukket af teknologi-industrien mellem software-udvikling og data-arbejde, ikke længere er tydeligt defineret, delvist fordi værktøjerne mellem disse to områder er konvergeret, og delvist fordi data-arbejde selv er blevet et software-udviklingsarbejde som følge af denne konvergens. Men da traditionelle data-praktikere typisk ikke har software-udviklingsbaggrund, og omvendt, hjælper jeg med at imødekomme dette gap.

Hvad er et interessant projekt, du arbejder på med SPR?

For nylig offentliggjorde jeg den første post i en multi-del case-studie-serie om den tidligere nævnte data-platform, mit team og jeg implementerede i AWS fra bunden dette år for CIO’en i en Chicago-baseret global konsulentvirksomhed. Denne platform består af data-pipelines, data-sø, kanoniske data-modeller, visualiseringer og maskinlæringsmodeller, der skal bruges af virksomhedens afdelinger, praksis og slutbrugere. Mens kernen af platformen skulle bygges af den corporate IT-organisation, der drives af CIO’en, var målet, at denne platform skulle bruges af andre organisationer uden for corporate IT til at centralisere data-aktiver og data-analyse på tværs af virksomheden med en fælles arkitektur, bygget oven på den for at imødekomme brugs-tilfælde for hver organisation.

Som med mange etablerede firmaer var brug af Microsoft Excel almindeligt, med regneark, der ofte blev distribueret inden for og på tværs af organisationer, såvel som mellem firmaet og eksterne kunder. Yderligere var forretningsenheder og konsulentpraksis blevet isolerede, hver især brugte forskellige processer og værktøjer. Så ud over at centralisere data-aktiver og data-analyse var et andet mål at implementere begrebet data-ejerskab og muliggøre deling af data på tværs af organisationer på en sikker og konsekvent måde.

Er der noget andet, du gerne vil dele om open source, SPR eller et andet projekt, du arbejder på?

Et andet projekt (læs om det her og her), som jeg nylig har ledt, omfattede en succesfuld implementering af Databricks Unified Analytics Platform og migration af udførelsen af maskinlæringsmodeller til dette fra Azure HDInsight, en Hadoop-distribution, for direktøren for data-engineering i en stor forsikringsgiver.

Alle disse modeller var beregnet til at forudsige niveauet af forbruger-accept, der kan forventes for forskellige forsikringsprodukter, hvoraf nogle var blevet migreret fra SAS for nogle år siden, da firmaet skiftede til brug af HDInsight. Den største udfordring var dårlig datakvalitet, men andre udfordringer inkluderede mangel på omfattende versionering, stamme-kendskab og ufuldstændig dokumentation, samt umodent Databricks-dokumentation og support i forhold til R-brug på det tidspunkt (Azure-implementationen af Databricks var lige blevet gjort generelt tilgængelig få måneder før dette projekt).

For at imødekomme disse nøgle-udfordringer anbefalede jeg, som en opfølgning på vores implementeringsarbejde, automatisering, konfiguration og versionering, adskillelse af data-bekymringer, dokumentation og nødvendig alignment på tværs af deres data-, platform- og model-team. Vores arbejde overbeviste en oprindeligt meget skeptisk Chief Data Scientist om, at Databricks er vejen at gå, med deres erklærede mål efter vores afgang at migrere deres resterende modeller til Databricks så hurtigt som muligt.

Dette har været et fascinerende interview, der berører mange emner, og jeg føler, at jeg har lært meget om open source. Læsere, der måske ønsker at lære mere, kan besøge SPR’s corporate-website eller Erik Gfessers website.