Erik Gfesser, Główny Architekt Praktyki Danych SPR – Wywiad

Erik dołączył do praktyki danych grupy Emerging Technology Group SPR jako Główny Architekt w 2018 roku.

Erik specjalizuje się w danych, rozwoju oprogramowania open source z wykorzystaniem Javy oraz praktycznej architektury przedsiębiorstw, w tym budowaniu Proof of Concept, prototypów i MVP.

Czym było to, co pierwotnie przyciągnęło Cię do uczenia maszynowego?

Umiejętnością aplikacji do ciągłego uczenia się. Zaczynałem swoją karierę jako starszy analityk danych, używając SPSS w firmie badawczej, a później włączyłem do swoich aplikacji silnik reguł biznesowych o nazwie Drools, ale wyniki tej pracy były w zasadzie statyczne.

Później uczestniczyłem w szkoleniu z doskonalenia procesów, podczas którego instruktorzy pokazywali, jak poprawiają procesy biznesowe swoich klientów za pomocą statystyki i innych metod, ale i tu wyniki były w dużej mierze ukierunkowane na punkty w czasie. Moje doświadczenie z poprawą produktu opieki zdrowotnej, który zbudowali moi koledzy i ja, pokazało mi, dlaczego ciągłe uczenie się jest konieczne w takich wysiłkach, ale wtedy nie istniały jeszcze dostępne zasoby.

Co ciekawe, moje zainteresowanie uczeniem maszynowym wróciło do punktu wyjścia, ponieważ mój opiekun na studiach ostrzegał mnie przed specjalizacją w tym, co wtedy nazywano sztuczną inteligencją, ze względu na “zimną wojnę” w dziedzinie AI. Zdecydowałem się używać terminów takich jak ML, ponieważ mają one mniej konotacji, a nawet AWS uznaje, że jego usługi AI są w zasadzie wyższą warstwą abstrakcji zbudowaną na jego usługach ML. Chociaż część z hossy ML jest nierzeczywista, dostarcza ona potężne możliwości z perspektywy deweloperów, o ile ci praktycy uznają, że wartość, którą ML dostarcza, jest tylko tak dobra, jak dane, które są przez nią przetwarzane.

Jesteś wielkim zwolennikiem oprogramowania open source, mogłbyś omówić, dlaczego open source jest tak ważne?

Jednym z aspektów oprogramowania open source, które musiałem wyjaśnić menedżerom na przestrzeni lat, jest to, że główną korzyścią z open source nie jest to, że oprogramowanie jest dostępne bez kosztów, ale to, że kod źródłowy jest dostępny bezpłatnie.

Ponadto deweloperzy, którzy korzystają z tego kodu, mogą go modyfikować do swoich potrzeb, a jeśli sugerowane zmiany zostaną zatwierdzone, mogą udostępnić je innym deweloperom. Ruch na rzecz oprogramowania open source powstał, ponieważ deweloperzy czekali długo, aż firmy komercyjne wprowadzą zmiany w produktach, których używali, więc deweloperzy sami napisali oprogramowanie o tej samej funkcjonalności i udostępnili je, aby mogli je ulepszać.

Komercyjne oprogramowanie open source wykorzystuje te korzyści, a rzeczywistością jest to, że wiele nowoczesnych produktów korzysta z oprogramowania open source pod powierzchnią, nawet jeśli wersje komercyjne takiego oprogramowania zwykle zawierają dodatkowe składniki, które nie są dostępne w ramach wydania open source, zapewniając różnice i wsparcie, jeśli jest to potrzebne.

Moje pierwsze doświadczenia z oprogramowaniem open source miały miejsce, gdy budowałem produkt opieki zdrowotnej, o którym wspomniałem wcześniej, używając narzędzi takich jak Apache Ant do budowy oprogramowania i wczesnego produktu DevOps o nazwie Hudson (którego baza kodu później stała się Jenkins). Głównym powodem, dla którego zdecydowaliśmy się użyć tych produktów open source, było to, że zapewniały one lepsze rozwiązania niż alternatywy komercyjne lub były innowacyjnymi rozwiązaniami, których nie oferowały firmy komercyjne, nie wspominając już o tym, że licencjonowanie komercyjne niektórych produktów, których używaliśmy, było nadmiernie restrykcyjne, prowadząc do nadmiernej biurokracji, gdy potrzebowaliśmy więcej licencji ze względu na koszty.

