1. Introduci la tua esperienza professionale dall’università fino all’ingresso in ORBYTA.

Ho iniziato la mia carriera lavorativa all’età di 20 anni in amministrazione e contabilità. Grazie alla giovane età, la curiosità e la voglia di imparare mi hanno spinta a mettermi sempre in gioco e posso dire che, a distanza di 10 anni ho maturato molta esperienza e padronanza nella materia.
Dal 2012 ad oggi, ho fatto tantissima strada ed il mio percorso mi ha portato ad entrare in Orbyta a gennaio 2020. Da allora sono passati 2 anni ed io sono sempre più convinta della mia scelta!

2. Di cosa ti occupi e che valore porti all’azienda?

Oggi in Orbyta ricopro il ruolo di responsabile dell’ufficio Finance & Administration. Siamo un team di tre persone che lavorano con energia ed entusiasmo raggiungendo gli obiettivi prefissati in modo efficace. Sono convinta che la mia crescita professionale sia frutto non solo del raggiungimento degli obiettivi lavorativi ma anche della mia attitudine al lavoro in team che mi porta a cercare sempre un confronto con le colleghe e con gli altri uffici trasmettendo loro la mia passione (e chissà magari qualche conoscenza).

3. Perché ti piace lavorare in ORBYTA?

Sono una persona molto socievole, amo le sfide e mi piace lavorare in un’ ambiente così giovane e dinamico. La nostra crescita professionale viene promossa e valorizzata perché in Orbyta condividiamo un progetto, abbiamo una visione comune e questo porta alla costante crescita di tutto il gruppo senza distaccare mai lo sguardo dal singolo.

#jointherevolution

1. Introduci la tua esperienza professionale dall’università fino all’ingresso in ORBYTA.

Subito dopo aver conseguito a pieni voti la laurea specialistica in Economia e Direzione delle Imprese, ho iniziato il mio percorso lavorativo nel mondo della consulenza aziendale, operando per alcune tra le più importanti aziende multinazionali d’Italia tra cui Ferrero, Stellantis (ex FCA), Magneti Marelli ed Enel.

Durante i primi otto anni di carriera ho avuto la fortuna di viaggiare molto in Italia e all’estero, e di collaborare con persone che mi hanno insegnato molto, sia a livello professionale che umano. Conservo, tra gli altri, splendidi ricordi del mio ultimo viaggio in Sud Africa, durante il quale ho avuto il piacere di occuparmi del go-live di un sistema gestionale, ma soprattutto di conoscere un Paese stupendo dalle mille sfaccettature accompagnata dalle persone del posto, cosa che difficilmente avrei potuto fare da semplice turista.

Nel 2016 divento mamma di Luca e nel 2018 colgo l’opportunità di entrare in Orbyta per occuparmi di Project Management in ambito bancario, un settore che ancora non avevo avuto modo di conoscere.

2. Di cosa ti occupi e che valore porti all’azienda?

Attualmente ricopro il ruolo di Product Manager presso Axerve, leader nel settore dei pagamenti e-commerce e parte del gruppo Sella.

Ad oggi lavoro ad un progetto sfidante con l’obiettivo di offrire sempre maggiore innovazione ai clienti del settore e-commerce, e mi impegno ogni giorno per supportare al meglio i colleghi con precisione ed entusiasmo.

3. Perché ti piace lavorare in ORBYTA?

In Orbyta, in un contesto fortemente dinamico ed in continua crescita, ho da subito percepito il valore che viene attribuito alle persone in quanto tali. Qualsiasi sia la tematica da affrontare, si può esser certi che si troverà chi saprà ascoltare ed aiutare al meglio. E poi, come non parlare del forte spirito di gruppo e di appartenenza creato dagli eventi e dalle iniziative di team building? Unici.

#jointherevolution

1. Introduci la tua esperienza professionale dall’università fino all’ingresso in ORBYTA.

Da sempre interessata al mondo delle risorse umane, ho conseguito la laurea magistrale in Psicologia del Lavoro e del Benessere nelle Organizzazioni presso l’Università degli Studi di Torino. 

Ho iniziato le mie esperienze lavorative durante il percorso universitario occupandomi del reclutamento e della selezione di personale tecnico-informatico presso un’azienda operante nel settore ICT. Al fine di ampliare le mie competenze e conoscenze, ho voluto svolgere il tirocinio professionalizzante post-lauream nell’ambito della formazione aziendale per poi proseguire la mia crescita professionale in un contesto innovativo e stimolante: a gennaio 2020 è iniziata la mia avventura in ORBYTA!


2. Di cosa ti occupi e che valore porti all’azienda?


Ad oggi faccio parte del team Business Development e ricopro il ruolo di Talent Acquisition & Business Support per le BU Data Analytics e Business Consulting. Nello specifico, mi occupo della ricerca e della selezione di profili ICT ed Engineering per progettualità interne o per opportunità su realtà clienti, del supporto a 360° ai Business Lead e ai Tech Lead con un focus sul monitoraggio e l’aggiornamento degli strumenti aziendali. 

Nel corso degli anni, ho potuto sviluppare competenze di settore e trasversali che mi hanno permesso di raggiungere gli obiettivi prefissati e collaborare in maniera efficace con i diversi team di lavoro. Il mio impegno quotidiano è quello di portare in ORBYTA l’entusiasmo, la precisione e la dedizione per supportare al meglio le attività aziendali.


3. Perché ti piace lavorare in 
ORBYTA?

Appassionata di innovazione digitale e sviluppo tecnologico, entrare a far parte di una realtà dinamica, giovane e smart come ORBYTA mi ha dato la possibilità di mettermi alla prova, di sperimentare e di imparare ogni giorno qualcosa di nuovo. Il confronto con colleghi competenti, disponibili e appassionati è prezioso così come lo sono le attività quotidiane di cui si è pienamente responsabilizzati. 

Gli Orbyters sono il motore dell’azienda, ognuno con le proprie competenze e peculiarità, ognuno con il proprio valore aggiunto. 

