Erik Gfesser, Architecte principal pour la pratique des données de SPR – Série d’entretiens

Erik a rejoint la pratique des données du groupe de technologie émergente de SPR en tant qu’architecte principal en 2018.

Erik est devenu spécialisé dans les données, le développement open source utilisant Java, et l’architecture d’entreprise pratique, notamment la construction de preuves de concept, de prototypes et de MVP.

Qu’est-ce qui vous a initialement attiré vers l’apprentissage automatique ?

C’est sa capacité à permettre aux applications d’apprendre en continu. J’avais commencé ma carrière de développement en tant qu’analyste de données senior utilisant SPSS dans une firme de recherche de marché mondiale, et j’ai ensuite incorporé l’utilisation d’un moteur de règles métier appelé Drools dans les applications que j’ai construites pour les clients, mais la sortie de tout ce travail était essentiellement statique.

Plus tard, j’ai travaillé sur l’amélioration des processus, au cours de laquelle les instructeurs ont démontré en détail comment ils pouvaient améliorer, grâce à la statistique et à d’autres méthodes, les processus métier utilisés par leurs clients, mais ici encore, la sortie était largement axée sur des points dans le temps. Mon expérience de travail pour améliorer un produit de soins de santé que mes collègues et moi avons construit pendant la même période est ce qui m’a montré pourquoi l’apprentissage continu est nécessaire pour de tels efforts, mais les ressources disponibles à l’époque n’existaient pas.

Intéressant, mon attrait pour l’apprentissage automatique est revenu à son point de départ, car mon directeur de thèse m’avait mis en garde contre une spécialisation dans ce qui était alors appelé l’intelligence artificielle, en raison de l’hiver de l’IA à l’époque. J’ai choisi de faire usage de termes tels que ML car ils comportent moins de connotations, et parce que même AWS reconnaît que sa couche de services IA est vraiment juste une abstraction de niveau supérieur construite sur sa couche de services ML. Alors que certaines des hype ML là-bas sont irréalistes, ils offrent des capacités puissantes du point de vue des développeurs, à condition que ces mêmes praticiens reconnaissent le fait que la valeur que ML fournit n’est aussi bonne que les données traitées par elle.

Vous êtes un grand défenseur de l’open source, pourriez-vous discuter de pourquoi l’open source est si important ?

Un aspect de l’open source que j’ai dû expliquer aux dirigeants au fil des ans est que le principal avantage de l’open source n’est pas que l’utilisation de ce logiciel est disponible sans coût monétaire, mais que le code source est disponible gratuitement.

En outre, les développeurs qui utilisent ce code source peuvent le modifier pour leur propre utilisation, et si des changements suggérés sont approuvés, les rendre disponibles aux autres développeurs qui l’utilisent. En fait, le mouvement derrière le logiciel open source a commencé parce que les développeurs attendaient longuement que les sociétés commerciales apportent des modifications aux produits qu’ils avaient sous licence, donc les développeurs ont pris les choses en main pour écrire des logiciels avec la même fonctionnalité, en les ouvrant pour être améliorés par d’autres développeurs.

L’open source commercialise profite de ces avantages, la réalité étant que de nombreux produits modernes utilisent l’open source en dessous, même si les variantes commerciales de tels logiciels fournissent généralement des composants supplémentaires non disponibles dans une version open source donnée, fournissant des différenciateurs ainsi que du support si cela est nécessaire.

Mes premières expériences avec l’open source ont eu lieu alors que je construisais le produit de soins de santé que j’ai mentionné plus tôt, en utilisant des outils tels qu’Apache Ant, utilisé pour construire des logiciels, et un produit DevOps précoce à l’époque appelé Hudson (la base de code duquel est devenue plus tard Jenkins). La principale raison derrière notre décision d’utiliser ces produits open source était qu’ils fournissaient de meilleures solutions que les alternatives commerciales, ou étaient des solutions innovantes non proposées par les entités commerciales, sans oublier que la licence commerciale de certains des produits que nous avions utilisés était excessivement restrictive, conduisant à une paperasse excessive lorsqu’il s’agissait d’obtenir plus de licences, en raison des coûts impliqués.