W miarę upływu czasu widziałem, jak oferty open source ewoluują, zapewniając bardzo potrzebną innowację. Na przykład wiele problemów, z którymi moi koledzy i ja zmagaliśmy się podczas budowy tego produktu opieki zdrowotnej, zostało później rozwiązanych przez innowacyjny produkt open source Javy o nazwie Spring Framework, który nadal działa po ponad dekadzie, a jego ekosystem rozciąga się daleko poza niektóre z innowacji, które początkowo wprowadził, takimi jak wstrzykiwanie zależności.

Używałeś oprogramowania open source do budowy Proof of Concept, prototypów i MVP. Czy mógłbyś podzielić się swoją historią związaną z niektórymi z tych produktów?

Jak wyjaśniłem w jednej z zasad, które przedstawiłem niedawnemu klientowi, budowa platformy danych, którą zbudowaliśmy dla nich, powinna być prowadzona w sposób iteracyjny w miarę potrzeb na przestrzeni czasu. Składniki zbudowane dla tej platformy nie powinny być uważane za statyczne, ponieważ potrzeby się zmieniają, a nowe składniki i funkcje będą dostępne w miarę upływu czasu.

Początkowo zawsze zaczynaj od tego, co jest najmniej konieczne, zanim dodasz niepotrzebne dzwony i gwizdki, co w niektórych przypadkach nawet obejmuje konfigurację. Zaczynaj od tego, co jest funkcjonalne, upewnij się, że rozumiesz to, a następnie rozwinij to. Nie trać czasu i pieniędzy na budowanie tego, co ma niską szansę na użycie, ale staraj się być przed potrzebami przyszłości.

MVP, który zbudowaliśmy dla tego produktu, musiał być zbudowany w taki sposób, aby można było na nim budować dodatkowe przypadki użycia, chociaż został dostarczony z implementacją jednego przypadku użycia, wykrywania anomalii wydatków. W przeciwieństwie do tego klienta wcześniejszy produkt, który zbudowałem, miał już pewną historię przed moim przybyciem. W tym przypadku stakeholderzy debatowali przez trzy lata (!) o tym, jak powinni podejść do produktu, który chcieli zbudować. Jeden z klientów wyjaśnił, że jednym z powodów, dla których mnie ściągnął, było to, aby pomóc firmie przekroczyć niektóre z tych wewnętrznych debat, szczególnie dlatego, że produkt, który chciał zbudować, musiał zadowolić hierarchię organizacji zaangażowanych.

Okazało się, że te wojny o terytorium były w dużej mierze związane z danymi należącymi do klienta, jego spółek zależnych i zewnętrznych klientów, więc w tym przypadku cały backlog produktu dotyczył tego, jak te dane będą pobierane, przechowywane, zabezpieczane i konsumowane w celu wygenerowania sieci dostawców opieki zdrowotnej do analizy kosztów.

Wcześniej w swojej karierze zrozumiałem, że jakość architektoniczna zwana “użytecznością” nie jest ograniczona tylko do użytkowników końcowych, ale także do samych deweloperów. Powodem jest to, że napisany kod musi być użyteczny, tak jak interfejsy użytkownika muszą być użyteczne dla użytkowników końcowych. Aby produkt był użyteczny, należy zbudować Proof of Concept, aby pokazać, że deweloperzy będą mogli zrobić to, co zamierzają, szczególnie w odniesieniu do konkretnych wyborów technologicznych. Ale Proof of Concept to tylko początek, ponieważ produkty są najlepsze, gdy ewoluują w czasie. Moim zdaniem podstawą MVP powinna być zbudowana na prototypach, które wykazują pewną stabilność, aby deweloperzy mogli nadal ją rozwijać.

Podczas przeglądania książki “Machine Learning at Enterprise Scale” stwierdziłeś, że “użycie produktów open source, frameworków i języków obok architektury zwinnej, składającej się z mieszaniny składników open source i komercyjnych, zapewnia zwinność, której wiele firm potrzebuje, ale nie zdaje sobie z tego sprawy od samego początku”. Czy mógłbyś omówić, dlaczego uważasz, że firmy, które używają oprogramowania open source, są bardziej zwrotne?

Wiele komercyjnych produktów danych wykorzystuje kluczowe składniki open source pod powierzchnią i umożliwia deweloperom korzystanie z popularnych języków programowania, takich jak Python. Firmy, które budują te produkty, wiedzą, że składniki open source, które wybrali, dają im przewagę, ponieważ są one już powszechnie używane przez społeczność.

