Erik Gfesser, Principal Arkitekt för Datapraxis på SPR – Intervju-serie

Erik gick med i datapraxisen på SPR:s Emerging Technology Group som Principal Arkitekt 2018.

Erik blev specialist på data, öppen källkodsutveckling 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 utvecklingskarriär som senior dataanalytiker med SPSS på ett globalt marknadsundersökningsföretag, och senare integrerade jag användningen av en affärsregelmotor som heter Drools i applikationer som jag byggde för kunder, men utdata från allt detta arbete var i princip statiskt.

Jag arbetade senare med processförbättringsträning, 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 även här var utdata till stor del fokuserat på punkter i tiden. Min erfarenhet av att arbeta för att förbättra en hälsovårdsprodukt som mina kollegor och jag byggde under samma period visade mig varför kontinuerligt lärande är nödvändigt för sådana insatser, men resurserna som finns tillgängliga idag fanns inte 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 de har färre konnotationer, och eftersom även AWS erkänner att dess AI-tjänstelager i princip är en högre abstraktionsnivå byggd ovanpå dess ML-tjänstelager. Medan en del av ML-hypen där ute är orealistisk, erbjuder det kraftfulla funktioner ur utvecklarnas perspektiv, så länge som dessa praktiker erkänner 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 öppen källkod, kan du diskutera varför öppen källkod är så viktig?

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

Dessutom kan utvecklare som använder denna källkod modifiera den för sitt eget bruk, och om föreslagna ändringar godkänns, göra dessa ändringar tillgängliga för andra utvecklare som använder den. Faktum är att rörelsen bakom öppen källkodsprogramvara startade 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, öppnade den för att förbättras av andra utvecklare.

Kommersiell öppen källkod utnyttjar dessa fördelar, verkligheten är att många moderna produkter använder öppen källkod 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 öppen källkodsrelease, vilket ger differentiering samt support om det behövs.

Mina första erfarenheter av öppen källkod skedde medan jag byggde den hälsovårdsprodukt jag nämnde tidigare, med hjälp av verktyg som Apache Ant, som används 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 beslutade att använda dessa öppna källkodsprodukter 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 vissa 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 de kostnader som var involverade.

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

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

Som jag förklarade i en av de ledande principerna jag presenterade för en nylig klient, bör byggnationen av dataplattformen vi byggde för dem fortsätta att utföras iterativt allteftersom behovet uppstår över tiden. Komponenterna som byggdes för denna plattform bör inte förväntas förbli statiska, eftersom behov förändras och nya komponenter och komponentfunktioner kommer att bli tillgängliga över tiden.

När man bygger ut plattformsfunktionalitet bör man alltid börja med vad som är minst livskraftigt innan man lägger till onödiga klockor och visselpipor, vilket i vissa fall till och med 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 gör ett försök att ligga före framtida behov.

MVP som vi byggde för denna produkt behövde uttryckligen byggas så att ytterligare användningsfall kunde fortsätta byggas ovanpå det, även om det levererades med implementeringen av ett enda användningsfall, för avvikelseidentifiering av utgifter. Till skillnad från denna klient hade en tidigare produkt som jag byggde en historia bakom den innan min ankomst. I detta fall hade intressenter diskuterat i tre år (!) hur de skulle närma sig en produkt de ville bygga. En klientchef 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 som han ville bygga behövde tillfredsställa hierarkin av organisationer som var involverade.

Jag kom att upptäcka att dessa revirstrider till stor del var förknippade med de data som ägdes av klienten, 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 är begränsad till endast slutanvändare, utan även programvaruutvecklare själva. Anledningen till att detta är fallet är att den kod som skrivs måste vara användbar, liksom användargränssnitt måste vara användbara för slutanvändare. För att en produkt ska bli användbar måste bevis på 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 på 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 dock idealiskt sett byggas på prototyper som visar en viss stabilitet så att utvecklare kan fortsätta att utveckla den.

Medan du granskade boken “Maskinlärning i företagsstorlek” sa du att “användningen av öppen källkodsprodukter, ramverk och språk tillsammans med en smidig arkitektur som består av en blandning av öppen källkod 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 öppen källkod är mer smidiga?

Många kommersiella dataprodukter använder nyckelöppen källkods 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 öppen källkods komponenter de har valt att integrera ger dem en försprång när dessa redan används av samhället.

Öppen källkods 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 sluten källkod, eller till och med öppen källkod som i huvudsak endast används av specifika kommersiella produkter, kräver ofta antingen utbildning av dessa leverantörer eller licenser för att kunna använda programvaran.

Dessutom ä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 för att kunna utföra sitt arbete. När allmänt accepterade öppen källkods 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 bero på kommersiella enheter för att kunna utföra sitt arbete.

Dessutom, eftersom komponenter som Apache Spark är allmänt accepterade som de facto-industristandardverktyg, kan kod också enklare migreras över kommersiella implementationer av sådana produkter. Företag kommer alltid att vara benägna att inkorporera 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 personlig 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 öppen källkodsprojekt, med fixen inkorporerad 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 öppen källkod är att den leder till “tillgång till starka utvecklar-samhällen”. Hur stora är några av dessa samhällen och vad gör dem så effektiva?

Utvecklar-samhällen kring en given öppen källkodsprodukt kan nå in i hundratusentals. Antaganden om antalet användare 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 virtuella cykler. Jag anser att samhällen är starka när de producerar hälsosam diskussion och effektiv dokumentation, och där aktiv utveckling pågår.

