Tecnologie per lo sviluppo di soluzioni informatiche

Considerazioni sui prodotti presenti sul mercato (CMS;CRM;ERP) e il loro impiegno in azienda per evitare di sviluppare soluzioni custom.

In ambito commerciale ed open source sono diffusi applicativi che già implementano determinati insiemi di funzionalità e che possono essere utilizzati per risolvere i problemi cui sono preposti.

Le soluzioni che questi strumenti propongono non coprono mai l’insieme universo, ma costituiscono solo un sottoinsieme, omogeneo per tipologia di funzionalità, che costituisce una base solida per gli sviluppi inerenti al contesto applicativo.

Supponiamo, ad esempio, che sia richiesto di creare un’applicazione web per condividere le esperienze dei consumatori rispetto ad un determinato prodotto, dove l’azienda stessa possa intervenire nel dialogo verso il cliente. Per questa esigenza, è possibile impiegare una piattaforma di blogging, che possiede già tutte le funzioni tipiche per questo tipo di applicazione. Ovviamente è possibile, e questo capita praticamente sempre, che lo strumento non costituisca una soluzione completamente esaustiva. Sempre nel caso di esempio, ipotizziamo che il marketing chieda come specifica che all’interno del blog debba essere incluso un post contente messaggi pubblicitari ogni volta che un consumatore apre una nuova discussione. Tale funzionalità esce dal concetto standard di blog e non è prevista dalla piattaforma; conseguentemente, sarà necessario integrare la piattaforma di blogging con quanto richiesto.

A questo scopo occorre effettuare un intervento di programmazione e realizzare il “delta” mancante, in gergo effettuare una “personalizzazione”. In questo caso di esempio, partendo da un’applicazione molto vicina all’esigenza, il volume di lavoro legato alle personalizzazioni è molto minore di quello risparmiato partendo da qualcosa di già pronto.

È chiaro che tanto più è vasto l’insieme di funzionalità offerte dalla piattaforma e tanto più è vicina alle problematiche in questione, tanto più è semplice adattare lo strumento a risolverle.

Queste due considerazioni sono vere, ma nascondono due grosse insidie:

  1. Più ampia è la piattaforma e maggiori sono i suoi costi, le risorse impiegate e le difficoltà di personalizzazione. Si rischia di sovradimensionare il sistema (è come “sparare ad un moscerino col bazooka”)
  2. Più vicina è la piattaforma al problema e più è facile risolverlo, ma sarà più difficile risolvere altri problemi con la stessa piattaforma.

Inoltre un fattore cruciale per l’adozione di strumenti è la semplicità con cui lo strumento può essere personalizzato ed esteso. Le necessità in fase di personalizzazione sono:

  1. Estendere la piattaforma inserendo nuove funzionalità. In questa fase le API della piattaforma possono rendere più o meno agevole il compito dello sviluppatore;
  2. Sovrascrivere un comportamento della piattaforma, imponendo le logiche desiderate (HOOK); in questo caso è necessario che ogni operazione sulla piattaforma preveda di poter essere alterata.

Nei paragrafi successivi saranno trattate alcune tipologie di piattaforme informatiche di supporto alle attività IT. Poiché la gamma di attività necessarie è vasta ed eterogenea, nonostante ci siano soluzioni commerciali che sostengono il contrario, è difficile trovare una piattaforma sulla quale sia conveniente sviluppare tutte le applicazioni informatiche. Di sicuro, è possibile farlo, ma la problematica più difficile è capire quando sia conveniente utilizzare quale strumento. Adottando strumenti specifici per ogni esigenza si genera una situazione in cui si presenta una moltitudine di strumenti isolati fra di loro, che per essere interconnessi necessitano di lavoro, che unitamente al dazio pagato per disservizi dovuti alla dispersione dell’informazione costituisce un costo importante. D’altro canto, adottando un’unica piattaforma, si uscirà sicuramente dal campo di lavoro del software, trovandosi a dover implementare ex-novo funzionalità già presenti in altri strumenti, rischiando di reinventare la ruota e pagando pegno per adottare soluzioni che rappresentano un compromesso tra funzionalità richieste e possibilità offerte dallo strumento. Il trade-off da accettare tra l’adozione di strumenti nuovi e l’estensione di quelli esistenti è sempre un argomento delicato, in cui influiscono fattori molteplici, quali:

 

  • Costi di licenza
  • Tempi di realizzazione
  • Offerta degli strumenti sul mercato

 