Składniki open source z silnymi społecznościami są łatwiejsze do sprzedaży ze względu na znajomość, którą one przynoszą. Produkty komercyjne, które składają się głównie z zamkniętego oprogramowania lub nawet oprogramowania open source, które jest używane głównie przez określone produkty komercyjne, często wymagają szkolenia od tych dostawców lub licencji, aby korzystać z oprogramowania.

Ponadto dokumentacja dla takich składników nie jest zazwyczaj udostępniana publicznie, co powoduje, że deweloperzy są uzależnieni od tych firm. Gdy szeroko akceptowane składniki open source, takie jak Apache Spark, są centralnym punktem, jak w przypadku produktów takich jak Databricks Unified Analytics Platform, wiele z tych elementów jest już dostępnych w społeczności, co minimalizuje części, na które zespoły deweloperskie muszą polegać na podmiotach komercyjnych, aby wykonać swoją pracę.

Ponadto, ponieważ składniki takie jak Apache Spark są powszechnie uznawane za standardowe narzędzia branżowe, kod może być również łatwiej przenoszony między wdrożeniami komercyjnymi takich produktów. Firmy zawsze będą skłonne dołączać to, co uważają za różnice konkurencyjne, ale wielu deweloperów nie chce używać produktów, które są całkowicie nowe, ponieważ okazuje się to wyzwaniem, aby przenieść się między firmami, i ma tendencję do cięcia ich powiązań ze społecznościami, których oczekują.

Z mojego doświadczenia wynika, że pracowałem z takimi produktami w przeszłości i okazało się to wyzwaniem, aby uzyskać kompetentne wsparcie. I jest to ironiczne, biorąc pod uwagę, że takie firmy sprzedają swoje produkty z oczekiwaniem, że wsparcie będzie dostarczane w terminie. Wysłałem wniosek o ściągnięcie do projektu open source, a poprawka została włączona do kompilacji tego samego dnia, ale nie mogę powiedzieć tego samego o żadnym komercyjnym projekcie, z którym pracowałem.

Czy jest coś innego, w co wierzysz, co dotyczy oprogramowania open source, a mianowicie “dostępu do silnych społeczności deweloperów”. Jak duże są niektóre z tych społeczności i co sprawia, że są one tak skuteczne?

Społeczności deweloperów wokół danego produktu open source mogą liczyć setki tysięcy osób. Wskaźniki adopcji nie wskazują koniecznie na siłę społeczności, ale są dobrym wskaźnikiem tego, że tak jest, ponieważ mają tendencję do tworzenia pozytywnych cykli. Uważam, że społeczności są silne, gdy produkują zdrową dyskusję i skuteczną dokumentację, a także gdy aktywny rozwój ma miejsce.

Gdy architekt lub starszy deweloper przechodzi przez proces wyboru, które produkty mają zostać zintegrowane z tym, co budują, wiele czynników zwykle gra rolę, nie tylko samego produktu i społeczności, ale także zespołów deweloperskich, które będą je przyjmować, czy są one dobrym dopasowaniem do ekosystemu, jaki jest rozwijany, jaki wygląda plan drogi, a w niektórych przypadkach, czy można znaleźć komercyjne wsparcie, jeśli jest to potrzebne. Jednak wiele z tych aspektów jest pomijanych w przypadku braku silnych społeczności deweloperów.

Przeczytałeś setki książek na swojej stronie internetowej, czy mogłbyś polecić trzy z nich naszym czytelnikom?

W ostatnim czasie czytam bardzo mało książek programistycznych, a chociaż są wyjątki, rzeczywistością jest, że są one zwykle przestarzałe bardzo szybko, a społeczność deweloperów zwykle zapewnia lepsze alternatywy za pośrednictwem forów dyskusyjnych i dokumentacji. Wiele książek, które teraz czytam, jest dostarczanych mi bezpłatnie, albo za pośrednictwem biuletynów technologicznych, do których się zapisuję, albo autorów i publicystów, którzy się ze mną kontaktują, albo tych, które Amazon (AMZN ) mi wysyła. Na przykład Amazon wysłał mi przedwydanie niepoprawionej książki “The Lean Startup” do przeglądu w 2011 roku, wprowadzając mnie w pojęcie MVP, a ostatnio wysłał mi kopię “Julia for Beginners”.

