Erik Gfesser, Principal Architect voor de Data Practice van SPR – Interviewreeks

Erik sloot zich aan bij de data practice van SPR‘s Emerging Technology Group als Principal Architect in 2018.

Erik is gespecialiseerd in data, open source-ontwikkeling met Java en praktische enterprise-architectuur, waaronder het opbouwen van PoC’s, prototypes en MVP’s.

Wat trok je aanvankelijk aan naar machine learning?

De mogelijkheid van toepassingen om continu te leren. Ik begon mijn ontwikkelcarrière als senior data-analist met SPSS bij een wereldwijd marktonderzoeksbureau en incorporeerde later de gebruik van een business rules-engine genaamd Drools in toepassingen die ik voor klanten bouwde, maar de output van al dit werk was in wezen statisch.

Ik werkte later door middel van procesverbeteringstraining, waarbij instructeurs gedetailleerd lieten zien hoe ze in staat waren om bedrijfsprocessen te verbeteren met behulp van statistieken en andere methoden, maar hier was de output ook grotendeels gericht op momenten in de tijd. Mijn ervaring met het verbeteren van een gezondheidsproduct dat mijn collega’s en ik tijdens dezelfde periode bouwden, liet me zien waarom continu leren noodzakelijk is voor dergelijke inspanningen, maar de middelen die nu beschikbaar zijn, bestonden toen nog niet.

Interessant is dat mijn aantrekkingskracht tot machine learning volledig rond is, omdat mijn graduate-adviseur me waarschuwde tegen een specialisatie in wat toen kunstmatige intelligentie werd genoemd, vanwege de AI-winter op dat moment. Ik koos ervoor om in plaats daarvan termen zoals ML te gebruiken, omdat deze minder connotaties hebben en omdat zelfs AWS erkent dat hun AI-dienstenlaag eigenlijk een hogere abstractielaag is die bovenop hun ML-dienstenlaag is gebouwd. Hoewel sommige van de ML-hype realistisch is, biedt het krachtige mogelijkheden vanuit het perspectief van ontwikkelaars, zolang deze praktijkmensen erkennen dat de waarde die ML biedt, alleen zo goed is als de data die door het wordt verwerkt.

Je bent een enorme open source-advocaat, kun je discussiëren waarom open source zo belangrijk is?

Een aspect van open source dat ik de afgelopen jaren aan executives heb uitgelegd, is dat het primaire voordeel van open source niet is dat het gebruik van dergelijke software zonder monetaire kosten beschikbaar wordt gesteld, maar dat de broncode vrij beschikbaar wordt gesteld.

Bovendien kunnen ontwikkelaars die gebruikmaken van deze broncode deze voor hun eigen gebruik aanpassen en als voorgestelde wijzigingen worden goedgekeurd, deze wijzigingen beschikbaar stellen aan andere ontwikkelaars die deze gebruiken. In feite is de beweging achter open source-software ontstaan doordat ontwikkelaars lang moesten wachten tot commerciële bedrijven wijzigingen aanbrachten in producten die ze licentieerden, dus namen ontwikkelaars het initiatief om software met dezelfde functionaliteit te schrijven en deze open te stellen voor verbetering door andere ontwikkelaars.

Gecommercialiseerde open source maakt gebruik van deze voordelen, waarbij de realiteit is dat veel moderne producten open source onder de motorkap gebruiken, zelfs als commerciële varianten van dergelijke software typisch extra componenten bieden die niet beschikbaar zijn als onderdeel van een bepaalde open source-release, waardoor differentiatie en ondersteuning mogelijk zijn als dat nodig is.

Mijn eerste ervaringen met open source vonden plaats toen ik het eerder genoemde gezondheidsproduct bouwde, waarbij ik gebruikmaakte van tooling zoals Apache Ant, dat werd gebruikt om software te bouwen, en een vroeg DevOps-product op dat moment genaamd Hudson (de codebasis waarvan later Jenkins werd). De belangrijkste reden achter onze beslissing om deze open source-producten te gebruiken, was dat deze ofwel betere oplossingen boden dan commerciële alternatieven, ofwel innovatieve oplossingen boden die niet door commerciële entiteiten werden aangeboden, om nog maar te zwijgen over het feit dat de commerciële licentie van sommige van de producten die we gebruikten, overmatig restrictief was, wat leidde tot overmatig rode tape wanneer het tijd was om meer licenties nodig te hebben vanwege de kosten.

