Erik Gfesser, Principal Architect for Data Practice i SPR – Interview Serie

Erik joinede data practice af SPR’s Emerging Technology Group som Principal Architect i 2018.

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

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

Det er dens evne til at låse applikationer op til at lære kontinuerligt. Jeg startede min udviklerkarriere som senior dataanalytiker med SPSS i et, der blev et globalt markedsvirksomhed, og senere inkorporerede jeg brugen af en forretningsregel-motor kaldet Drools i applikationer, jeg byggede til kunder, men outputtet for alt dette arbejde var essentieligt statisk.

Jeg arbejdede senere igennem procesforbedringsuddannelse, under hvilken tid instruktørerne demonstrerede i detaljer, hvordan de kunne forbedre, gennem statistik og andre metoder, forretningsprocesser brugt af deres kunder, men her igen var outputtet overvejende fokuseret på punkter i tiden. Min erfaring med at forbedre et sundhedsprodukt, mine kolleger og jeg byggede under samme periode, viste mig, hvorfor kontinuerlig læring er nødvendig for sådanne bestræbelser, men ressourcerne, der nu er til rådighed, fandtes ikke på det tidspunkt.

Interessant nok er min tiltrækning til maskinlæring kommet fuld cirkel, da min universitetsvejleder 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, fordi disse har færre konnotationer, og fordi selv AWS anerkender, at dets AI-tjenester er en højere niveau-abstraktion bygget oven på dets ML-tjenester. Selvom noget af ML-hysteriet derude er urealistisk, giver det kraftfulde muligheder set fra udvikleres perspektiv, så længe disse praktikere 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, kan du diskutere, hvorfor open source er så vigtigt?

En aspekt om open source, som jeg har behov for at forklare til direktører over årene, er, at den primære fordel ved open source ikke er, at brugen af sådan software er til rådighed uden monetær omkostning, men at kildekoden er til rådighed gratis.

Udviklere, der bruger denne kildekode, kan modificere den til deres egen brug, og hvis foreslåede ændringer er godkendt, kan de gøre disse ændringer til rådighed for andre udviklere, der bruger den. Faktisk startede bevægelsen bag open source-software på grund af, at udviklere ventede længe på, at kommercielle virksomheder skulle gøre ændringer i produkter, de licenserede, så udviklerne tog det selv i egen hånd at skrive software med samme funktionalitet og åbne 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 til rådighed 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, mens 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, der senere blev 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, ikke at nævne, at kommerciel licensering af nogle af de produkter, vi havde brugt, var for restriktiv, hvilket ledte til overmål af 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 at bygge dette sundhedsprodukt, senere en innovativ open source Java-produkt, vi startede med at bruge kaldet Spring Framework, der 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, så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 retningslinjer, jeg præsenterede for en ny klient, skal bygninger af dataplatformen vi byggede for dem fortsætte med at blive iterativt udført efter behov over tid.

Komponenterne, der bygges til platformens funktionalitet, skal ikke forventes at forblive statiske, da behov ændrer sig, og nye komponenter og komponentfunktioner vil blive til rådighed over tid.

Når man bygger platformfunktionalitet, skal man altid starte med, hvad der er minimalt livskraftigt, før man tilføjer unødvendige klokker og fløjter, hvilket i nogle tilfælde også inkluderer konfiguration. Start med, hvad der er funktionsdygtigt, sikre, at du forstår det, og derefter udvikle det. 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 foran fremtidige behov.

MVP’en, vi byggede til dette produkt, skulle udtrykkeligt bygges, så yderligere brugs Tilfælde kunne fortsætte med at bygges oven på den, selvom den kom i pakken med implementering af en enkelt brugs Tilfælde til afvigelse af udgifter. I modsætning hertil havde et tidligere produkt, jeg byggede, nogen historie bag det, før min ankomst. I dette tilfælde havde interessenter diskuteret i tre år (!), hvordan de skulle tilgang til et produkt, de ønskede at bygge. En kunde-direktør forklarede, at en af grundene til, at han hyrede mig, var for at hjælpe virksomheden med at komme forbi 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 de data, der ejedes af kunden, dets datterselskaber og dets eksterne kunder, så i dette tilfælde drejede hele produktbackloggen sig om, hvordan disse data skulle indtages, gemmes, sikres og forbruges til en enkelt brugs Tilfælde, der genererede netværk af sundhedsudbydere til omkostningsanalyser.

