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

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

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

Mikä aluksi veti sinut machine learningin puoleen?

Sen mahdollisuus sovelluksille jatkuvaan oppimiseen. Olin aloittanut kehittäjänurani seniori-data-analyytikkona SPSS: llä, josta tuli globaali markkinatutkimusyhtiö, ja myöhemmin otin käyttöön liiketoimintasääntömoottorin Droolsin sovelluksiin, joita rakensin asiakkaille, mutta kaiken tämän työn tulos oli lopulta staattinen.

Myöhemmin työskentelin prosessien parantamisessa, jolloin kouluttajat esittivät yksityiskohtaisesti, miten he pystyivät parantamaan tilastojen ja muiden menetelmien avulla asiakkaidensa liiketoimintaprosesseja, mutta tämäkin tulos oli pääosin keskittynyt tiettyyn ajankohtaan. Kokemukseni terveydenhuoltotuotteen parantamisesta, jonka kollegani ja minä rakensimme samanaikaisesti, osoitti, miksi jatkuva oppiminen on välttämätöntä tällaisille pyrkimyksille, mutta silloin saatavilla olevat resurssit eivät olleet olemassa.

Mielenkiintoisesti, vetovoimani kohtaan machine learning on tullut täyteen, koska väitöskirjani ohjaaja varoitti minua erikoistumasta siihen, mitä silloin kutsuttiin tekoälyksi, johtuen tekoälytalvesta. Päätin käyttää sen sijaan termejä, kuten ML, koska ne sisältävät vähemmän 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ä käytännön toimijat tunnustavat sen, että ML: n tarjoama arvo on yhtä hyvä kuin siihen prosessoitu data.

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

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

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, koska 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 se muille kehittäjille parantamista varten.

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

Omani ensikosketukseni avoimen lähdekoodin kanssa tapahtui, kun rakensin terveydenhuoltotuotetta, jossa käytin työkaluja, kuten Apache Antia, jota käytetään ohjelmistojen rakentamiseen, ja varhaisen DevOps-tuotteen, joka oli silloin Hudson (jonka koodipohja myöhemmin tuli tunnetuksi Jenkinsinä). Pääsyy avoimen lähdekoodin tuotteiden käyttöön oli, että ne tarjosivat parempia ratkaisuja kuin kaupalliset vaihtoehdot, tai olivat innovatiivisia ratkaisuja, joita kaupalliset yritykset eivät tarjonneet, ja kaupallisten tuotteiden lisensointi oli usein liian rajoittavaa, mikä aiheutti turhautta, kun tarvitsimme lisenssejä, johtuen kustannuksista.

Ajan myötä olen nähnyt, miten avoimen lähdekoodin tarjonta on jatkuvasti kehittynyt, ja se tarjoaa 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 asemassa yli kymmenen vuoden jälkeen, ja sen ekosysteemi on laajentunut paljon siitä, mitä se alun perin tarjosi, kuten riippuvuuden injektio.

Kerro meille matkastasi avoimen lähdekoodin kanssa PoC: n, prototyyppien ja MVP: n rakentamisessa?

Kuten selitin yhdelle asiakkaalleni esittämässäni ohjaavassa periaatteessa, data-alustan rakentaminen asiakkaallemme tulisi jatkuvasti toteuttaa iteratiivisesti tarpeen mukaan. Tälle alustalle rakennettavat komponentit eivät tulisi odottaa, että ne säilyvät staattisina, koska tarpeet muuttuvat ja uusia komponentteja ja ominaisuuksia tulee saataville ajan myötä.

Rakentaessasi alustan toiminnallisuutta, aloita aina siitä, mikä on vähintään tarpeen mukainen, ennen kuin lisäät turhia helppoja ominaisuuksia, mukaan lukien konfiguraatio. Aloita siitä, mikä on toimiva, varmista, että ymmärrät sen, ja kehitä sitä edelleen. Älä haaskaa aikaa ja rahaa rakentamalla sellaista, jolla on pieni todennäköisyys olla käytössä, mutta pyri olemaan valmiina tuleville tarpeille.

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

Toteutin, että nämä aluekiistat liittyivät pääosin asiakkaan, sen tytäryhtiöiden ja ulkoisten asiakkaiden omistamaan dataan, joten koko tuotteen takana oleva backlog keskittyi siihen, miten tämä data tulisi kerätä, tallentaa, turvata ja hyödyntää yhden käyttötapauksen luomiseen verkkoihin terveydenhuollon ammattilaisten kustannusanalyysiä varten.

