Quanto senso ha parlare ancora di applicazioni web o mobile? Il mondo dello sviluppo tende sempre più verso approcci che guardano all'omnicanalità come strumento per integrare questi contesti.
In ambito IT si parla di software headless (es. “headless Java”) per intendere un software capace di girare su un qualunque device senza un’interfaccia grafica. Il software riceve e restituisce dati interfacciandosi con una rete di servizi embedded.
Traslando il concetto sullo sviluppo di applicazioni Web o Mobile, parliamo ugualmente di applicazioni headless distinguendole dallo sviluppo web e mobile standard in cui ogni applicazione (sito o portale) ha il proprio apparato backend e frontend con interfaccia utente dedicata.
In queste installazioni tradizionali tutti i pezzi del puzzle lavorano con lo stesso codice base e comunicano in maniera diretta tra loro, rendendo l’applicazione un sistema unico e profondamente interconnesso. In un’applicazione headless invece il front-end è un pezzo di puzzle a sé stante, un software che in qualche modo sta in piedi da solo, per semplificare il concetto.
Come va allora ad integrarsi con il back end, vi chiederete voi? Lo fa attraverso le API: le due parti vitali del software – backend e frontend - operano separatamente l’una dall’altra potendo addirittura girare su server differenti (creando in questo modo una sorta di miniatura di un’architettura multi-server).
Le Api fanno da ponte tra i due sistemi, facendoli comunicare e connettendoli l’uno all’altro in modo che operino sì separatamente ma restando interconnesse. Il principale vantaggio di questo tipo di applicazioni consiste nell’ottimizzare considerevolmente le prestazioni e la flessibilità dell’applicazione stessa.
A questo punto caliamo il concetto di Web Application nel contesto dello sviluppo di un eCommerce B2B. In un approccio headless il front end del tuo shop eCommerce sarà separato e distinto dal suo back end, in gergo saranno “decoupled” (disaccoppiati).
La presentazione del contenuto sarà separata e autonoma rispetto alle logiche di business e alle funzionalità (ad esempio lo stack tecnologico dell'eCommerce esistente, le eventuali integrazioni di parti terze, la gestione stessa dell’eCommerce).
Questo tipo di architettura offre quindi il vantaggio di tenere separati i due piani d’interesse - il piano relativo all’esperienza cliente e quello relativo alle funzionalità di sistema – permettendo al team di sviluppo di creare soluzioni meno standard e più flessibili rispetto alle singole esigenze di progetto.
In un sistema headless, la parte dell'e-Commerce B2B con cui va ad interagire l’utente può essere gestita via CMS, o tramite una soluzione eCommerce costruita col suo stack tecnologico dedicato (React o Angular o persino come app mobile) o come una combinazione di entrambe (cosa che facciamo ad esempio nelle soluzioni eCommerce B2B SAEP).
La sempre più popolare diffusione delle applicazioni di tipo headless è dovuta fondamentalmente al crescente impiego di device mobili per la navigazione Web e l'acquisto online. Ne derivava quindi una costruzione a blocco unico della relativa applicazione con front end e back end accoppiati e interlacciati.
Ma con l’avvento della tecnologia mobile e multidevice è cambiato tutto: oggi non sono gli acquisti online sono aumentati vertiginosamente, ma passano attraverso una fruizione mobile e multidevice che ha reso necessari nuovi approcci di sviluppo.
Nel nuovo eCommerce B2B omnichannel la necessità primaria è la flessibilità: questa non può più essere garantita da una soluzione “full stack” in cui front end e back end vanno strettamente a braccetto per cui una modifica su un versante rende necessario l’allineamento sull’altro.
Marchi che storicamente hanno sempre utilizzato il loto sito web come una semplice “vetrina” dei propri contenuti sentono oggi la necessità di espandere il potenziale delle funzionalità accessibili online, soprattutto nel settore del B2B. Quello che tipicamente succede è che, data la massa di contenuto presente sul sito “storico” risulta molto più semplice costruire da zero un nuovo motore eCommerce e connetterlo al Content Management del sito storico, piuttosto che rifare questo da zero. Nel caso di siti particolarmente “vecchi” può in effetti avvenire anche il contrario, per cui si va a ricostruire il sito ex novo importando i vecchi contenuti (e -si spera- cogliendo l’occasione per una bella revisione ;)) e lo si va poi a connettere col nuovo motore eCommerce stand alone.
I moderni utenti di un B2B hanno bisogno di funzionalità d’acquisto avanzate: la piattaforma di eCommerce B2B dovrà prevedere – lato front end- offerte e listini personalizzate, mentre lato back end dovrà offrire ad agenti e uffici vendita la possibilità di aggiornare facilmente e rapidamente informazioni e contenuti caricati sul portale.
Con front end e backend disaccoppiati le aziende potranno caricare offerte e gestire piani di vendita in autonomia, senza bisogno di rivolgersi agli sviluppatori e senza alcun timore che i dati del “motore” eCommerce vengano in alcun modo compromessi.
La personalizzazione della propria offerta, la crescita delle funzionalità messe a disposizione sul portale, tutti gli aspetti vitali che rendono il tuo eCommerce unico e ben riconoscibile agli occhi dei tuoi clienti implicano del lavoro e della sperimentazione sul back end della piattaforma.
Il fatto che quest’ultimo sia disaccoppiato rispetto al portale disponibile agli utenti implica che non ci siano rallentamenti né disservizi nel funzionamento dei normali processi di acquisto e vendita mentre lato continua la ricerca di innovazione e di crescita del portale.
Il disaccoppiamento di front end e back end implica anche che nuove funzionalità ed integrazioni possono essere aggiunte in minor tempo e con a basso impatto in termini di lavoro, tempi di sviluppo e quindi costi proprio grazie al fatto che l’architettura è aperta, flessibile e predisposta per sua natura ad accogliere cambiamenti ed innovazioni nel sistema.
Quali aziende hanno più bisogno di un eCommerce B2B moderno? Tutte quelle che mirino a veicolare prodotti e servizi in maniera altamente personalizzata e che si rivolgono a settori e target di mercato molto distinti e caratterizzati. Oppure per tutte quelle realtà con un vasto e articolato portfolio clienti, con brands e divisioni interne ognuna con il proprio workflow di riferimento o con processi di approvazione e governance dei contenuti diversi.
Categorie:
