Erik Gfesser, pääarkkitehti SPR:n dataharjoittelussa – Haastattelusarja

Erik liittyi SPR:n Emerging Technology Groupin dataharjoitteluun pääarkkitehtina vuonna 2018.

Erik erikoistui dataan, avoimen lähdekoodin kehitykseen Java-kielellä ja käytännön yritysarkkitehtuuriin, mukaan lukien PoC:ien, prototyyppien ja MVP:ien rakentamiseen.

Mikä aluksi veti sinut machine learningin pariin?

Sen mahdollisuus sovelluksille oppia jatkuvasti. Olin aloittanut urani senior data-analyytikkona SPSS:llä globaalissa markkinatutkimusyhtiössä, ja myöhemmin otin käyttöön liiketoimintasääntömoottorin nimeltä Drools sovelluksiin, joita rakensin asiakkaille, mutta kaiken tämän työn tulokset olivat periaatteessa staattisia.

Myöhemmin työskentelin prosessien parantamisen koulutuksessa, jonka aikana kouluttajat esittivät yksityiskohtaisesti, miten he pystyivät parantamaan tilastojen ja muiden menetelmien avulla asiakkaidensa liiketoimintaprosesseja, mutta tämäkin työ tuotti pääasiassa ajankohdan mukaisia tuloksia. Kokemukseni terveydenhuoltotuotteen parantamisesta, jonka kollegani ja minä rakensimme, osoitti, miksi jatkuva oppiminen on välttämätöntä tämänkaltaisille pyrkimyksille, mutta silloin ei ollut käytettävissä nykyisiä resursseja.

Minun kiinnostukseni machine learningiin on tullut täyden kierroksen, sillä väitöskirjani ohjaaja varoitti minua erikoistumasta silloin nimeltään tekoälyyn, johtuen silloisesta tekoälytalvesta. Päätin sen sijaan käyttää termejä kuten ML, koska ne eivät sisällä yhtä paljon konnotaatioita, ja koska jopa AWS tunnustaa, että sen AI-palvelutaso on vain korkeamman tason abstraktio sen ML-palvelutasolla. Vaikka osa ML-hypestä on epärealistista, se tarjoaa voimakkaita ominaisuuksia kehittäjien näkökulmasta, kunhan nämä ammattilaiset tunnustavat sen, että ML:n arvo on yhtä hyvä kuin siihen prosessoitu data.

Olet suuri avoimen lähdekoodin puolustaja, voitko kertoa, miksi avoin lähdekoodi on niin tärkeä?

Yksi avoimen lähdekoodin näkökulma, jonka olen selittänyt johtajille vuosien varrella, on, että avoimen lähdekoodin ensisijainen etu ei ole se, että ohjelmistoa voidaan käyttää ilman rahallista kustannusta, vaan se, että lähdekoodi on vapaasti käytettävissä.

Lisäksi kehittäjät, jotka käyttävät tätä lähdekoodia, voivat muokata sitä omiin tarpeisiinsa, ja jos ehdotetut muutokset hyväksytään, tehdä nämä muutokset saataville muille kehittäjille, jotka käyttävät sitä. Itse asiassa avoimen lähdekoodin ohjelmistojen taustalla oleva liike aloitettiin, kun kehittäjät odottivat pitkään, että kaupalliset yritykset tekisivät muutoksia lisensoimiinsa tuotteisiin, joten kehittäjät päättivät itse kirjoittaa ohjelmistoa, jolla oli sama toiminnallisuus, ja avata sen kehittämisen muille kehittäjille.

Kaupallistettu avoin lähdekoodi hyödyntää näistä eduista, ja todellisuudessa monet modernit tuotteet käyttävät avoimen lähdekoodin tekniikkaa, vaikka kaupalliset variantit tällaisista ohjelmistoista tarjoavat yleensä lisäominaisuuksia, joita ei ole saatavilla avoimen lähdekoodin julkaisussa, ja tarjoavat erottuvuutta sekä tukea, jos sitä tarvitaan.