#jointherevolution

Introduzione

Molti di voi probabilmente conosceranno già il concetto di database a grafo, un’alternativa al classico modello di database relazionale che risulta particolarmente efficiente quando si ha a che fare con delle relazioni complesse, mutevoli e gerarchicamente strutturate tra le entità, come potrebbero essere i dati tipici di un social media. L’aspetto forse un po’ meno noto è che anche Management Studio, dalla sua versione del 2017, supporta la creazione di un DB a grafo completamente integrato nel SQL Engine, nonostante da tempo già ci fossero delle soluzioni che in qualche modo cercavano mimarne il comportamento, come le CTE ricorsive o il tipo HierarchyId.

In un DB relazionale abbiamo righe, tabelle, chiavi esterne e relazioni, mentre le entità tipiche del DB a grafo sono note come nodi (nodes) e archi (edges). Mentre i nodi non sono dissimili dal concetto di tabella come la potremmo incontrare in un normale DB, l’entità più interessante sono proprio gli archi, delle specie di relazioni “arricchite” che definiscono il rapporto tra i nodi e che sono contraddistinte a loro volta da attributi e proprietà. Per usare una definizione intuitiva, anche se non troppo precisa, possiamo considerare i nodi come “oggetti” (prodotti, luoghi, clienti etc.), e gli archi come “azioni” (vive a, comprato a, lavora per).

Ecco un esempio di DB a grafo molto semplice ma che rende già l’idea

La peculiarità del DB a grafo è proprio la possibilità di associare degli attributi direttamente alla relazione (cioè all’arco), che in questo modo supera il suo semplice compito di mettere in rapporto una tabella con un’altra, diventando dato essa stessa. Sfruttando questa struttura possiamo scrivere delle query dall’aspetto molto sintetico, che utilizzando un DB relazionale sarebbero estremamente più complesse e di difficile lettura. Grazie alle peculiarità del DB a grafo potremo tradurre in poche righe di codice interrogazioni come questa: “Trova tutte le persone nate a Torino nel 1990 che hanno valutato 5 stelle il McDonald di piazza dell’VIII Agosto di Bologna e hanno un amico, tifoso dei Los Angeles Lakers, che vive a Cagliari”.

Un esempio pratico

Non c’è cosa migliore per entrare nel vivo della questione che vedere un esempio pratico e cominciare a fare qualche prova. Se creiamo su SSMS un nuovo database ed espandiamo il menu delle tabelle, possiamo notare la presenza dell’entità Graph Tables, sotto alla quale troveremo tutte le tabelle create nel perimetro del nostro DB a grafo (il che comprende sia i nodi sia gli archi).

Per questo esempio prenderemo in considerazione una porzione ridotta del diagramma mostrato all’inizio dell’articolo, ovvero quella che coinvolge i soli nodi Persone e Ristoranti (con relativi archi); questo esempio, per quanto semplice, ci permetterà già di indagare diversi aspetti interessanti di questa funzionalità di SSMS.

Creiamo e popoliamo le entità nodi

Come prima entità creiamo una tabella nodo, in tutto e per tutto simile alla creazione di una classica tabella, se non fosse per l’aggiunta finale della dicitura “AS NODE”.

L’inserimento dei dati in questa tabella è invece del tutto indistinguibile dalla classica insert che potremmo eseguire per popolare una tabella normale.

Se eseguiamo una semplice SELECT * della tabella appena creata, possiamo già notare una prima differenza rispetto ad una tabella classica: le tabelle di tipo nodo vengono difatti equipaggiate con una colonna aggiuntiva generata automaticamente, chiamata $node_id (seguito da una stringa esadecimale).

Si tratta di una pseudo colonna utilizzabile nelle query, ed è possibile interrogarla anche omettendo la parte esadecimale, come possiamo notare nell’esempio seguente.

Il contenuto di questa particolare colonna è un JSON (anche questo generato automaticamente) che ci servirà per creare gli archi che connetteranno due tabelle nodo tra loro.

Creiamo e popoliamo allo stesso modo la tabella nodo “Ristoranti”, di cui per brevità vi mostro solo l’aspetto finale

Creiamo e popoliamo le entità archi

La sintassi per la creazione di un arco è identica alla creazione delle tabelle nodo, con la differenza che la specifica “AS NODE” sarà sostituita da “AS EDGE”

Questa relazione, che mette in rapporto le persone con i ristoranti, annovera tra i suoi attributi la valutazione che ciascuna persona ha espresso nei confronti di quel ristorante. Possiamo quindi visualizzare questa relazione tra due dati di esempio come

dove le ellissi sono i dati ospitati nei nodi Persone e Ristoranti, il connettore è la relazione rappresentata dall’arco AmaMangiareDa, e la parola tra parentesi quadre è l’attributo “Valutazione” dell’arco stesso, come lo abbiamo definito nel passaggio precedente.

Finora non abbiamo ancora collegato tra loro in nessun modo le persone e i ristoranti, quindi il prossimo passaggio consisterà nell’aggiungere dati alla tabella arco in questo modo:

Così facendo ho recuperato un record dalla tabella delle persone ovvero “Franz Liszt”, un record dalla tabella dei ristoranti, ovvero “Osteria Francescana”, e ho aggiunto la valutazione di cinque stelle che Franz Liszt ha assegnato a tale ristorante.

Se proviamo adesso ad interrogare la tabella appena popolata, otteniamo questo risultato

Esattamente come era avvenuto per le tabelle nodo, viene aggiunta automaticamente una colonna contenente un JSON, chiamata $edge_id. Possiamo anche notare la presenza delle due colonne che puntano ai nodi collegati da questo arco (praticamente delle chiavi esterne), una riferita alla tabella di partenza (quella delle persone), cioè $from_id, e una riferita alla tabella di destinazione (quella dei ristoranti), cioè $to_id, popolate con il contenuto delle rispettive colonne $node_id che avevamo recuperato al momento di inserire i dati nell’arco. Anche in questo caso il nome “vero” delle colonne generate automaticamente è seguito da una stringa esadecimale, ma analogamente a quanto avveniva per le tabelle nodo, possiamo interrogarle omettendo il suffisso.