(1) Jedną z książek, którą poleciłem z O’Reilly, jest “In Search of Database Nirvana”. Autor szczegółowo opisuje wyzwania, przed którymi staje silnik zapytań bazy danych, aby obsłużyć obciążenia od OLTP po analitykę, z obciążeniami operacyjnymi i analitycznymi pośrodku. Ta książka może być użyta jako przewodnik do oceny silnika bazy danych lub połączenia silnika zapytań i silnika przechowywania, ukierunkowanego na spełnienie wymagań obciążenia, niezależnie od tego, czy są one transakcyjne, analityczne, czy mieszane. Dodatkowo autorzy pokrywają “kołysankę bazy danych” w ostatnich latach, co jest szczególnie dobrze zrobione.

(2) Chociaż wiele się zmieniło w przestrzeni danych w ciągu ostatnich kilku lat, nowe produkty analityczne są wprowadzane, “Disruptive Analytics” prezentuje podejście do krótkiej historii 50-letniej innowacji w analityce, której nie widziałem gdzie indziej, i omawia dwa rodzaje perturbacji: innowacji perturbacyjnych w łańcuchu wartości analitycznej i perturbacji branży za pomocą innowacji w analityce. Z perspektywy startupów i praktyków analitycznych sukces jest umożliwiony przez perturbację ich branży, ponieważ używanie analityki do różnicowania produktu jest sposobem na stworzenie modelu biznesowego perturbacyjnego lub stworzenie nowych rynków. Z perspektywy inwestowania w technologie analityczne dla swoich organizacji, podejście “czekaj i zobacz” może mieć sens, ponieważ technologie narażone na perturbację są ryzykowne z powodu skróconych okresów użytkowania.

(3) Jedną z najlepszych książek biznesowych, jakie czytałem, jest “The Limits of Strategy” napisana przez współzałożyciela Research Board (nabytego przez Gartner), międzynarodowego think tanku, który bada rozwój świata komputera i jak korporacje powinny się do niego dostosować. Autor przedstawia bardzo szczegółowe notatki z wielu swoich rozmów z liderami biznesu, dostarczając głęboką analizę na przestrzeni całej książki o swoich doświadczeniach z budowaniem (wraz z żoną) grupy klientów, dużych firm, które potrzebowały dostosować swoje strategie do eksplozji świata komputera. Jak skomentowałem w moim przeglądzie, to, co wyróżnia tę książkę spośród innych podobnych, to dwie pozornie przeciwne cechy: szerokość branży i intymność, która jest dostępna tylko za pośrednictwem interakcji twarzą w twarz.

Jesteś Głównym Architektem praktyki danych SPR. Czy mógłbyś opisać, co robi SPR?

SPR to konsulting technologiczny z siedzibą w Chicago, dostarczający projekty technologiczne dla szerokiego zakresu klientów, od przedsiębiorstw z listy Fortune 1000 po lokalne startupy. Budujemy kompleksowe doświadczenia cyfrowe, wykorzystując szeroki zakres możliwości technologicznych, od niestandardowego rozwoju oprogramowania, doświadczenia użytkownika, danych i infrastruktury chmury, po coaching DevOps, testowanie oprogramowania i zarządzanie projektami.

Jakie są Twoje obowiązki w SPR?

Jako Główny Architekt, moim kluczowym obowiązkiem jest napędzanie dostarczania rozwiązań dla klientów, prowadzenie architektury i rozwoju projektów, co często oznacza noszenie innych kapeluszy, takich jak właściciel produktu, ponieważ możliwość relacji z tym, jak produkty są budowane z perspektywy praktycznej, ma duży wpływ na to, jak praca powinna być priorytetem, szczególnie podczas budowy od podstaw. Jestem również wciągany do rozmów z potencjalnymi klientami, gdy potrzebna jest moja ekspertyza, a firma poprosiła mnie o rozpoczęcie serii sesji z innymi architektami w praktyce danych, aby omówić projekty klientów, projekty poboczne i to, co moi koledzy robią, aby być na bieżąco z technologią, podobnie jak to, co robiłem dla poprzedniej firmy konsultingowej, chociaż wewnętrzne spotkania w tej innej firmie obejmowały całą praktykę technologiczną, a nie tylko praktykę danych.

Przez większą część swojej kariery specjalizowałem się w rozwoju oprogramowania open source z wykorzystaniem Javy, wykonując przy tym coraz więcej pracy z danymi. Oprócz tych dwóch specjalizacji wykonuję również to, co moi koledzy i ja nazywamy “praktyczną” lub “pragmatyczną” architekturą przedsiębiorstw, co oznacza wykonywanie zadań architektonicznych w kontekście tego, co ma być zbudowane, i budowanie go, a nie tylko mówienie o tym lub rysowanie diagramów, zdając sobie sprawę, że te inne zadania są również ważne.

