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

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

Erik specialiseerde zich in data, open source-ontwikkeling met Java en praktische enterprise-architectuur, waaronder het bouwen van PoC’s, prototypes en MVP’s.

Wat trok je aanvankelijk aan bij machine learning?

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

Ik werkte later door middel van procesverbeteringstraining, waarbij instructeurs in detail lieten zien hoe ze in staat waren om bedrijfsprocessen te verbeteren met 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 deze periode hadden gebouwd, liet me zien waarom continue 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 een volledige cirkel heeft beschreven, aangezien mijn graduate-adviseur me destijds had gewaarschuwd tegen een specialisatie in wat toen kunstmatige intelligentie werd genoemd, vanwege de AI-winter van 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 zijn AI-dienstenlaag in feite een hogere abstractie is die is gebouwd op zijn ML-dienstenlaag. Hoewel sommige van de ML-hype daarbuiten onrealistisch 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-voorstander, kun je uitleggen waarom open source zo belangrijk is?

Een aspect van open source dat ik de afgelopen jaren aan executives heb moeten uitleggen, 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.

Ontwikkelaars die gebruikmaken van deze broncode kunnen 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 hebben gewacht tot commerciële bedrijven wijzigingen aanbrachten in producten die ze hadden gelicentieerd, dus ontwikkelaars namen het op zich om software met dezelfde functionaliteit te schrijven en deze open te stellen voor verbetering door andere ontwikkelaars.

Commercieel open source maakt gebruik van deze voordelen, waarbij de realiteit is dat veel moderne producten open source gebruiken onder de motorkap, 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 voor het bouwen van software, en een vroeg DevOps-product genaamd Hudson (de codebasis waarvan later Jenkins werd). De primaire reden achter onze beslissing om deze open source-producten te gebruiken, was dat deze ofwel betere oplossingen boden dan commerciële alternatieven, of innovatieve oplossingen die niet eens 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 eerder hadden gebruikt, overmatig beperkend was, wat leidde tot een overmatige hoeveelheid rode tape wanneer het tijd was om meer licenties nodig te hebben vanwege de kosten die daarbij waren gemoeid.

In de loop van de tijd heb ik gezien dat open source-aanbod blijft evolueren, waarbij veel van de problemen waarmee mijn collega’s en ik worstelden bij het bouwen van dit gezondheidsproduct, later werden opgelost door een innovatief open source Java-product dat we waren gaan gebruiken, genaamd Spring Framework, dat nog steeds sterk staat na meer dan een decennium, waarvan het ecosysteem nu verder reikt dan enkele van de innovaties die het oorspronkelijk bood, die nu als vanzelfsprekend worden beschouwd, zoals afhankelijkheidsinjectie.

Je hebt open source gebruikt voor het bouwen 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 die ik aan een recente klant presenteerde, zei, moeten build-outs voor het dataplatform dat we voor hen hebben gebouwd, voortdurend iteratief worden uitgevoerd zoals nodig in de loop van de tijd. De componenten die voor dit platform zijn gebouwd, mogen niet worden verwacht om statisch te blijven, aangezien behoeften veranderen en nieuwe componenten en componentfuncties in de loop van de tijd beschikbaar zullen komen.

Wanneer platformfunctionaliteit wordt gebouwd, moet men altijd beginnen met wat minimaal haalbaar is voordat men onnodige beloften en klokkenspelen 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 die weinig kans hebben om te worden gebruikt, maar probeer vooruit te kijken naar toekomstige behoeften.

De MVP die we voor dit product hebben gebouwd, moest uitdrukkelijk zo worden gebouwd dat aanvullende use cases konden worden gebouwd op basis van deze, zelfs als deze werd geleverd met de implementatie van één use case, voor afwijkingsdetectie van uitgaven. In tegenstelling tot deze klant had een eerder product dat ik had gebouwd, enige 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 had ingehuurd, was om het bedrijf te helpen om enkele van deze interne debatten te overwinnen, vooral omdat het product dat hij wilde bouwen, de hiërarchie van organisaties die erbij betrokken waren, moest bevredigen.

Ik kwam erachter dat deze territoriumstrijd grotendeels verband hield met de door de klant bezette gegevens, diens dochterondernemingen en externe klanten, dus in dit geval draaide het hele productbacklog om hoe deze gegevens zouden worden opgenomen, opgeslagen, beveiligd en verbruikt voor één use case die netwerkdiagrammen van zorgverleners voor kostenanalyses gegenereerde.