Volendo pensare in termini relazionali alla struttura appena creata, non abbiamo fatto qualcosa di molto diverso rispetto al creare una tabella molti a molti tra la tabella Persone e la tabella Ristoranti.

Se adesso riapriamo il menu delle Graph Tables su Management studio, troviamo le tre entità create finora.

Guardando l’icona a sinistra del nome è possibile distinguere tra tabelle nodo e tabelle arco, essendo le prime contraddistinte da un pallino pieno, mentre le seconde da un connettore che unisce tra di loro due pallini vuoti.

È importante osservare che di default tutti gli archi creati sono bidirezionali; ciò significa che, se non imponiamo nessun vincolo, potremmo inserire un record in cui un ristorante recensisce un utente, che costituirebbe uno scenario un po’ strano.

Per proteggerci da questa eventualità possiamo aggiungere un vincolo sull’arco che connette le persone ai ristoranti, in modo da imporre la direzionalità delle recensioni solo dalla persona verso il ristorante.

Come ultimo passaggio per completare il grafo di esempio che vogliamo riprodurre ho creato e popolato in modo del tutto analogo anche la tabella arco che rappresenta il legame tra due persone, chiamata AmicoDi ovvero un arco che collega la tabella Persone a sé stessa (stavolta senza attributi).

A questo punto abbiamo ricreato esattamente la struttura che volevamo, e possiamo eseguire qualche query per renderci conto di come estrarre informazioni dal sistema appena costruito.

La funzione MATCH

Come primo esempio vorrei trovare quali ristoranti il signor Wagner ha valutato con più di tre stelle: la forma della query sarà la seguente

L’aspetto più significativo di questa query è sicuramente la presenza della funzione MATCH e dell’indicazione che segue (P-(A)->R).

Quello che stiamo facendo nella FROM è sostanzialmente un prodotto cartesiano tra le tabelle Persone, Ristoranti e AmaMangiareDa: la funzione Match invece si preoccupa di stabilire la gerarchia tra queste entità, mostrando con una sintassi che riproduce in modo quasi visuale la relazione tra le tabelle considerando che il nostro scopo è quello di scoprire quale persona (P) ama mangiare (A) in quale ristorante (R).

Volendo possiamo complicare un po’ di più la cosa aggiungendo il livello della relazione tra le persone. Proviamo quindi a ricavare tutti i ristoranti con valutazione uguale a 5 recensiti dagli amici del signor Wagner.

Da questo comando è possibile notare che le tabelle nodo vanno specificate nella FROM n volte, una per ogni occorrenza nel MATCH, mentre all’interno del MATCH stesso abbiamo semplicemente aggiunto degli anelli alla catena per coinvolgere nella query anche le relazioni tra persona e persona.

La funzione SHORTEST_PATH

Abbiamo detto che i DB a grafo sono molto adatti per rappresentare i legami e le relazioni tipiche di un sistema come un social network; immaginiamo quindi che la nostra tabella Persone rappresenti un mini social network di compositori ottocenteschi, i cui membri siano relazionati in questo modo

Ricordiamo che abbiamo strutturato l’arco che referenzia la tabella “Persone” con sé stessa in modo che sia bidirezionale e che non sia pesato: Richard è amico di Clara esattamente come lei lo è di lui e l’amicizia tra loro due vale esattamente come l’amicizia tra qualunque altra coppia di membri direttamente connessi di questo diagramma.

La nostra esigenza in questo momento è quella di capire qual è il minimo percorso possibile per andare da una persona all’altra, per esempio da Felix Mendelssohn (in alto a sinistra) ad Anton Bruckner (in basso a destra).

A differenza di quanto si potrebbe credere questa operazione nasconde una certa complessità, dato che stabilire dei percorsi tra i nodi è un’operazione molto costosa, come scopriremo tra poco a nostre spese. La soluzione consisterà nell’intendere ciascun percorso come una serie di nodi raggruppati, un approccio che sarà determinante nel cercare di minimizzare i passaggi tra un nodo e l’altro.

Lanciamoci in una veloce disamina di questa query, a partire dalla FROM.

L’espressione FOR PATH che segue l’arco e il nodo di destinazione ricorda in qualche modo una GROUP BY, dato che il suo scopo sarà quello di raggruppare i nodi che costituiscono il percorso minimo tra il nodo di partenza e quello di arrivo.

La funzione STRING_AGG è stata di recente aggiunta in SQL Server ed è una semplice concatenazione tra stringhe, che permette di collegare il set di nomi nella colonna Friends con i caratteri voluti (nel nostro caso, ‘->’), mentre la LAST_VALUE restituisce l’ultimo valore di un certo set (ovvero del nodo di destinazione).