Moim zdaniem te trzy specjalizacje nakładają się na siebie i nie są wzajemnie wykluczające. Wyjaśniłem menedżerom w ciągu ostatnich kilku lat, że linia, która została tradycyjnie narysowana przez branżę technologiczną między rozwojem oprogramowania a pracą z danymi, nie jest już dobrze zdefiniowana, częściowo dlatego, że narzędzia między tymi dwoma obszarami zbiegły się, a częściowo dlatego, że w wyniku tego zbieżenia praca z danymi sama w sobie w dużej mierze stała się wysiłkiem rozwoju oprogramowania. Jednak ponieważ praktycy danych tradycyjnie nie mają tła w rozwoju oprogramowania, a vice versa, pomagam zapełnić tę lukę.

Czy jest jakiś interesujący projekt, nad którym obecnie pracujesz z SPR?

Właśnie opublikowałem pierwszy post w serii studium przypadku o platformie danych, którą moja drużyna i ja zaimplementowaliśmy od podstaw w AWS w zeszłym roku dla dyrektora generalnego chicagowskiej globalnej firmy konsultingowej. Ta platforma składa się z potoków danych, jeziora danych, modeli danych kanonicznych, wizualizacji i modeli uczenia maszynowego, które będą wykorzystywane przez departamenty korporacyjne, praktyki i klientów końcowych klienta. Chociaż rdzeń platformy miał być zbudowany przez organizację IT kierowaną przez dyrektora generalnego, celem było to, aby platforma ta była wykorzystywana przez inne organizacje poza IT, aby scentralizować aktywa danych i analizy danych w całej firmie, wykorzystując wspólną architekturę, budując na niej, aby spełnić potrzeby przypadku użycia każdej organizacji.

Jak w przypadku wielu ustanowionych firm, używanie Microsoft Excel było powszechne, a arkusze kalkulacyjne były często rozpowszechniane wewnątrz i między organizacjami, a także między firmą a zewnętrznymi klientami. Dodatkowo jednostki biznesowe i praktyki konsultingowe zostały zdezorganizowane, każda z nich wykorzystywała odrębne procesy i narzędzia. Więc oprócz scentralizowania aktywów danych i analizy danych, kolejnym celem było wdrożenie pojęcia własności danych i umożliwienie udostępniania danych między organizacjami w sposób bezpieczny i spójny.

Czy jest coś innego, co chciałbyś podzielić się na temat oprogramowania open source, SPR lub innego projektu, nad którym pracujesz?

Inny projekt (przeczytaj o tym tutaj i tutaj), który niedawno prowadziłem, obejmował pomyślną implementację Databricks Unified Analytics Platform i migrację wykonywania modeli uczenia maszynowego do niego z Azure HDInsight, dystrybucji Hadoop, dla dyrektora inżynierii danych dużej firmy ubezpieczeniowej.

Wszystkie te przetransferowane modele były przeznaczone do przewidywania poziomu przyjęcia, jaki można oczekiwać dla różnych produktów ubezpieczeniowych, a niektóre z nich zostały wcześniej przeniesione z SAS kilka lat temu, kiedy firma przeszła na korzystanie z HDInsight. Największym wyzwaniem była słaba jakość danych, ale innymi wyzwaniami były brak kompleksowego wersjonowania, wiedza plemienna i niekompletna dokumentacja, a także niedojrzała dokumentacja i wsparcie Databricks w odniesieniu do użycia R w tym czasie (wdrożenie platformy Databricks na platformie Azure zostało udostępnione ogólnie tylko kilka miesięcy przed tym projektem).

Aby rozwiązać te kluczowe wyzwania, jako następstwo naszej pracy wdrożeniowej, zaleciłem automatyzację, konfigurację i wersjonowanie, separację problemów z danymi, dokumentację i potrzebną wyrównanie między ich zespołami danych, platformy i modelowania. Nasza praca przekonała początkowo bardzo sceptycznego Chief Data Scientist, że Databricks jest drogą do podążania, a ich deklarowanym celem po naszym odejściu jest migracja pozostałych modeli do Databricks jak najszybciej.

Był to fascynujący wywiad, dotykający wielu tematów, czuję, że nauczyłem się wiele o oprogramowaniu open source. Czytelnicy, którzy mogą chcieć dowiedzieć się więcej, mogą odwiedzić stronę korporacyjną SPR lub stronę internetową Erik Gfesser.