Di conseguenza, per adottare una scelta piuttosto che l’altra è necessario conoscere bene il problema in oggetto e le possibili soluzioni.

Piattaforme CMS “User Oriented”

Un CMS (Content Management System), è uno strumento software installato su un web server, il cui compito è facilitare la gestione dei contenuti, rendendo i proprietari del sito autonomi nella gestione, senza necessitare di conoscenze tecniche in ambito informatico.

Generalmente offre un’interfaccia di amministrazione con cui l’amministratore può gestire ogni aspetto del sito web, e un’interfaccia di gestione WISWIG (What You See Is What You Get), che permette di modificarne i contenuti nel contesto in cui sono pubblicati.

Esistono CMS specializzati, cioè appositamente progettati per un tipo preciso di contenuti, e CMS generici, che tendono a essere più flessibili per consentire la pubblicazione di diversi tipi di contenuti. In linea di principio tutti i CMS sono estensibili e possono potenzialmente implementare qualunque funzionalità, poiché tecnicamente, un CMS è un’applicazione web che si appoggia su un database per lo stoccaggio dei contenuti.

Schematizzando, l’applicazione è suddivisa in più parti:

  • Una sezione di amministrazione, che serve ad organizzare e supervisionare la produzione dei contenuti; in quest’area è possibile gestire la configurazione del sistema ed effettuare le operazioni di manutenzione.
  • Una sezione applicativa, che l’utente web (visitatore del sito) usa per fruire dei contenuti e delle applicazioni del sito. Negli strumenti dove è prevista la modalità WISWIG, gli utenti che ne hanno diritto possono modificarne i contenuti.
  • I plug-in, ovvero moduli addizionali che aggiungono funzionalità al CMS. La piattaforma viene fornita con un certo numero di funzionalità incluse nel bundle; tramite l’aggiunta di questi moduli è possibile estendere il numero di funzionalità presenti.

Nel campo dei siti internet personali, o istituzionali, caratterizzati da specifiche funzionali semplici, si sono affermati strumenti gratuiti e totalmente Open Source (drupal, wordpress, joomla).

Le motivazioni principali che hanno permesso l’ascesa di questi strumenti sono:

  • Costi ridotti
    • No licenze per il software
    • No licenze per il sistema operativo
    • No licenze per web server
    • No licenze per Db server
  • Facilità d’uso
  • Community
    • Molte delle funzionalità aggiuntive sono prodotte e condivise tramite la rete

Nei sistemi CMS viene fornito un set di funzionalità predefinito e, se si necessita di qualcosa di diverso, si procede come segue:

  1. Si cerca sul mercato un plug-in che si avvicini all’esigenza
  2. Si procede alla configurazione del plug-in da interfaccia web per farne convergere il comportamento verso quello desiderato
  3. Se non si riesce comunque ad ottenere il risultato atteso, si possono percorrere due strade
    • Ci si accontenta del risultato ottenuto
    • Si procede ad effettuare interventi di programmazione per modificare il plug-in, o se ne costruisce uno nuovo, seguendo la strada più conveniente

 