Infine nella WHERE troviamo, all’interno della MATCH che abbiamo già visto, la dicitura “SHORTEST_PATH”, che ricerca il percorso più breve tra un nodo e l’altro del diagramma. Alla sintassi ormai nota per specificare a quali nodi e quali archi siamo interessati (Person1(-(fo)->Person2) abbiamo in aggiunta un segno ‘+’ che sta ad indicare che vogliamo le informazioni riguardo all’intero percorso tra ciascun membro del nodo di partenza e di quello di destinazione, senza limitare il numero dei singoli passaggi. Ogni volta che la query viene eseguita, il risultato dell’esecuzione di questo modello sarà una raccolta ordinata di nodi e archi attraversati lungo il percorso, dal nodo iniziale al nodo finale.

Questa funzionalità merita alcune riflessioni. La prima è che, se eseguiamo solamente la CTE della query esposta in precedenza, otterremo come risultato i percorsi più brevi tra il nodo Mendelssohn e tutti gli altri nodi del grafico.

Questa considerazione deve sicuramente far scattare un campanello d’allarme dal punto di vista delle performance: se già in uno schema semplice come questo abbiamo così tante ramificazioni, sicuramente per una realtà più complessa le risorse impiegate per sfornare i risultati possono esplodere facilmente. Teniamo anche in considerazione che avevamo specificato esplicitamente il nodo di partenza, cioè Mendelssohn, nella condizione WHERE: non l’avessimo fatto avremmo ottenuto i percorsi che collegano tutti i nodi dello schema con tutti gli altri nodi.

Un’azione che sicuramente aiuta a migliorare le performance in uno scenario come questo consiste nell’aggiunta un indice sulle colonne $from_id e $to_id

Proprio per limitare il dispendio di risorse, anche se ci sono due o più percorsi che portano da un nodo ad un altro con lo stesso numero di passaggi, SQL Server ne mostrerà sempre e solo uno (scelto in base al primo trovato). Prendiamo ad esempio il percorso che viene mostrato come il più breve per andare da Mendelssohn a Bruch: ci viene mostrato il corretto cammino Mendelssohn->Wagner->Schumann-> Bruch, ma al tempo stesso viene ignorato quello del tutto equipollente Mendelssohn->Wagner->Schubert-> Bruch.

Un altro aspetto interessante da notare è che di default non c’è vincolo che escluda il nodo di partenza dai nodi di arrivo, troviamo infatti alla sesta riga il loop Mendelssohn -> Wagner -> Mendelssohn.

Purtroppo al momento la funzione SHORTEST_PATH non è in grado di essere parametrizzata in modo esplicito con i nodi di partenza e di arrivo; la conseguenza di ciò è che il filtraggio dei risultati deve essere eseguito in un secondo momento tramite opportune clausole WHERE, come in questo caso: una interna alla CTE per definire il nodo di partenza e una esterna per definire il nodo di arrivo.

Come ultimo esempio possiamo indagare una sintassi alternativa al ‘+’ visto nella MATCH dell’esempio precedente, che ci permette di specificare a che livello di profondità fermare la nostra ricerca sui nodi.

In questa query abbiamo pertanto estratto tutte le persone ad un minimo di uno e un massimo di due livelli di distanza da Richard Wagner e che abbiano lasciato una recensione a MacDonalds. La prima condizione è fornita dal segmento di codice {1,2} che ha sostituito il segno ‘+’ visto in precedenza, il vincolo sulla presenza della recensione è invece espresso dalla seconda condizione all’interno della MATCH.

Conclusioni

Alla luce di queste considerazioni possiamo chiederci quando effettivamente possa convenire utilizzare un DB a grafo su SQL Server.

Attualmente SSMS non è ancora in grado di competere con tecnologie sviluppate appositamente, come Neo4j, OrientDB o HyperGraph DB, specie se teniamo presenti alcune limitazioni piuttosto importanti, ad esempio

  • Non è permesso eseguire operazioni di UPDATE sulle colonne degli archi
  • Tabelle temporanee e tabelle temporanee globali non sono supportate
  • Non è possibile eseguire query cross-database
  • Non c’è un modo diretto per convertire tabelle normali in tabelle di un DB a grafo
  • Non esiste GUI: per visualizzare il grafo dobbiamo appoggiarci a strumenti esterni come Power BI

Se però la nostra esigenza è di sviluppare un DB a grafo non eccessivamente complesso e performante senza cambiare tecnologia, sicuramente questa funzionalità già completamente integrata in SQL Server può essere di grande aiuto.

Nota

Tutto il codice utilizzato nell’articolo è disponibile a questo link

https://drive.google.com/drive/folders/1DQo4CioViLCcNylA88T02aZeLRo9q40D?usp=sharing

Sitografia

https://docs.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-architecture?view=sql-server-ver15

https://docs.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-sample?view=sql-server-ver15

https://docs.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-shortest-path?view=sql-server-ver15

https://docs.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-overview?view=sql-server-ver15

https://docs.microsoft.com/it-it/sql/relational-databases/graphs/sql-graph-shortest-path?view=sql-server-ver15

https://medium.com/swlh/how-to-make-use-of-sql-server-graph-database-features-946ce38190cc

https://novacontext.com/getting-started-with-sql-server-graph/index.html

https://www.red-gate.com/simple-talk/databases/sql-server/t-sql-programming-sql-server/sql-server-2019-graph-database-and-shortest_path/

https://www.sqlshack.com/graph-database-features-in-sql-server-2019-part-1/

#jointherevolution

1. Introduci la tua esperienza professionale dall’università fino all’ingresso in Orbyta.

Dopo un percorso di studi in Informatica al Politecnico di Torino, ho iniziato subito a lavorare presso una piccola realtà locale, nel modo dello sviluppo software e servizi per gli ospedali e le strutture mediche private.

Mentre apprendevo nuove conoscenze nell’ambito informatico e in quello medico, l’azienda è entrata a far parte di una realtà multinazionale. Questa fase è stata un’occasione di crescita, sia da un punto di vista tecnico che personale: oltre allo sviluppo software ho potuto occuparmi di gestione progetti, sia in Italia che all’estero, e di collaborazione diretta con i clienti.

Dopo diversi anni, di fronte anche alla possibilità di trasferirmi per lavoro all’estero, ho deciso di rimanere a Torino e cercare una realtà in cui poter seguire e coordinare un progetto software da zero. Questa possibilità si è concretizzata con la mia presenza presso un importante gruppo di centri medici in Piemonte. Durante questa esperienza ho collaborato con molte persone, ho affrontato le difficoltà e sfide di un software usato regolarmente da centinaia di utenti ed ho approfondito le mie competenze, in particolare per gli aspetti di architettura software, back-end e front-end.

A maggio 2021 sono entrato a far parte della realtà Orbyta, portandomi dietro il bagaglio di conoscenze ed esperienze acquisito durante gli anni.


2. Di cosa ti occupi e che valore porti all’azienda?

In Orbyta ricopro il ruolo di Technical Leader per la divisione Process Automation Open, che si concentra sulla parte back-end dei progetti, facendo uso di linguaggi e tecnologie open-source, in particolare Java. Mi occupo di analisi, sviluppo e gestione di progetti software collaborando da un lato con gli sviluppatori impegnati sui singoli progetti e dall’altro con il team di sviluppo business.

Ancora prima di iniziare il percorso di studi universitario, l’informatica ha sempre attirato la mia attenzione e curiosità, portandomi a studiare ed approfondire numerose tecnologie. Il percorso lavorativo che ho affrontato dopo gli studi mi ha permesso di integrare le competenze tecniche con la capacità di interagire con colleghi e clienti, soprattutto in ambito internazionale.
Sono felice di portare in azienda il mio bagaglio di competenze, la passione per i dettagli e l’attenzione per la precisione.

3. Perché ti piace lavorare in Orbyta?

In Orbyta, fin da subito, ho trovato un gruppo di persone affiatate, disponibili e simpatiche. Poiché penso che il lavoro di gruppo ed i rapporti interpersonali siano molto importanti, apprezzo molto l’ambiente che trovo in Orbyta. L’attività che svolgo mi consente di conoscere numerose realtà ed ambiti, mettendo alla prova le mie competenze e permettendomi di apprendere nuove tecnologie e incrementare le mie conoscenze.

#jointherevolution

Introduzione

Il New York Times presenta la data science come il settore che promette di rivoluzionare tutte le imprese e associazioni: dal governo, all’assistenza sanitaria, dal mondo accademico, alle aziende. Tuttavia, i ruoli all’interno di questa branca sono svariati e in questo articolo vi daremo una panoramica sulle principali figure professionali attualmente presenti nel campo:

  • BI developer e Data Analyst
  • Back-end developer
  • Data Scientist e AI Engineer
  • (Big) Data Engineer e Data Architect

Ogni azienda dà definizioni proprie di questi impieghi e delle responsabilità che a loro competono, ma mettendo insieme le concezioni più chiare e comuni su questo tema, iniziamo a descrivere cosa fa un BI Developer.

BI developer e Data Analyst

Uno sviluppatore di Business Intelligence (BI) è incaricato di sviluppare, distribuire e mantenere le interfacce BI. Questi includono strumenti di interrogazione e modellizzazione dati, nonché visualizzazione delle informazioni tramite report ad hoc o dashboard interattive.  Una piattaforma per la BI ha 3 livelli: origine dati, warehouse e reporting.

Nel livello dell’origine dati vengono archiviati i dati grezzi. Essi possono essere dati strutturati o non. I dati strutturati vengono archiviati in un formato predefinito e vengono comunemente archiviati nei data warehouse (DWH). I dati non strutturati invece (per esempio, video e immagini) vengono archiviati solitamente invece nei data lake (DL). Entrambi hanno un potenziale di utilizzo del cloud, ma i dati strutturati consentono meno spazio di archiviazione.

Il livello warehouse comprende tutte le tecnologie che facilitano il processo di storage per tutti i dati aziendali e gli strumenti che eseguono l’estrazione, la trasformazione e il caricamento (ETL). In questo modo i dati vengono spostati in un unico database così da standardizzare i dati in formati coerenti in modo che possano essere interrogati efficacemente. La sua implementazione e manutenzione è un campo di responsabilità per gli sviluppatori di database/ETL e gli analisti/ingegneri di dati.

Il livello di reporting è l’effettiva interfaccia BI che consente agli utenti di accedere ai dati, per esempio tramite tool come Power BI, Qlik Sense, Tableau. 

I tool di visualizzazione e analisi dati devono essere padroneggiati anche da un buon Data Analyst, colui che consente alle aziende di ottimizzare il valore dei propri asset di dati utilizzando anch’essi dashboard e report ad hoc.

Essi interrogano ed elaborano i dati, fornendone visualizzazioni, aggregazioni e interpretazioni che permettono  di trasformarli in informazioni utili al business e al processo decisionale. Hanno quindi meno dimestichezza a livello tecnico per quel che riguarda l’architettura generale che prepara i dati prima dell’ultimo layer, ma hanno forti competenze di analisi e nel dare valore pratico ai dati ottenuti. 

Lavorando sull’ultimo layer devono, inoltre, avere le competenze necessarie per interrogare agilmente i dati finali, per questo sono anche responsabili di apportare migliorie ai report e dashboard indicando al BI Developer anche l’eventuale esigenza di implementare o modificare i flussi dati.

Seguono alcuni importanti tool del settore e alcune certificazioni di interesse.

Back-end developer

Viene definito back end tutto ciò che opera dietro le quinte di una pagina web, in contrapposizione al front end, che indica invece gli elementi visibili agli occhi dell’utente, elaborati lato client (client side).

Le mansioni di questa figura sono molteplici e possono differire sia rispetto al livello di intervento sul codice, sia sul piano dei processi che portano un prodotto digitale. 

Per diventare Back End Developer è essenziale soprattutto conoscere un’ampia gamma di linguaggi di programmazione. Spesso infatti le aziende ricercano Sviluppatori Back End a partire proprio da questo requisito, richiedendo competenze di coding nel linguaggio impiegato nei propri sistemi informatici. 

Tra i linguaggi più diffusi e richiesti troviamo: Ruby, Python, C++, SQL, Java e Javascript.

A questi devono aggiungersi anche i framework già predisposti per la programmazione come Spring o Hibernate, nonché competenze di creazione e organizzazione di database digitali (tramite Oracle, MySQL, NoSQL, MongoDB, ecc.), poiché in genere le aziende dispongono già di un database digitale e cercano sviluppatori che siano in grado di operare.Inoltre bisogna tenere conto della velocità impressionante con cui si evolvono questi linguaggi, per cui è bene che uno sviluppatore si mantenga costantemente aggiornato sulle novità in termini di coding e programmazione. Proprio per questo aspetto, consigliamo delle certificazioni focalizzate sulla conoscenza dei linguaggi di programmazione: 

I back-end developer lavorano in tutti i settori dell’informatica, e molto spesso, quelli che lavorano all’interno di un team focalizzato nella data science finiscono con lo specializzarsi su metodologie e librerie padroneggiate dai data scientist o data engineer.

Data scientist e AI Engineer

Il Data Scientist è colui che analizza e interpreta dati complessi, combinando più campi, tra cui statistica, AI e analisi dei dati. Il loro lavoro può andare dall’analisi descrittiva, all’analisi predittiva. L’analisi descrittiva valuta i dati attraverso un processo noto come analisi esplorativa dei dati (EDA). L’analisi predittiva viene usata in ambito di Machine Learning per applicare tecniche di modellazione in grado di rilevare anomalie o modelli. 

L’analisi descrittiva e quella predittiva rappresentano solo un aspetto del lavoro dei data scientist. Come prerequisito essenziale emerge la capacità di programmare, per esempio usando Python e R, ma anche la capacità di implementare algoritmi sofisticati di ML.

Adesso chiariamo un’importante differenza che spesso viene tralasciata: quella tra un data scientist e un AI engineer.

Gli AI Engineer sono responsabili dello sviluppo di nuove applicazioni e sistemi che utilizzano l’Intelligenza Artificiale per migliorare le prestazioni e l’efficienza, prendere decisioni migliori, ridurre i costi e aumentare i profitti. Un esperto di intelligenza artificiale deve essere in grado di analizzare e associare i principi dell’IA al ragionamento e all’incertezza in qualsiasi ambiente prospettico, saper applicare queste tecniche per l’analisi e la ricostruzione delle immagini, risolvere una varietà di problemi o scenari complessi ma anche per modellare il comportamento umano nello svolgimenti di compiti complicati o completare processi complessi. La valutazione e il miglioramento delle prestazioni delle applicazioni nei domini di intelligenza artificiale e machine learning è un requisito importante che un AI Engineer deve avere ed è importante aver sviluppato consapevolezza e competenza su queste attività principali  poiché chiunque lavori nell’IA o nell’apprendimento automatico verrà chiesto di gestire questo tipo di responsabilità quasi quotidianamente. Si tratta di una professione complessa che richiede una grande quantità di conoscenze tecniche ed esperienze specifiche.

Un AI Engineer aiuta le aziende a creare nuovi prodotti di AI efficacemente funzionanti, mentre un data scientist implementa strumenti che utilizzando i dati promuovono un processo decisionale redditizio sfruttando anche l’AI se necessario. Queste figure lavorano a stretto contatto per creare prodotti utilizzabili per i clienti. Un data scientist per esempio potrebbe implementare i modelli di machine learning su IDE mentre un AI engineer potrebbe crearne una versione distribuibile del modello creato dal data scientist integrando i suoi modelli nel servizio finale. 

Gli AI Engineer sono anche responsabili della creazione di API di servizi Web sicure per la distribuzione di modelli. In altre parole, un data scientist utilizza l’IA come strumento per aiutare le organizzazioni a risolvere i problemi mentre un AI Engineer per servire i clienti guardando però al business da un punto strategico più basso. Entrambi devono lavorare in modo collaborativo per creare una soluzione che funzioni con la più alta efficienza e precisione possibile quando implementata nella vita reale.

Ecco alcune certificazioni consigliate: 

(Big) Data Architect e Data Engineer

Il Data Architect  è specializzato nella progettazione di sistemi informatici per la gestione e la conservazione di dati e informazioni. Egli si occupa di organizzare i dati, impostare i criteri di accesso e coordinare le varie fonti, il tutto con lo scopo di rendere i dati stessi fruibili e funzionali al raggiungimento degli obiettivi aziendali. Utilizzano la loro conoscenza dei linguaggi informatici orientati ai dati per organizzare e mantenere i dati in database relazionali e repository aziendali, sviluppando strategie di architettura dei dati per ogni area tematica del modello dati aziendale.

Le competenze professionali comuni dei data architect comprendono competenze tecniche avanzate (in particolare in linguaggi come SQL e XML), un eccellente acume analitico, una visualizzazione creativa e capacità di problem-solving, e un forte orientamento al dettaglio. Ne consegue che l’Architetto dei Dati, raccogliendo ed elaborando dati derivanti sia da fonti interne, sia da fonti esterne, può essere visto come una sorta di anello di congiunzione tra l’area IT e le altre aree dell’organizzazione. 

Chiariamo qua un’altra differenza spesso non sottolineata: i Data Architect progettano la visione e il progetto del framework dei dati dell’organizzazione, mentre il Data Engineer è responsabile della creazione di tale visione.

I data engineer si occupano del provisioning e della configurazione delle tecnologie di piattaforma dati, in locale e nel cloud. Gestiscono e proteggono il flusso di dati strutturati e non strutturati da più origini. Devono anche avere un forte background tecnico con la capacità di creare e integrare API e comprendere le pipeline dei dati e l’ottimizzazione delle prestazioni. Le competenze tecniche desiderate includono la conoscenza dei sistemi Linux, la competenza nella progettazione di database SQL e una solida padronanza di linguaggi di codifica come Java, Python, Kafka, Hive o Storm. 

Le piattaforme dati usate possono includere database relazionali e non relazionali, flussi di dati e archivi di file. I data engineer verificano inoltre che i servizi dati siano integrati in modo sicuro e trasparente.L’ambito di lavoro di un data engineer va oltre la gestione di un database e del server in cui questo è ospitato e probabilmente non include la gestione complessiva dei dati operativi. 

Un data engineer può aggiungere un notevole valore sia ai progetti di business intelligence che a quelli di data science. Quando il data engineer raccoglie i dati, operazione spesso detta di data wrangling, i progetti avanzano più rapidamente, perché i data scientist possono concentrarsi sulle proprie aree di lavoro. Un BI developer collabora a stretto contatto con un data engineer per assicurarsi che sia possibile accedere a una vasta gamma di origini dati, strutturate e non, a supporto dell’ottimizzazione dei modelli di dati, che sono in genere forniti da un data warehouse o un data lake moderno.

Di seguito alcune certificazioni possibili per un data engineer: 

I professionisti che si occupano di Big Data in particolare si specializzano nel trattare set di dati troppo grandi o complessi per essere gestiti dai tradizionali software applicativi di elaborazione dati. I dati con molti campi (righe) offrono una maggiore potenza statistica, mentre i dati con una maggiore complessità (più attributi o colonne) possono portare a un tasso di false discovery più elevato. Le sfide dell’analisi dei big data includono l’acquisizione di dati, l’archiviazione dei dati, l’analisi dei dati, la ricerca, la condivisione, il trasferimento, la visualizzazione, l’interrogazione, l’aggiornamento, la privacy delle informazioni e l’origine dati. L’analisi dei big data presenta sfide nel campionamento, consentendo quindi in precedenza solo osservazioni e campionamenti. Pertanto, i big data spesso includono dati con dimensioni che superano la capacità del software tradizionale di elaborare entro un tempo e un valore accettabili. Ecco un percorso di certificazione per iniziare a studiare il problema: https://intellipaat.com/big-data-hadoop-training/

Conclusioni

Dopo questa panoramica sulle figure professionali del settore analytics speriamo possiate averne un’idea più chiara e, perchè no, di avere ispirato alcuni di voi nella costruzione/proseguimento della propria carriera in questo settore.

FONTI:

Articolo a cura di Lucia Campomaggiore (MS BI Developer) e Carla Melia (Head of Analytics), 14.03.2022

#jointherevolution

1) Introduci la tua carriera professionale fino al ruolo di CEO Infogest.


