Attorno all’Xml si è creato un consenso che abbraccia tutti i più grandi vendor e che suona come una garanzia per la diffusione di applicazioni in grado di garantirne il supporto. Molte software house di piccole e medie dimensioni restano tuttavia dubbiose su come affrontar
Maggio 2003,
Ogni volta che sul mercato appare una tecnologia che promette di diventare uno
standard c’è da stare attenti. A parte le normali difficoltà che
punteggiano il cammino di qualsiasi candidato verso gli standard c’è
da aggiungere che quando una "innovazione" è in odore di standard
ecco che viene irrimediabilmente presa di mira dai grandi vendor. O comunque
da tutti coloro che ritengono di poter trarre vantaggio dal fatto di associare
il proprio marchio al nome di uno standard. Il rischio evidente è che
se qualcuno ci riesce viene meno il primo requisito fondamentale di ogni standard,
ovvero il fatto di essere indipendente. Nello stesso tempo, però, se
una tecnologia candidata agli standard non si sporca le mani accettando di mettersi
alla prova nel business, rischia di essere snobbata dai produttori, ovvero da
coloro che poi concretamente hanno la possibilità di tradurla in prodotti
e/o servizi.
È un film ben noto a chi frequenta i "cinema" dell’informatica.
E se si fa eccezione per gli standard de facto, considerabili come un genere
a parte, non ci si deve stupire della grande attenzione con cui i big seguono
le avventure e disavventure di ogni candidatura e in particolare, oggi, dell’Xml.
Mettere le mani su una tecnologia "standard" significa assicurarsi
un potentissimo veicolo di marketing. Viceversa, non riuscire a mettere il proprio
marchio sul carro di uno standard vincente comporta pesanti conseguenze in termini
di opportunità di vendita. Anche e per questo la storia dell’informatica
è piena di standard annunciati ma poi persi per strada, vuoi perché
non hanno mantenuto le promesse sul piano tecnico, vuoi perché qualcuno
è riuscito a metterci sopra il proprio marchio. Così come è
ben ricca di standard de facto, ovvero di tecnologie che senza avere l’assenso
preventivo di istituti, enti o consorzi si sono affermate in quanto sono state
scelte dagli utilizzatori. Tutta questa premessa serve per affrontare con la
dovuta cautela il tema Xml. Attorno a questo linguaggio si è creata una
straordinaria intesa, tutti sono d’accordo nel considerarlo come il linguaggio
di riferimento per il futuro, come l’unico formato in grado di garantire una
vera interoperabilità e come il tassello fondamentale per la creazione
dei Web services, ovvero per poter dare vita a delle librerie applicative accessibili
via Web.
Sul grande quadro strategico Xml ha già segnato parecchi punti a proprio
favore, è stato, come detto, unanimemente accettato e sul tema dell’interoperabilità
ha iniziato a essere collaudato come sistema ponte tra ambienti, applicazioni,
mondi diversi. In altre parole, i grandi nomi in generale stanno già
di fatto utilizzando Xml come uno standard.
La situazione è certamente più complessa se si guarda al mondo
delle piccole e medie software house, ovvero alla stragrande maggioranza del
mercato italiano. In questo caso Xml è sì conosciuto e diffuso,
ma è ben lontano da essere considerato uno standard. Al contrario esso
rappresenta oggi più che mai una nuova sfida che in tempi grami come
quelli attuali rischia di trascinare più scetticismo che entusiasmo.
E sarebbe un bel guaio.
L’opportunità di sviluppare in Xml
Il problema di fondo è che Xml, come ogni altra tecnologia, per essere
abbracciata da una software house richiede cospicui investimenti, un forte impegno
in termini di sviluppo, di creazione di una rete di collaborazioni, di testing.
Ogni buon amministratore, anche il più entusiasta, prima o poi si trova
a chiedere se ne vale la pena, se l’adozione di Xml aumenta la possibilità
di vendere nuovi prodotti o vendere meglio quelli esistenti. E la risposta non
è certo nelle mani dello sviluppatore o del team dei product manager.
La risposta sta tutta nella capacità dell’azienda di collocare i propri
prodotti all’interno di una architettura di alleanze tecnologiche con fornitori,
partner e clienti basata anche sull’Xml. In altre parole non è la semplice
implementazione del linguaggio Xml che produce in sé risultati. Ciò
che vale è la capacità di trasformare l’Xml in un veicolo strategico
con il quale garantire l’interoperabilità con altre imprese o istituti
o distretti che condividono la stessa scelta. Questo secondo aspetto, di tipo
strategico, costituisce l’unico vero strumento in grado di conseguire un obiettivo
di tipo commerciale. Perché se l’ambiente nel quale si fa ricadere l’offerta
Xml è un contesto che condivide questa necessità allora si può
rispondere affermativamente a quell’amministratore che chiede se poi, alla fine,
venderà di più. Dunque prima ancora di essere un problema tecnico
e di sviluppo l’Xml è, per le piccole e medie software house, un problema
di tipo relazionale, politico-commerciale.
Perché dal punto di vista tecnico la questione è certamente più
semplice, il vantaggio competitivo dell’Xml è evidente e consiste nel
dare risposte nuove ad antichi problemi, intervenendo sul modo in cui vengono
prodotti i documenti e garantendo una indipendenza dalle applicazioni, dalle
piattaforme, dai sistemi operativi ecc. In altre parole, trasferendo sul linguaggio
problemi tuttora irrisolti che prima erano affrontati a valle, ovvero facendo
i conti con gli ambienti operativi e con le applicazioni.
Banalizzando la questione, Xml svincola il documento prodotto dall’applicazione
e dal sistema operativo e la rende autonoma e indipendente lasciando all’utilizzatore
(e allo sviluppatore) la possibilità di poterne usufruire o di poterla
elaborare nelle modalità a lui più congeniali e appropriate.
Non è tutto oro quel che luccica
Certo, se tutto fosse esattamente così, l’Xml sarebbe la soluzione immediata
a un sacco di problemi, ma così non è. La realtà è
sempre più complessa della teoria e chiama in gioco da una parte i limiti
della tecnologia e dall’altra – per l’appunto – quell’invincibile desiderio
di ciascun operatore di appropriarsi o di mettere un proprio sigillo su qualsivoglia
nuova tecnologia vincente faccia capolino sul mercato. Il limite della tecnologia
merita, nel caso dell’Xml, una storia a parte. Il vero problema riguarda il
modo con cui i grandi veicolatori di una tecnologia come l’Xml decidono di metterla
a disposizione del mercato. In altre parole l’Xml come tantissime altre tecnologie
può essere utilizzata così com’è, rispettando quelle caratteristiche
che ne fanno uno standard de facto, oppure può essere interpretata, ovvero
può essere oggetto di ulteriori sviluppi dando luogo di fatto a una nuova
versione che banalizzando viene definita dialetto e che di fatto toglie ossigeno
a quella che è la caratteristica fondamentale di ogni standard, ovvero
il fatto di essere condivisa da tutti nelle sue caratteristiche essenziali.
E non è solo o necessariamente questione di business opportunity, non
è cioè che un produttore decide di mettere le mani sulla tecnologia
allo scopo di appropriarsene vincolando così lo spazio di manovra e di
scelta dei propria partner o clienti. In molti casi è necessario mettere
le mani sulla tecnologia per consentirle di dare risposte adeguate ai servizi
che è chiamata a risolvere. Un bell’esempio lo si può trovare
nel sistema Moda-Ml di cui si parla nell’articolo a pagina 60. Ed è proprio
questo tema che introduce il problema che sta sul tavolo di molte software house
e che necessita di trovare una sua soluzione. Vale la pena di investire sull’Xml
e se sì con quale approccio?
La risposta tecnologia e politica alla prima domanda è già stata
data ed è certamente affermativa. Non solo ne vale la pena, ma l’Xml
costituisce la premessa per dare alle proprie applicazioni un nuovo vantaggio
competitivo e per non rimanere emarginati nel momento in cui la diffusione di
questa tecnologia assumerà a tutti gli effetti i connotati di uno standard.