Urani alussa ymmärsin, 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ä, samoin kuin käyttöliittymien on oltava käytettävissä loppukäyttäjille. Jotta tuote voi tulla käytettäväksi, on rakennettava konseptin todistus, jotta voidaan osoittaa, että kehittäjät pystyvät tekemään sen, minkä he aikovat tehdä, erityisesti silloin, kun on kyse tiettyjen teknologiavalintojen tekemisestä. Mutta konseptin todistus on vain alku, koska tuotteet ovat parhaimmillaan, kun ne kehittyvät ajan myötä. Mielestäni MVP: n perusta tulisi rakentua prototyyppien varaan, jotka osoittavat jonkinlaista vakautta, jotta kehittäjät voivat jatkossa kehittää niitä.

Kun tarkastelit kirjaa “Machine Learning at Enterprise Scale”, totesit, että “avoimen lähdekoodin tuotteiden, kehysjen ja kielten käyttö yhdessä joustavan arkkitehtuurin kanssa, joka koostuu sekä avoimen lähdekoodin että kaupallisten komponenttien sekoituksesta, tarjoaa joustavuuden, jota monilla yrityksillä on tarve, mutta jota he eivät heti tunnusta aluksi”. Voitko antaa joitakin yksityiskohtia 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äyttää suosittuja ohjelmointikieliä, kuten Pythonia. 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 siitä, että ne tuovat tuttua tunnetta pöytään. Kaupalliset tuotteet, jotka koostuvat pääosin suljetusta lähdekoodista tai avoimesta lähdekoodista, jota käytetään pääosin vain tiettyjen kaupallisten tuotteiden kanssa, vaativat usein joko koulutusta näiden myyjien toimesta tai lisenssejä ohjelmiston käyttämiseksi.

Lisäksi tällaisten komponenttien dokumentaatio ei ole pääosin julkaistu, mikä pakottaa kehittäjät jatkuvasti riippuvaisiksi näistä yrityksistä. Kun laajasti hyväksytyt avoimen lähdekoodin komponentit, kuten Apache Spark, ovat keskeisiä, kuten Databricks Unified Analytics Platform -tuotteissa, monet näistä kohteista ovat jo saatavilla yhteisössä, vähentäen osia, joista kehittäjien on riippuvainen kaupallisten yritysten toimista.

Lisäksi, koska komponentit, kuten Apache Spark, ovat laajasti hyväksyttyjä teollisuuden standardi-työkaluja, koodi voidaan myös helpommin siirtää eri kaupallisten tuotteiden toteutuksiin. Yritykset aina pyrkivät sisällyttämään mihin tahansa kilpailukykyisiä eroja, mutta monet kehittäjät eivät halua käyttää täysin uusia tuotteita, koska se osoittautuu haasteelliseksi siirtyä yritysten välillä ja taipuu heidän vahvojen yhteisöjensä kanssa.

Omasta kokemuksestani olen työskennellyt tällaisilla tuotteilla aiemmin, ja se on osoittautunut haasteelliseksi saada osaavaa tukea. Ja tämä on ironista, koska nämä yritykset myyvät tuotteitaan odotuksella, että tuki on saatavilla ajallaan. Olen kokenut, että olen lähettänyt pull-pyynnön avoimen lähdekoodin projektiin, ja korjaus on otettu käyttöön 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 tietyn avoimen lähdekoodin tuotteen ympärillä voivat olla satoja tuhansia. Otanta-arviot eivät välttämättä osoita yhteisön vahvuutta, mutta ne ovat hyvä osoitus siitä, että ne tuottavat voittavan kehän. Pitäisin 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, jossa valitaan, mitkä tuotteet sisällytetään rakenteilla olevaan, useat tekijät tulevat yleensä peliin, ei vain itse tuotteen tai yhteisön suhteen, vaan myös kehittäjätiimien, jotka ottaisivat ne käyttöön, sekä siitä, ovatko ne hyvä sopimus kehittäjätiimien kanssa, mitkä ovat kehitysraitti ja onko kaupallista tukea saatavilla, jos sitä tarvitaan.

Olet arvostellut satoja kirjoja verkkosivullasi, voitko suositella kolmea, joita voimme suositella lukijoillemme?