Ho iniziato la mia carriera lavorativa nel 1988, quando ero ancora studente, proprio nella quasi “neonata” Infogest , come tecnico informatico.
Un rapporto, quello con Infogest e con i suoi soci fondatori, che non si è mai interrotto e che in seguito alla mia fuoriuscita, si è trasformato, è cresciuto e ci ha tenuti uniti con l’amicizia, fino a quando sono recentemente rientrato, per volontà degli stessi, per prenderne il timone.


Dal 1992, rapida carriera nell’information tecnology, con ruoli crescenti, prima sviluppatore, poi project manager e quindi ICT manager presso diverse multinazionali del settore manifatturiero.


La mia intraprendenza ed il mio desiderio di crescita hanno fatto sì che allargassi i miei interessi al controllo di gestione, alla gestione delle risorse umane ed ai processi aziendali.
Alle responsabilità nel settore dell’ICT si sono aggiunte quelle sull’organizzazione e sul controllo di gestione.
Ormai da quindici anni il mio lavoro è quello di amministratore delegato di aziende PMI nei settori ICT e metalmeccanico.

2) Qual è il valore che Infogest ha portato al Gruppo ORBYTA?

Orbyta è una splendida realtà fatta di giovani ambiziosi e molto competenti; è nata recentemente ma si fonda su solide esperienze pregresse fatte dai soci fondatori, che hanno messo a fattor comune realtà preesistenti con grande potenziale di sviluppo. Orbyta, con grande determinazione, chiarezza d’intenti e competenza, sta costruendo un sistema che funziona bene sia internamente che per i Clienti.


