Mi chiamo Marco Orlandin. Faccio l'IT Architect: progetto e semplifico sistemi complessi.

Non ho un pitch. Lavoro su ambienti che qualcun altro ha costruito, che funzionano "finché va bene", e che prima o poi smettono di farlo. Il mio lavoro è capire cosa c'è sotto, decidere cosa va cambiato e cosa va lasciato in pace, e fare in modo che chi subentra dopo di me trovi un sistema leggibile.

Cosa faccio in pratica

Riduco il debito tecnico. Non in senso generico: in senso concreto. Infrastrutture accumulate negli anni senza documentazione, costi cloud che nessuno sa spiegare, deployment che dipendono dalla memoria di una persona. Prendo queste situazioni e le trasformo in qualcosa di descritto, versionato e ripetibile.

Mi occupo di architetture dichiarative (Infrastructure as Code), ottimizzazione dei costi cloud, progettazione di sistemi event-driven e domain-driven. Ma il filo comune è sempre lo stesso: rendere esplicito ciò che prima era implicito.

Come lavoro

Parto dall'assessment, sempre. Prima di proporre qualsiasi soluzione, guardo. Capisco cosa c'è, perché è fatto così, e cosa succederebbe se si rompesse domani. A volte la risposta è "non serve cambiare niente." A volte è "serve cambiare, ma non dove pensi tu."

Non vendo tecnologia. Se il problema si risolve con un processo, dico che si risolve con un processo. Se serve uno strumento nuovo, spiego perché, cosa cambia e cosa costa adottarlo. Se non serve il mio intervento, lo dico. Preferisco un cliente soddisfatto che mi ha pagato meno a uno insoddisfatto che mi ha pagato di più.

Da dove vengo

Non nasco informatico. Mi sono diplomato nel 2004 come Tecnico delle Industrie Meccaniche, con specializzazione in programmazione e manutenzione di macchine a controllo numerico. Disegno tecnico, prototipazione, taglio laser, stampa 3D: attività che porto avanti ancora oggi, parallele all'IT. L'IT l'ho costruito da zero, pezzo dopo pezzo, senza un percorso accademico che me lo spianasse davanti.

Ho aperto la mia prima partita IVA nel 2009, dopo alcune esperienze come programmatore e sistemista che mi hanno insegnato soprattutto come non si gestisce un team e un progetto. Da lì, anni di lavoro come sviluppatore in contesti diversi: web agency, editoria digitale, software house. Ogni passaggio mi ha dato qualcosa, anche quando il contesto non era ideale.

Il punto di svolta è stato entrare come dipendente numero due in una web-company. Ci sono rimasto quasi sei anni. Ho trovato un monolite ereditato da uno sviluppo offshore, fragile, ingestibile, tenuto insieme con il nastro adesivo. L'abbiamo riscritto pezzo per pezzo, trasformandolo in un'architettura a microservizi che reggeva carichi reali: sistemi distribuiti, code, notifiche multipiattaforma, analisi finanziaria. Sono entrato come backend developer. Ne sono uscito come CTO e architetto, con un team di undici persone e la responsabilità di far funzionare tutto.

È lì che ho imparato il mestiere che faccio oggi: non scrivere codice, ma decidere come un sistema deve stare insieme. Sono stato uno degli ultimi ad andarmene. L'azienda non c'è più, ma quello che ho imparato lì dentro vale più di qualsiasi certificazione.

Dopo, ho curato l'architettura backend di una piattaforma e-commerce: code, delivery, tutto quello che fa funzionare il sistema sotto il cofano.

Oggi opero come consulente.

Scrivo codice quando serve, ma il mio valore non è scrivere codice. È capire quale codice non va scritto.

Dove trovarmi

Il modo più diretto per contattarmi è via email. Mi trovi anche su GitHub, LinkedIn e X.

Se hai un sistema che ti tiene sveglio la notte, o un costo che non riesci a spiegare, o un'infrastruttura che funziona "perché nessuno la tocca"... parliamone.