Nyt luen hyvin vähän ohjelmistokehityskirjoja, ja vaikka on poikkeuksia, todellisuus on, että ne ovat yleensä vanhentuneita hyvin nopeasti, ja kehittäjäyhteisö tarjoaa yleensä parempia vaihtoehtoja keskustelufoorumeilla ja dokumentaatiolla. Monet kirjat, joita nykyään luen, ovat saatavilla minulle ilmaiseksi, joko teknologiauutiskirjeiden kautta, joille tilaan, kirjailijoilta ja kustantajilta, jotka ottaa minuun yhteyttä, tai niitä, jotka Amazon lähettää minulle. Esimerkiksi Amazon lähetti minulle ennen julkaisua oikaisematon käsikirjoitus “The Lean Startup” -kirjasta arvosteluni varten vuonna 2011, jossa esiteltiin minulle MVP-käsite, ja äskettäin lähetti minulle kopion “Julia for Beginners” -kirjasta.

(1) Yksi O’Reilly-kirja, jonka olen suositellut, on “In Search of Database Nirvana”. Kirjailija käy yksityiskohtaisesti läpi 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 operatiivisista ja liiketoimintatiedon työkuormista välissä. Tätä kirjaa voidaan käyttää oppaana arvioida tietokantamoottoria tai yhdistelmää kysely- ja tallennusmoottoreista, joka on suunniteltu täyttämään työkuormien vaatimukset, olivat ne transaktio- tai analytiikkatyökuormia tai näiden kahden yhdistelmää. Lisäksi kirjailijan käsittely “tietokannan heiluriliikkeestä” viime vuosina on erityisen hyvin tehty.

(2) Vaikka paljon on muuttunut data-tilassa viime vuosina, uudet data-analytiikkatuotteet jatkuvasti esitellään, “Disruptive Analytics” esittää lähestymistavan, joka on helppo seurata, lyhyen historian viimeisten 50 vuoden innovaatioista analytiikassa, jota en ole nähnyt muualla, ja käsittelee kahta tyypin mukaisia disruptioita: innovaatiivista disruptiota analytiikka-arvoketjussa ja toimialan disruptiota innovaatioiden kautta analytiikassa. Aloittajien ja analytiikka-ammattilaisten näkökulmasta menestys on mahdollista disruptoimalla heidän alojaan, koska analytiikan käyttäminen tuotteen erottautumiseen on tapa luoda disruptoiva liiketoimintamalli tai luoda uusia markkinoita. Sijoittajien näkökulmasta, jotka sijoittavat analytiikkaan, odottaminen voi olla järkevää, koska teknologiat, joissa on riski disruptioon, ovat riskialttiita, johtuen niiden lyhentyneistä 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 hankki) perustaja, joka on kansainvälinen think tank, joka tutkii kehitystä tietokoneiden maailmassa ja miten yritykset tulisi sopeuttaa siihen. Kirjailija esittää erittäin yksityiskohtaiset muistiinpanot monista keskusteluistaan liiketoimintajohtajien kanssa, ja tarjoaa tarkoitushakuisen analyysin koko kirjan ajan, miten hän rakensi (vaimonsa kanssa) asiakasryhmän, joka koostui suurista yrityksistä, jotka tarvitsivat sovittaa strategiansa kasvavaan tietokoneiden maailmaan. Kuten kommentoin arvostelussani, se, mikä erottaa tämän kirjan muista samankaltaisista pyrkimyksistä, on kaksi näennäisesti vastakkaista ominaisuutta: toimialan laajuus ja läheisyys, joka on saatavilla vain kasvokkain-vuorovaikutuksen kautta.

Olet SPR:n dataharjoittelun pääarkkitehti. Voitko kuvailla, mitä SPR tekee?

SPR on digitaalisen teknologian konsulttiyhtiö, joka toimii Chicagossa, ja toteuttaa teknologiahankkeita asiakkailleen, alkaen Fortune 1000 -yrityksistä paikallisiin startup-yrityksiin. Rakennamme kokonaisvaltaisia digitaalisia kokemuksia käyttäen laajaa valikoimaa teknologiaominaisuuksia, kaikenlaisia mukautettuja ohjelmistokehityksiä, käyttökokemusta, dataa ja pilvirakennetta, DevOps-valmennuksesta, ohjelmistotestauksesta ja projektipäällikkötoiminnasta.

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