In questo preciso disegno Infogest è andata a colmare uno dei tasselli che contribuiscono a rendere ancora più solida l’offerta ICT di Orbyta Tech. Un valore aggiunto sia per i Clienti che per l’Azienda, ovvero la certezza di comprare l’ Hardware alle migliori condizioni di mercato, non solo di prezzo.
Condizioni raggiungibili solo dopo tanti anni di presenza sul mercato, contraddistinti da una condotta sempre seria con risultati sempre positivi e clienti sempre soddisfatti.

3) Quali sono le prospettive per Infogest e come pensi di affrontarle?

Infogest, grazie all’ingresso nel gruppo Orbyta, è destinata a crescere in modo importante nei volumi di vendita e questa prospettiva indica chiaramente una necessità di strutturare opportunamente la nostra organizzazione in modo da riuscire a rispondere alle esigenze di un maggior numero di Clienti con lo stesso livello di qualità che ci ha permesso di restare sul mercato in tutti questi anni, fidelizzando anche i nuovi clienti come abbiamo fatto con quelli che ci premiano con la loro fedeltà ormai da molti anni.

#jointherevolution

1. Introduci la tua esperienza professionale dall’università fino all’ingresso in ORBYTA.

Mi avvicino al mondo informatica fin dall’adolescenza scegliendo di spianarmi la strada in questo settore studiando e conseguendo il diploma di perito informatico con specializzazione in telecomunicazioni. 