Minun ensikosketukseni avoimeen lähdekoodiin tapahtui, kun rakensin terveydenhuoltotuotetta, josta mainitsin aiemmin, ja käytin työkaluja kuten Apache Antia, jota käytetään ohjelmistojen rakentamiseen, ja varhaisen DevOps-tuotteen nimeltä Hudson (jonka koodipohja myöhemmin tuli tunnetuksi Jenkinsinä). Pääsyy avoimen lähdekoodin tuotteiden valintaan oli, että ne tarjosivat joko parempia ratkaisuja kuin kaupalliset vaihtoehdot, tai olivat innovatiivisia ratkaisuja, joita kaupalliset yritykset eivät tarjonneet, ja kaupallisten tuotteiden lisensointi, joita olimme aikaisemmin käyttäneet, oli liian rajoittavaa, mikä johti kohtuuttomaan byrokratiaan lisensointien tarpeen vuoksi, johtuen kustannuksista.

Ajan myötä olen nähnyt, miten avoimen lähdekoodin tarjonta on jatkuvasti kehittynyt, ja tarjonnut tarpeellista innovaatiota. Esimerkiksi monet ongelmat, joita kollegani ja minä kamppailimme terveydenhuoltotuotteen rakentamisessa, ratkaistiin myöhemmin innovatiivisella avoimen lähdekoodin Java-tuotteella, jota kutsutaan Spring Frameworkiksi, joka on edelleen vahvassa käytössä yli kymmenen vuoden jälkeen, ja jonka ekosysteemi ulottuu nykyään paljon laajemmalle kuin alun perin tarjoamat innovaatiot, kuten riippuvuuden injektio.

Olet käyttänyt avoimen lähdekoodin rakentamaan PoC:ia, prototyyppejä ja MVP:itä. Voitko kertoa jotain näiden tuotteiden taustoista?

Kuten mainitsin yhdessä ohjaavista periaatteista, jotka esitin asiakkaalleni, data-alustan rakentaminen asiakkaalleni tulisi jatkuvasti toteuttaa iteratiivisesti tarpeen mukaan. Alustan komponentit eivät tulisi odottaa, että ne säilytetään staattisina, vaan ne tulisi kehittää edelleen, kun tarpeet muuttuvat ja uusia komponentteja ja ominaisuuksia tulee saataville.

Alustan toiminnallisuuden rakentamisessa tulee aina aloittaa siitä, mikä on vähintään toimiva, ennen kuin lisätään turhia helppoja ratkaisuja, mikä voi johtaa myös konfiguraatioon. Tulee aloittaa siitä, mikä on toimiva, varmistaa, että ymmärretään se, ja sitten kehittää sitä. Älä haaskaa aikaa ja rahaa rakentamalla sellaista, jolla on pieni todennäköisyys olla käytössä, mutta pyri olemaan edellä tulevien tarpeiden toteuttamisessa.

MVP, jonka rakensimme tälle tuotteelle, piti rakentaa siten, että siihen voitiin jatkossa rakentaa lisää käyttötapauksia, vaikka se toimitettiin yhden käyttötapauksen, kuluherkkien havaintojen, toteutuksella. Toisin kuin tämä asiakas, aiempi tuote, jonka olin rakentanut, oli jo jonkin verran historiaa ennen kuin tulin mukaan. Tässä tapauksessa sidosryhmät olivat kiistelleet kolme vuotta (!) siitä, miten heidän tulisi lähestyä tuotetta, jonka he aikoivat rakentaa. Asiakkaan toimitusjohtaja selitti, että yksi syy, miksi hän toi minut mukaan, oli auttaa yritystä pääsemään ylitse näistä sisäisistä kiistakapuloista, erityisesti koska tuote, jonka hän aikoivat rakentaa, piti tyydyttää hierarkiaa organisaatioita, jotka olivat osallisina.

Toteutin, että nämä aluekiistat liittyivät pääasiassa asiakkaan, sen tytäryhtiöiden ja ulkoisten asiakkaiden omistamaan dataan, joten koko tuotteen takana oleva takana oleva tuote liittyi siihen, miten tämä data sisäistettäisiin, säilytettäisiin, turvattaisiin ja käytettäisiin yhden käyttötapauksen luomiseen verkkoihin terveydenhuollon tarjoajien kustannusanalyysien vuoksi.

