Erik Gfesser, Principal Architect för Data Practice på SPR – Intervju-serie

Erik gick med i datapraktiken för SPR:s Emerging Technology Group som Principal Architect 2018.

Erik blev specialiserad på data, open source-utveckling med Java och praktisk företagsarkitektur, inklusive byggnation av PoC, prototyper och MVP.

Vad var det som initialt drog dig till maskinlärning?

Det var dess förmåga att låta applikationer lära sig kontinuerligt. Jag började min utvecklarbana som senior dataanalytiker med SPSS på ett företag som senare blev ett globalt marknadsundersökningsföretag, och senare införlivade jag användningen av en affärsregelmotor som kallades Drools i applikationer som jag byggde för kunder, men utdata för allt detta arbete var i princip statiskt.

Jag arbetade senare igenom processförbättringsutbildning, under vilken tid instruktörerna demonstrerade i detalj hur de kunde förbättra, genom statistik och andra metoder, affärsprocesser som användes av deras kunder, men här igen var utdata i stor utsträckning fokuserat på punkter i tiden. Min erfarenhet av att förbättra en hälsovårdsprodukt som mina kollegor och jag byggde under samma tid visade mig varför kontinuerligt lärande är nödvändigt för sådana insatser, men de resurser som finns tillgängliga idag fanns inte tillgängliga då.

Intressant nog har min dragning till maskinlärning kommit full cirkel, eftersom min handledare varnade mig för att specialisera mig på vad som då kallades artificiell intelligens, på grund av AI-vintern vid den tiden. Jag valde att istället använda termer som ML eftersom dessa har färre konnotationer, och eftersom till och med AWS erkänner att dess AI-tjänste-lager i själva verket är en högre abstraktionsnivå byggd ovanpå dess ML-tjänste-lager. Medan en del av ML-hypen där ute är orealistisk, erbjuder den kraftfulla funktioner ur utvecklarnas perspektiv, så länge som dessa praktiker erkänner faktum att värdet som ML tillhandahåller endast är så bra som de data som bearbetas av det.

Du är en stor förespråkare för open source, kan du diskutera varför open source är så viktigt?

En aspekt om open source som jag har behövt förklara för chefer under åren är att den primära fördelen med open source inte är att användningen av sådan programvara görs tillgänglig utan monetärt kostnad, utan att källkoden görs fritt tillgänglig.

Utöver detta kan utvecklare som använder denna källkod modifiera den för sin egen användning, och om föreslagna ändringar godkänns, göra dessa ändringar tillgängliga för andra utvecklare som använder den. I själva verket startade rörelsen bakom open source-programvara på grund av att utvecklare väntade länge på att kommersiella företag skulle göra ändringar i produkter som de licensierade, så utvecklare tog det på sig att skriva programvara med samma funktionalitet, och öppnade den för att förbättras av andra utvecklare.

Kommersiell open source utnyttjar dessa fördelar, verkligheten är att många moderna produkter använder open source under ytan, även om kommersiella varianter av sådan programvara vanligtvis tillhandahåller ytterligare komponenter som inte är tillgängliga som en del av en given open source-utgåva, och tillhandahåller differentiering samt support om detta behövs.

Min första erfarenhet av open source skedde medan jag byggde den hälsovårdsprodukt jag nämnde tidigare, med hjälp av verktyg som Apache Ant, som användes för att bygga programvara, och en tidig DevOps-produkt vid den tiden som kallades Hudson (kodbasen för vilken senare blev Jenkins). Den primära anledningen till att vi valde att använda dessa open source-produkter var att de antingen tillhandahöll bättre lösningar än kommersiella alternativ, eller var innovativa lösningar som inte ens erbjöds av kommersiella enheter, för att inte tala om att kommersiell licensiering av några av de produkter vi hade använt var alltför restriktiv, vilket ledde till överdriven byråkrati när det var dags att behöva fler licenser på grund av kostnaderna som var involverade.

