Lavoro in una società di consulenza cresciuta attorno a Salesforce — Marketing Cloud e B2C Commerce in particolare. Quel focus è un punto di forza: competenza profonda sulla piattaforma, persone certificate, un modello di delivery di cui i clienti si fidano. Ma ogni piattaforma ha un confine, e parte del lavoro di un architetto è accorgersi di quando un progetto continua a sbatterci contro.
Parte del mio lavoro oggi è aiutare la practice a diversificare verso Microsoft Azure — non per allontanarci da Salesforce, ma per far funzionare meglio il lavoro su Salesforce. Quello che segue è il ragionamento, perché il perché conta più del cosa.
I confini contro cui continuavamo a sbattere
Salesforce è eccezionale per ciò a cui serve: dati del cliente, journey, commerce, il layer di engagement. L’attrito si presentava nelle giunture, in pattern come questi:
- Compute custom che non appartiene a una piattaforma di marketing. Trasformazioni dati pesanti, job schedulati, elaborazione di immagini o documenti — fattibili con contorsioni dentro SFMC, ma stai combattendo lo strumento.
- Integrazioni con sistemi che non sono Salesforce. ERP, PIM, logistica, back-office custom. Ti serve un posto dove ospitare middleware, code e API che non sia legato a un singolo SaaS.
- Costi e governance su scala. Alcuni workload sono semplicemente più economici e controllabili su un cloud general-purpose che come add-on a un SaaS licenziato per funzionalità.
- Dati e AI. Quando un cliente vuole combinare i dati Salesforce con tutto il resto ed eseguirci sopra dei modelli, vuoi una vera data platform sotto.
Nessuna di queste dice “Salesforce è brutto”. Dicono “Salesforce è un layer, e una soluzione matura di solito ne richiede più di uno”.
Costruire il business case (per l’azienda, non solo per gli ingegneri)
Introdurre un secondo cloud in una consulenza focalizzata non è una decisione tecnica — è commerciale. L’argomento che ha fatto centro non era “Azure è figo”. Era:
- Stavamo già perdendo scope. Ogni volta che un deal richiedeva cloud custom, middleware di integrazione o una data platform, quella parte andava a qualcun altro. Prendercela significa ingaggi più grandi e più duraturi.
- Riduce il rischio sulla relazione col cliente. Poter dire “gestiamo il lato Salesforce e l’architettura intorno” ci trasforma da fornitore specialista a advisor di fiducia.
- È un fit naturale col nostro mondo. [I clienti retail ed e-commerce / il segmento che serviamo] spesso vivono già nell’ecosistema Microsoft. Incontrarli lì abbassa l’attrito.
Il messaggio al management era formulato in termini di pipeline e margine, non di servizi e funzioni. È la traduzione che un architetto deve saper fare.
Cosa mi sono preso in carico davvero
La strategia sulla carta non basta. In pratica questo ha significato prendere in carico [il nostro ambiente Azure / il footprint cloud dell’azienda], insieme a [Git aziendale, dominio e sito] — il tessuto connettivo che serve a una società di servizi per operare in modo credibile. Quella base permette al team di:
- Ospitare middleware di integrazione e API (Functions, Service Bus, App Service) che stanno tra Salesforce e tutto il resto.
- Eseguire workload schedulati ed event-driven fuori dalla piattaforma di marketing.
- Costruire capacità di dati e, sempre più, AI accanto ai dati Salesforce invece che intrappolate al loro interno.
Pattern di riferimento: Salesforce come layer di engagement, Azure come backbone
L’architettura a cui torno sempre è questa:
- Salesforce possiede il layer verso il cliente — journey Marketing Cloud, storefront B2C Commerce, la logica di engagement e commerce.
- Azure possiede il backbone — integrazione, compute custom, orchestrazione, dati e AI.
- Un contratto di integrazione pulito tra i due (eventi + API), così nessuno dei due riversa la propria complessità sull’altro.
Azzecca questa separazione e ottieni il meglio di entrambi: Salesforce resta pulito e aggiornabile, Azure assorbe il lavoro custom che altrimenti lo inquinerebbe.
Cosa è cambiato
Il cambiamento vero è nelle conversazioni. Abbiamo smesso di ridurre i progetti a “la parte che facciamo noi” e abbiamo iniziato a progettare la soluzione intera. Per una consulenza è la differenza tra essere una voce di costo ed essere l’architetto di riferimento — e per me personalmente è la differenza tra eseguire il piano di qualcun altro e disegnarlo.
Diversificare non è slealtà verso Salesforce. È ciò che ci permette di portare Salesforce più lontano.
Se stai valutando come combinare Salesforce con un’architettura cloud più ampia, mi fa sempre piacere confrontarmi.