Alberto Mucignat

Ne ho scritto già due volte. Oggi segnalo un bel contributo di Sett Gottlieb, che è forse indirizzato a clienti molto enterprise.

Ultimamente avrete capito che mi piace parlare più di content management framework, che un amico ha ribattezzato publishing framework. Però il mercato dei cms non è per niente morto.

Comunque, trovo molto interessanti i punti 6, 7 e 8 di Seth.

Per prima cosa, quando avete fatto una lista di fornitori, ingaggiate una relazione con le aziende, in modo da capire non solo quali feature differenziano i prodotti dagli altri, ma anche come funziona il loro approccio. Non accontentatevi di documenti descrittivi, insomma, parlate con le aziende e cercate di capire come lavorano, come sviluppano, ecc. Soprattutto, cercate di capire se la metodologia va bene per voi.

Inoltre, fatevi fare dei prototipi e testateli, perchè non è detto che una soluzione ultra-professionale si adatti a quello che serve a voi. Questa cosa è molto intelligente, specie se pensiamo che molti prodotti vengono comparati solo in base a funzionalità e prezzo, ma poi vengono presi un po' a scatola chiusa.

Infine, provate a progettare un'implementazione. Serve per molte ottime ragioni, tra cui aggiungo il fatto di capire qual'è la portata dei cambiamenti, cosa comportano, come affrontarli, ecc.

Lettura utile per tutti, anche se credo che questi consigli vadano bene per progetti la cui scelta di un cms sia strategica per l'impegno economico e gestionale che richiede. Penso probabilmente a grossi progetti come mega-portali istituzionali, grosse intranet o portali di turismo con budget milionario...

Negli ultimi giorni ho giocato un po' con Rails e Django, giusto il setup di una piccola applicazione, tanto per vedere come funzionano.

La scelta tra i due è ardua, ma credo che per ora utilizzerò Django, lo trovo più comodo e intuitivo. Devo ancora però vedere come funzionano le interfacce AJAX nei due modelli. Ovviamente, questo è uno dei punti più interessanti e importanti.

Per ora alcune riflessioni iniziali e da profano (quindi incline alle gaffe colossali):
- ci vogliono pochi minuti per avere un prototipo
- la programmazione è intuitiva (model/view)
- si fa solo il necessario, è importante l'efficenza
- ci si concentra principalmente a strutturare i dati (contenuti) e configurare le viste (pagine web)
- il web è sottointeso, l'interfaccia web quasi nativa
- il content management è quasi una conseguenza naturale. Strutturi i contenuti e li navighi/gestisci poco dopo.

Per chiudere, magari la sparo grossa, ma ho l'impressione che i sistemi di content management siano ormai superati. Con questo livello di efficenza, questi framework sono il content management personalizzato.

È come se non servissero gli enormi baracconi di una volta, tanto le funzionalità comuni sono espresse ormai a livello di API. Il valore è nella possibilità di customizzazione.

Che dire... tutto ciò è copiaincolloso!

Tempo fa ho parlato di IBM e Drupal. Nel corso del 2006, IBM ha continuato ad aggiungere nuovi contributi, per cui ora il progetto è spiegato interamente nel sito DeveloperWorks di IBM.

La cosa è interessante anche per chi non sviluppa con Drupal, poichè presenta la modalità UX-oriented di IBM (ri-linko perchè merita), oltre a un contributo sull'utilizzo delle taxonomies, feature che manca in molti cms opensource.

Luca Mascaro ha rilasciato una serie di linee guida per la costruzione del CMS Enterprise definitivo, come lo chiama lui. Il documento, in italiano, è disponibile a tutti, specie per chi sta pensando di sviluppare un CMS.

Personalmente ritengo che un ECMS sia una cosa talmente complessa, una specie di mega blackbox che racchiude una serie di procedure, workflow, controllo documentale, ecc, da far pensare che fa tutto e niente.

In realtà spesso vale la seconda: chi ha usato websphere (io mai) me lo conferma, trattasi di uno scatolo con cui puoi fare tutto on demand, ovvero la base c'è, ma le funzionalità vanno costruite ad hoc.

Anche eZ publish è più un framework che un cms, per come siamo abituati ad intendere un cms, ovvero il modello "scrivo, clicco e pubblico". Però ci puoi fare potenzialmente tutto.

Peraltro, i CMS di classe enterprise dovrebbero avere, imho, una serie di intellingence evolute come il search engine, il controllo dei vocabolari, APIs per l'integrazione di contenuti e servizi, ecc: features che è difficile implementare direttamente, ma che richiedono molto lavoro a margine (es: usabilità e personalizzazione), sia da parte del produttore del cms, ma anche dell'azienda che lo utilizza.

Insomma, Luca, non me ne volere, ma per me è na battaglia persa in partenza, anche se il tuo documento offre molti spunti utili che ognuno può utilizzare come meglio crede.

IBM ha scelto Drupal per sviluppare un loro nuovo sito collaborativo.

Drupal l'avevo testato un paio di anni fa e mi sembrava quello più valido tra i sistemi cms opensource, per la chiarezza di sviluppo e per alcune altre cose illuminanti che altri cms al tempo non avevano.

Ora IBM lo sceglie comparandolo ad alcuni altri cms simili e valutando alcune caratteristiche importanti come:
- session management
- flessibilità ed estendibilità (moduli)
- separazione tra presentazione e contenuto (templating)
- scalabilità