Au fil du temps, j’ai vu les offres open source continuer à évoluer, fournissant l’innovation nécessaire. Par exemple, de nombreux problèmes avec lesquels mes collègues et moi avons lutté pour construire ce produit de soins de santé ont été résolus plus tard par un produit open source Java innovant que nous avons commencé à utiliser appelé Spring Framework, qui est toujours solide après plus d’une décennie, l’écosystème duquel s’étend maintenant bien au-delà de certaines des innovations qu’il a initialement fournies, maintenant considérées comme courantes, telles que l’injection de dépendances.

Vous avez utilisé l’open source pour la construction de preuves de concept, de prototypes et de MVP. Pourriez-vous partager votre parcours derrière certains de ces produits ?

Comme je l’ai expliqué dans l’un des principes directeurs que j’ai présentés à un client récent, les constructions pour la plate-forme de données que nous avons construite pour eux devraient continuer à être réalisées de manière itérative au besoin au fil du temps. Les composants construits pour cette plate-forme ne devraient pas être censés rester statiques, car les besoins changent et de nouveaux composants et fonctionnalités de composants seront mis à disposition au fil du temps.

Lors de la construction de la fonctionnalité de la plate-forme, commencez toujours par ce qui est viable au minimum avant d’ajouter des cloches et des sifflets inutiles, qui dans certains cas incluent même la configuration. Commencez par ce qui est fonctionnel, assurez-vous de le comprendre, puis évoluez-le. Ne perdez pas de temps et d’argent à construire ce qui a peu de chances d’être utilisé, mais faites un effort pour anticiper les besoins futurs.

Le MVP que nous avons construit pour ce produit devait expressément être construit de telle sorte que d’autres cas d’utilisation puissent continuer à être construits sur celui-ci, même s’il est livré avec la mise en œuvre d’un seul cas d’utilisation, pour la détection des anomalies de dépenses. Contrairement à ce client, un produit que j’ai construit plus tôt avait une histoire derrière lui avant mon arrivée. Dans ce cas, les parties prenantes débattaient depuis trois ans (!) de la manière dont elles devraient aborder un produit qu’elles cherchaient à construire. Un dirigeant du client m’a expliqué qu’une des raisons pour lesquelles il m’a fait appel était de les aider à dépasser certains de ces débats internes, notamment parce que le produit qu’il cherchait à construire devait satisfaire la hiérarchie des organisations impliquées.

J’ai découvert que ces guerres de territoire étaient en grande partie liées aux données appartenant au client, à ses filiales et à ses clients externes, donc dans ce cas, l’ensemble du backlog du produit tournait autour de la manière dont ces données seraient ingérées, stockées, sécurisées et consommées pour un seul cas d’utilisation générant des réseaux de fournisseurs de soins de santé à la volée pour les analyses de coûts.

Plus tôt dans ma carrière, j’ai compris qu’une qualité architecturale appelée “utilisabilité” n’était pas limitée aux seuls utilisateurs finals, mais également aux développeurs de logiciels eux-mêmes. La raison pour laquelle c’est le cas est que le code qui est écrit doit être utilisable, tout comme les interfaces utilisateur doivent être utilisables par les utilisateurs finals. Pour qu’un produit devienne utilisable, des preuves de concept doivent être construites pour démontrer que les développeurs seront en mesure de faire ce qu’ils se proposent de faire, notamment en ce qui concerne les choix de technologie spécifiques qu’ils font. Mais les preuves de concept ne sont que le début, car les produits sont meilleurs lorsqu’ils évoluent au fil du temps. À mon avis, la base d’un MVP devrait idéalement être construite sur des prototypes présentant une certaine stabilité afin que les développeurs puissent continuer à l’évoluer.

Alors que vous examiniez le livre “Machine Learning at Enterprise Scale”, vous avez déclaré que “l’utilisation de produits, de cadres et de langages open source aux côtés d’une architecture agile composée d’un mélange de composants open source et commerciaux fournit l’agilité que de nombreuses entreprises ont besoin mais ne réalisent pas immédiatement au départ”. Pourriez-vous entrer dans les détails de pourquoi vous croyez que les entreprises qui utilisent l’open source sont plus agiles ?

