Je pense que les rôles se chevauchent étroitement - et en termes de compétences et de parcours individuels, ils sont presque identiques. En fait, de nombreux ingénieurs de données que je connais sont ou ont également été des ingénieurs logiciels.
Certains ensembles de compétences communs, bien que des exceptions existent certainement :
- L'éducation est l'ingénierie, l'informatique, l'IT
- Les langages de programmation de haut niveau (Java, C++, PHP, JS, Python, etc.), ETL, les langages de données et de plate-forme (SQL, HiveQL, MongoDB, Spark, Kafka, etc.), langages de calcul scientifique (SAS, R, Matlab), développement mobile (C#, Swift/Obj-C)
- Réseau, interfaces, API (TCP/IP, REST, FTP)
- Cloud, virtualisation, conteneurs, informatique distribuée (AWS/Azure/GCP, VMWare, Xen, etc.)
- Architectures logicielles/données (n-Tier, MVC, client-serveur, Edge, P2P, etc.)
Et il pourrait y en avoir d'autres - en fonction des outils et de la pile uniques du client ou de l'employeur.
Je pense que la principale distinction réside dans l'objectif du rôle. Une chose importante à considérer est que dans les deux cas, les ingénieurs soutiennent les utilisateurs. Les ingénieurs logiciels soutiennent les utilisateurs d'applications tandis que les ingénieurs de données soutiennent la science des données. Les ingénieurs logiciels sont principalement requis pour les applications - qu'elles soient de bureau, web, mobiles - l'intention principale est de créer des logiciels pour une utilisation générale, publique ou d'entreprise. Les ingénieurs de données sont principalement requis pour construire et maintenir l'infrastructure de données - les applications prises en charge sont centrées sur les données, telles que la veille économique, l'analyse avancée ou l'apprentissage automatique.
Les deux rôles sont des constructeurs - mais les cycles de vie de construction sont plus différents que similaires. Les builds des ingénieurs logiciels ont généralement tendance à être plus serrés - en regardant des versions spécifiques liées aux lancements de produits ou à la maintenance. Les builds des ingénieurs en données ont plus de variabilité par exemple, il peut être fluide et moins structuré pour soutenir l'exploration des données et le prototypage de la science des données à quelque chose de plus rigide comme un entrepôt de données ou le déploiement d'un lac de données.
Une autre chose à considérer est que ces rôles pourraient évoluer l'un vers l'autre. Par exemple, une architecture de science des données simple pourrait soudainement être développée en une architecture d'application à part entière si la décision est prise de transformer une simple expérience de science des données en une application (par exemple, transformer un algorithme de classement géospatial en une application de trafic comme Waze ou un système de prix de pointe pour Uber). À ce stade, les ingénieurs de données impliqués dans l'expérience initiale peuvent faire partie de la nouvelle équipe d'ingénierie logicielle. Et vice-versa, une application publique/utilisatrice peut être transformée en une source de données pour une enquête de science des données - à ce stade, la base de données de l'application originale peut être portée dans une architecture de données pour une analyse future. Dans ce cas, les ingénieurs logiciels d'origine peut-être mis à contribution pour faire partie de l'équipe d'ingénierie des données pour le nouveau projet.
Je pense que l'ingénierie des données est devenue un terme reconnaissable plus récemment en raison de la demande de science des données. Cela ne peut être que bénéfique pour les ingénieurs logiciels en général, car cela permet d'offrir plus de voies de carrière vers et hors du développement logiciel général.