Aikaisemmin urallani olin oppinut, että arkkitehtoninen laatu, jota kutsutaan “käytettävyydeksi”, ei rajoitu vain loppukäyttäjiin, vaan myös itse ohjelmistokehittäjille. Tämä johtuu siitä, että kirjoitettu koodi on käytettävä, aivan kuten käyttöliittymien on oltava käytettävissä loppukäyttäjille. Jotta tuote voi olla käytettävä, on rakennettava todisteita siitä, että kehittäjät pystyvät tekemään sen, mihin he pyrkivät, erityisesti silloin, kun on kyse tiettyjen teknologisten valintojen toteuttamisesta. Mutta todisteet ovat vain alkua, koska tuotteet ovat parhaimmillaan, kun ne kehittyvät ajan myötä. Mielestäni MVP:n perusta tulisi rakentua prototyypeistä, jotka ovat jo jonkin verran vakiintuneita, jotta kehittäjät voivat jatkaa sen kehittämistä.

Kun arvioit kirjaa “Machine Learning at Enterprise Scale”, totesit, että “avoimen lähdekoodin tuotteiden, kehysjen ja kielten käyttäminen yhdessä joustavan arkkitehtuurin kanssa, joka koostuu sekä avoimen lähdekoodin että kaupallisten komponenttien sekoituksesta, tarjoaa monille yrityksille tarpeen, mutta ei välittömästi toteuta sen alussa”. Voitko antaa yksityiskohtaisempaa tietoa siitä, miksi uskot, että yritykset, jotka käyttävät avoimen lähdekoodin tuotteita, ovat joustavampia?

Monet kaupalliset data-tuotteet käyttävät avoimen lähdekoodin komponentteja sisäisesti, ja mahdollistavat kehittäjien käytön suositulla ohjelmointikielellä kuten Python. Nämä tuotteiden rakentajat tietävät, että heidän valitsemansa avoimen lähdekoodin komponentit antavat heille etulyöntiaseman, koska ne ovat jo laajasti käytössä yhteisössä.

Avoimen lähdekoodin komponentit, joilla on vahvat yhteisöt, ovat helpompia myydä, johtuen tuttuuden, jonka ne tuovat pöytään. Kaupalliset tuotteet, jotka koostuvat pääasiassa suljetusta lähdekoodista tai avoimesta lähdekoodista, jota käytetään vain tiettyjen kaupallisten tuotteiden kanssa, vaativat usein joko koulutusta näiden valmistajien toimesta tai lisenssejä ohjelmiston käyttämiseksi. Lisäksi tällaisten komponenttien dokumentaatio ei ole laajalti julkaistu, mikä pakottaa kehittäjät jatkuvasti riippuvaisiksi näistä yrityksistä. Kun laajasti hyväksyttyjä avoimen lähdekoodin komponentteja kuten Apache Spark on kyseessä, kuten Databricks Unified Analytics Platform -tuotteessa, monet näistä kohteista ovat jo saatavilla yhteisössä, mikä vähentää osia, joista kehitystiimit tarvitsevat riippua kaupallisten yritysten toiminnasta.

Lisäksi, koska komponentit kuten Apache Spark ovat laajasti hyväksyttyjä teollisuuden standardien mukaisia työkaluja, koodi voidaan myös helpommin siirtää kaupallisten tuotteiden välillä. Yritykset aina pyrkivät sisällyttämään kilpailuetuja, mutta monet kehittäjät eivät halua käyttää täysin uusia tuotteita, koska se osoittautuu haasteelliseksi siirtyä yritysten välillä, ja se katkaisee heidän siteensä vahvoihin yhteisöihin, joita he ovat tottuneet odottamaan.

Oman kokemukseni perusteella olen työskennellyt näiden tuotteiden parissa aiemmin, ja se on osoittautunut haasteelliseksi saada pätevää tukea. Ja tämä on ironista, koska nämä yritykset myyvät tuotteitaan asiakkaiden odottaen, että tuki on saatavilla ajallaan. Olen esittänyt pull-pyynnön avoimen lähdekoodin projektiin, ja korjaus on sisällytetty samana päivänä, mutta en voi sanoa samaa mistään kaupallisesta projektiin, jossa olen työskennellyt.

