Erik Gfesser, Principal Architect für die Data-Praxis von SPR – Interview-Serie

Erik trat der Data-Praxis von SPR als Principal Architect im Jahr 2018 bei. Erik spezialisierte sich auf Daten, Open-Source-Entwicklung mit Java und praktische Unternehmensarchitektur, einschließlich dem Bau von PoCs, Prototypen und MVPs. Was hat Sie ursprünglich zum Maschinellen Lernen hingezogen? Seine Fähigkeit, Anwendungen dazu zu bringen, kontinuierlich zu lernen. Ich hatte meine Entwicklungskarriere als Senior-Data-Analyst mit SPSS bei einem globalen Marktforschungsunternehmen begonnen und später die Verwendung einer Business-Regel-Engine namens Drools in Anwendungen integriert, die ich für Kunden erstellt hatte, aber die Ausgabe all dieser Arbeit war im Wesentlichen statisch. Ich habe später an Prozessverbesserungsschulungen teilgenommen, während denen die Dozenten demonstrierten, wie sie Geschäftsprozesse, die von ihren Kunden verwendet wurden, durch Statistiken und andere Methoden verbessern konnten, aber auch hier war die Ausgabe größtenteils auf Punkte in der Zeit fokussiert. Meine Erfahrung bei der Verbesserung eines Healthcare-Produkts, das meine Kollegen und ich während desselben Zeitraums entwickelt hatten, zeigte mir, warum kontinuierliches Lernen für solche Bemühungen notwendig ist, aber die damals verfügbaren Ressourcen existierten nicht. Interessanterweise ist meine Anziehung zum Maschinellen Lernen vollständig, da mein Doktorvater mich vor einer Spezialisierung auf künstliche Intelligenz, wie sie damals genannt wurde, warnte, aufgrund des AI-Winters zu dieser Zeit. Ich entschied mich, stattdessen Begriffe wie ML zu verwenden, da diese weniger Konnotationen haben und weil selbst AWS anerkennt, dass seine KI-Dienste ein höheres Abstraktionsniveau auf seinem ML-Dienste-Level sind. Während einige der ML-Hype unrealistisch sind, bietet es leistungsstarke Fähigkeiten aus der Perspektive der Entwickler, solange diese Praktiker die Tatsache anerkennen, dass der Wert, den ML bietet, nur so gut ist wie die Daten, die von ihm verarbeitet werden.   Sie sind ein großer Open-Source-Befürworter, könnten Sie darüber sprechen, warum Open Source so wichtig ist? Ein Aspekt von Open Source, den ich über die Jahre hinweg gegenüber Managern erklären musste, ist, dass der Hauptvorteil von Open Source nicht darin besteht, dass die Verwendung solcher Software ohne monetäre Kosten zur Verfügung steht, sondern dass der Quellcode frei verfügbar ist. Zusätzlich können Entwickler, die diesen Quellcode verwenden, ihn für ihre eigene Verwendung ändern und wenn vorgeschlagene Änderungen genehmigt werden, diese Änderungen anderen Entwicklern zur Verfügung stellen, die ihn verwenden. Tatsächlich begann die Bewegung hinter Open-Source-Software, weil Entwickler lange auf kommerzielle Unternehmen warteten, um Änderungen an Produkten vorzunehmen, die sie lizenziert hatten, also nahmen sich die Entwickler selbst daran, Software mit ähnlicher Funktionalität zu schreiben und sie anderen Entwicklern zur Verbesserung zur Verfügung zu stellen. Kommerzialisiertes Open Source nutzt diese Vorteile, die Realität ist, dass viele moderne Produkte Open Source unter der Oberfläche verwenden, selbst wenn kommerzielle Varianten solcher Software typischerweise zusätzliche Komponenten bieten, die nicht Teil einer bestimmten Open-Source-Veröffentlichung sind, und somit Differenzierungen sowie Support bieten, wenn dies benötigt wird. Meine ersten Erfahrungen mit Open Source fanden statt, als ich das oben erwähnte Healthcare-Produkt baute, wobei ich Tooling wie Apache Ant verwendete, um Software zu erstellen, und ein frühes DevOps-Produkt namens Hudson (dessen Codebasis später zu Jenkins wurde). Der Hauptgrund für unsere Entscheidung, diese Open-Source-Produkte zu verwenden, war, dass sie entweder bessere Lösungen als kommerzielle Alternativen boten oder innovative Lösungen, die von kommerziellen Unternehmen nicht angeboten wurden, um die Lizenzierung einiger der Produkte, die wir verwendeten, zu erwähnen, die übermäßig restriktiv war und zu übermäßigem Bürokratieaufwand führte, wenn es darum ging, weitere Lizenzen zu benötigen, aufgrund der damit verbundenen Kosten. Im Laufe der Zeit habe ich gesehen, wie Open-Source-Angebote weiterentwickelt wurden und wichtige Innovationen bereitstellten. Zum Beispiel wurden viele der Probleme, mit denen meine Kollegen und ich beim Bau dieses Healthcare-Produkts zu kämpfen hatten, später durch ein innovatives Open-Source-Java-Produkt namens Spring Framework gelöst, das noch nach über einem Jahrzehnt stark ist, und dessen Ökosystem nun weit über einige der Innovationen hinausgeht, die es ursprünglich bereitgestellt hat, die jetzt als gängig angesehen werden, wie z.B. Abhängigkeitsinjektion.   Sie haben Open Source für den Bau von PoCs, Prototypen und MVPs verwendet. Könnten Sie Ihre Reise hinter einigen dieser Produkte teilen? Wie in einem der Leitprinzipien, die ich einem aktuellen Kunden präsentierte, sollten die Ausbauten für die Datenplattform, die wir für sie gebaut haben, weiterhin iterativ durchgeführt werden, wenn dies erforderlich ist. Die Komponenten, die für diese Plattform erstellt werden, sollten nicht als statisch angesehen werden, da sich Bedürfnisse ändern und neue Komponenten und Komponentenfunktionen im Laufe der Zeit verfügbar werden. Wenn Sie die Plattformfunktionalität aufbauen, beginnen Sie immer mit dem, was minimal viable ist, bevor Sie unerforderliche Glöckchen und Pfiff hinzufügen, was in einigen Fällen sogar die Konfiguration umfasst. Beginnen Sie mit dem, was funktional ist, stellen Sie sicher, dass Sie es verstehen, und entwickeln Sie es dann weiter. Verschwenden Sie keine Zeit und Geld damit, zu bauen, was eine geringe Wahrscheinlichkeit hat, verwendet zu werden, aber bemühen Sie sich, zukünftige Bedürfnisse vorwegzunehmen. Das MVP, das wir für dieses Produkt gebaut haben, musste ausdrücklich so gebaut werden, dass zusätzliche Use-Cases darauf aufgebaut werden konnten, obwohl es mit der Implementierung eines einzelnen Use-Cases für die Erkennung von Ausgabenanomalien ausgeliefert wurde. Im Gegensatz dazu hatte ein früheres Produkt, an dem ich gearbeitet hatte, bereits eine Geschichte, bevor ich ankam. In diesem Fall hatten Stakeholder drei Jahre (!) lang debattiert, wie sie ein Produkt angehen sollten, das sie bauen wollten. Ein Client-Executive erklärte, dass einer der Gründe, warum er mich hereingeholt hatte, darin bestand, dem Unternehmen zu helfen, einige dieser internen Debatten zu überwinden, insbesondere weil das Produkt, das er bauen wollte, die Hierarchie der beteiligten Organisationen erfüllen musste. Ich fand heraus, dass diese Revierkämpfe größtenteils mit den Daten verbunden waren, die dem Client, seinen Tochtergesellschaften und externen Kunden gehörten, sodass das gesamte Produkt-Backlog sich um die Frage drehte, wie diese Daten aufgenommen, gespeichert, gesichert und für einen einzelnen Use-Case zur Generierung von Netzwerken von Healthcare-Providern für Kostenanalysen verarbeitet werden sollten. Früher in meiner Karriere erkannte ich, dass eine architektonische Qualität namens “Benutzerfreundlichkeit” nicht nur auf Endbenutzer beschränkt ist, sondern auch auf Software-Entwickler selbst. Der Grund dafür ist, dass der Code, der geschrieben wird, genauso benutzerfreundlich sein muss wie Benutzeroberflächen, die von Endbenutzern benutzerfreundlich sein müssen. Damit ein Produkt benutzerfreundlich wird, müssen Konzepte erstellt werden, um zu demonstrieren, dass Entwickler das tun können, was sie vorhaben, insbesondere im Zusammenhang mit den spezifischen Technologieentscheidungen, die sie treffen. Aber Konzepte sind nur der Anfang, da Produkte am besten sind, wenn sie im Laufe der Zeit weiterentwickelt werden. Meiner Meinung nach sollte die Grundlage für ein MVP idealerweise auf Prototypen aufbauen, die einige Stabilität aufweisen, damit Entwickler sie weiterentwickeln können.   Bei der Überprüfung des Buches “Machine Learning at Enterprise Scale” haben Sie angegeben, dass “die Verwendung von Open-Source-Produkten, -Frameworks und -Sprachen neben einer agilen Architektur, die aus einer Mischung von Open-Source- und kommerziellen Komponenten besteht, die Wendigkeit bietet, die viele Unternehmen benötigen, aber nicht sofort realisieren, wenn sie beginnen”. Könnten Sie einige Details dazu geben, warum Sie glauben, dass Unternehmen, die Open Source verwenden, wendiger sind? Viele kommerzielle Datenprodukte verwenden wichtige Open-Source-Komponenten unter der Oberfläche und ermöglichen es Entwicklern, beliebte Programmiersprachen wie Python zu verwenden. Die Unternehmen, die diese Produkte bauen, wissen, dass die Open-Source-Komponenten, die sie sich ausgesucht haben, um sie zu integrieren, ihnen einen Vorsprung geben, wenn diese bereits von der Community weit verbreitet sind. Open-Source-Komponenten mit starken Gemeinschaften sind einfacher zu verkaufen, aufgrund der Vertrautheit, die sie mit sich bringen. Kommerziell verfügbare Produkte, die hauptsächlich aus Closed-Source bestehen oder sogar Open Source sind, die hauptsächlich von bestimmten kommerziellen Produkten verwendet wird, erfordern entweder Schulungen durch diese Anbieter oder Lizenzen, um die Software zu verwenden. Zusätzlich ist die Dokumentation für solche Komponenten größtenteils nicht öffentlich verfügbar, was die Entwickler dazu zwingt, weiterhin von diesen Unternehmen abhängig zu sein. Wenn weit akzeptierte Open-Source-Komponenten wie Apache Spark im Mittelpunkt stehen, wie bei Produkten wie Databricks Unified Analytics Platform, sind viele dieser Elemente bereits in der Community verfügbar, was den Teil, auf den Entwicklungsteams angewiesen sind, um von kommerziellen Unternehmen abhängig zu sein, minimiert. Darüber hinaus können Komponenten wie Apache Spark, die als De-facto-Branchenstandard-Tooling angesehen werden, auch leichter zwischen kommerziellen Implementierungen solcher Produkte migriert werden. Unternehmen werden immer dazu neigen, das zu integrieren, was sie als Wettbewerbsvorteile betrachten, aber viele Entwickler wollen nicht Produkte verwenden, die völlig neu sind, da dies sich als herausfordernd erweist, zwischen Unternehmen zu wechseln, und tendenziell ihre Bindungen an die starken Gemeinschaften kappen, die sie zu erwarten gelernt haben. Aus persönlicher Erfahrung habe ich mit solchen Produkten in der Vergangenheit gearbeitet und es kann schwierig sein, kompetenten Support zu erhalten. Und das ist ironisch, da solche Unternehmen ihre Produkte mit der Kundenwartung verkaufen, dass Support in angemessener Zeit bereitgestellt wird. Ich habe die Erfahrung gemacht, einen Pull-Request an ein Open-Source-Projekt zu senden, mit dem Fix, der am selben Tag in den Build aufgenommen wurde, aber ich kann das Gleiche nicht über ein kommerzielles Projekt sagen, an dem ich gearbeitet habe.   Etwas anderes, an das Sie glauben, ist, dass Open Source zu “Zugang zu starken Entwicklergemeinschaften” führt. Wie groß sind einige dieser Gemeinschaften und was macht sie so effektiv? Entwicklergemeinschaften um ein bestimmtes Open-Source-Produkt können Hunderttausende umfassen. Die Akzeptanzrate weist nicht unbedingt auf die Stärke der Gemeinschaft hin, ist aber ein guter Indikator dafür, da sie dazu neigt, sich selbst verstärkende Kreise zu erzeugen. Ich betrachte Gemeinschaften als stark, wenn sie gesunde Diskussionen und effektive Dokumentation hervorbringen und wenn aktive Entwicklung stattfindet. Wenn ein Architekt oder ein Senior-Entwickler durch den Prozess geht, um zu entscheiden, welche solchen Produkte in das zu integrieren sind, was sie bauen, kommen viele Faktoren typischerweise ins Spiel, nicht nur über das Produkt selbst und wie die Gemeinschaft aussieht, sondern über die Entwicklungsteams, die diese übernehmen werden, ob diese eine gute Passung für das Ökosystem sind, das entwickelt wird, was die Roadmap aussieht und in einigen Fällen, ob kommerzieller Support zu finden ist, wenn dies benötigt wird. Viele dieser Aspekte fallen jedoch in Abwesenheit starker Entwicklergemeinschaften weg.   Sie haben 100 Bücher auf Ihrer Website überprüft, gibt es drei, die Sie unseren Lesern empfehlen können? Heute lese ich sehr wenige Programmierbücher und während es Ausnahmen gibt, ist die Realität, dass diese typischerweise sehr schnell veraltet sind und die Entwicklergemeinschaft in der Regel bessere Alternativen über Diskussionsforen und Dokumentationen bietet. Viele der Bücher, die ich derzeit lese, werden mir kostenlos zur Verfügung gestellt, entweder durch Technologie-Newslettern, denen ich beitrete, Autoren und Verleger, die mich kontaktieren, oder die Amazon mir sendet. Zum Beispiel hat Amazon mir ein vorab veröffentlichtes unkorrigiertes Beweisexemplar von “The Lean Startup” für meine Überprüfung im Jahr 2011 geschickt und mich mit dem Konzept des MVP vertraut gemacht und hat mir kürzlich ein Exemplar von “Julia for Beginners” geschickt. (1) Ein Buch von O’Reilly, das ich empfohlen habe, ist “In Search of Database Nirvana”. Der Autor deckt detailliert die Herausforderungen ab, denen eine Datenabfrage-Engine gegenübersteht, um Workloads zu unterstützen, die von OLTP auf der einen Seite bis hin zu Analytics auf der anderen Seite reichen, mit operativen und Geschäftsanalyse-Workloads in der Mitte. Dieses Buch kann als Leitfaden verwendet werden, um eine Datenbank-Engine oder eine Kombination von Abfrage- und Speicher-Engines zu bewerten, die auf die Arbeitslastanforderungen ausgerichtet ist, sei es transaktional, analytisch oder eine Mischung aus beidem. Darüber hinaus ist die Abdeckung des Autors des “schwingenden Datenpendels” in den letzten Jahren besonders gut gemacht. (2) Während sich viel im Datenbereich in den letzten Jahren geändert hat, da neue Datenanalyseprodukte weiterhin eingeführt werden, präsentiert “Disruptive Analytics” einen ansprechbaren, kurzen Überblick über die letzten 50 Jahre der Innovation in der Analytik, den ich nicht anderswo gesehen habe und diskutiert zwei Arten von Disruption: disruptiver Innovation innerhalb der Analysewertkette und Branchendisruption durch Innovationen in der Analytik. Aus der Perspektive von Start-ups und Analytik-Praktikern wird Erfolg durch die Disruption ihrer Branchen ermöglicht, da die Verwendung von Analytik zur Differenzierung eines Produkts eine Möglichkeit ist, ein disruptives Geschäftsmodell zu schaffen oder neue Märkte zu schaffen. Aus der Perspektive des Investierens in Analyse-Technologie für ihre Organisationen kann ein abwartender Ansatz sinnvoll sein, da Technologien, die von Disruption bedroht sind, riskant sind, aufgrund ihrer verkürzten Lebensdauer. (3) Einer der besten Technologie-Geschäftstexte, den ich gelesen habe, ist “The Limits of Strategy” von einem Mitbegründer von Research Board (erworben von Gartner), einem internationalen Think-Tank, der Entwicklungen in der Rechenwelt und wie Unternehmen sich anpassen sollten, untersucht. Der Autor präsentiert sehr detaillierte Notizen von vielen seiner Gespräche mit Geschäftsführern und bietet eine insightful Analyse über seine Erfahrungen beim Aufbau (mit seiner Frau) einer Gruppe von Kunden, wichtigen Unternehmen, die ihre Strategien mit der explodierenden Welt der Rechnertechnik verbinden mussten. Wie ich in meiner Überprüfung kommentierte, sind zwei scheinbar entgegengesetzte Merkmale, die dieses Buch von anderen ähnlichen Bemühungen abheben: branchenweite Breite und Intimität, die nur durch direktes Gespräch verfügbar ist.   Sie sind der Principal Architect für die Data-Praxis von SPR. Könnten Sie beschreiben, was SPR tut? SPR ist ein digitales Technologieberatungsunternehmen mit Sitz in der Region Chicago, das Technologieprojekte für eine Reihe von Kunden, von Fortune-1000-Unternehmen bis hin zu lokalen Start-ups, durchführt. Wir bauen End-to-End-Digitalerfahrungen mit einer Reihe von Technologiefähigkeiten, von benutzerdefinierter Softwareentwicklung, Benutzeroberflächen, Daten und Cloud-Infrastruktur bis hin zu DevOps-Coaching, Software-Testen und Projektmanagement.   Was sind einige Ihrer Verantwortungen bei SPR? Als Principal Architect ist meine Hauptverantwortung, die Lösungslieferung für Kunden zu leiten, die Architektur und Entwicklung für Projekte zu leiten, was oft bedeutet, andere Hüte zu tragen, wie z.B. Produktbesitzer, da die Fähigkeit, sich vorzustellen, wie Produkte aus einer hands-on-Perspektive gebaut werden, stark in Bezug auf die Priorisierung der Arbeit wiegt, insbesondere beim Aufbau von Grund auf. Ich werde auch in Diskussionen mit potenziellen Kunden gezogen, wenn meine Expertise benötigt wird und das Unternehmen hat mich kürzlich gebeten, eine laufende Serie von Sitzungen mit meinen Kollegen in der Data-Praxis zu starten, um über Kundenprojekte, Seitenprojekte und was meine Kollegen tun, um auf dem neuesten Stand der Technologie zu bleiben, zu diskutieren, ähnlich wie ich es für ein vorheriges Beratungsunternehmen getan habe, obwohl die internen Meetups sozusagen für dieses andere Unternehmen die gesamte Technologiepraxis umfassten, nicht spezifisch auf Datenarbeit beschränkt. Für den größten Teil meiner Karriere habe ich mich auf Open-Source-Entwicklung mit Java spezialisiert und führe eine zunehmende Menge an Datenarbeit durch. Zusätzlich zu diesen beiden Spezialisierungen mache ich auch, was meine Kollegen und ich “praktische” oder “pragmatische” Unternehmensarchitektur nennen, was bedeutet, Architektaufgaben im Kontext dessen auszuführen, was gebaut wird, und es tatsächlich zu bauen, anstatt nur darüber zu sprechen oder Diagramme darüber zu zeichnen, wobei ich mich natürlich bewusst bin, dass diese anderen Aufgaben auch wichtig sind. Meiner Meinung nach überschneiden sich diese drei Spezialisierungen und sind nicht gegenseitig ausschließend. Ich habe Managern in den letzten Jahren erklärt, dass die Linie, die traditionell von der Technologiebranche zwischen Softwareentwicklung und Datenarbeit gezogen wurde, nicht mehr gut definiert ist, teilweise weil die Tooling zwischen diesen beiden Bereichen konvergiert ist und teilweise weil, als Ergebnis dieser Konvergenz, Datenarbeit selbst größtenteils zu einer Software-Entwicklungsanstrengung geworden ist. Da traditionelle Datenpraktiker jedoch typischerweise keine Software-Entwicklungs-Hintergrund haben und umgekehrt, helfe ich, diese Lücke zu schließen.   Was ist ein interessantes Projekt, an dem Sie derzeit mit SPR arbeiten? Ich habe kürzlich den ersten Beitrag in einer mehrteiligen Fallstudien-Serie über die oben erwähnte Datenplattform veröffentlicht, die mein Team und ich im vergangenen Jahr für den CIO eines in Chicago ansässigen globalen Beratungsunternehmens von Grund auf in AWS implementiert haben. Diese Plattform besteht aus Datenpipelines, Data-Lake, kanonischen Datenmodellen, Visualisierungen und Machine-Learning-Modellen, die von Unternehmensabteilungen, -praktiken und Endkunden des Kunden verwendet werden sollen. Wie bei vielen etablierten Unternehmen war die Verwendung von Microsoft Excel weit verbreitet, wobei Tabellenblätter innerhalb von Organisationen und zwischen dem Unternehmen und externen Kunden verteilt wurden. Darüber hinaus waren Geschäftseinheiten und Beratungspraktiken in sich abgeschlossen und nutzten unterschiedliche Prozesse und Tooling. Daher bestand neben der Zentralisierung von Datenvermögen und Datenanalyse ein weiteres Ziel darin, das Konzept des Datenbesitzes umzusetzen und die Weitergabe von Daten zwischen Organisationen auf sichere und konsistente Weise zu ermöglichen.   Gibt es noch etwas, das Sie über Open Source, SPR oder ein anderes Projekt, an dem Sie arbeiten, teilen möchten? Ein weiteres Projekt (lesen Sie darüber hier und hier), das ich kürzlich geleitet habe, umfasste die erfolgreiche Implementierung der Databricks Unified Analytics Platform und die Migration der Ausführung von Machine-Learning-Modellen von Azure HDInsight, einer Hadoop-Verteilung, auf diese Plattform für den Leiter der Daten-Engineering-Abteilung eines großen Versicherungsunternehmens. Alle diese migrierten Modelle sollten die erwartete Verbrauchernachfrage für verschiedene Versicherungsprodukte vorhersagen, von denen einige Jahre zuvor von SAS migriert worden waren, als das Unternehmen zu HDInsight wechselte. Die größte Herausforderung bestand in der schlechten Datenqualität, aber andere Herausforderungen umfassten das Fehlen einer umfassenden Versionierung, Stammwissen und unvollständige Dokumentation sowie unreife Databricks-Dokumentation und -Support in Bezug auf die Verwendung von R zu diesem Zeitpunkt (die Azure-Implementierung von Databricks war nur wenige Monate vor diesem Projekt allgemein verfügbar geworden). Um diese wichtigsten Herausforderungen anzugehen, habe ich im Anschluss an unsere Implementierungsarbeiten Empfehlungen zu Automatisierung, Konfiguration und Versionierung, Trennung von Datenbedenken, Dokumentation und erforderlicher Ausrichtung zwischen ihren Daten-, Plattform- und Modellierungsteams gegeben. Unsere Arbeit überzeugte einen anfänglich sehr skeptischen Chief Data Scientist davon, dass Databricks der Weg ist, den man gehen sollte, mit dem erklärten Ziel, nach unserem Abgang die restlichen Modelle so schnell wie möglich zu Databricks zu migrieren. Dieses Interview war faszinierend und hat viele Themen berührt, ich denke, ich habe viel über Open Source gelernt. Leser, die mehr erfahren möchten, können die SPR-Unternehmenswebsite oder die Website von Erik Gfesser besuchen.