Drupal ha anche un modulo per le tassonomie molto apprezzato da Luca Rosati, che di architettura delle informazioni se ne intende.

Da riprovare.

ps: interessante anche l'analisi del metodo di lavoro di IBM.

Lucene è un search engine opensource scritto in Java. Ho sentito spesso parlare di questo motore come un'ottima (ed economica) soluzione al problema della ricerca a livello enterprise (cioè quando si hanno moolti documenti, molte fonti, molti utenti). Da quel che vedo, Lucene si presta molto ad integrare la ricerca su molteplici contenuti e deliverando su più client e device, grazie a numerose implementazioni.

All'eZ conference 2006 è stato rilasciato il Lucene search plugin per eZ publish, che molti vedono come valida alternativa all'attuale motore di eZ, per la verità poco performante e senza molte features. Ne parla anche il suo creatore, Paul Borgersman.

Anche il progetto Midgard, un cms che mi sembra avere parecchie carte in regola per entrare nel mondo enterprise, utilizza Lucene (nativamente) come proprio motore di ricerca interno.

All'eZ conference 2006, Martin White, nel suo keynote sull'enterprise content management, ha focalizzato molto sulla ricerca, descrivendola come componente chiave per la realizzazione di una intranet.

Spesso il mondo opensource ha già le risposte pronte a molte delle esigenze che incontriamo quotidianamente.

A quanto pare il mercato dei cms enterprise è stagnante. Almeno in america, che è qualche anno avanti.

Qualche tempo fa ho scritto dei consigli per le aziende che devono scegliere un CMS. Segnalo ora alcune risorse a corredo delle mie osservazioni.

Per primo segnalo la pagina inglese di Wikipedia, contenente molte spiegazioni e riferimenti.

Poi, l'ottimo CMS Matrix, che consente di comparare le features di decine di CMS. Benchè sia un lavoro da esperti, può essere utile anche per chi vuole farsi un'idea di massima. Unica pecca: non ho idea di quanto siano aggiornate le features dei vari CMS, ma in rete è il sistema di comparazione migliore che ho trovato.

Esiste poi un recente report dei principali CMS opensource. Il report è interessante perchè parte dalla fatidica scelta del tipo di sito che si vuole realizzare (blog, giornale online, portale, ecc) e confronta i 3-4 CMS più diffusi per ogni tipo.

Rockley report ha una serie di approfondimenti su CMS e architettura delle informazioni, liberamente scaricabili.

Infine, altro sito pieno di risorse: CMS Watch, per chi è disposto a pagare per dei report professionali.

Consiglio finale: forse è meglio avvalersi di un esperto, che può analizzare la struttura aziendale, le esigenze, i contenuti e aiutare l'azienda a fare la scelta giusta.

Negli ultimi giorni sono usciti un paio di articoli molto interessanti riguardo il futuro di eZ publish.

- eZ publish 4.0 features list: dove si spiega anche come mai il rilascio di eZ publish 4.0 è stato spostato nel 2007 e quali saranno le nuove features
- Intervista sul futuro dello sviluppo di eZ: brainstorming tra sviluppatori, dove si annuncia tra l'altro che Frederick Holljen lascia la guida dello sviluppo a Vidar Langseid.

Nelle features di eZ sono stati inclusi anche alcuni suggerimenti che avevo fatto, per cui sono particolarmente contento.

Entrambi gli articoli sono molto interessanti e secondo me rappresentano bene la filosofia open di eZ systems. Complimenti a Sandro per il suo ottimo lavoro di Knowledge Manager.

Di oggi è invece l'articolo che riassume il partner meeting a cui anch'io ho partecipato. Così adesso sapete cosa sono andato a fare in Germania in pieno inverno...

Ultimamente qualcuno mi ha chiesto quale CMS è meglio, secondo me. Il mio parere è che la scelta di un CMS per un'azienda è una cosa da valutare seriamente.

Spesso consiglio un CMS, perchè ci lavoro e so cosa comporta sviluppare i tool di cui un'azienda ha bisogno. Ho un metodo collaudato per sviluppare con quel tipo di CMS e mi ci trovo bene, ma questo non significa che valga anche per altri, che hanno diverse esperienze e competenze.

Da parte dell'azienda, quando si valuta l'adozione di un CMS andrebbe fatto un confronto (benchmark) dei vari CMS sul mercato, ma anche e soprattutto va fatta un'analisi delle esigenze reali e dell'impatto sulla propria infrastruttura.

La scelta di un CMS significa anche un'eventuale modifica o migrazione dell'infrastruttura: anche in questo caso vanno valutati i benefici e i costi di una tale operazione.

Per dirne una: non credo che eZ publish sia una soluzione giusta per tutte le aziende. Come non penso che WordPress sia adatto alle esigenze di un editore (già mi immagino le saette che mi arriveranno per questa eresia).

Probabilmente, se dovete scegliere un CMS e non vi fidate di un giudizio di parte, dovreste richiedere uno studio tra diversi CMS in base alle vostre esigenze, che stimi anche il TCO per ognuno.

Per quanto mi riguarda, solitamente tendo a consigliare un CMS quando lo reputo adatto alle esigenze e quando porta benefici diretti al committente. Per capire le esigenze devo fare un'analisi, che comprenda anche l'infrastruttura, solitamente lavorando a stretto contatto con il cliente.