Il World Wide Web nasce dal lavoro di Tim Berners-Lee presso il CERN di Ginevra e vede praticamente la luce nel 1991 basato sul protocollo di comunicazione HTTP, sviluppato come protocollo di rete per la distribuzione di documenti scritti in HTML (Hyper Text Markup Lenguage) visualizzabili dagli utenti via browser, un programma apposito che rende il codice HTML.
Originariamente consisteva in una serie di documenti usati dagli scienziati e dai ricercatori per condividere idee e informazioni. Mano a mano che sempre più utenti iniziarono ad usare la rete si sviluppò la necessità di interagire con questi documenti ma il modello operativo originario consisteva in un server Web che non faceva altro che fornire, su richiesta, i vari documenti.
Con questo sistema, senza un esplicito intervento del programmatore, i contenuti delle pagine non cambiavano mai, questo rendeva le informazioni ivi contenute difficilmente riutilizzabili e decisamente poco flessibili oltre che assai onerose da tenere aggiornate.
HTTP infatti è un semplice protocollo con comandi elementari di richiesta e risposta, dove un browser dopo aver inviato al server la richiesta di un determinato documento attraverso il comando GET si vede restituire dal server sotto forma di codice HTML il documento specifico che rende sullo schermo dell'utente.
Tuttavia nel corso del tempo è diventato evidente che l'HTML aveva alcuni limiti intrinseci che impedivano agli sviluppatori di sfruttare appieno le potenzialità del medium sul quale veniva utilizzato; il più grosso di questi si è dimostrato essere la commistione fra elementi di presentazione, cioè come devono essere disposti i vari componenti di una pagina, ed elementi di strutturazione, ovvero com'è organizzata logicamente una pagina.
Con l'introduzione dei fogli di stile o CSS questa contraddizione si è fortemente attenuata e con l'uso di passaggi intermedi per la generazione di codice HTML, la triplice XML-DTD-CSS, è ormai possibile presentare le stesse informazioni per “viste” diverse a seconda del device o della versione del software che le richiedono, quindi viste solo testo per browser testuali o lettori braille, versioni semplificate per la stampa o apposite per palmari, cellulari ecc.
Tuttavia rimane il fatto che le informazioni non possono essere utilizzate contemporaneamente in contesti diversi e che è quindi molto difficile e costoso tenere traccia delle duplicazioni, tenere tutte le parti di un sito aggiornato, presentare nelle varie sezioni contenuti che siano coerenti fra di loro, provvedere a mantenere attivi i link senza lasciarne di obsoleti.
Nella mente degli sviluppatori ha cominciato a farsi strada l'idea che se i contenuti (le informazioni) fossero stati del tutto indipendenti dalla disposizione sia visiva che logica all'interno delle pagine di un sito e richiamabili a piacere tramite richieste specifiche, per venire poi strutturati e impaginati prima dell'invio al browser che ne aveva fatto richiesta, sarebbe diventato molto più semplice la gestione delle grosse moli di dati che si stavano creando, sia abbassando i costi di gestione e manutenzione, sia rendendo più efficienti i sistemi con cui si rendevano accessibili le informazioni agli utenti di internet.

I programmatori non tardarono ad accorgersi che se HTML poteva essere scritto a mano, uno script Perl, ad esempio, poteva avere la stessa funzione e lo stesso risultato dato che al browser sarebbe sempre stato inviato codice HTML che sarebbe stato interpretato nella maniera tradizionale. Così incorporando nella URL di un documento alcuni parametri ad hoc usabili come variabili una richiesta HTML può diventare una query ad un database i cui risultati vengono trasformati dallo script in codice HTML che il server invia a seguito della richiesta ad un browser.
Nacque così CGI (Common Gateway Interface) che fu creata per consentire proprio l'interazione fra gli utenti e i siti Web e che incrementò in maniera significativa la funzionalità pratica di Internet. Improvvisamente i documenti potevano cambiare in funzione dei parametri cui erano associati, incorporando dati da altre sorgenti o modificandoli o creando nuovi collezioni di dati attraverso form con cui gli utenti inviavano al server informazioni.
Ma dal momento che CGI solamente definisce come il server Web debba comunicare con i programmi deputati a processare le informazioni provenienti dalla rete, i programmatori si trovavano nella costante necessità di riscrivere da capo tutte le altre componenti di una applicazione Web ogni volta che volevano implentare qualche cosa di nuovo.
Inoltre il funzionamento di CGI, che in pratica riceve una determinata richiesta da un browser, di solito la richiesta di un file in una determinata directory o con .cgi come estensione, ne interpreta i parametri come coppie chiave/valore e le intestazioni come variabili d'ambiente per poi svolgere determinate azioni in base a questi valori, di solito un accesso ad un database dal quale attinge le informazioni richieste, per generare infine del codice HTML e fornire al browser una risposta comprensibile alla richiesta HTTP che era sta inviata; ebbene,questo modo di CGI di funzionare crea sul server un nuovo processo per ogni richiesta, la qual cosa in situazioni di elevato traffico rende o troppo onerosa (necessità di avere troppe macchine dedicate al processamento delle richieste), o troppo lenta (le macchine che ci sono sono sovraccariche di lavoro) la soddisfazione delle richieste HTTP.
A un certo punto di sviluppo del traffico in rete quindi CGI diventa decisamente inappropriato a gestire le richieste del mercato.

I linguaggi di scripting lato server sono ad oggi la migliore risposta che è stata fornita dalla comunità informatica per semplificare e rendere più efficace la creazione di pagine dinamiche. Questi linguaggi consentono ai server sui quali sono configurati gli opportuni moduli, di assemblare al momento la pagina che il client richiede, prendendone i contenuti da sorgenti esterne, fornendo contemporaneamente gli stessi contenuti in più contesti, non intasando il server di processi e cambi di contesto dal momento che girano come muduli interni allo stesso server HTTP di solito una sola istanza di un processo.

I più diffusi sono:

• ASP, sviluppato da Microsoft, le pagine .asp possono contenere al loro interno spezzoni di HTML che non vengono processati ma inviati così come sono e parti VBScript basato su VisualBasic o Jscript, linguaggio simile a Javascript e utilizzato nelle Java Server Page

• PHP, linguaggio a sorgente aperto espressamente sviluppato per il web che com ASP consente di mescolare parti di HTML e di PHP, l'estensione delle pagine è .php e consente sia la connessione con i database sia la generazione di pagine in più linguaggi, come XML, HTML, XHTML oppure di documenti PDF e filmati Flash.

• JSP-J2EE queste tecnologie per server Web hanno combinato tutte le potenzialità di Java con la connettività a database, l'accesso alle reti, le operazioni multithread e, soprattutto, un nuovo modello di elaborazione. I servlet e le pagine JSP operano da un'unica istanza che rimane in memoria e utilizza più thread per rispondere simultaneamente a più richieste di servizi. I servlet e le pagine JSP possono inoltre utilizzare l'ambiente J2EE (Java 2 Enterprise Edition) che consente di realizzare applicazioni sofisticate e solide.

Esiste inoltre la possibilità di utilizzare come linguaggi di scripting lato server anche Python o PERL, a condizione che siano supportati dal server e che siano installati i relativi moduli.

Con questi sistemi la pagina che l'utente va a visualizzare con il suo browser non è altro che l'output di un processo innescato dalla richiesta di un deteminato insieme di contenuti, non più un documento creato una volta per tutte da un programmatore.

L'attenzione è quindi focalizzata sui contenuti che vengono considerati come del tutto separati ed indipendenti dalla modalità con la quale verranno riprodotti sullo schermo dell'utente; a sua volta la disposizione visuale, il layout, può quindi essere gestito a prescindere dai contenuti specifici che vi verranno rappresentati.

La gestione separata dei due momenti fondamentali della funzione di un sistema di pubblicazione di informazioni via internet/intranet, la creazione dei contenuti e la loro disposizione in uno spazio digitale, è il primo passo che è stato necessario per iniziare a riflettere su come utilizzare meglio le possibilità che la diffusione elettronica dei dati poteve offrire. Sono iniziate così a circolare nella comunità degli sviluppatori, librerie di applicazioni web che permettevano di mettere online semplici portali in maniera automatica che potevano poi essere personalizzati in modo da avere un look originale i cui contenuti poteveno essere facilmente aggiornati e sostituiti senza la necessità di intervenire in alcun modo sulla rappresentazione delle pagine.

Erano nate le pagine dinamiche, le basi per la costruzione di applicazioni complesse che saranno poi i CMS, i sistemi di gestione dei contenuti