In de loop van de tijd heb ik open source-aanbod zien evolueren, waardoor veel nodige innovatie ontstond. Zo losten veel van de problemen die mijn collega’s en ik hadden bij het bouwen van dit gezondheidsproduct, later een innovatief open source-Java-product op dat we begonnen te gebruiken, genaamd Spring Framework, dat nog steeds sterk staat na meer dan een decennium, waarvan het ecosysteem nu verder reikt dan sommige van de innovaties die het oorspronkelijk bood, die nu als vanzelfsprekend worden beschouwd, zoals afhankelijkheidsinjectie.

Je hebt open source gebruikt voor het opbouwen van PoC’s, prototypes en MVP’s. Kun je je reis achter sommige van deze producten delen?

Zoals ik in een van de leidende principes uitlegde die ik aan een recente klant presenteerde, moeten de opbouw van de data-platform die we voor hen bouwden, voortdurend iteratief worden uitgevoerd naarmate de tijd verstrijkt. De componenten die voor dit platform zijn opgebouwd, mogen niet verwacht worden statisch te blijven, aangezien de behoeften veranderen en nieuwe componenten en componentfuncties beschikbaar zullen komen.

Bij het opbouwen van platformfunctionaliteit moet je altijd beginnen met wat minimaal haalbaar is voordat je onnodige beloften en klokkenluiders toevoegt, wat in sommige gevallen zelfs configuratie omvat. Begin met wat functioneel is, zorg ervoor dat je het begrijpt en evolueer het vervolgens. Verspil geen tijd en geld aan het bouwen van dingen met een lage kans om gebruikt te worden, maar doe moeite om vooruit te kijken naar toekomstige behoeften.

Het MVP dat we voor dit product specifiek moesten bouwen, moest zo worden opgebouwd dat aanvullende use cases bovenop konden worden gebouwd, zelfs als het werd geleverd met de implementatie van één use case, voor de detectie van uitgaveafwijkingen. In tegenstelling tot deze klant had een eerder product dat ik bouwde al een geschiedenis voordat ik arriveerde. In dit geval hadden stakeholders drie jaar (!) gedebatteerd over hoe ze een product dat ze wilden bouwen, zouden aanpakken. Een klantdirecteur legde uit dat een van de redenen waarom hij me binnenhaalde, was om het bedrijf te helpen om sommige van deze interne debatten te boven te komen, vooral omdat het product dat hij wilde bouwen de hiërarchie van organisaties moest bevredigen.

Ik kwam erachter dat deze territoriumstrijden grotendeels geassocieerd waren met de data die door de klant, zijn dochterondernemingen en externe klanten werd bezeten, dus in dit geval draaide het volledige productbacklog om hoe deze data zou worden opgenomen, opgeslagen, beveiligd en verbruikt voor één use case die op het vliegtuig netwerken van zorgverleners voor kostenanalyses genereerde.

Vroeg in mijn carrière kwam ik erachter dat een architectuurkwaliteit genaamd “gebruiksvriendelijkheid” niet beperkt was tot alleen eindgebruikers, maar ook tot softwareontwikkelaars zelf. De reden hiervoor is dat de code die wordt geschreven, net zo gebruikersvriendelijk moet zijn als gebruikersinterfaces die door eindgebruikers moeten worden gebruikt. Om een product gebruikersvriendelijk te maken, moeten bewijzen van concepten worden gebouwd om te demonstreren dat ontwikkelaars in staat zullen zijn om te doen wat ze willen doen, vooral met betrekking tot de specifieke technologiekeuzes die ze maken. Maar bewijzen van concepten zijn slechts het begin, aangezien producten het beste zijn wanneer ze in de loop van de tijd evolueren. Volgens mij moet de basis voor een MVP idealiter worden opgebouwd op prototypes die enige stabiliteit vertonen, zodat ontwikkelaars deze kunnen blijven ontwikkelen.

Terwijl je het boek ‘Machine Learning at Enterprise Scale’ beoordeelde, zei je dat ‘het gebruik van open source-producten, -frameworks en -talen naast een agile-architectuur die bestaat uit een mengsel van open source- en commerciële componenten, de behendigheid biedt die veel bedrijven nodig hebben, maar niet onmiddellijk realiseren bij het begin’. Kun je enkele details geven over waarom je denkt dat bedrijven die open source gebruiken, behendiger zijn?