Över tiden har jag sett open source-erbjudanden fortsätta att utvecklas, och tillhandahåller mycket behövlig innovation. Till exempel löstes många av de problem som mina kollegor och jag brottades med när vi byggde denna hälsovårdsprodukt senare av en innovativ open source-Java-produkt som vi började använda som kallades Spring Framework, som fortfarande är stark efter mer än ett decennium, och ekosystemet för vilket nu sträcker sig långt bortom några av de innovationer som det initialt tillhandahöll, och nu ses som vanliga, såsom beroendeinjektion.

Du har använt open source för att bygga PoC, prototyper och MVP. Kan du dela din resa bakom några av dessa produkter?

Som förklarats i en av de vägledande principer som jag presenterade för en nylig kund, bör byggnationer för dataplattformen vi byggde för dem fortsätta att utföras iterativt allteftersom behoven ändras över tiden.

När man bygger ut plattformsfunktionalitet bör man alltid börja med vad som är minimallyt väldigt innan man lägger till onödiga klockor och visselpipor, som i vissa fall även inkluderar konfiguration. Börja med vad som är funktionellt, se till att du förstår det, och sedan utveckla det. Slösa inte bort tid och pengar på att bygga det som har låg sannolikhet att användas, men lägg ner möda på att komma före framtida behov.

MVP som vi byggde för denna produkt behövde uttryckligen byggas så att ytterligare användningsfall kunde fortsätta att byggas ovanpå den, även om den levererades med implementering av ett enda användningsfall, för avvikelse-detektion för utgifter. Till skillnad från denna kund, hade ett tidigare produkt som jag byggde en viss historia bakom sig innan min ankomst. I detta fall hade intressenter debatterat i tre år (!) hur de skulle närma sig en produkt de ville bygga. En kundchef förklarade att en av anledningarna till att han anställde mig var att hjälpa företaget att komma förbi några av dessa interna debatter, särskilt eftersom produkten han ville bygga behövde tillfredsställa hierarkin av organisationer som var involverade.

Jag kom att upptäcka att dessa revirstrider i stor utsträckning var associerade med de data som ägdes av kunden, dess dotterbolag och dess externa kunder, så i detta fall kretsade hela produktbacklogen kring hur dessa data skulle samlas in, lagras, säkras och konsumeras för ett enda användningsfall som genererar nätverk av hälsovårdspersonal för kostnadsanalyser.

Tidigare i min karriär kom jag att förstå att en arkitekturkvalitet som kallas “användbarhet” inte var begränsad till bara slutanvändare, utan även till själva utvecklarna. Anledningen till detta är att den kod som skrivs behöver vara användbar, liksom användargränssnitt behöver vara användbara för slutanvändare. För att en produkt ska bli användbar behöver bevis för koncept byggas för att demonstrera att utvecklare kommer att kunna göra vad de har för avsikt att göra, särskilt när det gäller de specifika tekniska val de gör. Men bevis för koncept är bara början, eftersom produkter är bäst när de utvecklas över tiden. Enligt min mening bör grunden för en MVP idealiskt sett byggas på prototyper som visar en viss stabilitet, så att utvecklare kommer att kunna fortsätta att utveckla den.

Medan du granskade boken “Maskinlärning i företagsstorlek” sa du att “användning av open source-produkter, ramverk och språk tillsammans med en agil arkitektur som består av en blandning av open source- och kommersiella komponenter tillhandahåller den smidighet som många företag behöver men inte omedelbart inser från början”. Kan du gå in på några detaljer om varför du tror att företag som använder open source är mer smidiga?

Många kommersiella dataprodukter använder viktiga open source-komponenter under ytan, och möjliggör för utvecklare att använda populära programmeringsspråk som Python. Företagen som bygger dessa produkter vet att de open source-komponenter de har valt att införliva ger dem en försprång när dessa redan används av samhället.