Tidligt i min karriere kom jeg til at forstå, at en arkitekturkvalitet kaldet “brugervenlighed” ikke kun 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 er relateret 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 ‘Maskinlæring på virksomhedsniveau’ sagde du, at ‘brug af open source-produkter, rammer og sprog sammen med en agil arkitektur sammensat af en blanding af open source- og kommercielle komponenter giver den smidighed, som mange virksomheder har brug for, men ikke umiddelbart erkender fra starten’. Kan du gå i detaljer om, hvorfor du mener, at virksomheder, der bruger open source, er mere smidige?

Mange kommercielle dataprodukter bruger nøgle open source-komponenter under dække og giver udviklere mulighed for at bruge populære programmeringssprog som Python. Virksomhederne, 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 kun bruges af bestemte kommercielle produkter, kræver ofte enten uddannelse fra disse leverandører eller licenser for at kunne bruge softwaren.

Desuden er dokumentation for disse komponenter overvejende ikke offentligt tilgængelig, hvilket tvinger udviklerne til at fortsætte deres afhængighed af disse virksomheder. 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 til rådighed i fællesskabet, hvilket minimiserer de dele, udviklingsteams behøver at afhænge af kommercielle enheder for at udføre deres arbejde.

Desuden, da komponenter som Apache Spark er bredt accepteret som de facto-industristandardværktøj, kan kode også lettere migreres over kommercielle implementeringer af disse produkter. Virksomheder 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, da dette viser sig at være udfordrende at flytte mellem virksomheder og tenderer til at skære deres bånd med de stærke fællesskaber, de er kommet til at forvente.

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 sådanne virksomheder 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å ind 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 dydige cykler. Jeg betragter fællesskaber som stærke, når de producerer sunde diskussioner og effektiv dokumentation, og hvor aktiv udvikling finder sted.

Når en arkitekt eller senior udvikler arbejder igennem 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 også om udviklingsteams, der skal adoptere disse, om de er en god match for det økosystem, der udvikles, hvad vejviseren ligner, og i nogle tilfælde, om kommerciel support kan findes, hvis dette er nødvendigt.

Men mange af disse aspekter falder fra hinanden i manglen på stærke udviklerfællesskaber.

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

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 sender til mig. For eksempel sendte Amazon mig et før-udgivelses-urettesagt bevis af “The Lean Startup” til min anmeldelse i 2011, hvilket introducerede mig til konceptet MVP, og lige for nylig sendte de mig en kopi af “Julia for Beginners”.

(1) En bog fra O’Reilly, som jeg har anbefalet, er “I søgen efter database-nirvana”. Forfatteren dækker i detaljer udfordringerne for en databaseforespørgsel-motor til at understøtte arbejdsbelastninger, der spænder over spektret af OLTP på den ene side til analytics på den anden side, med operationel og forretningsmæssig intelligens-arbejdsbelastninger i midten. Denne bog kan bruges som en vejledning til at vurdere en database-motor eller en kombination af forespørgsel- og lagringsmotorer, med henblik på at opfylde arbejdsbelastningskrav, enten disse er transaktionelle, analytiske eller en blanding af disse to. Desuden er forfatterens dækning af “database-pendulums svingninger” i de seneste år særlig godt gjort.

(2) Selvom meget har ændret sig i dataområdet de seneste par år, da nye dataanalyseprodukter fortsat introduceres, 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 industriel disruption ved innovation i analytics. Fra startups og analytics-praktikeres synspunkt er succes muliggjort ved at disrupte deres industrier, da brugen af analytics til at differentiere et produkt er en måde at skabe en disruptiv forretningsmodel eller at skabe nye markeder. Fra synspunktet om at investere i analytics-teknologi til deres organisationer kan en vent-og-se-adfærd måske have mening, da teknologier, der er i risiko for at blive disrupteret, er risikable investeringer på grund af forkortede nyttige levetider.