Successivamente decido di trasferirmi dalla mia amata Puglia per studiare al Politecnico di Torino. Un percorso di studi piuttosto impegnativo ma mirato a costruire la forma mentis adatta a quella che poi sarebbe stata la mia futura professione. Dopo aver conseguito la laurea triennale in Ingegneria Informatica, proseguo gli studi seguendo la specializzazione in Computer Networks. Mi riavvicino allo sviluppo software durante il periodo di tesi; qui infatti, scelgo una tesi sperimentale in un gruppo di ricerca del Politecnico di Torino in modo da entrare nelle dinamiche di un team di sviluppo.

Terminati gli studi, ho l’opportunità di entrare a far parte di una software house di una prestigiosa multinazionale dove ho avuto il piacere di lavorare con colleghi esperti nello sviluppo web orientato ai servizi finanziari. Col passare degli anni e l’aumentare dell’esperienza sono stato coinvolto maggiormente in tutte le fasi di un progetto: dall’analisi di fattibilità e la stima economica fino al design di applicativi più o meno complessi.

Passano circa 4 anni, prima che decida di iniziare a guardarmi attorno per poter mettermi in gioco in contesti differenti. In questo periodo ricevo la chiamata di Daniele Sabetta, l’attuale CTO che conoscevo e stimavo da tempo, per illustrarmi le potenzialità di Orbyta e l’obiettivo di creare una software house aziendale sempre più stabile e con un maggiore afflusso di progetti chiavi in mano. Da qui, l’inizio della mia avventura in Orbyta e che ad oggi conta circa 3 anni e mezzo di esperienza fianco a fianco.