Nel caso 3, è interessante riflettere sulle dinamiche che possono conseguire. Accontentarsi del risultato ottenuto, significa implicitamente variare le specifiche iniziali al fine di avere un problema risolvibile con lo strumento utilizzato. Questo processo, da un punto di vista puramente concettuale è inaccettabile, poiché significa formulare il problema sulla base dello strumento, invece che utilizzare lo strumento per risolvere il problema. Facendo un paragone con l’edilizia è come se il cliente commissiona un muro a secco, e l’impresa che lo deve realizzare non disponendo delle capacità necessarie realizza un muro in cemento armato. Dal punto di vista funzionale, la soluzione adottata dalla ditta può essere anche migliore visti i costi minori e la maggiore resistenza del cemento armato, ma non soddisfa le specifiche del cliente. L’esempio, nella sua semplicità evidenzia come può essere scorretto concettualmente applicare un procedimento simile, ma anche come in termini pratici a volte possa essere accettabile. Nei limiti dello strumento e del buon senso non è un male procedere in tal senso purché il problema iniziale non sia snaturato. Tornando all’esempio precedente, se le motivazione che aveva spinto il cliente a richiedere un muro a secco fosse stata presa per motivazioni legate alle normative ambientali, costruire un muro in cemento armato avrebbe comportato sanzioni economiche.

In campo aziendale, difficilmente è tollerabile un cambio di specifiche a causa dei limiti dello strumento informatico. L’azienda analizza un problema, ne formalizza la soluzione e commissiona l’implementazione al reparto IT (che eventualmente si avvarrà di consulenza esterna), e si aspetta che la realizzazione informatica combaci con quello che era stato previsto.

In questo ambito, generalmente si procede operando personalizzazioni sul CMS o su un plug-in particolare, il che richiede ovviamente del lavoro di programmazione.

La programmazione all’interno del CMS è vincolata da particolari specifiche che fanno sì che gli sviluppi si integrino all’interno del sistema e che le nuove parti riescano a cooperare con le vecchie. Da una parte questi vincoli rallentano il lavoro dello sviluppatore, dall’altro la piattaforma lo aiuta mettendo a disposizione una serie di API che velocizzano lo sviluppo.

In tutti i processi aziendali, anche se in alcuni casi i concetti sono impliciti all’interno del software sviluppato, occorre gestire dati, documenti e flussi di lavoro. Tali procedimenti, debolmente supportati dai CMS che hanno un orientamento più rivolto alla massa che all’azienda, giocano un ruolo fondamentale nello sviluppo software.

Negli ultimi anni, alcune piattaforme informatiche si sono orientate alla gestione di problemi tipici delle aziende, quali la gestione dei documenti (Web e non) e dei flussi aziendali. Tali piattaforme sono dette ECM (Enterprise Software Management).

Piattaforme E-CMS

Il termine di Enterprise content managment (ECM) fa riferimento ad un insieme di strumenti, metodi e strategie utilizzati per organizzare e raccogliere documenti e altri contenuti, di carattere organizzativo, relativi ai processi organizzativi di un’impresa.

Nel 2000 l’AIIM (Association for Information and Images Management), organismo di portata mondiale, definisce il concetto di Enterprise Content Management, che nel corso degli anni acquisisce sfumature diverse.

 

Fine 2005: Gli ECM sono delle tecnologie usate per acquisire, gestire, immagazzinare, preservare e riportare contenuti e documenti relativi a processi organizzativi.

Inizio 2006: Gli ECM sono delle tecnologie usate per acquisire, gestire, immagazzinare, preservare e riportare contenuti e documenti relativi a processi organizzativi. Gli strumenti e le strategie di ECM consentono al management di ottenere informazioni non strutturate dell’azienda, dovunque queste informazioni si trovino.

Inizio 2008: Gli ECM sono delle strategie, dei metodi e strumenti usati per acquisire, gestire, immagazzinare, preservare e riportare contenuti e documenti relativi a processi organizzativi. Gli strumenti e le strategie di ECM consentono al management di ottimizzare la gestione delle informazioni non strutturate, ovunque queste informazioni si trovino.

Inizio 2010: Gli ECM sono delle strategie, dei metodi e strumenti usati per acquisire, gestire, immagazzinare, preservare e riportare contenuti e documenti relativi a processi organizzativi. Gli ECM conferiscono al management tutte quelle informazioni che riguardano l’organo centrale di un’impresa, che possono avere la forma di un documento cartaceo, di un file o di un flusso di stampa.