Open source-komponenter med starka samhällen är lättare att sälja, på grund av den bekantskap som dessa för med sig till bordet. Kommersiellt tillgängliga produkter som består huvudsakligen av stängd källkod, eller till och med open source som i stor utsträckning endast används av specifika kommersiella produkter, kräver antingen utbildning av dessa leverantörer, eller licenser för att kunna använda programvaran.

Utöver detta är dokumentation för sådana komponenter till stor del inte offentligt tillgänglig, vilket tvingar utvecklare att fortsätta vara beroende av dessa företag. När allmänt accepterade open source-komponenter som Apache Spark är i fokus, som med produkter som Databricks Unified Analytics Platform, är många av dessa artiklar redan tillgängliga i samhället, vilket minskar de delar som utvecklingsteam behöver vara beroende av kommersiella enheter för att kunna utföra sitt arbete.

Utöver detta kan kod också enklare migreras över kommersiella implementationer av sådana produkter, eftersom komponenter som Apache Spark är allmänt accepterade som branschstandardverktyg. Företag kommer alltid att vara benägna att införliva det som de anser vara konkurrensfördelar, men många utvecklare vill inte använda produkter som är helt nya, eftersom detta visar sig vara utmanande att flytta mellan företag, och tenderar att skära av deras band med de starka samhällen de har kommit att förvänta sig.

Från min egen erfarenhet har jag arbetat med sådana produkter tidigare, och det kan vara utmanande att få kompetent support. Och detta är ironiskt, med tanke på att sådana företag säljer sina produkter med kundens förväntan att support kommer att tillhandahållas på ett tillförlitligt sätt. Jag har haft erfarenheten av att skicka in en pull-begäran till ett open source-projekt, med korrigeringen införlivad i bygget samma dag, men kan inte säga detsamma om något kommersiellt projekt som jag har arbetat med.

Något annat som du tror om open source är att det leder till “tillgång till starka utvecklarsamhällen”. Hur stora är några av dessa samhällen och vad gör dem så effektiva?

Utvecklarsamhällen kring ett visst open source-produkt kan nå in i hundratusentals. Antagandefrekvenser pekar inte nödvändigtvis på samhällsstyrka, men är en bra indikator på att detta är fallet på grund av deras tendens att producera dygdercykler. Jag anser att samhällen är starka när dessa producerar hälsosam diskussion och effektiv dokumentation, och där aktiv utveckling pågår.

När en arkitekt eller senior utvecklare arbetar igenom processen att välja vilka sådana produkter som ska införlivas i det som byggs, kommer många faktorer vanligtvis in i spel, inte bara om produkten i sig och vad samhället ser ut som, utan också om utvecklingsteam som kommer att anta dessa, om de är en bra match för ekosystemet som utvecklas, vad vägen ser ut som, och i vissa fall om kommersiell support kan hittas om detta behövs.

Men många av dessa aspekter faller bort i avsaknad av starka utvecklarsamhällen.

Du har granskat hundratals böcker på din webbplats, finns det tre som du kan rekommendera till våra läsare?

Dessa dagar läser jag mycket få programmeringsböcker, och medan det finns undantag, är verkligheten att dessa vanligtvis är föråldrade mycket snabbt, och utvecklarsamhället vanligtvis tillhandahåller bättre alternativ via diskussionsforum och dokumentation. Många av de böcker jag läser idag görs fritt tillgängliga för mig, antingen via tekniska nyhetsbrev som jag prenumererar på, författare och publicister som kontaktar mig, eller de som Amazon skickar till mig. Till exempel skickade Amazon till mig ett förpublicerat, okorrigerat bevis på “The Lean Startup” för min granskning 2011, och introducerade mig till konceptet MVP, och precis nyligen skickade de till mig en kopia av “Julia for Beginners”.