2. Di cosa ti occupi e che valore porti all’azienda?

Attualmente ricopro il ruolo di Technical Leader della business unit Process Automation Microsoft. Sono coinvolto nei processi aziendali che riguardano l’analisi, lo sviluppo e gestione di progetti che prevedono l’uso di tecnologie mappate sullo stack Microsoft. 

Cerco inoltre di destreggiarmi nella gestione del team impegnato su diverse attività in modo da fare da collante tra il team di tecnici e il team impegnato nello sviluppo business. 

In pochi anni in Orbyta ho dimostrato di credere in un progetto davvero accattivante affrontando sfide più o meno impegnative e che grazie ad un’ottima guida abbiamo superato sempre brillantemente. Ecco, da parte mia sicuramente c’è sempre stato un entusiasmo positivo anche nelle difficoltà ed una gestione attenta del team per limitare al massimo le pressioni dovute ai diversi impegni e alle esigenze dei vari clienti. Pertanto per concludere, il valore che porto in Orbyta è sicuramente un oculato senso di responsabilità.

3. Perché ti piace lavorare in ORBYTA?

In Orbyta sono circondato da persone altamente qualificate e con molta esperienza. Soprattutto nell’ultimo anno la nostra realtà è stata capace di attrarre professionisti navigati nel mondo dell’Information Technology. Questo mi fa capire che nonostante i successi e i traguardi raggiunti, Orbyta non è appagata ma pronta più che mai a superarsi continuamente per raggiungere brillanti obiettivi. 

#jointherevolution

1. Introduci la tua esperienza professionale dall’università fino all’ingresso in ORBYTA.

Ho iniziato a lavorare nel mondo dell’informatica immediatamente dopo le superiori su attività di data-entry, per poi affrontare una vera e propria gavetta. Partendo dal supporto tecnico end users, passando dal supporto lato server sino ad arrivare a gestire sistemi complessi e ampi per clienti internazionali.

Poco prima di approdare in ORBYTA sono stato service manager dell’end users services di una multinazionale e, complice la mia passione videoludica, ho avuto l’occasione di frequentare un workshop presso un’azienda di videogiochi che ha sviluppato uno dei MOBA più giocati al mondo.

Grazie a queste esperienze ho potuto accrescere le mie competenze lato sistemistico vedendo diverse realtà e settori, dall’automotive al bancario, dall’assicurativo al gaming e alle telecomunicazioni.

Queste realtà variegate hanno aumentato la mia curiosità e passione dandomi lo slancio per certificarmi su diverse tecnologie.



2. Di cosa ti occupi e che valore porti all’azienda?

Ad oggi sono Tech Lead del gruppo infrastrutture, mi occupo di coordinare le attività di natura sistemistica su vari clienti di ORBYTA e fornire consulenze specifiche sulla virtualizzazione di ambienti, hardening e gestione infrastrutturale.

Posso serenamente dire che il mio team è grintoso e coraggioso, poiché lavoriamo perennemente su ambienti produttivi e ci occupiamo di garantire la stabilità, l’efficienza e l’affidabilità delle infrastrutture affrontando problemi di diversa natura.

Mi sono sempre definito un professionista quindi mi sento di dire che il valore che porto è una grande professionalità, attenzione nei confronti dei clienti e dell’azienda in cui credo moltissimo.



3. Perché ti piace lavorare in ORBYTA?

Ho visto vari ambienti di lavoro nella mia vita ma raramente ho notato un’attenzione verso la crescita professionale del dipendente così come in ORBYTA.

L’ambiente è giovane, stimolante, divertente e costruttivo. Il tutto senza mai perdere di vista la professionalità e la serietà che contraddistingue un’azienda di valore.

Di solito sono caratteristiche che uno non considera come prioritarie, ma lo diventano subito quando le trovi e ti ci trovi dentro come in ORBYTA!

#jointherevolution

1. Introduci la tua esperienza professionale dall’università fino all’ingresso in ORBYTA.

Il mio percorso professionale inizia con il conseguimento del diploma da perito informatico presso un istituto tecnico.

Successivamente ho voluto fare un’esperienza di lavoro all’estero per migliorare l’uso della lingua inglese e per capire come andasse il mondo ICT fuori dall’Italia.

Al mio ritorno ho iniziato a lavorare presso un’azienda di software gestionale nel reparto R&D dove sono rimasto per 4 anni, per poi spostarmi su Milano in un’altra società nello stesso settore. Tuttavia, mi sono reso conto che lavorare in un ambito così specifico poteva limitare la mia crescita professionale ed è così che è iniziata la mia vita da consulente presso un cliente enterprise nel settore automotive.

Durante questa esperienza ho avuto l’opportunità di fare anche qualche trasferta in giro per il mondo entrando a contatto con realtà molto differenti. Dopodiché ho conosciuto il mondo ORBYTA e mi sono appassionato all’idea di imparare a lavorare in ambiti diversi, portando in cambio la mia esperienza professionale.

2. Di cosa ti occupi e che valore porti all’azienda?

Attualmente in ORBYTA ricopro il ruolo di Tech Leader per la BU Digital e Mobile, gestendo un piccolo team di sviluppatori in AREA 51 (la nostra software house interna) per diversi clienti e progetti.

Il mio contributo alla causa di ORBYTA consiste nel portare la mia esperienza e la mia passione per l’ambito in cui lavoro per cercare di introdurre sempre nuove tecnologie e affrontare tutte le sfide quotidiane insieme al team.

3. Perché ti piace lavorare in ORBYTA?

In ORBYTA ho trovato l’ambiente che ho a lungo cercato in altre aziende. Un ufficio di giovani professionisti con grandi competenze, ma anche con tanta voglia di mettersi sempre in gioco e a volte uscire dalla comfort zone per affrontare nuove sfide e imparare cose sempre nuove.

#jointherevolution