De nombreux produits de données commerciaux utilisent des composants open source clés en dessous, et permettent aux développeurs d’utiliser des langages de programmation populaires tels que Python. Les entreprises qui construisent ces produits savent que les composants open source qu’ils ont choisis d’incorporer leur donnent un coup de pouce lorsqu’ils sont déjà largement utilisés par la communauté.

Les composants open source avec des communautés solides sont plus faciles à vendre, en raison de la familiarité qu’ils apportent. Les produits disponibles commercialement qui consistent principalement en du code fermé, ou même en du code open source qui est largement utilisé uniquement par des produits commerciaux spécifiques, nécessitent souvent une formation par ces fournisseurs, ou des licences pour utiliser le logiciel.

En outre, la documentation de tels composants n’est largement pas rendue publiquement disponible, forçant la dépendance continue des développeurs à l’égard de ces entreprises. Lorsque des composants open source largement acceptés tels qu’Apache Spark sont au centre de l’attention, comme avec des produits tels que Databricks Unified Analytics Platform, de nombreux éléments sont déjà disponibles dans la communauté, minimisant les parties sur lesquelles les équipes de développement doivent dépendre des entités commerciales pour faire leur travail.

En outre, parce que des composants tels qu’Apache Spark sont largement acceptés comme des outils standard de l’industrie, le code peut également être plus facilement migré entre les implémentations commerciales de tels produits. Les entreprises seront toujours enclines à incorporer ce qu’elles considèrent comme des différenciateurs concurrentiels, mais de nombreux développeurs ne veulent pas utiliser des produits qui sont complètement nouveaux car cela s’avère difficile à déplacer entre les entreprises, et tend à couper leurs liens avec les solides communautés auxquelles ils sont habitués.

D’après mon expérience personnelle, j’ai travaillé avec de tels produits par le passé, et il peut être difficile d’obtenir un support compétent. Et c’est ironique, étant donné que ces entreprises vendent leurs produits avec l’attente client que le support sera fourni de manière rapide. J’ai eu l’expérience de soumettre une demande de tirage à un projet open source, avec la correction incorporée dans la construction le même jour, mais je ne peux pas en dire autant pour tout projet commercial avec lequel j’ai travaillé.

Quelque chose d’autre que vous croyez sur l’open source est qu’il conduit à “l’accès à de solides communautés de développeurs”. Quelles sont les tailles de certaines de ces communautés et qu’est-ce qui les rend si efficaces ?

Les communautés de développeurs autour d’un produit open source donné peuvent atteindre des centaines de milliers. Les taux d’adoption ne pointent pas nécessairement vers la force de la communauté, mais constituent un bon indicateur que c’est le cas en raison de leur tendance à produire des cycles vertueux. Je considère les communautés comme solides lorsqu’elles produisent des discussions saines et une documentation efficace, et où le développement actif a lieu.

Lorsqu’un architecte ou un développeur senior travaille à travers le processus de choix de quels produits à intégrer dans ce qu’ils construisent, de nombreux facteurs entrent généralement en jeu, non seulement sur le produit lui-même et sur la communauté, mais sur les équipes de développement qui adopteront ces produits, sur le fait qu’ils conviennent à l’écosystème en développement, sur ce à quoi ressemble la feuille de route, et dans certains cas sur la disponibilité d’un support commercial si cela est nécessaire. Cependant, de nombreux aspects sont mis de côté en l’absence de solides communautés de développeurs.

Vous avez examiné des centaines de livres sur votre site Web, y a-t-il trois que vous pourriez recommander à nos lecteurs ?

Ces jours-ci, je lis très peu de livres de programmation, et bien qu’il y ait des exceptions, la réalité est que ceux-ci sont généralement obsolètes très rapidement, et la communauté des développeurs fournit généralement de meilleures alternatives via des forums de discussion et des documentations. Beaucoup des livres que je lis actuellement me sont fournis gratuitement, soit via des newsletters de technologie auxquelles je suis abonné, soit via des auteurs et des éditeurs qui me contactent, soit via ceux que Amazon (AMZN ) m’envoie. Par exemple, Amazon m’a envoyé une preuve de lecture préalable non corrigée de “The Lean Startup” pour ma révision en 2011, me présentant le concept de MVP, et récemment m’a envoyé un exemplaire de “Julia for Beginners”.