Nelle varie definizioni associate al concetto ECM, il termine generico “documento” si può riferire ad entità diverse (documento testuale, file Excel, una pagina web, news, etc.) e viene esteso anche a quelle che non sono costituite materialmente da un file fisico.

In definitiva il concetto di ECM si riferisce a tutte quelle piattaforme integrate di document management, web content management, ricerche, collaborazioni, record management, digital asset management, workflow mangement, di acquisizione e di dematerializzazione delle quali si può dotare una organizzazione per la gestione dei processi e del ciclo di vita dei contenuti, informazioni e documenti dalla loro creazione/acquisizione alla loro uscita/archiviazione o distruzione. Tali piattaforme costituiscono un nucleo accentrato per l’informazione che, oltre a svolgere le funzioni di cui sopra, risolvono un insieme molto vasto di problematiche, si prestano ad essere estese e personalizzate, in modo da coprire in linea teorica tutte le casistiche possibili. Queste soluzioni possono essere usate per fornire:

  • Soluzioni per il mondo consumer: Business to consumer(B2C);
  • Soluzioni per i cittadini: Governement to Citiziens (G2C);
  • Soluzioni per le Aziende private: Business to Business (B2B), Government to Business (G2B)
  • Soluzioni per le Pubbliche Amministrazioni: Business to Government (B2G), Government to Governments (G2G)
  • Soluzioni per i dipendenti delle Organizzazioni: Government to Employers (G2E) e Business to Employers (B2E)

L’insieme di funzionalità core presenti in questa tipologia di prodotti, unitamente alle possibilità di estensione, colmano le lacune e superano le problematiche lasciate scoperte dalle piattaforme CMS.

È logico che tali vantaggi non vengano gratis, infatti rispetto alle soluzioni CMS sono richieste risorse maggiori per permetterne il funzionamento, sia in termini sistemistici (hardware, licensing, giorni uomo per il setup e la manutenzione) che del prodotto (licenze, consulenza per il setup). A fronte di questo impegno maggiore, si ottiene:

  • Maggiori funzionalità (discusse precedentemente)
  • Maggiori possibilità di estensione del prodotto
  • Garanzie maggiori (affidabilità, durata nel tempo, continuità)
  • Uno strumento orientato alla risoluzione di problemi, non un set di soluzioni

 

Piattaforme CRM

Sono piattaforme informatiche specializzate nella gestione di attività CRM (Customer Relashionsip Managment).

Tipicamente le funzionalità incluse in questi software comprendono:

  • Gestione anagrafica clienti
  • Gestione lead e ticketing
  • Gestione ordini
  • Gestione agende
  • Fatture (ma la contabilità difficilmente è presente)
  • Reportistica

A corredo di tutte queste funzionalità che già da sole coprono in pratica la totalità delle esigente CRM di base, i sistemi più evoluti mettono a disposizione la possibilità di estendere il set di funzionalità in modo da integrare i casi standard con soluzioni che vengano in contro ad esigenze particolari dell’azienda. Generalmente l’estensione di queste piattaforme avviene:

  • Tramite l’aggiunta di flussi di lavoro che si scatenano:
    • In automatico, all’avvenire di determinate condizioni (aggiunta fattura, chiusura ticket, ricezione di un email)
    • Manualmente, su richiesta degli utenti
  • Tramite l’aggiunta di entità personalizzate
  • Tramite API esposte come servizi