(1) En bok från O’Reilly som jag har rekommenderat är “In Search of Database Nirvana”. Författaren täcker i detalj utmaningarna för en databasfrågemotor för att stödja arbetsbelastningar som spänner över spektrumet från OLTP på ena sidan till analyser på den andra sidan, med operativa och affärsintelligensarbetsbelastningar i mitten. Denna bok kan användas som en guide för att bedöma en databasmotor eller en kombination av fråge- och lagringsmotorer, inriktad på att möta ens arbetsbelastningskrav, vare sig dessa är transaktionella, analytiska eller en blandning av dessa två. Utöver detta är författarens täckning av “den gungande databaspendeln” under de senaste åren särskilt väl gjord.

(2) Medan mycket har förändrats i datarummet under de senaste åren, eftersom nya dataanalysprodukter fortsätter att introduceras, presenterar “Disruptive Analytics” en tillgänglig, kort historia om de senaste 50 årens innovation inom analyser som jag inte har sett någon annanstans, och diskuterar två typer av störning: innovativ innovation inom analytics-värdet, och branschstörning genom innovationer inom analyser. Från perspektivet för startups och analytics-praktiker möjliggör framgång störning av deras industrier, eftersom användning av analyser för att differentiera en produkt är ett sätt att skapa en disruptiv affärsmodell eller att skapa nya marknader. Från perspektivet att investera i analytics-teknologi för sina organisationer kan en “vänta och se”-strategi vara meningsfull, eftersom teknologier som riskerar att störas är riskfyllda investeringar på grund av förkortade användbara livslängder.

(3) En av de bästa tekniska affärstexterna jag har läst är “The Limits of Strategy”, av en medgrundare av Research Board (förvärvad av Gartner), en internationell tankesmedja som undersöker utvecklingen inom datavärlden och hur företag bör anpassa sig. Författaren presenterar mycket detaljerade anteckningar från många av sina samtal med affärsledare, och tillhandahåller insiktsfull analys genom hela boken om sina erfarenheter av att bygga (med sin fru) en grupp kunder, stora företag som behövde sammanfoga sina strategier med den exploderande världen av datorkraft. Som jag kommenterade i min granskning, är det som särskiljer denna bok från andra relaterade ansträngningar två tydligt motsatta egenskaper: branschomfattande bredd, och intimitet som endast är tillgänglig genom ansikte mot ansikte-interaktion.

Du är Principal Architect för datapraktiken på SPR. Kan du beskriva vad SPR gör?

SPR är ett digitalt teknikkonsultföretag baserat i Chicago-området, som levererar teknologi-projekt för en mängd olika kunder, från Fortune 1000-företag till lokala startups. Vi bygger digitala upplevelser från ax till limpa med hjälp av en mängd olika tekniska förmågor, allt från anpassad programvaruutveckling, användarupplevelse, data och molninfrastruktur, till DevOps-coaching, programvarutestning och projektledning.

Vad är några av dina ansvarsområden med SPR?

Som principal architect är min huvudsakliga ansvar att driva lösningstillförsel för kunder, leda arkitektur och utveckling för projekt, och detta innebär ofta att jag måste bära andra hattar, som produktägare, eftersom förmågan att relatera till hur produkter byggs från ett praktiskt perspektiv väger tungt i fråga om hur arbetet ska prioriteras, särskilt när man bygger från scratch. Jag är också indragen i diskussioner med potentiella kunder när min expertis behövs, och företaget har nyligen begärt att jag startar en pågående serie sessioner med kollegor i datapraktiken för att diskutera kundprojekt, sidoprojekt och vad mina kollegor gör för att hålla sig à jour med tekniken, liknande det som jag hade kört för ett tidigare konsultföretag, fast den interna mötet så att säga för detta andra företag involverade hela tekniska praktiken, inte specifikt dataarbete.

Under större delen av min karriär har jag specialiserat mig på open source-utveckling med Java, och har utfört en alltmer ökande mängd dataarbete på vägen. Utöver dessa två specialiseringar gör jag också vad mina kollegor och jag har kommit att kalla “praktisk” eller “pragmatisk” företagsarkitektur, vilket innebär att utföra arkitektuppgifter i sammanhanget med vad som ska byggas, och faktiskt bygga det, snarare än att bara tala om det eller rita diagram om det, medveten om att dessa andra uppgifter också är viktiga.