Veel commerciële dataprodukten gebruiken belangrijke open source-componenten onder de motorkap en stellen ontwikkelaars in staat om populaire programmeertalen zoals Python te gebruiken. De bedrijven die deze producten bouwen, weten dat de open source-componenten die ze hebben gekozen om op te nemen, hen een voorsprong geven wanneer deze al breed door de gemeenschap worden gebruikt.

Open source-componenten met sterke gemeenschappen zijn gemakkelijker te verkopen vanwege de vertrouwdheid die ze met zich meebrengen. Commercieel beschikbare producten die voornamelijk uit gesloten broncode bestaan, of zelfs open source die voornamelijk alleen door specifieke commerciële producten wordt gebruikt, vereisen vaak training door deze leveranciers of licenties om de software te gebruiken.

Bovendien is de documentatie voor dergelijke componenten grotendeels niet openbaar beschikbaar, waardoor ontwikkelaars afhankelijk blijven van deze bedrijven. Wanneer breed geaccepteerde open source-componenten zoals Apache Spark centraal staan, zoals bij producten zoals Databricks Unified Analytics Platform, zijn veel van deze items al beschikbaar in de gemeenschap, waardoor de delen waarop ontwikkelteams afhankelijk zijn van commerciële entiteiten om hun werk te doen, worden geminimaliseerd.

Bovendien kunnen componenten zoals Apache Spark, die breed worden geaccepteerd als de facto-industriestandaardtooling, code ook gemakkelijker migreren tussen commerciële implementaties van dergelijke producten. Bedrijven zullen altijd geneigd zijn om te incorporeren wat ze zien als concurrentiedifferentiatie, maar veel ontwikkelaars willen geen producten gebruiken die volledig nieuw zijn, omdat dit het moeilijk maakt om tussen bedrijven te migreren en de sterke gemeenschappen te doorsnijden die ze zijn gaan verwachten.

Uit persoonlijke ervaring heb ik met dergelijke producten gewerkt in het verleden en het kan moeilijk zijn om bekwame ondersteuning te krijgen. En dit is ironisch, gezien het feit dat dergelijke bedrijven hun producten verkopen met de verwachting van de klant dat ondersteuning op tijd zal worden verleend. Ik heb ervaring met het indienen van een pull-verzoek bij een open source-project, waarbij de fix diezelfde dag in de build werd opgenomen, maar kan hetzelfde niet zeggen over enig commercieel project waaraan ik heb gewerkt.

Iets anders dat je gelooft over open source is dat het toegang geeft tot sterke ontwikkelaarsgemeenschappen. Hoe groot zijn sommige van deze gemeenschappen en wat maakt ze zo effectief?

Ontwikkelaarsgemeenschappen rond een bepaald open source-product kunnen in de honderdduizenden lopen. Adoptiepercentages geven niet noodzakelijkerwijs de kracht van de gemeenschap aan, maar zijn een goede indicator dat dit het geval is vanwege hun neiging om deugdelijke cycli te produceren. Ik beschouw gemeenschappen als sterk wanneer deze gezonde discussies en effectieve documentatie produceren en waar actieve ontwikkeling plaatsvindt.

Wanneer een architect of senior ontwikkelaar door het proces gaat om te kiezen welke dergelijke producten te incorporeren in wat ze bouwen, komen veel factoren typisch in het spel, niet alleen over het product zelf en hoe de gemeenschap eruitziet, maar over de ontwikkelteams die deze zullen aannemen, of deze een goede fit zijn voor het ecosysteem dat wordt ontwikkeld, wat de roadmap eruitziet en in sommige gevallen of commerciële ondersteuning kan worden gevonden als dat nodig is. Echter, veel van deze aspecten vallen weg in de afwezigheid van sterke ontwikkelaarsgemeenschappen.

Je hebt honderden boeken op je website beoordeeld, zijn er drie die je aan onze lezers zou kunnen aanbevelen?

Deze dagen lees ik heel weinig programmeerboeken en hoewel er uitzonderingen zijn, is de realiteit dat deze typisch snel verouderd zijn en de ontwikkelaarsgemeenschap meestal betere alternatieven biedt via discussieforums en documentatie. Veel van de boeken die ik nu lees, worden gratis aan me beschikbaar gesteld, hetzij via technologie-nieuwsbrieven waarop ik ben geabonneerd, auteurs en publicisten die contact met me opnemen of degene die Amazon me stuurt. Zo stuurde Amazon me bijvoorbeeld een voorpublicatie-ongecorrigeerde proef van “The Lean Startup” voor mijn beoordeling in 2011, waardoor ik kennismaakte met het concept van het MVP, en onlangs stuurde Amazon me een exemplaar van “Julia for Beginners”.