Jotain muuta, mitä uskot avoimen lähdekoodin johtavan, on “pääsy vahvoihin kehittäjäyhteisöihin”. Kuinka suuria nämä yhteisöt voivat olla ja mitä tekee niistä tehokkaita?

Kehittäjäyhteisöt avoimen lähdekoodin tuotteiden ympärillä voivat olla satoja tuhansia. Otsonaatio ei välttämättä osoita yhteisön vahvuutta, mutta se on hyvä osoitus siitä, että virtuaalinen kehitys on mahdollista. Pitäisi yhteisöjä vahvoina, kun ne tuottavat terveitä keskusteluja ja tehokasta dokumentaatiota, ja kun aktiivista kehittämistä on meneillään. Kun arkkitehti tai vanhempi kehittäjä työskentelee prosessin läpi valitakseen, mitkä tuotteet otetaan käyttöön, useat tekijät tulevat yleensä kyseeseen, eikä vain itse tuotetta ja yhteisöä, vaan myös kehitystiimejä, jotka ottaisivat ne käyttöön, onko ne hyvä sopimus ekosysteemiin, jota kehitetään, mikä on tiestö, ja joissain tapauksissa, onko kaupallista tukea saatavilla, jos sitä tarvitaan.

Olet arvostellut satoja kirjoja verkkosivullasi, voitko suositella kolmea niistä lukijoillemme?

Nykyään luen hyvin vähän ohjelmistokehyskirjoja, ja vaikka on poikkeuksia, todellisuus on, että ne vanhenevat nopeasti, ja kehittäjien yhteisö tarjoaa yleensä parempia vaihtoehtoja keskustelufoorumeilla ja dokumentaatioissa. Monet kirjat, joita luen, ovat saatavilla minulle ilmaiseksi, joko teknologiauutiskirjeiden kautta, joille olen tilannut, kirjailijoilta ja julkaisijoilta, jotka ovat ottaa minuun yhteyttä, tai Amazonilta, joka lähettää minulle kirjoja. Esimerkiksi Amazon (AMZN ) lähetti minulle ennen julkaisua oikaisemattoman käsikirjoituksen “The Lean Startup” -kirjasta vuonna 2011, jossa esiteltiin MVP-käsite, ja äskettäin lähetti minulle “Julia for Beginners” -kirjan.

(1) Yksi O’Reillyn kirjoista, jonka suosittelen, on “In Search of Database Nirvana”. Kirjailija käsittelee yksityiskohtaisesti haasteita, joita tietokantakyselymoottorin on täytettävä, jotta se voi tukea työkuormia, jotka ulottuvat OLTP:stä toisessa päässä analytiikkaan toisessa päässä, ja liiketoimintatiedon välissä. Tämä kirja voidaan käyttää oppaana arvioida tietokantamoottoria tai yhdistelmää kysely- ja tallennusmoottoreista, jotta voidaan täyttää työkuorman vaatimukset, olivat ne transaktioita, analytiikkaa tai näiden yhdistelmää. Lisäksi kirjailijan käsittely “heiluvasta tietokannasta” viime vuosina on erityisen hyvin tehty.

(2) Vaikka paljon on muuttunut data-tilassa viime vuosina, ja uusia data-analytiikkaan liittyviä tuotteita jatkuvasti esitellään, “Disruptive Analytics” esittää lähestymistavan, joka on helppo seurata, lyhyt historia viimeisten 50 vuoden innovaatioista analytiikassa, jota en ole nähnyt muualla, ja käsittelee kahta tyypin mukaisia disruptioita: innovaatioita analytiikka-arvoketjussa ja toimialan disruptiota analytiikan innovaatioiden kautta. Aloittajien ja analytiikka-ammattilaisten näkökulmasta menestys on mahdollista, kun toimialaa disruptoidaan, koska analytiikan käyttäminen tuotteen erottamiseen on tapa luoda disruptiivinen liiketoimintamalli tai luoda uusia markkinoita. Sijoittajien näkökulmasta, jotka sijoittavat analytiikkaan, odottaa ja katselee -lähestymistapa voi olla järkevä, koska teknologiat, jotka ovat vaarassa disruptiota, ovat riskialttiita johtuen lyhennetyistä käyttöikäluvuista.