Vroeger in mijn carrière kwam ik tot de conclusie 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 laten zien 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 als ze in de loop van de tijd evolueren. Volgens mij moet de basis voor een MVP idealiter worden gebouwd op prototypes die enige stabiliteit vertonen, zodat ontwikkelaars deze kunnen blijven evolueren.

Terwijl je het boek ‘Machine Learning at Enterprise Scale’ beoordeelde, zei je dat ‘het gebruik van open source-producten, -kaders en -talen naast een agile architectuur die bestaat uit een mix van open source- en commerciële componenten, de behendigheid biedt die veel bedrijven nodig hebben, maar niet meteen beseffen’. 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 omdat deze al op grote schaal 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 bronbestanden bestaan, of zelfs open source die voornamelijk door specifieke commerciële producten wordt gebruikt, vereisen vaak training door deze leveranciers of licenties om de software te gebruiken.

Daarnaast is de documentatie voor dergelijke componenten grotendeels niet openbaar beschikbaar, waardoor ontwikkelaars voortdurend afhankelijk zijn 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 artikelen al beschikbaar in de gemeenschap, waardoor de delen waarop ontwikkelteams afhankelijk zijn van commerciële entiteiten, worden geminimaliseerd.

Daarnaast kan code ook gemakkelijker tussen commerciële implementaties van dergelijke producten worden gemigreerd, omdat componenten zoals Apache Spark breed worden geaccepteerd als de facto-industriestandaardtooling. 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 moeilijk is om tussen bedrijven te migreren en de sterke gemeenschappen waaraan ze gewend zijn geraakt, te doorbreken.

Uit persoonlijke ervaring heb ik met dergelijke producten gewerkt en kan ik zeggen dat het moeilijk is om competent 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 de ervaring gehad om een pull-verzoek in te dienen bij een open source-project, met de fix die dezelfde dag in de build is opgenomen, maar kan dat niet zeggen over enig commercieel project waaraan ik heb gewerkt.

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

Ontwikkelaarsgemeenschappen rond een bepaald open source-product kunnen honderdduizenden tellen. Adoptiepercentages wijzen niet noodzakelijkerwijs op communitykracht, maar zijn een goede indicator dat dit het geval is vanwege hun neiging om positieve 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 aanbevelen?

Deze dagen lees ik zeer weinig programmeerboeken, en hoewel er uitzonderingen zijn, is de realiteit dat deze meestal snel verouderd zijn, en de ontwikkelaarsgemeenschap biedt meestal betere alternatieven via discussieforums en documentatie. Veel van de boeken die ik momenteel lees, worden me kosteloos ter beschikking gesteld, hetzij via technologie-nieuwsbrieven waaraan ik me abonneer, auteurs en publicisten die contact met me opnemen, of degene die Amazon (AMZN ) me toestuurt. Bijvoorbeeld, Amazon stuurde me een voorpublicatie-ongecorrigeerde bewijs van “The Lean Startup” voor mijn beoordeling in 2011, waardoor ik kennismaakte met het concept van de MVP, en onlangs stuurde Amazon me een kopie 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 databasequery-engine om workloads te ondersteunen die het spectrum van OLTP aan de ene kant tot analytics aan de andere kant bestrijken, met operationele en bedrijfsinformatieworkloads in het midden. Dit boek kan worden gebruikt als gids om een database-engine of een combinatie van query- en opslag-engines te beoordelen, met als doel de workloadvereisten te vervullen, of deze nu transactie-, analytisch of een combinatie van beide zijn. Bovendien is de behandeling van de “zwaaiende databasependel” in de afgelopen jaren door de auteur bijzonder goed gedaan.

(2) Hoewel er de afgelopen jaren veel is veranderd in de dataruimte, 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 verstoring: verstoring van de analytics-waardeketen en industrie-verstoring door innovaties in analytics. Vanuit het perspectief van startups en analytics-praktijkmensen wordt succes mogelijk gemaakt door industrieën te verstoren, omdat het gebruik van analytics om een product te differentiëren een manier is om een verstoring te creëren of een nieuw marktmodel 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 die risico lopen te worden verstoord, risicovol zijn vanwege hun verkorte nuttige levensduur.