(1) Een boek van O’Reilly dat ik heb aanbevolen, is “In Search of Database Nirvana”. De auteur behandelt in detail de uitdagingen voor een dataquery-engine om workloads te ondersteunen die variëren van OLTP aan de ene kant tot analytics aan de andere kant, met operationele en business intelligence-workloads in het midden. Dit boek kan worden gebruikt als een gids om een database-engine of een combinatie van query- en opslag-engines te beoordelen, gericht op het vervullen van de workload-vereisten, of deze nu transactie-, analytische of een mengsel van deze twee zijn. Bovendien is de behandeling van de “zwaaiende databasependulum” in de afgelopen jaren door de auteur bijzonder goed gedaan.

(2) Hoewel er de afgelopen jaren veel is veranderd in de dataruimte, omdat nieuwe data-analyseproducten voortdurend worden geïntroduceerd, biedt “Disruptive Analytics” een benaderbare, korte geschiedenis van de afgelopen 50 jaar aan innovatie in analytics die ik nergens anders heb gezien en bespreekt twee soorten disruptie: disruptieve innovatie binnen de analytics-waardeketen en industriedisruptie door innovaties in analytics. Vanuit het perspectief van startups en analytics-praktijkmensen wordt succes mogelijk gemaakt door industrieën te disrupteren, omdat het gebruik van analytics om een product te differentiëren een manier is om een disruptief bedrijfsmodel te creëren of om nieuwe markten te creëren. Vanuit het perspectief van investeren in analytics-technologie voor hun organisaties, kan een wacht-en-ziemodel een goede keuze zijn, omdat technologieën met het risico van disruptie riskante investeringen zijn vanwege hun verkorte nuttige levensduur.

(3) Een van de beste technologiezakelijke teksten die ik heb gelezen, is “The Limits of Strategy”, van een medeoprichter van Research Board (overgenomen door Gartner), een internationaal denktank dat ontwikkelingen in de computwereld onderzoekt en hoe bedrijven zich hieraan moeten aanpassen. De auteur presenteert zeer gedetailleerde notities van veel van zijn gesprekken met zakenleiders, waarin hij gedurende de hele tijd inspirerende analyses biedt over zijn ervaringen met het opbouwen (met zijn vrouw) van een groep klanten, grote bedrijven die hun strategieën moesten afstemmen op de exploderende wereld van computing. Zoals ik opmerkte in mijn beoordeling, is wat dit boek onderscheidt van andere gerelateerde inspanningen, twee schijnbaar tegenstrijdige kenmerken: industriebrede breedte en intimiteit die alleen beschikbaar is via face-to-face-interactie.

Je bent de Principal Architect voor de data practice van SPR. Kun je uitleggen wat SPR doet?

SPR is een digitale technologieadviesbureau met hoofdkantoor in de regio Chicago, dat technologieprojecten levert voor een reeks klanten, van Fortune 1000-ondernemingen tot lokale startups. We bouwen eind-tot-eind digitale ervaringen met behulp van een reeks technologiecapaciteiten, alles van aangepaste softwareontwikkeling, gebruikerservaring, data en cloud-infrastructuur tot DevOps-coaching, softwaretesting en projectmanagement.

Wat zijn enkele van je verantwoordelijkheden bij SPR?

Als principal architect is mijn belangrijkste verantwoordelijkheid om oplossingslevering voor klanten te stimuleren, leidend in architectuur en ontwikkeling voor projecten, en dit betekent vaak dat ik andere hoeden draag, zoals producteigenaar, omdat het kunnen relateren aan hoe producten zijn gebouwd vanuit een hands-on perspectief zwaar weegt in de mate waarin werk moet worden geprioriteerd, vooral bij het opbouwen van scratch. Ik word ook betrokken bij discussies met potentiële klanten wanneer mijn expertise nodig is en het bedrijf vroeg me onlangs om een reeks sessies te starten met mede-architecten in de data practice om klantprojecten, zijprojecten en wat mijn collega’s doen om op de hoogte te blijven van technologie te bespreken, vergelijkbaar met wat ik had opgezet voor een eerder adviesbureau, hoewel de interne bijeenkomsten voor dit andere bedrijf de hele technologiepraktijk omvatten, niet specifiek gericht op datawerk.