(3) En af de bedste teknologi-forretnings tekster, jeg har læst, er “Strategiens grænser”, 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 igennem hele bogen om sine erfaringer med at bygge (med sin kone) en gruppe af kunder, store virksomheder, der havde brug for at sammenflette 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: industriel bredde og intimitet, der kun er tilgængelig gennem ansigt-til-ansigt-interaktion.

Du er Principal Architect for data practice i SPR. Kan du beskrive, hvad SPR gør?

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

Hvad er nogle af dine ansvar som SPR?

Som principal arkitekt er min primære ansvar at drive løsningslevering til kunder, lede arkitektur og udvikling for projekter, og dette betyder ofte, at man også skal bære andre hattesomme, som produkt-ejer, fordi evnen til at relatere til, hvordan produkter er bygget fra en hånd-til-hånd-perspektiv, vejer tungt i forhold til, hvordan arbejdet skal prioriteres, især når man bygger noget fra bunden. Jeg er også trukket ind i diskussioner med potentielle kunder, når min ekspertise er nødvendig, og virksomheden har nylig bedt mig om at starte en løbende række sessioner med mine kollega-arkitekter i data practice 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 konsulentvirksomhed, om end de interne møder for denne anden virksomhed omfattede deres samlede teknologi-praksis, ikke specifikt for data-arbejde.

For størstedelen af min karriere har jeg specialiseret mig i open source-udvikling med Java og udfører en øgende mængde data-arbejde undervejs. Udover disse to specialiseringer udfører jeg også, hvad mine kolleger og jeg er kommet til at kalde “praktisk” eller “pragmatisk” virksomhedsarkitektur, hvilket betyder at udføre arkitekt-opgaver i konteksten af, 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.

I min mening overlapper disse tre specialiseringer hinanden og er ikke gensidigt udelukkende. Jeg har forklaret direktører de seneste par år, at den linje, der traditionelt var trukket af teknologi-industrien mellem software-udvikling og data-arbejde, ikke længere er godt defineret, delvist fordi værktøjet mellem disse to områder er konvergeret, og delvist fordi data-arbejde selv i høj grad er blevet et software-udviklingsarbejde. Imidlertid, da traditionelle data-praktikere typisk ikke har software-udviklingsbaggrund, og omvendt, hjælper jeg med at dække denne åbning.

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

Lige for nylig publicerede 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 i sidste år til CIO’en for en Chicago-baseret global konsulentvirksomhed. Denne platform består af data-rørledninger, data-sø, kanoniske data-modeller, visualiseringer og maskinlæringsmodeller, der skal bruges af virksomhedens afdelinger, praksis og slutbrugere til at centralisere data-aktiver og data-analyse på tværs af virksomheden ved hjælp af en fælles arkitektur, bygget oven på den for at opfylde brugs Tilfælde-kravene for hver organisation.

Som med mange etablerede virksomheder var brugen af Microsoft Excel almindelig, med regneark, der ofte blev distribueret inden for og på tværs af organisationer, samt mellem virksomheden og eksterne kunder. Desuden var forretningsenheder og konsulentpraksis blevet isolerede, hver 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, involverede en succesfuld implementering af Databricks Unified Analytics Platform og migration af udførelsen af maskinlæringsmodeller til dette fra Azure HDInsight, en Hadoop-distribution, til direktøren for data-ingeniørarbejde i en stor forsikringsvirksomhed.

Alle disse overførte modeller var beregnet til at forudsige niveauet af forbruger-tilpasning, der kan forventes for forskellige forsikringsprodukter, hvoraf nogle var blevet overført fra SAS for nogle år siden, da virksomheden skiftede til brug af HDInsight. Den største udfordring var dårlig datakvalitet, men andre udfordringer inkluderede manglende omfattende versionsstyring, stamme-kendskab og ufuldstændig dokumentation, samt umodent Databricks-dokumentation og support med hensyn til R-brug på det tidspunkt (Azure-implementeringen af Databricks var blevet gjort generelt tilgængelig få måneder før dette projekt).

For at imødegå disse nøgleudfordringer anbefalede jeg, som følge af vores implementeringsarbejde, omkring automatisering, konfiguration og versionsstyring, adskillelse af data-bekymringer, dokumentation og nødvendig justering 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, jeg føler, 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.