(3) Een van de beste technologie-zakelijke teksten die ik heb gelezen, is “The Limits of Strategy”, van een mede-oprichter van Research Board (overgenomen door Gartner), een internationaal denktank dat ontwikkelingen in de computwereld onderzoekt en hoe bedrijven zich daaraan moeten aanpassen. De auteur presenteert zeer gedetailleerde notities van veel van zijn gesprekken met zakenleiders, waardoor hij gedurende de hele tekst een interessante analyse biedt over zijn ervaringen met het opbouwen (samen met zijn vrouw) van een groep klanten, grote bedrijven die hun strategieën moesten afstemmen op de exploderende wereld van computertechnologie. Zoals ik in mijn beoordeling opmerkte, is wat dit boek onderscheidt van andere soortgelijke 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 technologieconsultancy met hoofdkantoor in de regio Chicago, die technologieprojecten levert voor een breed scala aan klanten, van Fortune 1000-bedrijven tot lokale startups. We bouwen end-to-end digitale ervaringen met een breed scala aan technologiecapaciteiten, alles van aangepaste software-ontwikkeling, 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 aan te sturen, waarbij ik leiding geef aan 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 verband met hoe werk moet worden geprioriteerd, vooral bij het bouwen van scratch. Ik word ook betrokken bij discussies met potentiële klanten wanneer mijn expertise nodig is, en het bedrijf heeft onlangs gevraagd of ik een reeks sessies kan starten met collega-architecten in de data practice om over klantprojecten, nevenprojecten en wat mijn collega’s doen om op de hoogte te blijven van technologie te praten, vergelijkbaar met wat ik had gerund voor een eerdere consultancy, hoewel de interne bijeenkomsten voor dat bedrijf de hele technologiepraktijk omvatten, niet specifiek voor datawerk.

Ik heb me de afgelopen jaren gespecialiseerd in open source-ontwikkeling met Java en voer een toenemend aantal data-werkzaamheden uit. Naast deze twee specialisaties doe ik ook wat mijn collega’s en ik “praktische” of “pragmatische” enterprise-architectuur zijn gaan noemen, wat inhoudt 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 natuurlijk erken dat deze andere taken ook belangrijk zijn.

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

Wat is een interessant project waar je momenteel aan werkt met SPR?

Ik publiceerde onlangs de eerste post in een meerdelige casestudy over het eerder genoemde dataplatform dat mijn team en ik vorig jaar van scratch in AWS hebben geïmplementeerd voor de CIO van een in Chicago gevestigde wereldwijde consultancy. Dit platform bestaat uit datapipelines, een datalake, canonieke datamodellen, visualisaties en machine learning-modellen, die door corporate afdelingen, praktijken en eindgebruikers van de klant zullen worden gebruikt. Hoewel het kernplatform door de corporate IT-organisatie van de CIO zou worden gebouwd, was het doel dat dit platform zou worden gebruikt door andere organisaties buiten de corporate IT om data-activa en data-analyse over het hele bedrijf te centraliseren met een gemeenschappelijke architectuur, waarop kan worden voortgebouwd om aan de use case-behoeften van elke organisatie te voldoen.

Net als bij veel gevestigde bedrijven was het gebruik van Microsoft Excel gebruikelijk, met spreadsheets die binnen en tussen organisaties, evenals tussen het bedrijf en externe klanten, werden verdeeld. Bovendien waren businessunits en consultancypraktijken gefragmenteerd geraakt, waarbij elke eenheden verschillende processen en tooling gebruikten. Dus, naast het centraliseren van data-activa en data-analyse, was een ander doel om het concept van data-eigendom te implementeren en om data tussen organisaties op een beveiligde en consistente manier te delen.

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 hier en hier) dat ik onlangs heb geleid, behelsde de succesvolle implementatie van Databricks Unified Analytics Platform en de migratie van de uitvoering van machine learning-modellen naar dit platform vanuit 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 geleden van SAS waren gemigreerd toen het bedrijf overstapte op het gebruik van HDInsight. De grootste uitdaging was slechte gegevenskwaliteit, maar andere uitdagingen omvatten een gebrek aan uitgebreide versiebeheer, stamkennis en onvolledige documentatie, en onvolwassen Databricks-documentatie en ondersteuning met betrekking tot R-gebruik op dat moment (de Azure-implementatie van Databricks was enkele maanden voor dit project algemeen beschikbaar gesteld).

Om deze belangrijke uitdagingen aan te pakken, deed ik, als follow-up op ons implementatiewerk, aanbevelingen over automatisering, configuratie en versiebeheer, scheiding van gegevenszorgen, documentatie en benodigde uitlijning over hun data-, platform- en modelteams. Ons werk overtuigde een aanvankelijk zeer sceptische Chief Data Scientist ervan dat Databricks de weg is die moet worden gevolgd, 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.