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 s’est spécialisé dans les données, le développement open source en 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 en utilisant SPSS dans une société de recherche de marché qui est devenue mondiale, et j’ai ensuite incorporé l’utilisation d’un moteur de règles d’entreprise appelé Drools dans les applications que j’ai construites pour les clients, mais la sortie de tout ce travail était essentiellement statique.

J’ai ensuite suivi une formation d’amélioration des processus, au cours de laquelle les instructeurs ont démontré en détail comment ils pouvaient améliorer, grâce à des statistiques et à d’autres méthodes, les processus commerciaux 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 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 d’IA est vraiment une abstraction de niveau supérieur construite sur sa couche de services ML. Alors que certaines des vantardises autour de l’apprentissage automatique sont irréalistes, il offre des capacités puissantes du point de vue des développeurs, à condition que ces mêmes praticiens reconnaissent le fait que la valeur que l’apprentissage automatique offre n’est que aussi bonne que les données traitées par lui.

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 à des 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 mis librement à disposition.

De plus, les développeurs qui utilisent ce code source peuvent le modifier pour leur propre usage, et si des changements suggérés sont approuvés, les rendre disponibles à d’autres développeurs qui l’utilisent. En fait, le mouvement derrière le logiciel open source a commencé parce que les développeurs attendaient longtemps que les sociétés commerciales fassent des changements dans les 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 commercialisé tire parti de ces avantages, la réalité étant que de nombreux produits modernes utilisent de l’open source sous le capot, même si les variantes commerciales de ces 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 de notre décision d’utiliser ces produits open source était qu’ils offraient 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’avoir besoin de plus de licences, en raison des coûts impliqués.

Au fil du temps, j’ai vu les offres open source continuer à évoluer, apportant 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 va toujours fort 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 proposées, 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 fil du temps. Les composants construits pour cette plate-forme ne devraient pas être considérés comme 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 minimalemment viable avant d’ajouter des cloches et des sifflets inutiles, qui incluent parfois même la configuration. Commencez par ce qui est fonctionnel, assurez-vous de le comprendre, puis évoluez-le. Ne gaspillez pas de temps et d’argent à construire ce qui a peu de chances d’être utilisé, mais faites un effort pour devancer 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 plus ancien que j’ai construit 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 client m’a expliqué qu’une des raisons pour lesquelles il m’avait fait venir é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.

Je me suis rendu compte que ces guerres de territoire étaient largement associées aux données appartenant au client, à ses filiales et à ses clients externes, donc dans ce cas, l’ensemble du backlog de 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 des 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 sont fixé pour objectif, 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 fondation d’un MVP devrait idéalement être construite sur des prototypes présentant une certaine stabilité afin que les développeurs puissent continuer à les faire évoluer.

Alors que vous examiniez le livre ‘Machine Learning at Enterprise Scale’ vous avez déclaré que ‘l’utilisation de produits open source, de frameworks et de langages 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 sociétés ont besoin mais ne réalisent pas immédiatement au début’. Pourriez-vous entrer dans les détails de pourquoi vous croyez que les sociétés qui utilisent l’open source sont plus agiles ?

De nombreux produits de données commerciaux utilisent des composants open source clés sous le capot, et permettent aux développeurs d’utiliser des langages de programmation populaires tels que Python. Les sociétés qui construisent ces produits savent que les composants open source qu’ils ont choisis d’incorporer leur donnent un avantage 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 commerciaux disponibles qui consistent principalement en des sources fermées, ou même en des sources open source qui sont largement utilisées uniquement par des produits commerciaux spécifiques, nécessitent souvent une formation par ces fournisseurs, ou des licences pour utiliser le logiciel.

De plus, la documentation pour ces composants n’est généralement pas mise à disposition publiquement, forçant la dépendance continue des développeurs à l’égard de ces sociétés. 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 sociétés commerciales pour faire leur travail.

De plus, parce que des composants tels qu’Apache Spark sont largement acceptés comme outils de référence de l’industrie, le code peut également être plus facilement migré entre les implémentations commerciales de ces produits. Les sociétés 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 à passer d’une société à l’autre, et tend à couper leurs liens avec les solides communautés auxquelles ils sont habitués.

Sur la base de mon expérience personnelle, j’ai travaillé avec de tels produits dans le passé, et il peut être difficile d’obtenir un support compétent. Et c’est ironique, étant donné que ces sociétés 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 d’extraction à 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 aucun projet commercial avec lequel j’ai travaillé.

Quelque chose d’autre que vous croyez à propos de l’open source, c’est qu’il conduit à ‘l’accès à de solides communautés de développeurs’. Quelle est la taille 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 fortes lorsqu’elles produisent des discussions saines et une documentation efficace, et lorsqu’un développement actif a lieu.

