Penso che i ruoli siano una stretta sovrapposizione - e in termini di competenze individuali e background sono quasi identici. Infatti molti ingegneri dei dati che conosco sono o sono stati anche ingegneri del software.
Alcuni set di competenze comuni, anche se esistono certamente delle eccezioni:
- La formazione è ingegneria, informatica, IT
- Linguaggi di programmazione di alto livello (Java, C++, PHP, JS, Python, ecc.), ETL, linguaggi di dati e piattaforme (SQL, HiveQL, MongoDB, Spark, Kafka, ecc.), linguaggi di calcolo scientifico (SAS, R, Matlab), sviluppo mobile (C#, Swift/Obj-C)
- Networking, interfacce, API (TCP/IP, REST, FTP)
- Cloud, virtualizzazione, container, calcolo distribuito (AWS/Azure/GCP, VMWare, Xen, ecc.)
- Architetture software/dati (n-Tier, MVC, Client-Server, Edge, P2P, ecc.)
E ce ne potrebbero essere altre - a seconda degli strumenti unici e dello stack del cliente o del datore di lavoro.
Penso che la distinzione principale stia nell'obiettivo del ruolo. La cosa importante da considerare è che in entrambi i casi gli ingegneri supportano gli utenti. Gli ingegneri del software supportano gli utenti delle applicazioni, mentre gli ingegneri dei dati supportano la scienza dei dati. Gli ingegneri del software sono richiesti principalmente per le applicazioni - sia desktop, web, mobile - l'intento principale è quello di creare software per uso generale, pubblico o aziendale. Gli ingegneri dei dati sono richiesti principalmente per costruire e mantenere l'infrastruttura dei dati - le applicazioni supportate sono dati-centriche come la Business Intelligence, Advanced Analytics, o Machine Learning.
Entrambi i ruoli sono costruttori - ma i cicli di vita di costruzione sono più diversi che simili. Le build degli ingegneri del software tendono generalmente ad essere più strette - guardando a specifiche release legate al lancio del prodotto o alla manutenzione. Le build degli ingegneri dei dati hanno più variabilità, per esempio possono essere fluide e meno strutturate per supportare l'esplorazione dei dati e la prototipazione della scienza dei dati fino a qualcosa di più rigido come un data warehouse o il rollout di un data lake.
Un'altra cosa da considerare è che questi ruoli potrebbero evolvere l'uno nell'altro. Per esempio, una semplice architettura di scienza dei dati potrebbe improvvisamente essere sviluppata in un'architettura applicativa completa se viene presa la decisione di trasformare un semplice esperimento di scienza dei dati in un'app (ad esempio, trasformare un algoritmo di classificazione geospaziale in un'app per il traffico come Waze o un sistema di prezzi per Uber). A questo punto gli ingegneri dei dati coinvolti nell'esperimento originale possono diventare parte del nuovo team di ingegneria del software. E viceversa, un'applicazione pubblica/utente può essere trasformata in una fonte di dati per un'indagine di scienza dei dati - a questo punto il database dell'applicazione originale può essere portato in un'architettura di dati per analisi future. In questo caso, gli ingegneri software originali potrebbero essere presi per far parte del team di ingegneria dei dati per il nuovo progetto.
Penso che l'ingegneria dei dati sia diventata un termine riconoscibile più recentemente a causa della richiesta di scienza dei dati. Questo può essere solo un bene per gli ingegneri del software in generale, dato che permette più percorsi di carriera dentro e fuori lo sviluppo generale del software.