|
Focus: Servizi e Portali Web e-Commerce, m-Commerce... u-Commerce, vortal, e-marketplace, e-chipiùnehapiùnemetta. Chi siamo, dove andiamo, che facciamo? Come lo facciamo? In questo articolo, presente e futuro di portali ed e-commerce. Portali e e-Commerce: a che stadio siamo?
L'ondata di entusiasmo che ha coinvolto il nostro settore negli anni passati si va bruscamente ritirando. A suggerirlo non sono solo gli inquietanti segnali che provengono da tutto quanto era "new economy", ma anche le premesse con le quali si affrontano i progetti che nascono ora, dove l'imperativo è: fare poco, fare bene. Anche la primitiva illusione che l'e-Commerce avrebbe travolto il mondo si è andata ridimensionando. Da questa constatazione è però possibile ricavare alcuni spunti di riflessione, da cui partire per costruire le prossime applicazioni di commercio elettronico.
e-Marketplace e Vortal Nonostante il mio intento sia quello di dare qui un contributo tecnico alla questione, non posso non accennare alla filosofia che deve essere alla base di un'applicazione di commercio elettronico che abbia qualche chance di avere successo, anche perché questa filosofia di fondo va ad influire pesantemente sulle scelte tecnologiche che andranno poi fatte. In particolare, quello che si è capito è che un portale generalizzato di e-Commerce rivolto al mercato consumer in genere non funziona. Non funziona per tutta una serie di motivi, primo fra tutti l'intrinseca insicurezza delle transazioni via carta di credito - cioè il fatto che non esiste ancora un modo standard e sicuro per accertare che chi è alla tastiera del PC sia effettivamente il possessore della carta di credito di cui sta immettendo numero e data di scadenza. In Italia, poi, dove la diffusione e l'uso delle stesse non è così popolare come in America, la situazione è ancora peggiore. Per non parlare dei costi e tempi di spedizione. Insomma, l'idea che un negozio si potesse "portare su Internet" non si è rivelata così vincente come ci si aspettava. Questo per quanto riguarda il B2C (soluzioni di e-Commerce rivolte al pubblico). Il discorso non è molto diverso per il B2B (e-Commerce tra aziende), laddove alcuni studi (di cui ho tentato di dare un'immagine in [1]) hanno rivelato che le soluzioni di EDI hanno portato in generale più costi che benefici e, sempre in generale, non hanno saputo prendere completamente il posto delle normali transazioni effettuate con i media tradizionali (telefono, soprattutto). Anche qui: chi pensava di applicare le vecchie regole del commercio al nuovo mezzo informativo (Internet o rete privata che fosse), ha fallito ed è dovuto tornare sui suoi passi. Ma chi avuto successo, dice un rapporto del Delphi Group [2], ha saputo operare in maniera innovativa. Si sono in particolare imposti due paradigmi, uno per il B2B - a volte chiamato e-Marketplace - e uno per il B2C - definito dallo stesso Delphi Group: Vortal, ossia portale verticale. L' e-Marketplace è un luogo virtuale dove operatori dello stesso business si incontrano, si confrontano e scambiano le loro merci. Qui il valore è dato dal fatto che operazioni ripetitive come: ricerca del miglior fornitore/acquirente, confronto prezzi, disponibilità, tempi di consegna possono essere automatizzate in modo semplice, trasparente per tutte le parti in gioco ed efficace. Immaginiamo per esempio un www.pasticcerieitaliane.it in cui i maggiori venditori di dessert possano esporre i loro cataloghi, le loro disponibilità aggiornate in tempo reale, tempi e modi di consegna. La parola chiave è aggregare: attorno a interessi comuni, attorno ad un business, attorno ai processi di trasformazione di un certo bene. Le economie di scala, il risparmio sui costi di risorse umane, e la maggior velocità di risposta rappresentano valori reali. Lo stesso concetto di "aggregare attorno a interessi comuni" è alla base del "Vortal" (Vertical Portal), il portale di e-Commerce B2C rivolto ad una comunità (community) di utenti consumatori che condividono una stessa passione, uno stesso interesse. Il Portale delle Carte dei Pokémon, il Portale della Pesca Subacquea, Il Portale delle Vacanze Intelligenti, il Portale degli e-Book, il Portale della Famiglia basta usare la fantasia. Qui la passione e l'interesse sono tali da vincere il disagio che possono provocare l'utilizzo di una carta di credito sul Web e l'attesa e il costo legato alla spedizione. Perché so, per esempio, che quella carta dei Pokèmon, a quel prezzo, la posso trovare solo lì. E perché anche i miei amici, che condividono i miei interessi, comprano lì. Il Vortal in più può essere cross-mediale: coinvolgere significa creare un brand e diffonderlo attraverso la televisione, i giornali, la radio, i telefonini. Quanto più l'utilizzo del Web è integrato con i media classici, tanto più si ottiene il risultato di creare qualcosa di irrinunciabile per l'appassionato. Di qui l'applicazione di e(lectronic)-Commerce si muove verso il m(obile)-Commerce (attraverso device mobili come il cellulare o il palmare) e infine verso l'u(ntethered)-Commerce: il commercio "scollegato" da qualsiasi vincolo mediatico (cavi, reti fisse o mobili), ma anche il commercio che ruota intorno a te (you), intorno ai tuoi interessi, alla tua specificità, alle tue preferenze. Da questo scenario segue che l'applicazione di e-Commerce prossima ventura non sarà basata esclusivamente sui moduli software classici:
ma sarà sempre più affiancata da moduli che eravamo abituati a vedere nei portali generalisti classici orientati alla community:
Architettura del sistema Come si costruisce un Vortal? Attorno a quali tecnologie si sviluppa un e-Marketplace? Quale hardware? Quale software? Forse ciò che veramente conta sono le idee e un buon grado di conoscenza della tecnologia di cui già disponiamo. Progetti eccessivamente ambiziosi, costruiti su tecnologie nuove e promettenti, ma non ancora sufficientemente testate e "acquisite" dalla comunità degli sviluppatori sono destinati all'insuccesso. Questa esigenza di semplicità e mantenibilità non è soltanto un requisito accademico, è il fattore che spesso determina il rispetto del piano di sviluppo e il time-to-market. Non è sempre vero che l'architettura più alla moda, che in genere è anche la più costosa e complessa, sia necessaria per fare una buona applicazione di e-Commerce, anzi spesso è vero il contrario. Si sono viste idee vincenti sviluppate con tecnologie povere e a volte persino open-source. Questo perché porsi degli obiettivi realistici può essere una soluzione più efficace che pensare di poter rispondere a qualsiasi esigenza presente e futura (con la quale pretesa il risultato è quasi sempre un sito eccessivamente lento e perciò inutilizzabile). Detto questo, non basta un web server qualunque e un po' di html per rispondere a qualsiasi esigenza. Se si prevede un traffico notevole, se l'applicazione deve essere in grado di veicolare contenuti dinamici (sia in termini di frequenza di aggiornamento, che in termini di molteplicità di formati: jpg, mp3, asf, ram), se infine occorre inglobare nell'applicazione la logica finanziaria e transazionale, allora il sistema sottostante deve essere adeguatamente dimensionato. Il diagramma mostrato in Figura 1 è una possibile architettura hardware e software per un'applicazione di e-Commerce di complessità medio-alta. È solo un esempio, certamente, ma dal quale vorrei far discendere alcuni suggerimenti nati dalla pratica:
Punto uno. Nonostante questa pratica sia abbastanza riconosciuta e applicata, è proprio nelle applicazioni di e-Commerce, in particolare in quelle rivolte al B2C dove il traffico che viene generato è particolarmente pesante, che deve essere osservata. I tre strati richiedono differenti impostazioni hardware e software. Per esempio, laddove per lo strato applicativo può risultare migliore la scelta di avere più mini-server in cluster, per lo strato di database è forse meglio utilizzare un super-server centrale - ma queste decisioni vanno prese a livello sistemistico e sono equivalenti per lo sviluppatore. L'importante è che i dati siano tenuti separati dagli oggetti che li utilizzano. Punto due. Negli anni del boom del Nasdaq, alcune società sono esplose proponendo prodotti estremamente flessibili per l'e-Commerce. Questa flessibilità (io ne ho usati e valutati tre, di altrettante società americane) è in realtà molto limitata. Non discuto l'effettiva potenza del software, discuto i tempi di apprendimento del pacchetto, che comunque è stato sviluppato secondo una ben precisa filosofia. A differenza del mercato americano, dove è possibile incontrare clienti disposti a modificare i loro processi per adeguarsi al sistema informativo, nel nostro mercato è vero il contrario: è il sistema informativo che si deve adeguare ai processi esistenti, che per di più sono in continua evoluzione. La morale è che, secondo me, i migliori strumenti per creare soluzioni di e-Commerce sono il buon vecchio editor, un linguaggio a oggetti e un compilatore. Punto tre. Ora che ho sviluppato i miei oggetti, avendo avuto cura di scriverli il più possibile stateless (oggetti che incapsulino una funzione, non che mantengano dei dati e il loro valore: per questo c'è il DB), ho il problema di renderli disponibili all'applicazione. L'application server è appunto quello strumento (software!) che si preoccupa di mantenere in memoria una schiera di questi oggetti e renderli operativi quando ce n'è bisogno. Esempi di application server: COM+ in ambiente Windows; Netscape iPlanet o BEA WebLogic in ambiente Java/Solaris. Punto quattro. Contrariamente alla tecnologia di cui al punto tre, che è relativamente nuova e perciò con molti problemi di bug e performance ancora da risolvere, la tecnologia dei DBMS relazionali è acquisita e certamente stabile. Per questo la tendenza è quella di memorizzare ogni valore, ogni variabile di stato degli oggetti, sul DB. Se il web server o l'application server non hanno un sistema di logging adeguato, anche il log va messo sul DB. Credo che non ci sia peggior luogo comune da sfatare che vuole che un'operazione sul DB sia più lenta di un'operazione diretta di I/O su disco. In un'architettura multi-tier avremmo, per esempio, duemila oggetti istanziati pronti a scrivere su disco piuttosto che sul DB: quel sistema è destinato alla paralisi. I DBMS sono applicazioni create apposta per gestire la concorrenza e la frequenza di operazioni di scrittura/lettura: usiamoli. Se poi scopriamo che abbiamo bisogno soprattutto di leggere e raramente di scrivere (es.: archivio utenti del sistema), allora un buon pacchetto di LDAP avrà prestazioni molto superiori anche a quelle del miglior DBMS. Aggiungo che se qualche utente malizioso usa un trucco per inviare un codice dannoso, se questo finisce sul DB è innocuo, se finisce sul file system invece…
Dietro le quinte Un'applicazione di e-Commerce è costituita, oltre che da tutto quanto è visibile sul sito - per esempio la gestione del carrello - anche da tutta una serie di moduli che rappresentano l'infrastruttura del sistema. Insieme si presentano e interagiscono tra loro come in Figura 2. Si tratta di: - CMS Sta per "Content Management System". È un pacchetto (vale la regola del make piuttosto che buy, ma se non si dispone di sviluppatori esistono numerose soluzioni come Vignette, OpenMarket) che consente la definizione della struttura dei contenuti (asset), del loro layout grafico, la revisione, e infine la pubblicazione (con o senza livelli intermedi di staging, ossia di siti dove è possibile vedere anteprime di come i contenuti verranno pubblicati). Il CMS deve permettere ad una squadra di redattori di comporre e modificare in modo facile i contenuti che appariranno poi sul sito. Questo tenendo conto delle logiche di workflow (chi può creare l'asset, chi lo può modificare, chi cancellare, chi pubblicare e via dicendo) e di sicurezza (in un e-Marketplace possono esserci logiche di permission sugli asset simili a quelle che siamo abituati a vedere nei comuni pacchetti di gestione documentale per Intranet aziendali). L'asset più importante - che può o meno ricevere dati dal sistema gestionale, quindi per esempio SAP - è il catalogo. - MQ (Gestore di code di messaggi) Un gestore di code (Message Queueing) permette lo scambio di messaggi tra due sistemi in modalità asincrona, in qualsiasi condizione di carico, assicurando che il messaggio
Ciò permette una corretta trasmissione delle informazioni critiche tra i sistemi, anche in caso di guasti o malfunzionamenti temporanei. Perciò nel nostro sistema, tutti i messaggi fra i vari attori (venditore, compratore, banca, sistema di logistica, sistema di e-fulfillment) vengono scambiati da gestori di code (in entrata e in uscita) installati o su ciascun sistema, o su un server centrale accedibile attraverso una rete privata. I messaggi, come vedremo in seguito, possono essere documenti XML cifrati. - Sistema transazionale Esistono almeno tre livelli di gestione delle transazioni:
Solitamente sono gli enti che gestiscono i circuiti delle carte di credito (es.: Servizi Interbancari) o il Bancomat ad offrire le funzionalità necessarie attraverso apposite interfacce ai loro sistemi. In genere all'applicazione di e-Commerce è richiesta la sola verifica della solvibilità finanziaria del cliente e non la transazione vera e propria. Di questa e di altri dettagli si occupano di solito società che offrono i cosiddetti servizi di e-fulfillment. - Servizi di e-fulfillment In genere venduti dalle maggiori società di consulenza, offrono in outsourcing tutte quelle operazioni che partono dal momento in cui l'ordine è acquisito verso la transazione finale. Si tratta della parte più cruciale dell'applicazione ed è quindi importante che sia svolta da un'organizzazione competente e specializzata. Oltre infatti all'aspetto economico (la somma in denaro congelata sul conto del cliente viene effettivamente spostata sul conto del venditore), l'e-fulfillment si occupa anche della logistica (eventuale movimentazione fisica delle merci) e delle eccezioni (tutte le procedure di mancata consegna, per esempio). Se si utilizzano tali servizi, in genere lo scambio di messaggi tra il nostro sistema e quello dell'e-fulfillment avviene attraverso documenti XML cifrati depositati nelle code di cui abbiamo parlato. - Servizi di hosting (ASP) Una volta che il progetto di e-Commerce è stato sviluppato e testato, è tempo che venga installato e ospitato presso un Application Service Provider. Si tratta, anche in questo caso, di servizi in outsourcing volti a pubblicare e mantenere in vita l'applicazione. L'ASP tipicamente si occuperà delle problematiche sistemistiche (quali e quanti server, quali connessioni di rete), di manutenzione (assicurare che il servizio sia sempre attivo e funzionante), business intelligence (quante page view, quante hit, da parte di chi, con che frequenza) e di Web Desk. Credo che quest'ultimo sia un aspetto decisamente critico. Il cliente che acquista via Internet non deve mai avere la sensazione di aver comprato qualcosa "da una macchina" e nemmeno di non poter sapere in che stato si trova il suo ordine (è stato accettato, è stato evaso, è in spedizione, quando la merce sarà consegnata e via dicendo). Il servizio di Web Desk / Customer Care - solitamente compreso nei servizi offerti da un'ASP - è costituito da un operatore (umano!) in grado di seguire il cliente confermandogli l'avvenuto ordine e rispondere alle più comuni domande. Insomma: il lato umano dell'u-Commerce.
Il ruolo di XML Il collante che sta attorno a tutto è rappresentato da una serie di documenti XML, meglio se imbustati in una busta Biztalk (cfr. [3]), che viaggiano fra gli attori del sistema e aggiornano lo stato di un ordine. I vari flussi di interscambio sono evidenziati in Figura 3. I messaggi fondamentali che occorre scambiare sono i seguenti:
Ogni documento XML è un messaggio. A meno che i documenti viaggino su una rete privata o su una VPN, il messaggio dovrà essere cifrato secondo un meccanismo a chiave pubblica - lo possiamo agevolmente fare usando le CryptoAPI se operiamo in ambiente Microsoft, o la JCA (Java Cryptography Architecture) in ambiente Java - e quindi inserito nella coda dell'MQ. Il gioco dell'integrazione fra i vari sistemi è fatto. Qualunque piattaforma utilizzino la banca e il servizio di e-fulfillment possiamo essere certi che saranno in grado di decodificare e interpretare attraverso un parser XML il messaggio che hanno ricevuto.
Conclusioni Sono due, credo, gli elementi che potranno decidere il successo di un'applicazione di e-Commerce prossima ventura: da un lato l'affidabilità - intesa come la capacità di assicurare una piena funzionalità ventiquattr'ore su ventiquattro in qualsiasi condizione di carico - dall'altro la personalizzazione - intesa come la capacità di costruire un sito che proponga dei contenuti veramente interessanti, altamente personalizzati, capaci di aggregare attorno ad interessi comuni - sia sul lavoro, che nel tempo libero.
Bibliografia [1] A.Saltarin - Facciamo e-Commerce con XML - Computer
Programming n. 90
Biografia Alessio Saltarin è technology evangelist in yond_ cross media factory, società del gruppo Fininvest dedicata alla progettazione e sviluppo di applicazioni cross-mediali. Può essere raggiunto tramite l’email asaltarin@programmers.net
|