Voor het grootste deel van mijn carrière heb ik me gespecialiseerd in open source-ontwikkeling met Java en voer ik een toenemend aantal data-werkzaamheden uit. Naast deze twee specialisaties doe ik ook wat mijn collega’s en ik zijn gaan noemen “praktische” of “pragmatische” enterprise-architectuur, wat betekent dat architectuurtaken worden uitgevoerd in de context van wat wordt gebouwd en dat het daadwerkelijk wordt gebouwd, in plaats van alleen erover te praten of erover te tekenen, waarbij ik me natuurlijk realiseer dat deze andere taken ook belangrijk zijn.

In mijn visie overlappen deze drie specialisaties met elkaar en zijn ze niet onderling uitgesloten. Ik heb de afgelopen jaren aan executives uitgelegd dat de lijn die traditioneel door de technologie-industrie tussen softwareontwikkeling en data-werk is getrokken, niet langer duidelijk is gedefinieerd, gedeeltelijk omdat de tooling tussen deze twee ruimtes is geconvergeerd en gedeeltelijk omdat, als gevolg van deze convergentie, data-werk zelf grotendeels een softwareontwikkelingsinspanning is geworden. Echter, aangezien traditionele data-praktijkmensen typisch geen softwareontwikkelingsachtergrond hebben en vice versa, help ik deze kloof te overbruggen.

Wat is een interessant project dat je momenteel met SPR werkt?

Ik publiceerde onlangs de eerste post in een meerdere delen tellende casestudy-serie over het eerder genoemde data-platform dat mijn team en ik van scratch in AWS hebben geïmplementeerd voor de CIO van een in Chicago gevestigd wereldwijd adviesbureau. Dit platform bestaat uit data-pijpleidingen, een data-lake, canonieke data-modellen, visualisaties en machine learning-modellen, die door afdelingen, praktijken en eindklanten van de klant worden gebruikt. Terwijl het kernplatform werd gebouwd door de corporate IT-organisatie die door de CIO wordt gerund, was het doel dat dit platform zou worden gebruikt door andere organisaties buiten de corporate IT om centrale data-assets en data-analyse over het hele bedrijf te centraliseren met een gemeenschappelijke architectuur, waarop elke organisatie kan bouwen om aan de use case-behoeften te voldoen.

Zoals bij veel gevestigde bedrijven, was het gebruik van Microsoft Excel algemeen, met spreadsheets die binnen en tussen organisaties en tussen het bedrijf en externe klanten werden verdeeld. Bovendien waren businessunits en consultancypraktijken gefragmenteerd geraakt, waarbij elke een gebruik maakte van afwijkende processen en tooling. Dus naast het centraliseren van data-assets en data-analyse, was een ander doel om het concept van data-eigendom te implementeren en het delen van data tussen organisaties op een beveiligde en consequente manier mogelijk te maken.

Is er nog iets anders dat je zou willen delen over open source, SPR of een ander project waar je aan werkt?  

Een ander project (lees erover hier en hier) dat ik onlangs leidde, betrof het succesvol implementeren van Databricks Unified Analytics Platform en het migreren van de uitvoering van machine learning-modellen naar het van Azure HDInsight, een Hadoop-distributie, voor de directeur van data-engineering van een grote verzekeraar.

Alle gemigreerde modellen waren bedoeld om het niveau van consumentenadoptie te voorspellen dat kan worden verwacht voor verschillende verzekeringsproducten, waarvan sommige enkele jaren eerder van SAS waren gemigreerd toen het bedrijf overstapte op het gebruik van HDInsight. De grootste uitdaging was slechte datakwaliteit, maar andere uitdagingen omvatten het ontbreken van een omvattende versie, stamkennis en onvolledige documentatie, en onvolwassen Databricks-documentatie en ondersteuning met betrekking tot R-gebruik op dat moment (de Azure-implementatie van Databricks was slechts enkele maanden eerder algemeen beschikbaar gesteld).

Om deze belangrijke uitdagingen aan te pakken, deed ik aanbevelingen over automatisering, configuratie en versie, scheiding van data-zorgen, documentatie en noodzakelijke uitlijning over hun data-, platform- en modelleerteams. Ons werk overtuigde een aanvankelijk zeer sceptische Chief Data Scientist ervan dat Databricks de weg is om te gaan, met als uitgesproken doel na ons vertrek om de resterende modellen zo snel mogelijk naar Databricks te migreren.

Dit is een fascinerend interview dat veel onderwerpen behandelt, ik voel alsof ik veel heb geleerd over open source. Lezers die meer willen leren, kunnen de SPR-corporate website of Erik Gfesser’s website bezoeken.