Pääarkkitehtina minun vastuullani on johtaa ratkaisujen toimitusta asiakkaille, johtaen arkkitehtuuri- ja kehitystyötä projekteissa, ja tämä usein tarkoittaa useiden muiden roolien, kuten tuotepäällikön, käyttämistä, koska pystyminen ymmärtämään, miten tuotteita rakennetaan käytännössä, painaa paljon siihen, miten työtä tulisi priorisoida, erityisesti kun rakennetaan alusta alkaen. Minut pyydetään myös keskusteluihin potentiaalisten asiakkaiden kanssa, kun minun asiantuntemusta tarvitaan, ja yritys pyysi minua aloittamaan jatkuvan sarjan istuntoja dataharjoittelun arkkitehtien kanssa keskustellakseen asiakkaiden projekteista, 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 olivat koko teknologiaharjoittelun kanssa, eivät vain dataan liittyvää.

Suurimman osan urastani olen erikoistunut avoimen lähdekoodin kehitykseen Java-kielellä ja suorittanut yhä enemmän dataa, ja myös “käytännön” tai “pragmatista” yritysarkkitehtuuria, mikä tarkoittaa arkkitehtuurin tehtävien suorittamista siinä kontekstissa, mitä on rakennettava, ja itse asiassa rakentamalla sitä, eikä vain puhumalla siitä tai piirtämällä siitä kaavioita, ymmärrettäessä tietysti, että nämä muut tehtävät ovat myös tärkeitä.

Mielestäni nämä kolme erikoisalaa limittyvät toisiinsa eivätkä ole toisensa vastaisia. Olen selittänyt johtajille viime vuosina, että teknologia-alalla perinteisesti piirretty raja ohjelmistokehityksen ja data-työn välillä ei ole enää hyvin määritelty, osittain koska välineet näiden kahden alan välillä ovat yhdistyneet, ja osittain koska data-työ itsessään on suurelta osin muuttunut ohjelmistokehitykseksi. Kuitenkin perinteiset data-ammattilaiset eivät yleensä ole ohjelmistokehittäjiä, ja päinvastoin, autan täyttämään tämän aukon.

Mitä mielenkiintoista projektiin SPR: llä parhaillaan työskentelet?

Vastikään julkaisin ensimmäisen kirjoituksen moniosaisessa case-tutkimussarjassa data-alustasta, jonka tiimini ja minä toteutimme AWS: ssä alusta alkaen viime vuonna Chicagossa toimivan globaalin konsulttiyhtiön CIO: lle. Tämä alusta koostuu data-pipelineista, datajärvestä, kanonisista data-malleista, visualisoinneista ja koneoppimismalleista, joita käytetään yrityksen hallinnollisissa osastoissa, harjoitteluissa ja loppuasiakkaiden kanssa. Vaikka alustan ydin oli tarkoitus rakentaa corporate IT -organisaatiolle, jota CIO johti, tavoitteena oli, että tätä alustaa käytettäisiin myös muiden organisaatioiden ulkopuolella corporate IT: tä, keskittääkseen data-varat ja data-analyysin koko yrityksessä yhteisen arkkitehtuurin avulla ja rakentamaan sen päälle tyydyttääkseen kunkin organisaation käyttötapauksia.

Kuten monissa vakiintuneissa yrityksissä, Microsoft Excelin käyttö oli yleistä, ja taulukot jaettiin yleensä sisäisesti ja eri organisaatioiden välillä, sekä yrityksen ja ulkoisten asiakkaiden välillä. Lisäksi liiketoimintayksiköt ja konsulttitoimistot olivat muodostuneet eristyneiksi, ja kullekin oli ominaisia prosesseja ja työkaluja. Joten data-varojen ja data-analytiikan keskittämisen lisäksi toinen tavoite oli toteuttaa data-omistajuuden käsite ja mahdollistaa datan jakaminen turvallisesti ja johdonmukaisesti eri organisaatioiden välillä.

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

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 tarkoitettu ennustamaan kuluttajien odotettavissa olevaa omaksumisen tasoa 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 asiakirjojen ja tuen kehittymättömyys R-käytön suhteen (Azure-toteutus Databricksista oli vasta muutamia kuukausia aiemmin julkaistu yleiseen saataville).

Näiden avainhaasteiden ratkaisemiseksi tein suosituksia automaation, konfiguraation ja versionhallinnan, datan erottelun, dokumentaation ja tarvittavan linjauksen heidän data-, alusta- ja mallintamistiimien välillä. Työmme vakuutti aluksi erittäin epäluuloinen päädata-tiedemies, jonka ilmoittama tavoite oli siirtää heidän jäljellä olevat mallit Databricksiin mahdollisimman nopeasti.

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