(3) Yksi parhaista teknologiaan liittyvistä liiketoimintakirjoista, jonka olen lukenut, on “The Limits of Strategy”, jota on kirjoittanut Research Boardin (jonka Gartner on hankkinut) perustaja, joka on kansainvälinen ajatushautomo, joka tutkii kehitystä tietokoneiden maailmassa ja miten yritykset tulisi sopeuttaa siihen. Kirjailija esittää yksityiskohtaisia muistiinpanoja monista keskusteluistaan liiketoimintajohtajien kanssa, ja tarjoaa syvällistä analyysiä koko kirjan ajan siitä, miten hän on rakentanut (vaimonsa kanssa) asiakasryhmän, joka koostuu suurista yrityksistä, jotka tarvitsevat sovittaa strategiansa räjähtävän tietokoneiden maailman kanssa. Kuten kommentoin arvostelussani, se, mikä erottaa tämän kirjan muista vastaavista pyrkimyksistä, on kaksi näennäisesti vastakkaista ominaisuutta: toimialan laajuus ja läheisyys, jota voidaan saavuttaa vain kasvokkain vuorovaikutuksen kautta.

Olet SPR:n dataharjoittelun pääarkkitehti, voitko kertoa, mitä SPR tekee?

SPR on digitaalisen teknologian konsultointiyritys, joka toimii Chicagossa, ja toteuttaa teknologiahankkeita asiakkailleen, alkaen Fortune 1000 -yrityksistä paikallisiin startup-yrityksiin. Rakennamme kokonaisvaltaisia digitaalisia kokemuksia laajalla valikoimalla teknologiaominaisuuksilla, kaikenlaisista mukautettavista ohjelmistokehityksestä, käyttökokemuksesta, datasta ja pilvirakenteesta DevOps-koulutukseen, ohjelmistotestaukseen ja projektiprojektin johtamiseen.

Mitkä ovat joitain tehtäviäsi SPR:llä?

Pääarkkitehtina minun vastuullani on ajaa ratkaisujen toimitusta asiakkaille, johtaa arkkitehtuuri- ja kehitystyötä projekteissa, ja tämä usein tarkoittaa muita rooleja, kuten tuotteen omistajaa, koska pystyäkseni ymmärtämään, miten tuotteita rakennetaan käytännössä, on tärkeää, miten työ priorisoidaan, erityisesti kun rakennetaan alusta alkaen. Minut pyydetään myös osallistumaan keskusteluihin potentiaalisten asiakkaiden kanssa, kun minun asiantuntemusta tarvitaan, ja yritys on pyytänyt minua aloittamaan jatkuvan sarjan istuntoja dataharjoittelun arkkitehtien kanssa keskustellakseen asiakasprojekteista, sivuprojekteista ja siitä, mitä heidän on tehtävä pysyäkseen ajan tasalla teknologian kehityksessä, samoin kuin mitä olin tehnyt aiemmalle konsultille, vaikka sisäiset tapaamiset kyseisessä yrityksessä käsittivät koko teknologiaharjoittelun, eikä vain dataa.

Urani suurimman osan olen erikoistunut avoimen lähdekoodin kehitykseen Java-kielellä, ja suorittanut yhä enemmän dataa. Lisäksi näiden kahden erikoistumisen lisäksi olen myös tehnyt sitä, mitä kollegani ja minä kutsuvat “praktiikaksi” tai “pragmatismiksi” yritysarkkitehtuuriin, mikä tarkoittaa arkkitehtuurin suorittamista siinä kontekstissa, mitä on rakennettava, ja sen rakentamista itse, eikä vain puhumista siitä tai piirtämistä siitä. Tietäisin, että nämä kolme erikoisalaa ovat toisistaan riippumattomia, ja olen selittänyt johtajille viime vuosina, että teknologia-alalla piirretty raja ohjelmistokehityksen ja data-työn välillä ei enää ole hyvin määritelty, osittain siksi, että välineet näiden kahden alan välillä ovat lähentyneet, ja osittain siksi, että data-työ itsessään on suurelta osin muuttunut ohjelmistokehitykseksi. Kuitenkin, koska perinteiset data-ammattilaiset eivät yleensä ole ohjelmistokehittäjiä, ja päinvastoin, autan täyttämään tämän aukon.