Generalmente la tipologia di interventi fattibili sulla piattaforma è orientata principalmente ad aspetti funzionali e pratici, l’aspetto grafico e l’interfaccia utente sono invece standardizzati e difficilmente personalizzabili. Per la determinata tipologia di applicazioni la standardizzazione dell’interfaccia grafica non è un problema, in quanto si tratta di piattaforme operative, e per molti versi costituisce un vantaggio:

  • Le funzioni personalizzate vengono visualizzate come tutte le altre già presenti, si rende immediato l’utilizzo di nuove funzionalità poiché ciascuna nuova sezione è strutturata in maniera analoga a quelle che l’utente conosce
  • L’interfaccia utente di base è pensata e studiata da team di lavoro specifici e tiene conto di aspetti funzionali, quindi è un ottimo punto di partenza
  • L’interfaccia standard impedisce di prendere iniziative estemporanee e poco sensate da parte degli sviluppatori e del committente

In definitiva le piattaforme CRM sono generalmente ottime dal punto di vista operativo e funzionale. Personalizzazioni che rientrano negli standard previsti sono realizzabili in maniera efficiente ed in tempi brevi, quindi spesso tali piattaforme diventano l’accentratore dell’informazione all’interno dell’azienda. La standardizzazione dell’interfaccia e del modo di lavorare è un pregio e, contemporaneamente, un limite, in quanto per esigenze molto spinte di personalizzazione conviene costruire altre soluzioni software che si integrano tramite servizi al CRM. In questo modo nella piattaforma derivata non ci sono limiti particolari, e si riesce comunque ad integrarsi con la piattaforma. Ad esempio si pensi ad un form contatti per l’acquisizione di nuove lead. In tal caso, ipotizzando che i requisiti grafici richiesti non siano compatibili con le possibilità offerte dal CRM, è ipotizzabile la creazione di un form di acquisizione totalmente custom all’interno del sito web, che scrive la lead all’interno del CRM, utilizzando le api esposte.

Piattaforme Scaffolding \ Data managment

All’interno di questa categoria rientrano un set di tool che permettono di costruire in maniera automatica applicazioni orientate all’origine dati. In questo caso le funzionalità presenti all’interno del pacchetto sono minimali ed orientate principalmente allo sviluppatore piuttosto che all’utente finale. Si tratta di applicazioni general purpose che non soddisfano alcun problema specifico, ma permettono di costruire velocemente applicazioni web che gestiscano una base dati.

Anche in questo caso esistono più soluzioni per ciascuna tecnologia adottata; quindi è un mondo vasto e variegato.

In termini pratici l’adozione di questi strumenti è conveniente nei casi in cui la complessità dell’applicazione sia circoscritta all’integrazione con la base dati o in cui tale aspetto ne costituisca il ruolo principale, e i vincoli sull’interfaccia non siano così stringenti.

Nella quasi totalità dei casi, è presente un passaggio di generazione del codice; tale peculiarità può avvenire a diversi livelli, a seconda del framework utilizzato:

  • Generazione dell’ORM (Object-Relational Mapping)
  • Generazione dell’interfaccia
  • Generazione dell’intero progetto

La prassi di costruire l’applicazione in base alla struttura dei dati, e nella fattispecie la generazione del codice, è detta “data first”, in quanto il flusso operativo parte dalla base dati.

In contrapposizione a questo approccio, che impone intrinsecamente che la tecnologia adottata per lo stoccaggio dei dati sia fissata, si può adottare l’approccio “design first”, che invece permette di scegliere la struttura delle entità all’interno dell’applicazione in maniera agnostica rispetto alla base dati. Questa seconda modalità di lavoro è stata aggiunta in tempi più recenti in alcuni di questi strumenti per venire in contro a tali esigenze di design.

Modalità di acquisizione

Sebbene il tema riguardi anche il caso dei prodotti CRM, nel caso ECM acquisisce una rilevanza cruciale, dati i costi di licensing e hosting maggiori. Tali strumenti possono essere acquistati nelle seguenti formule.

On premise software

Rientrano in questa categoria le soluzioni installate sui server dell’impresa. Questa soluzione implica:

  1. Il dimensionamento, l’acquisto, l’hosting e la manutenzione di tutti gli apparati hardware necessari per il funzionamento del sistema;
  2. L’acquisto del software;
  3. L’installazione e la manutenzione del software.