När en arkitekt eller senior utvecklare arbetar genom processen att välja vilka sådana produkter som ska inkorporeras i det som byggs, kommer många faktorer vanligtvis in i spel, inte bara om produkten själv och vad samhället ser ut, utan också om utvecklingsteam som kommer att anta dessa, om de är en bra passform för det ekosystem som utvecklas, vad vägen ser ut, och i vissa fall om kommersiellt stöd kan hittas om detta behövs. Men många av dessa aspekter faller bort i avsaknad av starka utvecklar-samhällen.

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

Idag läser jag mycket få programmeringsböcker, och medan det finns undantag, är verkligheten att dessa vanligtvis är föråldrade mycket snabbt, och utvecklargemenskapen vanligtvis tillhandahåller bättre alternativ via diskussionsforum och dokumentation. Många av de böcker jag läser idag görs tillgängliga för mig kostnadsfritt, antingen via tekniska nyhetsbrev som jag prenumererar på, författare och publicister som kontaktar mig, eller de som Amazon (AMZN ) skickar till mig. Till exempel skickade Amazon mig ett förpublicerat, okorrigerat bevis på “The Lean Startup” för min granskning 2011, vilket introducerade mig till konceptet MVP, och nyligen skickade de 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 behandlar i detalj utmaningarna för en databasfrågemotor för att stödja arbetsbelastningar som spänner över spektrumet av OLTP på ena sidan till analyser på den andra sidan, med operativa och affärsintelligensarbetsbelastningar däremellan. 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, oavsett om dessa är transaktionella, analytiska eller en blandning av dessa två. Dessutom är författarens täckning av den “svängande databaspendeln” under de senaste åren särskilt väl gjord.

(2) Medan mycket har förändrats i dataområdet under de senaste åren, eftersom nya dataanalysprodukter fortsätter att introduceras, presenterar “Disruptive Analytics” en tillgänglig, kort historia om de senaste 50 åren av innovation inom analyser som jag inte har sett någon annanstans, och diskuterar två typer av störningar: störande innovation inom analytics-värdet och branschstörning genom innovationer inom analyser. Från startups och analytics-praktikers perspektiv möjliggörs framgång genom att störa deras branscher, eftersom användning av analyser för att differentiera en produkt är ett sätt att skapa en störande affärsmodell eller skapa nya marknader. Från perspektivet att investera i analyser för sina organisationer kan en vänta-och-se-strategi ha mening, 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ärsböckerna 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 (tillsammans med sin fru) en grupp av kunder, stora företag som behövde sammanfoga sina strategier med den exploderande världen av datorkraft. Som jag kommenterade i min granskning, det som särskiljer denna bok från andra relaterade ansträngningar är två tydligt motsatta egenskaper: branschomfattande bredd och intimhet som endast är tillgänglig genom ansikte-mot-ansikte-interaktion.

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

SPR är en digital teknikkonsultfirma baserad 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 arkitekt ä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 bära andra hattar, som till exempel 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 bör 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 andra arkitekter i datapraxisen för att diskutera kundprojekt, sidoprojekt och vad mina kollegor gör för att hålla sig à jour med tekniken, liknande det jag tidigare drev för en annan konsultfirma, fast den interna mötet så att säga för det andra företaget involverade hela tekniska praxis, inte bara dataarbete.

För större delen av min karriär har jag specialiserat mig på öppen källkodsutveckling med Java, och har utfört en alltmer ökande mängd dataarbete på vägen. Utöver dessa två specialiseringar gör jag också det som 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 över 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 under de senaste åren att den linje som traditionellt dragits av teknologiindustrin mellan programvaruutveckling och dataarbete inte längre är väldefinierad, delvis för att verktygen mellan dessa två områden har konvergerat, och delvis för att dataarbetet i sig har till stor del blivit ett programvaruutvecklingsarbete. Men eftersom traditionella datapraktiker 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?

Bara nyligen publicerade jag den första posten i en serie om flera delar om det tidigare nämnda data-plattformen som mitt team och jag implementerade från scratch i AWS förra året för CIO på en Chicago-baserad global konsultfirma. 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 kärnplattformen 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ändningsfallen för varje organisation.

Som i många etablerade företag var användningen av Microsoft Excel vanligt förekommande, med kalkylblad som vanligtvis distribuerades inom och mellan organisationer, samt mellan företaget och externa kunder. Dessutom hade affärsenheter och konsultpraktiker blivit siloade, 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 mellan organisationer på ett säkert och konsekvent sätt.

Finns det något annat som du vill dela om öppen källkod, SPR eller ett annat projekt som du arbetar på?

Ett annat projekt (läs om det här och här) som jag nyligen ledde innebar att jag framgångsrikt implementerade Databricks Unified Analytics Platform, och migrerade körningen av maskinlärningsmodeller till den från Azure HDInsight, en Hadoop-distribution, för data-engineering-chefen på en stor försäkringsgivare.

Alla dessa migrerade modeller var avsedda att förutsäga den förväntade nivån av konsumentacceptans som kan förväntas för olika försäkringsprodukter, med vissa som tidigare migrerats från SAS för några år sedan när företaget gick över till att använda HDInsight. Den största utmaningen var dålig datakvalitet, men andra utmaningar inkluderade brist på omfattande versionering, stamkunskap 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 hantera dessa nyckelutmaningar rekommenderade jag, som en uppföljning till vårt implementeringsarbete, automatisering, konfiguration och versionering, separation av data-angelägenheter, dokumentation och nödvändig samstämmighet mellan deras data-, plattforms- och modellerteam. 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 ett fascinerande samtal som berör många ämnen, jag känner att jag har lärt mig mycket om öppen källkod. Läsare som kanske vill lära sig mer kan besöka SPR:s företagssajt eller Erik Gfessers webbplats.