(1) Un livre de O’Reilly que j’ai recommandé est “In Search of Database Nirvana”. L’auteur couvre en détail les défis pour un moteur de requête de base de données pour supporter des charges de travail allant de l’OLTP à l’analyse, avec des charges de travail d’intelligence des affaires et opérationnelles au milieu. Ce livre peut être utilisé comme guide pour évaluer un moteur de base de données ou une combinaison de moteurs de requête et de stockage, axé sur la satisfaction des exigences de charge de travail, qu’elles soient transactionnelles, analytiques ou une combinaison des deux. De plus, la couverture de l’auteur du “pendule de base de données” au cours des dernières années est particulièrement bien faite.

(2) Bien que beaucoup de choses aient changé dans l’espace des données au cours des dernières années, depuis que de nouveaux produits d’analyse de données continuent d’être introduits, “Disruptive Analytics” présente une approche historique abordable et courte des 50 dernières années d’innovation dans l’analyse que je n’ai vu nulle part ailleurs, et discute de deux types de disruption : l’innovation perturbatrice dans la chaîne de valeur de l’analyse, et la perturbation de l’industrie par les innovations dans l’analyse. Du point de vue des startups et des praticiens de l’analyse, le succès est rendu possible par la perturbation de leurs industries, car l’utilisation de l’analyse pour différencier un produit est un moyen de créer un modèle d’affaires perturbateur ou de créer de nouveaux marchés. Du point de vue de l’investissement dans la technologie d’analyse pour leurs organisations, adopter une approche d’attente peut avoir du sens car les technologies à risque de perturbation sont des investissements risqués en raison de leur durée de vie utile abrégée.

(3) L’un des meilleurs textes commerciaux de technologie que j’ai lus est “The Limits of Strategy”, d’un co-fondateur de Research Board (acquis par Gartner), un think tank international qui étudie les développements dans le monde de l’informatique et la manière dont les entreprises devraient s’adapter. L’auteur présente des notes très détaillées de nombreuses de ses conversations avec des dirigeants d’entreprise, fournissant une analyse perspicace tout au long de ses expériences de construction (avec sa femme) d’un groupe de clients, de grandes entreprises qui avaient besoin de faire correspondre leurs stratégies avec le monde explosif de l’informatique. Comme je l’ai commenté dans ma révision, ce qui distingue ce livre d’autres efforts liés est deux caractéristiques apparemment opposées : la largeur de l’industrie et l’intimité qui n’est disponible que par interaction face à-face.

Vous êtes l’architecte principal pour la pratique des données de SPR. Pourriez-vous décrire ce que fait SPR ?

SPR est une société de conseil en technologie numérique basée dans la région de Chicago, qui livre des projets de technologie pour une gamme de clients, allant des entreprises du Fortune 1000 aux startups locales. Nous construisons des expériences numériques de bout en bout en utilisant une gamme de capacités technologiques, allant de la conception de logiciels personnalisés, de l’expérience utilisateur, des données et de l’infrastructure cloud, au coaching DevOps, aux tests de logiciels et à la gestion de projet.

Quelles sont certaines de vos responsabilités avec SPR ?

En tant qu’architecte principal, ma responsabilité principale est de conduire la livraison de solutions pour les clients, en dirigeant l’architecture et le développement pour les projets, et cela signifie souvent porter d’autres chapeaux tels que propriétaire de produit car être capable de comprendre comment les produits sont construits d’un point de vue pratique pèse lourdement dans la manière dont le travail devrait être priorisé, notamment lors de la construction à partir de zéro. Je suis également sollicité pour des discussions avec des clients potentiels lorsque mon expertise est nécessaire, et la société m’a récemment demandé de commencer une série de sessions continues avec les architectes de la pratique des données pour discuter des projets des clients, des projets parallèles et de ce que mes collègues font pour rester à jour avec la technologie, similaire à ce que j’avais dirigé pour une société de conseil antérieure, bien que les réunions internes, pour ainsi dire, pour cette autre société impliquaient leur pratique technologique entière, et non spécifique à la pratique des données.