Enligt min mening överlappar dessa tre specialiseringar varandra och är inte ömsesidigt uteslutande. Jag har förklarat för chefer de senaste åren att den linje som traditionellt dragits av teknologi-industrin mellan programvaruutveckling och dataarbete inte längre är väldefinierad, delvis för att verktygen mellan dessa två utrymmen har konvergerat, och delvis för att dataarbete i sig självt till stor del har blivit ett programvaruutvecklingsarbete. Men eftersom traditionella data-praktiker vanligtvis inte har programvaruutvecklingsbakgrund, och vice versa, hjälper jag till att möta denna lucka.

Vad är ett intressant projekt som du för närvarande arbetar med på SPR?

Alldeles nyligen publicerade jag den första posten i en multi-delad fallstudie-serie om den tidigare nämnda data-plattformen som mitt team och jag implementerade i AWS från scratch under det senaste året för CIO på ett Chicago-baserat globalt konsultföretag. Denna plattform består av data-pipelines, data-sjö, kanoniska data-modeller, visualiseringar och maskinlärningsmodeller, som ska användas av företagets avdelningar, praktiker och slutkunder. Medan den centrala plattformen skulle byggas av den korporativa IT-organisationen som drivs av CIO, var målet att denna plattform skulle användas av andra organisationer utanför den korporativa IT för att centralisera data-tillgångar och data-analys över hela företaget med en gemensam arkitektur, byggd ovanpå den för att möta användningsfallens behov för varje organisation.

Som med många etablerade företag var användningen av Microsoft Excel vanligt förekommande, med kalkylblad som vanligtvis delades inom och över organisationer, samt mellan företaget och externa kunder. Utöver detta hade affärsenheter och konsultpraktiker blivit isolerade, var och en använder olika processer och verktyg. Så utöver att centralisera data-tillgångar och data-analys, var ett annat mål att implementera konceptet data-ägarskap, och möjliggöra delning av data över organisationer på ett säkert och konsekvent sätt.

Finns det något annat som du vill dela om open source, SPR eller ett annat projekt som du arbetar med?

Ett annat projekt (läs om det här och här) som jag nyligen ledde involverade framgångsrikt implementering av Databricks Unified Analytics Platform, och migrering av körningen av maskinlärningsmodeller till den från Azure HDInsight, en Hadoop-distribution, för data-teknikdirektören för en stor försäkringsgivare.

Alla dessa migrerade modeller var avsedda att förutsäga den förväntade konsument-acceptansen för olika försäkringsprodukter, med några som hade migrerats från SAS för flera år sedan, då företaget flyttade till att använda HDInsight. Den största utmaningen var dålig datakvalitet, men andra utmaningar inkluderade brist på omfattande versionering, stam-kunskap och ofullständig dokumentation, och omogen Databricks-dokumentation och support med avseende på R-användning vid den tiden (Azure-implementationen av Databricks hade precis blivit allmänt tillgänglig några månader före detta projekt).

För att tackla dessa nyckelutmaningar rekommenderade jag, som en uppföljning till vårt implementeringsarbete, automatisering, konfiguration och versionering, separation av data-bekymmer, dokumentation och nödvändig samstämmighet över deras data-, plattforms- och modellerings-team. Vårt arbete övertygade en initialt mycket skeptisk Chief Data Scientist om att Databricks är vägen att gå, med deras uttalade mål efter vår avresa att migrera deras återstående modeller till Databricks så snabbt som möjligt.

_Detta har varit en fascinerande intervju som berör många ämnen, jag känner att jag har lärt mig mycket om open source. Läsare som kanske vill veta mer kan besöka SPR:s företagssajt eller Erik Gfessers webbplats.