Lorsqu’un architecte ou un développeur senior travaille sur le processus de choix de quels produits à incorporer dans ce qu’il construit, de nombreux facteurs entrent généralement en jeu, non seulement sur le produit lui-même et sur l’apparence de la communauté, mais sur les équipes de développement qui adopteront ces produits, sur le fait qu’ils constituent un bon ajustement pour l’écosystème en développement, sur ce à quoi ressemble la feuille de route, et dans certains cas sur la possibilité de trouver un support commercial si cela est nécessaire. Cependant, de nombreux aspects tombent à l’eau 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 même si il y a des exceptions, la réalité est que ceux-ci sont généralement obsolètes très rapidement, et la communauté de développeurs fournit généralement de meilleures alternatives via des forums de discussion et de la documentation. La plupart 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 attachés de presse qui me contactent, soit via ceux que m’envoie Amazon.

(1) Un livre de O’Reilly que j’ai recommandé est À la recherche du nirvana des bases de données. L’auteur couvre en détail les défis pour un moteur de requête de base de données pour prendre en charge des charges de travail allant de l’OLTP d’un côté à l’analyse de l’autre, avec des charges de travail opérationnelles et d’intelligence commerciale 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 un mélange 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) Alors que beaucoup de choses ont changé dans l’espace des données au cours des dernières années, puisque de nouveaux produits d’analyse de données continuent d’être introduits, Disruptive Analytics présente une approche historique abordable 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 au sein de 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 en perturbant leurs industries, car l’utilisation de l’analyse pour différencier un produit est un moyen de créer un modèle d’entreprise 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’aie lus est Les limites de la stratégie, 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 sociétés doivent s’adapter. L’auteur présente des notes très détaillées de nombreuses conversations avec des dirigeants d’entreprise, fournissant une analyse perspicace tout au long de ses expériences de construction (avec son épouse) d’un groupe de clients, de grandes sociétés qui avaient besoin de faire coïncider leurs stratégies avec le monde explosif de l’informatique. Comme je l’ai commenté dans ma critique, 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 réalise 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 du développement 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 se rapporter à la manière dont les produits sont construits d’un point de vue pratique pèse lourdement en ce qui concerne 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 continue de sessions avec d’autres 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 précédente, bien que les réunions internes, pour ainsi dire, pour cette autre société impliquaient l’ensemble de la pratique technologique, et non spécifiquement le travail de 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 nombre croissant de travaux de données au fil du chemin. En plus de ces deux spécialisations, je fais également ce que mes collègues et moi appelons “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 en fait construire. En réalisant que ces trois spécialisations se chevauchent les unes les autres et ne sont pas mutuellement exclusives. J’ai expliqué à des dirigeants ces 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 largement devenu un effort de développement de logiciels. Cependant, puisque les praticiens de données traditionnels n’ont généralement pas de formation en développement de logiciels, et vice versa, j’aide à combler ce fossé.

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

Tout récemment, j’ai publié le premier article d’une série d’études de cas en plusieurs parties sur la plate-forme de données que mon équipe et moi avons mise en œuvre dans AWS à 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 de la société. Alors que la plate-forme principale devait être construite par l’organisation IT de la société gérée par le 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 l’analyse 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 sociétés établies, l’utilisation de Microsoft Excel était courante, avec des feuilles de calcul distribuées à 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 étaient devenues cloisonnées, chacune utilisant des processus et des outils disparates. Donc, en plus de la centralisation des actifs de données et de l’analyse 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 à propos de l’open source, de SPR ou d’un autre projet sur lequel vous travaillez ?

Un autre projet (en savoir plus ici et ici) que j’ai récemment dirigé 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 de Azure HDInsight, une distribution Hadoop, vers celle-ci, pour le directeur de l’ingénierie des données d’un grand assureur.

Tous ces modèles migrés étaient destinés à prédire le niveau d’adoption des consommateurs qui peut être attendu pour divers produits d’assurance, certains ayant été migrés de SAS il y a quelques années, lorsque la société est passée à l’utilisation de HDInsight. Le plus grand défi était la mauvaise qualité des données, mais d’autres défis incluaient l’absence d’une version complète, des connaissances tribales et une documentation incomplète, ainsi que la documentation et le support immatures de Databricks en ce qui concerne l’utilisation de R à l’époque (la mise en œuvre d’Azure de Databricks venait de être rendue généralement disponible quelques mois seulement avant 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 de la version, de la séparation des préoccupations liées aux 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 de la data science 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 touché à de nombreux sujets, je me sens comme ayant appris beaucoup sur l’open source. Les lecteurs qui souhaitent en savoir plus peuvent visiter le site Web corporatif SPR ou le site Web d’Erik Gfesser.