I sistemi di gestione dei contenuti sono nati con lo scopo di rendere gestibili ed efficaci nel modo più semplice ed economico possibile, siti e portali le cui dimensioni e complessità stavano iniziando a diventare problematiche per chi doveva occuparsene. Il continuo aggiornamento delle informazioni, la rapida obsolescenza dei layout, la complessità delle strutture dei siti, la scarsa efficacia della catena di produzione-pubblicazione dei contenuti in rete (ovvero il ping pong autore-programmatore-autore-programmatore) cui si doveva ricorrere per ogni nuova pagina, per ogni aggiornamento sono stati problemi che per essere alleviati in maniera sensibile hanno avuto bisogno di un nuovo modo affrontare la questione del come organizzare l'intero processo di creazione-pubblicazione delle informazioni e della loro gestione informatica.
I CMS orientati alla pubblicazione per il web (Web Publishing Systems) sono una combinazione di database, filesystem e altri moduli software collegati che servono per immagazzinare e rintracciare grossi moli di dati. Una delle differenze tra i sistemi di gestione orientati alla pubblicazione e i database è che i primi possono indicizzare contenuti come testi, videoclips o immagini contenuti in una base di dati cui gli  utenti potranno risalire attraverso una ricerca per keywords, autore, data di creazione ecc., i CMS possono venire utilizzati per creare portali che funzionino come dorsale per la gestione dei dati sia in entrata che in uscita e della loro rappresentazione agli occhi degli utenti del sistema.
In pratica i Content Management Systems sono programmi che si occupano di fare in modo che le unità di informazione si trovino sempre disposte, all'interno di uno spazio digitale accessibile tramite un browser, coerentemente con le regole disposte dallo staff tecnico; un software che permette di gestire ed organizzare la creazione, la  pubblicazione e la dislocazione digitale delle informazioni in maniera coerente con le necessità operative ed organizzative di un qualsiasi ente.

Una possibile definizione di CMS è:
    “A CMS is  a  tool that  enables  a variety of (centralized)
    technical and (decentralized) nontechnical staff to create,
    edit,  manage   and finally  pubblish  a variety  of content
    (such  as text, graphics,  video, and  so  on)  whilst  being
    constrained by  a  centralized  set of  rules,  process, and
    workflow  that  ensure  a  coherent,  validate  Web  site
    apparence”1

Atrraverso l'adozione di un CMS per la pubblicazione una ditta può stoccare e gestire la documentazione elettronica aziendale in modo che i dipendenti possano riutilizzare le informazioni in differenti applicazioni e contesti. Il contenuto pubblicato sul web può anche essre distriubuito a clienti e partner fuori dall'organizzazione: la core application di un CMS è la gestione dell'intero ciclo di vita dei contenuti, dalla creazione alla pubblicazione fino alle eventuali revisioni o alla cancellazione.
Un Sistema di Gestione dei Contenuti orientato alla pubblicazione web permette di dare un layout valido e coerente ad un portale, di organizzarne al meglio la struttura e contemporaneamente permette al personale non-tecnico di pubblicare, aggiornare e di avere la supervisione sui propri contenuti utilizzando una semplice ma potente interfaccia browser-based.

Prendendo come esempio una qualsiasi pagina web quale potrebbe essere quella riportata qui di seguito vediamo come si potrebbero suddividere in diversi contenuti i suoi elementi.

L'immagine in alto a sinistra, per esempio è il logo, le due righe di testo in alto a destra l'intestazione del sito, la dicitura “OROSCOPI VARI” è il titolo della sezione, il rettangolo di testo con lo sfondo grigio uno specifico oroscopo.