Pour la majeure partie de ma carrière, j’ai spécialisé dans le développement open source en utilisant Java, effectuant un travail de données de plus en plus important au fil du chemin. En plus de ces deux spécialisations, j’ai également fait ce que mes collègues et moi avons appelé “pratique” ou “pragmatique” l’architecture d’entreprise, ce qui signifie effectuer des tâches d’architecture dans le contexte de ce qui est construit, et réellement le construire, plutôt que de simplement en parler ou de dessiner des diagrammes à ce sujet, en réalisant bien sûr que ces autres tâches sont également importantes.

À mon avis, ces trois spécialisations se chevauchent et ne sont pas mutuellement exclusives. J’ai expliqué à des dirigeants au cours des dernières années que la ligne qui avait été traditionnellement tracée par l’industrie technologique entre le développement de logiciels et le travail de données n’est plus bien définie, en partie parce que l’outillage entre ces deux espaces a convergé, et en partie parce que, à la suite de cette convergence, le travail de données lui-même est devenu en grande partie un effort de développement de logiciels. Cependant, puisque les praticiens de données traditionnels n’ont généralement pas de background en développement de logiciels, et vice versa, j’aide à combler cet écart.

Y a-t-il un projet intéressant sur lequel vous travaillez actuellement avec SPR ?

Récemment, j’ai publié le premier article d’une série d’études de cas sur la plate-forme de données que mon équipe et moi avons mise en œuvre à partir de zéro l’année dernière pour le CIO d’une société de conseil mondiale basée à Chicago. Cette plate-forme se compose de pipelines de données, d’un lac de données, de modèles de données canoniques, de visualisations et de modèles d’apprentissage automatique, destinés à être utilisés par les départements, les pratiques et les clients finals du client. Alors que la plate-forme principale devait être construite par l’organisation IT du CIO, l’objectif était que cette plate-forme serait utilisée par d’autres organisations en dehors de l’IT pour centraliser les actifs de données et les analyses de données à travers l’entreprise en utilisant une architecture commune, en construisant dessus pour répondre aux besoins de cas d’utilisation de chaque organisation.

Comme pour de nombreuses entreprises établies, l’utilisation de Microsoft Excel était courante, avec des feuilles de calcul réparties à l’intérieur et entre les organisations, ainsi qu’entre la société et les clients externes. De plus, les unités commerciales et les pratiques de conseil sont devenues cloisonnées, chacune utilisant des processus et des outils différents. Donc, en plus de la centralisation des actifs de données et des analyses de données, un autre objectif était de mettre en œuvre le concept de propriété des données et de permettre le partage de données entre les organisations de manière sécurisée et cohérente.

Y a-t-il autre chose que vous aimeriez partager sur l’open source, SPR ou un autre projet sur lequel vous travaillez ?

Un autre projet (lisez-en plus ici et ici) que j’ai récemment mené à bien a consisté à mettre en œuvre avec succès la plate-forme d’analyse unifiée Databricks, et à migrer l’exécution de modèles d’apprentissage automatique vers celle-ci à partir d’Azure HDInsight, une distribution Hadoop, pour le directeur de l’ingénierie des données d’une grande société d’assurance.

Tous ces modèles migrés étaient destinés à prédire le niveau d’adoption que l’on pouvait attendre pour divers produits d’assurance, certains ayant été migrés de SAS il y a quelques années, au moment où la société a commencé à utiliser HDInsight. Le plus grand défi était la mauvaise qualité des données, mais d’autres défis incluaient le manque de versionnage complet, les connaissances tribales et la documentation incomplète, ainsi que la documentation et le support de Databricks immatures par rapport à l’utilisation de R au moment de ce projet.

Pour relever ces défis clés, à la suite de notre travail de mise en œuvre, j’ai fait des recommandations autour de l’automatisation, de la configuration et du versionnage, de la séparation des préoccupations de données, de la documentation et de l’alignement nécessaire entre leurs équipes de données, de plate-forme et de modélisation. Notre travail a convaincu un chef des données scientifiques initialement très sceptique que Databricks est la voie à suivre, avec pour objectif déclaré après notre départ de migrer leurs modèles restants vers Databricks le plus rapidement possible.

Ceci a été un entretien fascinant qui a abordé de nombreux sujets, je me sens comme si j’avais appris beaucoup sur l’open source. Les lecteurs qui souhaitent en savoir plus peuvent visiter le site Web corporatif de SPR ou le site Web d’Erik Gfesser.