Di conseguenza sono richieste anche competenze specifiche e l’azienda deve essere sufficientemente strutturata per supportare lo strumento.

Software as services (SaaS)

Soluzioni in outsourcing con accesso web alle informazioni che risiedono sui server dei fornitori. La soluzione è meno impegnativa poiché pensa a tutto il fornitore del servizio. A seconda del prodotto adottato è possibile effettuare personalizzazioni a livelli diversi, in linea di massima l’insieme di operazioni potenzialmente fattibili sulla piattaforma sono un sottoinsieme di quelle ipotizzabili nelle soluzioni on-premise. La modalità di pagamento del servizio varia da vendor a vendor, ma in pratica è un costo per consumo (per numero utente, per fasce di utenti, per totale di dati memorizzati, etc.). Il vantaggio di queste soluzioni si sente particolarmente nella fase di startup e di sperimentazione del prodotto, in cui non si devono sostenere a monte i costi per l’installazione, ma si paga progressivamente in base all’utilizzo effettivo. Ad esempio, nel caso di Microsoft SharePoint, una server farm installata on-premise, si ha un costo complessivo nell’ordine dei 10K, mentre adottando la soluzione on-cloud dello stesso prodotto si pagano 3 euro ad utente. In definitiva le soluzioni SaaS sono vantaggiose in termini economici e di tempo, ma di contro:

si hanno garanzie sulle infrastrutture, ma non si ha controllo, né possibilità di verificare se gli standard di qualità promessi sono effettivamente implementati;

i propri dati risiedono su server altrui. In alcuni casi questo fenomeno può essere sconveniente:

  1. Non c’è massima thrust nel fornitore, che potenzialmente può accedervi
  2. Ci sono impedimenti legali sulla conservazione (ad esempio per le norme sulla privacy in vigore in Italia i dati sensibili devono risiedere in Italia, etc.)
  • Sono presenti dati estremamente importanti per l’azienda, che devono rimanere visibili solo all’interno dell’azienda (risultati di ricerca non brevettati, informazioni sulle strategie future, etc.)
  1. Tali servizi sono consumabili tramite web, di conseguenza tutti gli utenti all’interno della rete si collegano a server esterni per l’utilizzo del software. Sorgono problematiche di banda per garantire l’efficienza dei collegamenti, fermo restando che operazioni “massicce” in upload verranno sempre penalizzate.
  2. Hybrid solution: comprende sia le componenti del primo, sia quelle caratteristiche del secondo modello. Ad esempio è possibile installare il software in un set di macchine in hosting presso un fornitore esterno. Questa soluzione di compromesso è scarsamente utilizzata poiché comporta gli stessi problemi delle soluzioni SaaS e in più vanno sostenuti i costi ingenti delle soluzioni on-premise. Può essere vantaggiosa ad esempio nel caso in cui i servizi debbano essere esposti sul web per evitare di limitare il servizio con le prestazioni della rete aziendale.

 

L’ottimalità di una soluzione rispetto all’altra dipende in maniera forte dell’utilizzo che si fa dello strumento. In contesti applicativi reali, dato che la piattaforma viene impiegata per applicazioni diverse e talvolta con specifiche contrastanti, non esiste una soluzione ottima e spesso si tende ad impiegare una soluzione intranet ECM per le applicazioni interne, e una soluzione CMS (o E-commerce) per le applicazioni meno complesse e che richiedono di stare esposte sul web.

danielefontani

Actually CTO in Sintra Consulting s.r.l, I'm senior developer and architect specialized on portals, intranets, and others business applications. Particularly interested in Agile developing and open source projects, I worked on some of this as project manager and developer. My experience include: Frameworks \Technlogies: .NET Framework (C# & VB), ASP.NET, Java, php, Spring Client languages: XML, HTML, CSS, JavaScript, Angular.js,Angular. jQuery Platforms: Sharepoint,Liferay, Drupal Databases: MSSQL, ORACLE, MYSQL, Postgres

Lascia un commento