Ognuno di questi esempi è un contenuto, che in pratica è una qualsiasi informazione dotata di senso compiuto (es. l'intestazione) direttamente utilizzabile in un contesto adeguato che il sitema di gestione si occupa di organizzare logicamente e visivamente in modo coerente in base alle disposizioni dei programmatori e che fornisce al browser dell'utente in base alla richiesta HTTP che riceve.

I contenuti sono le grandezze elementari con le quali lavora un Sistema di Gestione.

Il trafiletto che riporta l'oroscopo dei nati del topo potrebbe a sua volta suddividersi in sottotrafiletti, le singole unità informative (ad esempio proposizioni) riunite in strutture semplici dotate di senso compiuto (ad esempio un trafiletto) vanno a formare quelli che chiameremo contenuti, cioè le grandezze elementari con le quali un utente di un CMS lavora.

L'aggregazione di contenuti semplici dà origine a contenuti complessi e lo stesso contenuto elementare può essere parte contemporaneamente di più contenuti complessi. Il CMS si occupa ad esempio di presentare all'utente finale contenuti semplici e complessi organizzati in modo da avere uno stile unitario ed ordinato logicamente. Ad esempio in una enciclopedia digitale di cucina il “soffritto di cipolla” potrebbe essere una unità di contenuto ricorrente in tutti i contenuti dove è necessario friggere un battuto di cipolle e carote per la preparazione del piatto. Con un CMS nella sottosezione /primipiatti/pastasciutta le diverse ricette potrebbero essere definite all'interno del sistema con righe di codice che tradotte in linguaggio naturale ed organizzatte in maniera intuitiva potrebbero essere qualcosa di simile:

Ogni volta che un utente richiedesse la pagina della “pasta alla amatriciana” il CMS andrebbe a recuperare i vari contenuti elementari che la compongono dove essi sono memorizzati per poi disporli sulla pagina in modo da fornire una valida ed efficace descrizione di come va preparata tale ricetta.

I contenuti possono essere creati ex novo oppure reperiti da fonti esterne, vengono poi convertiti in un formato interno al sistema, tipicamente XML, per renderli modificabili e gestibili.

Perché sia agevole il reperimento e l'aggregazione dei dati, per facilitarne il più possibile un utilizzo flessibile i contenuti vengono catalogati in base a più indici cui sono associati e che sono i metadati.

Metadati sono ad esempio la data di creazione di un documento ed il suo autore, l'argomento od il riassunto e permettono di avere i risultati migliori nelle ricerche e rendono possibile una catalogazione omogenea dei file disposti per tipologia ad uso degli operatori del CMS. È fondamentale avere un sistema di metadati completo e ben organizzato.
I metadati collegati ad un file non sono da confondere con informazioni relative allo stato del file stesso nel flusso di lavoro, dati che sono unici da sistema a sistema, ma sono informazioni stabili che si mantengono nel tempo e che sono gli stessi su sistemi diversi. Vanno standardizzati il più possibile per permettere risultati ottimali ai motori di ricerca interni ed eventualmente esterni.
Per questo è importante che a tutti i formati dei documenti siano collegati strutture di metadati, per file video potrebbero essere la durata, il soggetto, il produttore; per le immagini la risoluzione, il formato, di nuovo il soggetto e così via. Solitamente un sistema offre svariate tipologie di metadati di defoult ma deve dare la possibilità di crearne di nuovi ad hoc a seconda delle necessità e delle esigenze della specifica organizzazione.

"The association of standardized descriptive metadata with networked objects has the potential for substantially improving resource discovery capabilities by enabling field-based (e.g., author, title) searches, permitting indexing of non-textual objects, and allowing access to the surrogate content that is distinct from access to the content of the resource itself." (Weibel and Lagoze, 1997)

“L'associazione di metadati descrittivi standardizzati con oggetti in rete ha la potenzialità di aumentare sostanzialmente  le possibilità di reperire le risorse rendendo possibile la ricerca basata su campi (ad esempio autore, titolo), permettendo l'indicizzazione di oggetti non testuali, e autorizzando l'accesso a un contenuto surrogato che è distinto dall'accesso al contenuto della risorsa stessa.” da http://dublincore.org/documents/usageguide/

Lo scopo di un CMS è anche quello di gestire la pubblicazione verso l'utente finale di un insieme di contenuti su più media, quindi quello di generare automaticamente codice comprensibile sia dai “lettori braille” sia da device GPRS o UMTS sia viste stampabili o di solo testo. Attua quindi una netta separazione tra contenuti e rappresentazione, fornendo attraverso un motore opportunamente configurato diverse combinazioni degli stessi contenuti rappresentati visivamente in maniera diversa a seconda delle specifiche dei diversi dispositivi. Pur mantenedo la rappresentezione logica costante per qualsiasi genere di utente, i contenuti diventano più flessibili e godibili potenzialmente da qualsiaisi destinatario, dando la possibilità di aumentare il volume di traffico del sito, l'accesso ai prodotti e servizi e di conseguenza il volume di affari.
La possibilità di avere contenuti che siano media-neutral, cioè non dipendenti dal device sul quale saranno visualizzati o fruiti rende possibile tenere in gran conto la questione dell'accessibilità alle informazioni che fornisce all'utente anche un chiaro messaggio “sociale” sull'etica della ditta in tempi in cui i clienti sono molto sensibili a segnali di questo tipo e tutti gli indicatori danno in crescita questa tendenza.

Un CMS orientato alla pubblicazione web organizza tutte le fasi del ciclo vitale di un contenuto, dalla creazione (o dalla sua acquisizione da fonte esterna) alla rimozione, passando attraverso quelle che possono essere successive versioni dello stesso documento che possono a loro volta essere sottoposte alla approvazione di un supervisore che deve potervi apportare modifiche o aggiungere commenti e notazioni. Uno degli standard che più si sta diffondendo nei CMS in questo senso è WebDAV (Web Distribuited Autoring and Versioning), un set di protocolli HTTP che permette agli utenti di editare e gestire files su server web remoti. Qualsiasi client WedDAV può essere utilizzato per la connessione al server CMS e eseguire i metodi previsti, per il ruolo in base al quale si autentica, con il protocollo WebDAV che fornisce poi attraverso l'interfaccia utente del CMS le possibilità di lavorare sui relativi files.
Ma vediamo nello specifico quali sono i modi con cui un CMS può reperire i contenuti di cui terrà traccia:

CREAZIONE: un contenuto viene creato da zero e caricato nel database del CMS, il sistema si occupa anche della creazione e dello stoccaggio dei relativi metadati, in maniera automatica oppure personalizzabile.
ACQUISIZIONE: un contenuto viene rintracciato da fonti esterne al sistema di gestione, quali possono essere database o filesystem remoti ed acquisito come contenuto pronto per essere presentato.
CONVERSIONE: un contenuto acquisito o creato viene modificato nella sua struttura (ad esempio convertito in XML) per poter essere utilizzato dal sistema.
AGGREGAZIONE: un contenuto già in memoria viene suddiviso o aggregato ad altri contenuti per essere più facilmente gestibile con il sistema di metadati in uso.

Il CMS quindi fornisce la possibilità di creare contenuti dal nulla, di cambiarne di esistenti, di modificarne la visualizzazione, di disporli automaticamente nella corretta strutturazione logica attraverso l'utilizzo di template (it. mascherina). Deve inotre dare l'accesso alle persone indicate per lavorare sui vari file nelle maniere indicate, impedendo a chi non ne ha il diritto di intervenire dove intervenire non deve. Questi obiettivi vengono raggiunti attraverso l'implementazione di alcuni concetti chiave: il flusso di lavoro, ovvero come è strutturalmente organizzato il processo di gestione dei contenuti e il loro stato all'interno del sistema; e l'amministrazione della sicurezza che assicura la protezione delle informazioni e l'agibilità degli spazi digitali a chi se ne vede assegnato il diritto.
Vediamo ora più in dettaglio cosa sono queste due aree gestionali del CMS e come funzionano assieme ad alcuni esempi pratici tratti da  CMS attualmente sul mercato.

Il flusso di lavoro è una catena di azioni o di eventi di cui si ha bisogno per raggiungere un obbiettivo. Il flusso di lavoro spesso esprime il processo attraverso il quale si concretizza la realizzazione di un determinato business.

Ogni business ha le sue regole e un esempio di queste potrebbe includere:

• Prima che un documento di un dipendente sia diffuso esso deve essere visto ed approvato da un revisore.

• In una fabbrica di macchine utensili, per ogni macchina da assemblare l’ordine deve essere notificato e ogni cambiamento nello stato dell’assemblamento deve passare dalle strutture della fabbrica.

• Prima che una pagina Web sia pubblicata essa deve essere approvata dagli uomini del marketing, approvata dal web master ed eventualmente tradotta da un traduttore.

Il flusso di lavora organizza logicamente la catena di produzione e definisce il modello da seguire per la realizzazione di un prodotto o la fornitura di un servizio. Dal momento che esiste un’organizzazione logica dei compiti e dei passi necessari è più facile programmare dei cambiamenti o creare nuove strutture concettuali per rafforzare l’ efficacia del processo stesso.

Per cominciare introdurremo due termini: stato e transizione.

Uno stato è un’ informazione su una unità di contenuto in un dato momento. Esempi di stato sono: bozza, da visionare, non visibile e pubblicato. Ogni flusso di lavoro ha almeno uno stato iniziale dal quale tutti i contenuti partono, essi passeranno poi attraverso un certo numero di stati differenti nei quali saranno modificati fino allo stato finale. Nel caso dei CMS gli stati che possono essere considerati finali sono più d’uno a secondo della natura e della finalità dei documenti.

Per ogni unità di informazione che passa da uno stato ad un altro c’è bisogno di una transizione. Una transizione collega uno stato di partenza con uno di arrivo. Ogni transizione può comportare un gran numero di cambiamenti ma comunque essa muove un documento da uno stato ad un altro. Di solito una transizione avviene in seguito a una azione dall’esterno, ad esempio un click di un utente autorizzato.

Per visualizzare meglio il concetto riproporremo qui di seguito l’ esempio che Andy McKay usa nella sua “The definitive guide to Plone”¹ come introduzione all’argomento: il bollettino di pagamento delle carte di credito. (Andy McKay, The definitive Guide Plone, Berkeley, Apresse, 2004, cap. VIII, pp. 2-4.)

1. La banca prepara il bollettino e lo invia al mio domicilio.

2. Ritiro il bollettino e lo pongo sulla mia scrivania. Può succedere abbia dei dubbi su alcune delle voci di spesa e così faccio delle richieste di chiarimento alla banca.

3. Presento alla banca i miei dubbi che a volte possono rendere necessario l’invio di un nuovo bollettino o che vengono risolti in altra maniera.

4. Alla fine del mese saldo il debito da me contratto in precedenza.

Gli stati di questa situazione sono così riassumibili:

• Bozza: il bollettino è stato preparato e mi è stato inviato.

• Revisione: ho ricevuto il bollettino e lo sto esaminando.

• Pagato: il bollettino è stato saldato ed archiviato.

Individuati gli stati occupiamoci ora delle transizioni del caso:

• Spedizione: la banca mi invia il bollettino.

• Pagamento: il bollettino viene pagato.

• Chiarimento: nel bollettino c’è qualcosa di poco chiaro e per questo viene rinviato alla banca per chiarimenti

Il flusso di lavoro di questo processo è quindi visualizzabile attraverso il seguente diagramma:

Una volta esplicitato il processo per il pagamento dei bollettini in un flusso di lavoro, il passo successivo è l’ organizzazione dei ruoli per la sicurezza dei pagamenti. Per adesso questo flusso di lavoro contiene la struttura logica per una applicazione che si occupa del pagamento dei bollettini.
In qualsiasi sistema complesso ci sono utenti, ruoli e gruppi. Questo metodo organizzativo consente ai CMS di gestire in maniera flessibile la sicurezza anche in presenza di comunità di utenti molto numerose e diversificate al loro interno.
Quando un contenuto viene trasformato dal flusso di lavoro da uno stato a quello successivo possono variare anche le impostazioni della sicurezza e le regole di accesso.


Tornando all’ esempio dei bollettini bancari vediamo di ricavarne le possibili regole riguardo alla sicurezza del processo:

Figura 3.2. Le transizioni e le entità che possono attivarle

Da questa prospettiva sono chiare le transizioni e chi può renderle effettive. Non è però chiaro che tipo di accesso ognuna di queste entità effettuerà per compiere le azioni necessarie ad ogni transizione. Per esempio quand’ è che la banca emette il bollettino e quando può essere visionato?
Se solo io ho la possibilità di fare addebiti con la mia carta di credito, la banca senz’ altro può in ogni momento controllarne l’entità e eventualmente fornirmi chiarimenti a riguardo.
Vediamo quindi la tabella in figura 3.3 aggiornata sul tipo di accesso che le entità in questione hanno sul mio bollettino:

Stato	Debitore	Proprietario
Bozza		Spedire, vedere, emettere
Revisione	Pagare, chiedere pagamenti, vedere	vedere
Pagato	vedere	vedere

Figura 3.3. Entità e possibilità di accesso.

Com’ è evidente io non posso emettere il bollettino, solo la banca può. In questa situazione è la banca che è la proprietaria del bollettino. Questa è la dimostrazione pratica del concetto di proprietà digitale di un contenuto: sono il proprietario di una informazione quando le impostazioni della sicurezza mi danno la possibilità di crearla.

Se combiniamo transizioni e azioni con le entità e i ruoli la tabella avrà l’ aspetto seguente:

schema4

Anche se questo esempio è piuttosto forzato illustra un’ applicazione di base del flusso di lavoro.

Tornando ai CMS è importante che un amministratore possa assegnare ruoli diversi a utenti diversi, distribuendo a seconda delle necessità i diritti di accesso in modo da regolare la pubblicazione dei contenuti e la loro modifica.

A grandi linee questi ruoli possono essere raggruppati nella maniera seguente:

i CMS è importante che un amministratore possa assegnare ruoli diversi a utenti diversi, distribuendo a seconda delle necessità i diritti di accesso in modo da regolare la pubblicazione dei contenuti e la loro modifica.

A grandi linee questi ruoli possono essere raggruppati nella maniera seguente:

• Utente anonimo. Non viene assegnato dall’ amministratore, è chiunque navighi nel sito e può soltanto vedere i contenuti espressamente pubblicati e visibili.

• Utente autenticato. Viene riconosciuto dal sistema attraverso un nome utente e una password.

• Editor. È un utente autenticato che ha la possibilità di creare contenuti o contribuire alla elaborazione di quelli esistenti in specifiche aree del sito alle quali ha accesso, ma non ha la possibilità di pubblicare direttamente i documenti editati che deve invece sottoporre al revisore.

• Revisore. È un utente a cui i contenuti vanno inviati affinché vengano rivisti ed approvati per la pubblicazione oppure rimandati al mittente per eventuali modifiche. Tipicamente questo gruppo di utenti comprende i responsabili dei vari dipartimenti.

• Pubblisher. Chi è responsabile della pubblicazione definiva e che rende attivo questo stato.

• Amministratore. Questo utente è responsabile del sistema. È l’ amministratore che assegna ruoli e permessi ed ha accesso a qualsiasi documento. Possono esserci diversi livelli anche per gli amministratori che possono avere delle restrizioni a seconda delle sezioni del sito.

Introduciamo quindi dopo le entità attive all’ interno di un CMS un modello di macchina a stati che si occupa della gestione dei contenuti e che prende in esame flusso di lavoro potenziale tra l’ editor di un documento, il revisore e gli stati di visibile, privato, da rivedere e pubblico.

La figura 3.5 mostra i principali stati e le principali transizioni necessarie per la gestione delle informazioni attraverso un CMS. La linea punteggiata rappresenta una sorta di divisione che sono le impostazioni della sicurezza, alla destra della linea il revisore interagisce con i contenuti. Ogni contenuto può e deve avere soltanto un proprietario ovvero l’ utente che ne è l’autore.

Ora possiamo, proprio come per i bollettini bancari, associare le entità con le azioni e con i permessi in modo da esplicitare i ruoli all’interno del flusso di lavoro.

schema6

Quando un contenuto è stato pubblicato solo il Pubblisher ha la possibilità di ritirarlo e di modificarne il contenuto, il revisore si occupa invece di visionare le bozze che i proprietari propongono per la pubblicazione che se approvate vengono a loro volta passate al Pubblisher che ne rende operativa la pubblicazione.

Come abbiamo visto un flusso di lavoro di un CMS si occupa quindi di gestire in maniera standardizzata ed automatica i contenuti che una organizzazione produce al suo interno come quelli che possono giungerle dall’ esterno, la condizione sufficiente e necessaria è che l’ amministratore assegni ai vari utenti un ruolo nel sistema.

Una entità che non è stata presa per ora in esame è quella di membro di un gruppo. Per il lavoro collaborativo è necessario che i membri di un dipartimento possano intervenire su documenti che pur non essendo strettamente di contenuti digitali sono evidenti e sono stati trattati in precedenza. privati, ovvero accessibili al solo proprietario, non possono nemmeno essere visibili a tutti, la risposta che i CMS danno a questa necessità è la creazione dei gruppi. L’ amministratore può dare la possibilità di creare documenti in uno stato intermedio tra visibile e privato e cioè visibile soltanto ai membri di uno stesso gruppo.

L’ architettura del web non è stata progettata tenendo conto di considerazioni sulla sicurezza, se si esclude il fatto che è una rete decentralizzata a pacchetti progettata per funzionare pur se spezzettata da un attacco nucleare.
Inoltre la prima comunità virtuale è stata formata da ricercatori e studenti, l’ approccio era comunitario e si assumeva che le persone fossero quel che dicevano di essere, nessuno si preoccupava di danni deliberati. Dal momento che oggi la rete è una attività commerciale, ogni sorta di azioni di motivi per commettere azioni prima impensabili è divenuta attuale , ed è necessario mettere in atto serie misure di sicurezza – dagli strati più bassi a quelli più alti dei sistemi – per impedire questo genere di azioni abbiano successo.
Se i documenti di una organizzazione sono gestiti in modo centralizzato e si trovano quindi all’ interno di uno stesso spazio concettuale (il CMS) anche se distribuiti su più server, è necessario che questo spazio si rigidamente compartimentato per assicurare la sicurezza dei dati sensibili e il rispetto della privacy a termini di legge.
Vediamo ora come viene risolto di norma questo problema dai sistemi di gestione dei contenuti.

Ruoli e permessi regolano in pratica la possibilità di accesso dei diversi utenti ai contenuti e alle informazioni presenti nel sito, come accennato nel capitolo sul flusso di lavoro.
Vediamo ora un possibile esempio pratico di implementazione dei ruoli e quali possono essere, al di là della creazione  e pubblicazione dei documenti, le funzionalità critiche di un CMS e come è possibile gestirle

I ruoli ed i permessi sono di solitamente contenuti in una ACL ( Access Control List ). Le ACL sono un modello di gestione della sicurezza che specifica chi può fare cosain un determinato sistema. Se una entità ha il permesso verso un determinato oggetto allora ha anche la possibilità di intervenire e modificare od eseguire tale oggetto.

È poi possibile ulteriormente espandere il modello Access-Control dal lato dei permessi in alcune importanti direzioni:

• Ruoli

• Acquisizioni

• Proprietà

• Ruoli locali

Stabilendo dei permessi per i ruoli e definendo il ruolo di un utente si impostano direttamente i parametri della sicurezza per le diverse famiglie di utenti suddivisi a seconda delle necessità degli amministratori.

Un ruolo va associato ad un utente del sistema. Vediamo ora di esemplificare quali possono essere.

MANAGER: ha la possibilità di effettuare tutte le azioni possibili per defoult., la sua funzione è quella di intervenire e gestire qualunque parte del sito, ha la supervisione sul funzionamento del CMS, può modificarne gli stati.

PROPRIETARIO: è forse il ruolo più importante per la sicurezza dei CMS. È l’ utente che ha creato un oggetto e che può in qualsiasi situazione modificarlo ed eseguirlo.

Dal punto di vista di possibili attacchi o danni al sistema è importante che un utente che accede ad un oggetto che aziona una modifica dello stato corrente possa determinare effettivamente questo cambiamento soltanto se sia l’ utente che il proprietario dell’ oggetto hanno il prerequisito Permesso.

Questa importante impostazione impedisce quelli che vengono chiamati attacchi server-side trojan, possibili quando un utente malicious ha la possibilità di creare sul server del codice eseguibile.

Fondamentalmente questo tipo di attacco presenta il seguente scenario:

1. Un utente malicious crea sul server del codice eseguibile che tenta di di effettuare un’ azione per la quale l’utente non ha i permessi (ad esempio cancellare un folder nella directory di root sul server).

2. L’ utente malicious induce qualcuno che abbia i permessi, ad esempio il proprietario del sito, a visitare la pagina con il codice maligno.

3. Se il codice ha come unica restrizione quella del permesso dell’utente autenticato in quel momento (in questo caso il manager) il codice va in esecuzione e l’attacco ha esito positivo.

È quindi molto importante che per evitare questo e altri tipi di attacco i permessi relativi a codice eseguibile siano gestiti dal sistema e dall’ amministratore in maniera consapevole, un buon compromesso può essere quello di considerare come restricted il codice editato via web e mai concedergli l’accesso al filesystem locale.

D’ altro canto codice creato ad hoc per i più svariati utilizzi deve potervi accedere e in ogni caso una volta pubblicato non ci sono più restrizioni, potenzialmente utenti del CMS potrebbero accedere a tutte le risorse del sistema disponibili con cui il CMS è interfacciato, ma nella maggior parte dei casi questa è più una risorsa che un problema dove i permessi sono impostati correttamente.

L’ UTENTE AUTENTICATO: è qualunque navigatore sia in possesso di una coppia valida username-password. Solitamente per defoult non ha permessi associati al proprio ruolo.

L’ UTENTE ANONIMO: è qualunque navigatore visiti le pagine pubblicate del sito. Conferire permessi a questa categoria di utenti significa conferirli a tutte le altre categorie (a meno di non negarle espressamente nella Access-Control-List).

Nei CMS i ruoli locali vengono usati per garantire dei permessi a determinati utenti in specifiche sottosezioni del sito.

Uno dei modi standard di utilizzarli è quello di dare il ruolo di proprietario a chi crea un oggetto limitatamente all’ oggetto creato e alla sua posizione corrente al di fuori della quale il roulo proprietario non è più valido.

Come esempio ipotizziamo che nella sezione /Prodotti del sito sia contenuta della documentazione che tutti devono poter vedere ma che pochi possono modificare. In questo caso le impostazioni di defoult dovrebbero già garantire una efficace soluzione: tutti possono accedere alle informazioni pubblicate, solo il proprietario o il manager locale editarle.

Al contrario nella sezione accounting che contiene informazioni più delicate c'è la necessità che gli accessi siano più regolati e che soltanto alcuni operatori del dipartimanto abbiano i permessi necessari a visualizzare e/o modificare la cartella. Questa soluzione può essere semplicemente implementata disattivando l'opzione acquisizione o ereditarietà (a seconda dei CMS) dei permessi relativi al folder /Accounting. In questo modo nella cartella i ruoli validi nel resto del sito non sono più validi e ne vanno creati ad hoc per questa sottosezione.

I singoli utenti del sistema possono essere uniti secondo le necessità in gruppi. Un gruppo serve a creare uno spazio di lavoro condiviso dagli appartenenti ad uno stesso dipartimento ad esempio, viene creato il gruppo MARKETING e tutti gli utenti del sistema che rientrano in tale gruppo avranno il permesso di di aggiungere, editare e rimuovere contenuti nel relativo spazio di lavoro.

Il meccanismo è in pratica lo stesso usato per creare i ruoli locali, solo viene implementato più semplicemente e velocemente dal CMS.

Di seguito mostriamo quale può essere un'interfaccia per la amministrazione dei gruppi basata su tool visuali.

Può anche tornare utile assegnare dei ruoli direttamente ai gruppi. Se questo può sembrare strano basta immaginare il caso in cui ci fosse bisogno di organizzare un gruppo di revisori che si occupino della pubblicazione dei documenti pendenti degli altri dipartimenti. Per fare ciò è sufficiente assegnare direttamente ad un gruppo creato per lo scopo (gruppo Supervisori) il ruolo di REVISORE, d'ora in poi tutti gli attuali e futuri appartenenti a Supervisori avranno la facoltà di editare e pubblicare le bozze proposte dagli altri utenti. Anche in questo caso si fa un uso allargato dei ruoli locali tenendo conto che i meccanismi di sicurezza quando controllano i permessi di un utente vanno prima a vedere i permessi dell'utente e subito dopo quelli del gruppo cui appartiene.

In molte situazioni è necessario interfacciare il CMS con altri software già in uso come server di identificazione e database o assegnare permessi particolari in modo automatico per utenti apparteneti a determinati domini, ecco una breve lista delle soluzioni possibili.

AUTENTICATORI VERSO I DATABASE

Per essere in grado di autenticare gli utenti registrati nel DB e sfuttare le informazioni gia registrate in esso il CMS deve poter interagire con i più di diffusi database:

• MySQL

• PostgreeSQL

• Microsoft SQL Server

• Oracle

• Sybase

• Altri

In Questo modo gli utenti già registrati sul DB avranno acceso al sito e il CMS potrà aggiungere o eliminare utenti, recuperarne i dati personali o quantaltro con una query SQL e visualizzarne il contenuto.

AUTENTICATORI SSL

Utilizzano di norma il client SSLv3 per l'autenticazione

AUTENTICATORI NT

Servono per regolare gli accessi al CMS attraverso le impostazion i valide all'interno di domini Windows/NT.

AUTENTICATORI SMB

Hanno la stessa funzione di quelli NT ma per piattaforme diverse da Windows.

AUTENTICATORI /etc Users

Gestiscono gli accessi da domini Unix-Linux.

AUTENTICATORI LDAP E GESTIONE LDAP DEGLI UTENTI

Consentono al CMS di registrare sul server nuovi utenti e di dare l'accesso a quelli già registrati sul server LDAP in conformità con le regole in esso impostate.

L'introduzione della tecnologia client/server e del calcolo distribuito ha portato con sé un'accellerazione della tendenza di dare agli utenti un maggior controllo e possibilità di accesso ai loro dati.
I CMS hanno anche spostato il controllo dalle mani dei programmatori (in questo caso il dipartimento IT o webmaster) a quelle degli utenti finali, dipendenti e non, e più specificatamente i product manager, i brand manager, gli uomini del marketing e altre professionalità che creano correntemente i contenuti dei siti delle organizzazioni sia pubbliche che private.

Molte ditte o enti che nel corso del tempo si sono trovate con l'avere siti corporate di dimensioni sempre maggiori, hanno anche avuto la necessità di pagare grosse cifre per tenere questi siti aggiornati servendosi di manodopera specializzata.
Inoltre al di là delle dimensioni è cresciuta in maniera esponenziale anche la complessita dei siti che sono diventati una delle principali interfacce con il mondo esterno: sia con il cliente finale, sia verso il cosiddetto business to business.
Sono perciò state implementate nuove funzionalità come il commercio elettronico o il datawarehousing e oggi i siti comprendono la descrizione dei prodotti o servizi, tool di raccolta dati, listini, casi di studio, relazioni e ricerche di mercato, rassegne stampa, informazioni per gli investitori, FAQs, informazioni per i servizi ai clienti, le comunicazioni dei e per i dipendenti, offerte speciali, formazione e assistenza.

Dovendo fare da contenitore per tutti queste informazioni spesso i siti, pur partendo come ordinato modello di chiarezza  espositiva e coerenza visuale sono degenerati in un confuso labirinto non appena gli utenti hanno iniziato ad aggiungere i loro contenuti nelle varie sezioni senza sapere (e spesso badare a) quello che gli altri stavano facendo.
Anche se la sembianza di una consistenza di fondo dei dati era rintracciabile (al prezzo di molte ore passate da personale specializzato nel taglia-incolla di righe di codice) spesso non era possibile garantire che tutti i link fossero attivi e che tutte le informazioni venissero aggiornate in tempo utile.

E anche quando senza badare al dispendio di energie altrimenti utilizzabili diversamente, un sito corporate era gestito in maniera efficace e coerente, la decisione da parte di un dipartimento di cambiare in maniera radicale la propria sottosezione comportava un monte ore imponente e numerosi problemi non messi in conto in fase di ideazione.
Identificate queste sfide i conseguenti obbiettivi di un CMS a questo punto sono facilmente definibili.
La consistenza dei dati, la separazione dei contenuti dalla presentazione, della strutturazione logica del sito dalla sua rappresentazione grafica e la minimizzazione della ridondanza sono i principali motivi per i quali spesso una ditta ha una effettiva necessità di adottare un CMS. (Michael R. Bernstein, Scott Robertson, Zope Bible, New York, Hungry Minds, 2003, pp. 312-313)

In questa prospettiva il CMS è un software che permette a personale non-IT di cambiare, aggiornare, ingrandire e in pratica di apportare qualsiasi variazione ai contenuti di un sito sul quale è autenticato, in base al ruolo e al livello di accesso consentito.
Questi cambiamenti sono fattibili in maniera diretta attraverso  un'interfaccia basata sui più comuni web-browser.
I CMS sono per molte organizzazioni la soluzione a tre urgenze che si sono manifestate sempre più pressanti negli scorsi tre-cinque anni:

• la pressione interna – il desiderio di creare e di gestire i contenuti in maniera più efficiente;
• la consapevolezza che la soluzione poteva essere a portata di mano senza costi esorbitanti;
• la legislazione che, dai paesi più avanzati è andata uniformandosi nel mondo intero, ha affrontato la questione dell'accessibilità alle informazioni obbligando le organizzazioni ad adeguarsi. (da

  http://www.contentmanager.eu.com/needs.html )

    I CMS sono stati una risposta a questi bisogni e rappresentano in se stessi una soluzione a tali problemi; nel tempo si  sono evoluti  fino al punto in cui si trovano ora dove hanno raggiunto un'importanza strategica per le necessità operative delle organizzazioni, rispondono agli standard legislativi, hanno costi ragionevoli in forza alla disponibilità delle più svariate versioni disponibili, sono ormai prodotti stabili che garantiscono affidabilità nel tempo, sono facilmente sfruttabili e user-friendly.

Possono essere una soluzione alle necessità del lavoro collaborativo perché attraverso la strutturazione in gruppi degli utenti, la disponibilità di ruoli organizzati in maniera gerarchica e le possibili combinazioni a cui l'amministratore della sicurezza può ricorrere, l'elaborazione collettiva di documenti, la creazione di più versioni conseguenti dello stesso documento, il controllo sulla qualità e la sostanza dei contenuti prima della loro pubblicazione e per finire la loro eliminazione una volta diventati inutili e/o obsoleti è organizzata in maniera intuitiva e gestibile da personale senza conoscenze tecniche specifiche.
I vari documenti sono direttamente e immediatamente accessibili via browser non appena elaborati e, se le disposizioni in materia di sicurezza disposte dai responsabili del settore IT lo prevedono, con una semplice interfaccia basata sui browser sono  modificabili.
Lo stesso discorso sulla collaborazione vale al di fuori della organizzazione specifica perché se forniti degli opportuni permessi qualsiasi soggetto può ricoprire qualsiasi ruolo e a sua volta creare, modificare o rimuovere contenuti o sezioni dei siti; i CMS sono utilizzabili per gestire intranet ed extranet.

Senza un sistema di gestione dei contenuti, come accennato in precedenza, la prassi per l’ aggiornamento di un sito coinvolgeva un certo numero di persone: chi i contenuti li ideava, chi aveva il compito di trasformarli in pagine di HTML corretto e coerente con il layout del sito (uno o più web designer) e infine il web master che finalmente poteva inserire sul server le nuove informazioni.

Questo processo comporta una spesa a lungo andare non trascurabile, web designer e web master sono infatti personale specializzato con un elevato costo orario, e i contenuti una volta trasformati in codice HTML con un layout strutturato andavano comunque riproposti all’ autore iniziale per l’ approvazione definitiva che spesso si otteneva dopo più di un passaggio dando così vita a una sorta di ping pong che oltre ad ingolfare il dipartimento IT provocava spesso una pubblicazione tardiva delle informazioni.

Come risultato, le organizzazioni fallivano aggiornamenti critici dei loro siti o le informazioni non erano sincronizzate con il lancio dei prodotti rendendo il sito stesso inaccurato, inefficace e meno affidabile per i clienti.

Con l’adozione di un sistema di gestione gli utenti possono aggiornare le pagine web esistenti direttamente, oppure crearle e pubblicarle senza la mediazione del settore IT o del web master.

Un CMS offre numerosi vantaggi rispetto al metodo tradizionale di aggiornamento e pubblicazione e in particolare i seguenti:

Velocità. Gli aggiornamenti vengono creati e pubblicati nel giro di ore o giorni rispetto alle settimane o mesi che erano prima necessari. Le informazioni sui prodotti raggiungono prima i clienti consentendo una più rapida risposta alle esigenze di mercato.

Accuratezza. La pubblicazione più rapida dei contenuti sul sito significa che i visitatori hanno sempre di fronte le informazioni più fresche ed attendibili rispetto a pagine obsolete e tools inefficaci.

Controllo. La responsabilità di ciò che viene o non viene pubblicato è nelle mani dei dirigenti direttamente responsabili dei vari dipartimenti e prodotti. Le persone che “possiedono” le informazioni sono quindi gli autori delle pagine web che le conterranno e questa è la maniera migliore per fare sì che i contenuti importanti raggiungano effettivamente le pagine del sito

Convenienza. Gli utenti non dipendono più dai programmatori, come conseguenza diretta scende il costo di gestione di un sito e i programmatori possono essere impegnati in altre attività.

Consistenza. Anche se un CMS permette a molti utenti diversi dentro e fuori l’organizzazione di pubblicare direttamente sul sito, nello stesso tempo dispone anche le regole per la revisione e l’approvazione dei testi, dando la possibilità di mantenere la consistenza dei dati e la coerenza dello stile.

Facilità. Gli utenti possono creare e pubblicare nuove pagine dal loro computer, nessuna conoscenza di programmazione è richiesta e nessuna assistenza.

Risparmio di tempo. Sia che a lavorare siano o no programmatori in ogni caso è necessaria una minor quantità di tempo per svolgere gli stessi compiti di prima.

Aumento di traffico. I navigatori che vedono nel sito contenuti sempre aggiornati, torneranno sul sito più volentieri e più spesso, si fermeranno di più e soprattutto compreranno di più.

Servizio ai clienti. Con un maggior numero di persone che hanno la possibilità di pubblicare i clienti troveranno più facilmente ciò che cercano.

Semplicità. Adottare un CMS semplifica grandemente la gestione strategica di informazioni soprattutto in grosse organizzazioni che devono fare fronte ad esigenze molteplici con un consistente flusso di dati sia in entrata che in uscita, il tutto mediato da differenti livelli di sicurezza e di autorizzazioni.

Efficienza. Un più facile sfruttamento delle abilità individuali grazie alla possibilità di intervento sui contenuti grandemente generalizzata.

L'impatto che quindi, in base a questi indicatori, ha un sistema di gestione dei contenuti sull'efficacia e l'efficenza di un sito, specie se di notevoli dimensioni, può essere di stimolo ad un migliore sfruttamento delle potenzialità di internet.

Molti vendor di CMS sviluppano i loro prodotti su piattaforme proprietarie.

Sono quindi disponibili praticamente sempre release per Sistemi Operativi proprietari come Windows, OS/2 e MacOSX o almeno per alcuni di essi. I CMS che vengono sviluppati come prodotti Open Source oltre a questi sono installabili anche su S.O. che seguono la stessa filosofia come GNU-Linux o Sun SOLARIS.

È opportuno poi assicurasi che il prodotto consenta una buona scalabilità. La scalabilità, nel mondo dei computer come in quello degli affari, è la qualità di un sistema di non incrementare i costi operativi o di diminuirli con il crescere del numero delle transazioni. Nel caso in cui dovrà sostenere un traffico elevato e sorga la necessità di impiegare più server il sistema di gestione deve poter venire distribuito su più macchine e sostenere in maniera adeguata le richieste che può giungere dall’esterno. Può anche essere necessario bilanciare i carichi di lavoro in maniera differenziata a seconda delle ore del giorno o di altri fattori. È quindi molto importante preventivare tali situazioni secondo le aspettative di crescita digitale di ogni organizzazione e orientarsi di conseguenza verso il prodotto che, fra quelli disponibili, dia maggior garanzie di non gettare la spugna in situazioni critiche e spesso strategiche per il corretto svolgimento del business.

Il formato in cui saranno utilizzabili i dati dal sistema è molto importante perchè formati stravaganti o proprietari possono imprigionare l'organizzazione ed impedirle un utilizzo flessibile dei propri dati, inoltre per i formati proprietari eventuali modifiche possono essere a discrezione del vendor oppure avere un costo esorbitante. Una buona soluzione adottata da numerosi CMS può essere quella di orientarsi verso standard come XML.

XML è un linguaggio completamente aperto basato su una sintassi diffusa e con una semantica potenzialmente infinita. Questo significa che chi lo usa ha bisogno di seguire una serie di regole di base ma non c’ è la necessità di piegare il proprio business a un modello predefinito di dati. L’ organizzazione avrà probabilmente una propria struttura – o semantica – e XML si estenderà con i bisogni.

Rende possibile lo scambio universale dei dati. I più disparati sistemi ed organizzazioni possono condividere dati ed informazioni attraverso XML senza esporre il proprio modello o investire in costose integrazioni. Tuttavia se un’organizzazione avrà i propri dati esclusivamente in un formato per il Web può non essere il caso di adottare tale standard perché aggiungerebbe poco o nessun valore.

L’approccio “eXtensible” tipico del linguaggio dà un controllo maggiormente granulare e più flessibile. “Il Santo Graal della gestione dei contenuti è la separazione dei dati dalla mappa del sito (“dove vivono”) e dal layout delle pagine (“come appaiono”) (da CMS Watch, The CMS Report, 2005, http://www.cmswatch.com/CMS/Report ) e XML fa esattamente questo: definisce cosa i contenuti sono e non dove e come sono disposti.

Un sistema di tag più sofisticato significa anche una maggior incisività dei metadati e una migliore efficacia dei motori di ricerca debitamente impostati.

XML è diventato la lingua franca per aggregare i più disparati contenuti. Rende più facile uniformare unità di informazioni e organizzarle in un sito o in una singola pagina. Inoltre dal lato output XML fornisce una unica sorgente, e di fatto un solo paradigma, per generare diversi formati “consumabili” come PDF, WML o per la stampa.Qualunque sia la soluzione adottata conviene comunque indirizzarsi verso prodotti che assicurino la compatibilità con i più diffusi standard industriali e quindi piattaforme come J2EE, NET, PHP etc.

Una facile integrazione fra il software già in uso e il CMS da adottare è questione importante soprattutto per organizzazioni di grosse dimensioni alle prese con extranet ed intranet estese. Può ad esempio essere necessario che un migliaio di agenti carichino in tempo reale gli ordini e che venga tenuta traccia dei pagamenti e delle commissioni. In questi casi il fattore tempo è fondamentale così come l’efficacia del sistema. Il CMS pur senza occuparsi dell’ intero processo funziona come porta di entrata di tutto il flusso di dati che poi, se non gestisce direttamente, smista ad altri software come i database per il datawarehausing o i sistemi di posta elettronica per la notifica dei più importanti cambiamenti di stato.

Va inoltre assicurata la compatibilità con i software in uso presso gli utenti finali per assicurare la piena agibilità del sistema.

Proviamo ora a riassumere i principali componenti con i quali un CMS deve poter interagire:

Web Servers: il CMS anche se in alcuni casi ne ha uno proprio deve poter girare dietro uno specifico web server già in uso quali potrebbero essere Apache, Lotus Domino, Microsoft IIS od iPlanet

Server di applicazioni: spesso i CMS sono in coppia con uno specifico server di applicazioni, questa può essere una grossa limitazione e va programmata con attenzione una eventuale migrazione verso il server fornito con il CMS.

Sistemi operativi: importante è anche la compatibilità con i più diffusi S.O. sia dal lato server sia client. Se dal lato server può essere discriminante nella scelta del prodotto, dal lato client va assicurata la piena compatibilità sia con i prodotti proprietari (Windows, Mac) sia con quelli open source per non perdere in partenza una possibile fetta di mercato.

Database: interfaccia ODBC verso database SQL standard come Oracle, MySQL, Microsoft SQL o MSDE.

Editor di testi: supportare il copia-incolla dai più comuni text editor mantenendo la formattazione dei documenti e ottimizzando il risultante HTML/XML

La maggior parte dei Sistemi di gestione garantisce l’ integrazione dei vari software via API anche se spesso prodotti open source garantiscono una migliore versatilità e possono conformarsi meglio alle necessità senza costi aggiuntivi verso il vendor.

I CMS forniscono un sistema coerente di modelli (templates) per le pagine del sito. Ogni sistema adotta un proprio caratteristico layout visuale che modificato caratterizzerà poi l’identità web dell’organizzazione e sarà parte integrante della identità del gruppo.
Nella figure di seguito abbozziamo l'anatomia di un CMS e di come viene gestita la creazione di documenti attraverso l'interfaccia basata su web browser usando a titolo di esempio uno specifico sistema di gestione orientato alla pubblicazione web open source, Plone.
Nella figura 6.1 è visualizzata la pagina home di un utente autenticato da dove il proprietario della pagina può manipolare il contenuto della sua sezione, che in questo caso, in Plone, è anche organizzato come un folder per suggerire all'utente un contesto il più possibile familiare e autoevidente.
La disposizione intuitiva degli elementi permette all'utente di tenere sotto controllo la situazione delle sue cartelle e lo stato dei documenti. Attraverso click del mouse sui tasti che attivano la creazione o la modifica degli elementi  c'è la possibilità di aggiungere tutti i tipi di formati previsti dagli amministratori.

L'utente crea la propria pagina con una semplice interfaccia testuale nella quale può inserire i propri contenuti, immagini e link. L'interfaccia supporta il copia e incolla da altri editor testuali dei quali mantiene la formattazione di base della pagina

Dopo aver inserito nella form ciò che voleva essere pubblicato, l'autore sottopone al revisore la pagina creata per l'eventuale pubblicazione definitiva.

Il revisore al momento del login troverà automaticamente una tab con evidenziati i nuovi contenuti proposti per la pubblicazione e un riepilogo sugli ultimi documenti pubblicati in modo da avere un miglior controllo sulla sezione del sito del quale è responsabile.

A questo punto dopo aver verificato la validità del documento e dopo avervi apportato le eventuali modifiche il revisore ne decide la pubblicazione cambiandone lo stato da pending a pubblic. Il revisore ha comunque il controllo sugli stati di un contenuto che può ritirare , o renderlo non visibile, quindi privato (cioè visualizzabile solamente dal proprietario) in qualsiasi momento.

La cartella home dell'utente che abbiamo utilizzato per l'esempio se richiesta da un navigatore senza permessi di accesso avrà l'aspetto della figura 5.5, con gli elementi pubblicati disposti all'interno della pagina web con le indicazioni previste dagli amministratori (proprietario e data di creazione).

Come si vede dal confronto tra le figure le varie tabelle che compaiono sulla sinistra e sulla destra dello schermo per un utente riconsciuto dal sistema (nella figura 6.3 per il revisore sono upcoming events, news, review list, navigation e recent items ) non sono invece visualizzate se a richiedere la stessa pagina è un navigatore non riconosciuto e quindi senza permessi. Le pagine infatti vengono generate volta per volta in modo dinamico dal sistema che crea il codice HTML all'occorrenza secondo le regole disposte dagli amministratori andando a recuperare i contenuti da disporre nel template prestabilito.
In questo caso è stato previsto che utenti sprovvisti di password non possano ad esempio visualizzare gli gli “upcoming events” che sono invece visibili ed editabili da chi si autentica sul sistema.
L'autore del contenuto non deve preoccuparsi di come appariranno le informazioni che sta rendendo disponibili, alla stessa maniera chi si occupa del web design, stabilito una volta per tutte quali saranno i tipi di contenuto da gestire avrà la certezza che le pagine del sito saranno coerenti con quanto disposto.
L'esempio riportato in questo capitolo segue le fasi necessarie nel flusso di lavoro per la pubblicazione all'interno di un sito di un documento, dal momento della sua creazione a quello della sua effettiva pubblicazione, seguendo l'ordine gerarchico dei cmabiamenti di stato previsti. Attraverso una serie di passaggi simili il contenuto in questione sarà poi  rivisto per successive versioni (il revisore lo ritira e modifica o reinvia all'autore per l'aggiornamento) o ritirato per essere archiviato o definitivamente rimosso.

Vediamo ora, a grandi linee, quali sono funzionalità che in un CMS orientato alla pubblicazione possono avere grande importanza e di cui tenere conto in fase di adozione. Ogni sistema di gestione ha le sue specificità e a seconda dell'impiego cui è destinato è più o meno importante la presenza di un determinato tool. Le esigenze irrinunciabili di ciascuna organizzazione venno valutate con attenzione nella fase che precede l'acquisto o l'adozione di un determinato prodotto per indirizzarsi con più sicurezza verso il software giusto per i propri bisogni.

• Consentire il copia-incolla da documenti Microsoft mantenendo automaticamente la formattazione del testo

• Possibilità di inserire link ed immagini

• Supportare la creazione di nuovi templates

• Supportare la programmazione con linguaggi aperti in modo da poter creare ad hoc i templates necessaria

• Layout flessibile per una grafica più efficace

• Open Source o basato su tecnologie aperte

• Separazione dei ruoli amministrativi e degli utenti

• Informare gli utenti via mail dei principali cambiamenti di stato

• Permessi ed accessi gestiti dagli amministratori in modo sicuro

• Compatibilità con i più diffusi web browser per consentire l'editing dei documenti

• Interfacce intuitive ed user friendly

• Disponibilità di più versioni dello stesso documento (stampabile o inviabile via mail)

• Flusso di lavoro flessibile e configurabile a piacere in modo da poter conformare il CMS sulle necessità dei processi aziendali

• Scalabilità

• Possibilità di aggiornamento e di amministrazione remota

• Categorizzazione delle informazioni

• Indicizzazione attraverso parole chiave

• Gestione di più versioni dello stesso documento

• Disponibilità di localizzazione e quindi di diverse lingue

• Utilizzo di pagine statiche dove possibilie per incrementare le prestazioni del sistema

• Importazione dinamica delle pagine da creare direttamente da un database o quando è necessario aggiornarle

• Utilità di conversione per i files

• Precisione nel mappare i contenuti e nello spigare dove essi sono situati

• Gli editor devono controllare non solo i contenuti ma anche la loro dispozione nella pagina e i collegamenti

• Tenere traccia delle variazioni apportate a un contenuto

• Consentire ove necessario il commento o la discussione su un documento

• Supportare motori di ricerca di terze parti

• Pubblicare su live server multipli

• Integrarsi facilmenti con prodotti software di terzi attraverso tecnologie standard

• Gestire foto ed immagini

• Ricerche attraverso database interni ed esterni via SQL standard

• Fornire anteprime per le immagini e riduzioni per i documenti di testo

Adottare un CMS, il giusto CMS è una scelta strategica per l'organizzazione che vede i propri contenuti digitali, quali essi siano, divenire poco gestibili e difficilmente presentabili al pubblico e ai partner in maniera ordinata e aggiornata.

Vista l'abbondanza e la varietà delle soluzioni disponibili, oltre che la difficoltà e il costo di una retromarcia a seguito della scelta sbagliata proviamo di seguito a individuare quale può essere un esempio di Return of Investment (ROI) di un Sistema di Gestione e quali i punti critici da tenere in conto in fase di adozione.

Ecco un esempio semplificato di come può venire calcolata dal punto di vista dei costi l'opportunità di adottare o meno un sistema di gestione dei contenuti di livello medio con un costo di 40.000€ e della sua redditività distribuita su un periodo di tre anni.

FATTORI VARIABILI

IMPIEGO DI TEMPO SENZA CMS

COSTO MENSILE SENZA CMS

COSTI E RISPARMIO TOTALI

REDDITIVITÀ (ROI)

Pur se semplificato e con valore soltanto esemplificativo, questo calcolo può facilmente essere riportato, tenendo conto delle variazioni del caso, in specifiche realtà aziendali per facilitare la valutazione della reale opportunità di investire denaro e risorse nell'adozione di un Sistema di Gestione orientato alla pubblicazione.

Per CMS open source se non sono da calcolare le spese per le licenze, che spesso sono la voce più incisiva in un calcolo di questo tipo, vanno comunque tenuti in conto i costi cui si potrebbe andare incontro per l'assistenza tecnica da parte degli sviluppatori e il monte di ore che di cui i programmatori interni potrebbero aver bisogno per adattare un prodotto “preconfezionato” alle reali necessità dell'organizzazione, oltre alla possibile necessità di formazione specifica per gli utenti del sistema.

Messi in evidenza i vantaggi tecnici ed economici che può comportare l'acquisto di un sistema di gestione dei contenuti (persino se a pagamento) proviamo ora ad analizzare quali possono essere i possibili errori che in fase di valutazione di un prodotto possono venire commessi e che possono avere conseguenza niente affatto trascurabili.

Riportiamo di seguito i pericoli messi in evidenza dalla Hannon Hill Corporation che se sottovalutati rendono antieconomica e sottoutilizzabile una gestione centralizzata dei documenti.

1. AVERE BISOGNO DI UNA FEATURE SPECIFICA E SCOPRIRE CHE È UN COSTO AGGIUNTIVO – Verificare attentamente in fase di adozione (per i software a pagamento) quali funzionalità sono effettivamente comprese nelle licenze di base e quali disponibili solo come optional.

2. IL DIPARTIMENTO IT EFFETUA LA SCELTA SENZA SONDARE E COINVOLGERE CHI POI USERÀ IL CMS OGNI GIORNO – In molte organizzazioni la scelta sull'acquisto di un sistema di gestione è delegata completamente al dipartimento IT, se questo può sembrare del tutto naturale è anche importante che il personale tecnico si confronti a fondo con quelli che saranno gli effettivi utenti del sistema per non andare in contro a un prodotto che essi non siano poi in grado di utilizzare. Uno dei principali motivi per rivolgersi ad un CMS è eliminare il collo di bottiglia al dipartimento IT, assicurarsi che questo effetto venga effettivamente raggiunto.

3. NON CONSIDERARE LA FUTURA CRESCITA DIGITALE - Integrare con i software già in uso un sistema di gestione dei contenuti non è qualcosa che una organizzazione speri di fare due volte viste la complessità e gli effetti di una tale operazione. Spesso sul mercato si trovano prodotti eccessivamente specifici e con poca flessibilità per le necessità future. Quindi risulta molto importante rivolgersi verso vendors o comunità di sviluppatori solide e con una buona posizione di mercato, allo scopo di assicurarsi la possibiltà di avere assistenza per le problematiche per ora non in vista e non correre il pericolo di trovarsi nel giro di qualche anno con un prodotto obsoleto che nessuno si occupa più di sviluppare.

4. NON COMPRENDERE A SUFFICENZA L'IMPORTANZA DEI PERMESSI PER LE DIVERSE ATTIVITÀ – I permessi e i ruoli con i diversi livelli di accesso sono una delle più critiche funzionalità di un sistema di gestione, se implementata male o in modo non consapevole può permettere a utenti che non dovrebbero poterlo fare di modificare il layout del sito o di accedere a dati sensibili.

5. SBAGLIARE NEL VALUTARE IL LIVELLO DEL SUPPORTO – Una delle peggiori esperienze che possono capitare con un CMS è che quando qualcosa va storto non ci sia nessuno da chiamare per l'assistenza, questo in modo particolare per CMS open source o scontatissimi. Assicuratevi di aver valutato a fondo la qualità e la quantità di assistenza che verrà fornita in caso di reale bisogno.

6. NON CALCOLARE L'OTTIMIZZAZIONE CON I MOTORI DI RICERCA (SEO – Search Engine Optimization) - Dal momento che spesso vengono investite grosse somme di denaro per creare e mantenere il sito aziendale è fondamentale che il CMS risponda nella migliore maniera alle query degli spider dei motori di ricerca altrimenti potrebbero giacere nei database centinaia di pagine dal contenuto amazing ma lì restare inerti. Molti CMS forniscono strategie per l'ottimizzazione verso i motori di ricerca (SEO form) ma alcuni non tengono conto di una delle rpincipali funzionalità degli spider: processare gli URL e seguirli; è quindi molto importante che gli URL delle pagine siano il più possibile standard e puliti, del tipo http://www.miosito.it/prodotti/novità.html.

7. TROVARSI CONDIZIONATI DA UNO SPECIFICO FORMATO DIGITALE – Anche se a tutt'oggi la maggior parte del traffico della su protocollo HTTP e linguaggio HTML l'evoluzione della tecnologia mobile ela nascita di sempre nuovi device lascia prevedere che fra non molto tempo i navigatori della rete potrebbero richiedere i dati con un diverso formato. Di conseguenza é importante che il CMS supporti più di uno degli standard attualmente più diffusi e che promettono di essere sempre più utilizzati in futuro (in particolare XML).

8. RIMANERE PRIGIONIERI DI UN PREDEFINITO MODELLO DI TEMPLATES – La maggior parte dei sistemi di gestione forniscono un più o meno completo set di template per la creazione dei contenuti. Tuttavia può essere necessario doverne creare di nuovi ad hoc per necessità specifiche sia di design che di gestione vera e propria. Valutare quindi a fondo se i template preinstallati sono facilmente modificabili se possono essere sostituiti con altri sviluppati in proprio.

9. ESSERE IMPOSSIBILITATI AD ESPORTARE I DATI IN UN FORMATO CONFORME AGLI STANDARD – Concetti come usabilità ed accessabilità stanno guadagnando giustamente sempre nuovo credito e popolarità. Gli standard proposti dal W3C stanno sempre di più diventando quelli di fatto; qiundi può essere importante che le pagine generate possano validate conto, magari con una vista dedicata, senza richiedere eccessivo lavoro.

10. NON ESSERE IN GRADO DI ESPORTARE I DATI IN UN FORMATO STRUTTURATO ED USABILE – Prendiamo come esmpio RSS che sta iniziando a rimpiazzare come strumento più rispettoso dell'utente e della sua privacy le campagne pubblicitarie prima portate avanti con le e-mail. Sono pochi i sistemi di gestione che hanno le funzionalità per utilizzare questo canale mentre guadagna sempre più importanza. Anche se si potrebbero fare altri esempi questo significa che è necessario fare una attenta analisi dei bisogni informatici dell'organizzazione e delle possibilità di integrazione del CMS prima di procedere a una scelta che può poi rivelarsi definitiva.

Ognuno dei software disponibili sul mercato ha i suoi punti di forza, che vengono fortemente messi in evidenza dai vendors in fase di valutazione. È però importante analizzare per tempo quelle che potrebbero essere le debolezze di un sistema, possibilmente testandolo a fondo e mettendo in preventiva quelli che potrebbero essere i momenti critici che da affrontare – un esempio potrebbe essere quello della scalabilità di un prodotto ovvero del suo comportamento in caso di forte aumento del traffico o delle dimensioni dei siti nei quali è impiegato – per orientarsi il più possibile verso il giusto CMS la propria realtà organizzativa.

Abbiamo analizzato quali possono essere i punti in cui ditte o enti pubblici possono trovarsi in difficoltà confrontandosi con la digitalizzazione dei documenti e con l'importanza sempre crescente che i canali bidirezionali digitali stanno venendo ad avere. La diffusione di informazioni avviene ormai sempre di più attraverso le reti, siano Internet od Intranet, per questa ragione anche la creazione stessa dei contenuti va ormai organizzata in modo da essere spendibile su questo medium.
I CMS come si è visto vengono in soccorso proprio di chi si trova con la necessità strategica di offrire le proprie informazioni in tempo reale, sempre aggiornate e strutturate in maniera ordinata e coerente, con un sistema sicuro per tenere traccia dei cambiamenti che vi vengono apportati. Sono proprio questi i problemi che vengono  risolti dai Content Management Systems orientati alla pubblicazione web.
In pratica chi realmente è il proprietario dei contenuti, l'autore, può gestire in proprio il processo di creazione e di pubblicazione dei contenuti stessi, evitando complicate mediazioni da parte del dipartimento IT che vanno a creare il cosiddetto collo di bottiglia proprio nel dipartimento che spesso ha i costi tra i più elevati.
Inoltre il CMS si occupa anche di archiviare e tenere traccia dei documenti in esso presenti e delle modifiche apportate in modo sistematico, in modo da fornire anche un adeguato supporto in caso di attacchi e rappresenta un utile strumento nel malaugurato caso in cui occorra la necessità di fornire rapporti legali sufficentemente collegati a dati incontestabili, sostenibili nelle sedi adeguati senza possibilità di ambiguità.
In caso di complicazioni tutte le tracce, i log del CMS, saranno al loro posto consentendo una facile e precisa ricostruzione degli eventi, il tutto a beneficio di eventuali azioni legali che saranno così più semplici e correttamente documentate.
Abbiamo anche visto che i CMS, se gestiti in maniera consapevole, offrono un adeguato e coerente modello di sicurezza, cosa che consente nella maggior parte dei casi di affidargli senza troppe preoccupazioni dati sensibili e lavori collaborativi, lavoro che in pratica viene svolto basandosi su quello che forse è il più diffuso programma al mondo, il browser web.
Questo lo rende trasparente agli utenti finali e alle piattaforme dalle quali si collegano, questo risolve gran parte dei problemi connessi all'esistenza di diversi tipi di architetture e piattaforme.
È stata presa in esame la necessità di integrare il sistema di gestione con i software già in uso nelle organizzazioni, che possono essere web-server, application server, database, server di autenticazione, sistemi di e-mail e altri ancora e abbiamo visto che numerose delle soluzioni in commercio rispondono a queste esigenze con più o meno facilità ed affidabilità.
Abbiamo fornito una breve panoramica delle soluzioni open source e a pagamento presenti in questo momento sul mercato, spendendo qualche parola sui relativi punti di forza.
Infine abbiamo provato a vedere l'effetto che l'adozione di un CMS può avere nell'allocazione dei costi per il  web di una organizzazione di medie dimensioni per poi prendere in esame quelle che possono essere considerate le principali debolezze che un CMS può avere e che possono non rispondere alle reali necessità di chi a questi sofware si rivolge.
I CMS sono in definitiva una importante innovazione che verrà sempre più utillizzata negli anni a venire e che già oggi nelle organizzazioni di vaste dimensioni è una realtà. Secondo gli analisti il mercato dei Sistemi di Gestione è in movimento e assume dimensioinisempre più rilevanti; secondo una consulenza di Ovum, una agenzia di ricerca del Regno Unito il valore del mercato dei CMS potrebbe raggiungere nel 2007 il valore di 7 miliardi di dollari e, se nel prossimo futuro i prezzi dei sistemi di gestione avranno un brusco ridimensionamento le loro funzionalità stanno raggiungendo un elevato grado di standardazzazione. Nel corso di questo processo molti dei progetti che attualmente implementano i vari tipi di CMS scompariranno dal mercato sopratutto a causa della poca accessibilità ed usabilita dei sistemi implementati. Probabilmente si assisterà alla nascita di grossi vendors dal valore di 2-3 miliardi di dollari ognuno ma resteranno probabilmente sempre i migliori progetti Open Source che supportati da floride comunità di sviluppatori potranno rappresentare per alcune realtà organizzative sempre la scelta migliore.