Mitä mielenkiintoista projektiä olet parhaillaan työstämässä SPR:llä?

Viime aikoina olen julkaissut ensimmäisen postauksen moniosaisessa tapaustutkimussarjassa data-alustasta, jonka tiimini ja minä toteutimme AWS:lle alusta alkaen viime vuonna Chicagossa toimivan globaalin konsultointiyhtiön CIO:lle. Tämä alusta koostuu data-pipelineista, datajärvestä, kanonisista data-malleista, visualisoinneista ja koneoppimismalleista, joita käytetään yritysten sisäisissä osastoissa, harjoitteluissa ja loppukäyttäjien keskuudessa. Vaikka alustan ydin oli tarkoitus rakentaa corporate IT -organisaatiolle, jota CIO johti, tavoitteena oli, että alusta käytettäisiin myös muiden organisaatioiden ulkopuolella corporate IT:hen, keskittääkseen data-omaisuutta ja data-analytiikkaa yhteisen arkkitehtuurin avulla koko yrityksessä, ja rakentamaan sen päälle tapausten mukaan.

Kuten monissa vakiintuneissa yrityksissä, Microsoft (MSFT ) Excelin käyttö oli yleistä, ja taulukot jaettiin yleisesti organisaatioiden sisällä ja niiden välillä, sekä yrityksen ja ulkoisten asiakkaiden välillä. Lisäksi liiketoimintayksiköt ja konsultointipraktiikat olivat muodostuneet eristetyiksi, ja käyttivät erilaisia prosesseja ja työkaluja. Joten keskittämisen data-omaisuutta ja data-analytiikkaa lisäksi, toinen tavoite oli toteuttaa datan omistajuuden käsite, ja mahdollistaa datan jakaminen organisaatioiden välillä turvallisella ja johdonmukaisella tavalla.

Onko mitään muuta, mitä haluaisit jakaa avoimen lähdekoodin, SPR:n tai jonkin muun projektin kanssa, jolla olet työstämässä?

Toinen projekti (lue siitä täältä ja täältä), jonka johtaminen minulle annettiin, liittyi Databricks Unified Analytics Platformin onnistuneeseen toteutukseen, ja koneoppimismallien siirtämiseen siihen Azure HDInsightista, Hadoop-jakeluun, suuren vakuutusyhtiön data-insinöörien johtajalle. Kaikki nämä siirretyt mallit oli tarkoitus ennustaa, mitä kuluttajien hyväksymistä voidaan odottaa eri vakuutustuotteille, joista osa oli siirretty SAS:sta muutamia vuosia aiemmin, kun yhtiö siirtyi käyttämään HDInsightia. Suurin haaste oli heikko data-laatu, mutta muita haasteita olivat puutteellinen versionhallinta, heimoperinteen ja epätäydellisen dokumentaation, sekä Databricksin dokumentaation ja tuen puutteellisuus suhteessa R-käyttöön silloin, kun Azure-toteutus Databricksista oli vasta julkaistu muutamia kuukausia aiemmin.

Jotta voitaisiin vastata näihin avainhaasteisiin, suosittelin automaatiota, konfiguraatiota ja versionhallintaa, erottamista datahuollosta, dokumentaatiota ja tarvittavaa linjaa data-, alusta- ja mallinnusjoukkueiden välillä. Työmme vakuutti aluksi epäilevän päädata-tieteilijän siitä, että Databricks on oikea valinta, ja heidän tavoitteena oli siirtää loput malleista Databricksiin mahdollisimman nopeasti, kun he lähtevät.

Tämä on ollut mielenkiintoinen haastattelu, joka koskee monia aiheita, ja minusta tuntuu, että olen oppinut paljon avoimen lähdekoodin saloista. Lukijat, jotka haluavat oppia enemmän, voivat vierailla SPR:n yrityssivustolla tai Erik Gfesserin sivustolla.