Quel che resta del backoffice

I sistemi di amministrazione dei siti o progetti web (i cosiddetti sistemi di backoffice) sono una delle problematiche che il web project manager si trova ad affrontare. Il motivo è che sono la parte del sito che il grande pubblico non vede, e quindi la parte più penalizzata quando il budget è esiguo o i tempi ristretti. Spesso sono sistemi progettati senza tenere in considerazione gli utenti a cui si rivolgono, che si rifiuteranno quindi di utilizzarli.

Di sistemi di backoffice accennerò durante il mio intervento “Guerrilla web project management” a Better Software il prossimo 27 giugno. Lo stesso giorno a Better Software, però, Luca Mearelli dedicherà un intero intervento all’argomento, intitolato non a caso “L’altra metà del web“. Ne ho allora approfittato per rivolgere a Luca qualche domanda.

“Intanto mettiamo online il sito e gestiamo il caricamento dei contenuti ‘a mano’: l’amministrazione la finiremo più avanti”. Da project manager penso di aver sentito questa frase decine di volte. Come mai si presta così poca attenzione al backoffice: è solo una questione di costi?

Se è per questo, a me è capitato anche che gli utenti chiedessero di realizzare export ed import da Excel… dopo aver sviluppato tutto il backoffice!

Sulle motivazioni (scuse?) per trascurare l’interfaccia di amministrazione, io credo che ce ne siano siano di condivisibili, ad esempio la spinta ad arrivare rapidamente sul mercato o lo sperimentare il servizio in fase di prototipo, ed altre comprensibili ma meno condivisibili, come appunto quella del budget.

Per la parte pubblica di un servizio web sempre di più si affrontano i progetti mettendo al centro dell’attenzione gli utenti e le loro esigenze. Al contrario per il backoffice si continua a guardare al progetto esclusivamente dal punto di vista tecnico o della modellazione e gestione dei dati, rischiando di realizzare strumenti che sono perfettamente inutili ed in-usabili proprio dalle persone a cui dovrebbero essere destinati.

In questo contesto è facile che le attività legate al backoffice siano relegate in secondo piano, e dunque ritenute meno degne di cura anche a livello del bilancio di un progetto (trovo che sia un atteggiamento che si avvicina a quello che si deve affrontare rispetto all’implementazione dei test automatizzati sul codice o all’utilizzo delle pratiche agili).

Per far accettare l’attività legata all’implementazione del backoffice occorre educare i committenti a riconoscere che il servizio esterno e l’amministrazione del servizio sono due facce di un’unica entità e che le attività del sito non si possono esaurire con la prima.

Inoltre il backoffice può essere molto di più di un’interfaccia di amministrazione: nei casi migliori può diventare uno strumento che permette di raccogliere e analizzare i dati che provengono dal software sintetizzando informazioni utili a guidare la gestione del servizio e la sua evoluzione.

Quali sono, nella tua esperienza, le problematiche principali dei sistemi di backoffice e come possono essere evitate?

Uno dei problemi è sicuramente la comunicazione tra i “proprietari” del progetto, gli utenti interni e i professionisti incaricati di coordinare e implementare il progetto. I primi spesso non riescono ad identificare se stessi con il proprio ruolo e i propri obiettivi all’interno del sistema, anche se riconoscono gli attori esterni alla propria organizzazione  (un problema di punto di vista).

Quando gli utenti interni sono relegati in un secondo piano c’è il rischio concreto che non siano ascoltati dai project manager o dagli sviluppatori e risulta difficile in fase di progettazione far emergere i requisiti dell’interfaccia di amministrazione.

Ci si può trovare, come mi è capitato, ad aver realizzato un sistema di amministrazione e poi a scoprire una vera disconnessione tra gli obiettivi degli utenti interni e quello che il backoffice mette a disposizione. L’utente si lamenta di non riuscire a navigare nei dati secondo il flusso che per lui è naturale, mentre lo sviluppatore non riesce a vedere oltre il punto di vista dei dati nudi e crudi.

Un altro elemento di frizione nell’adozione di un’interfaccia di amministrazione è la velocità. Sappiamo tutti quanto questo sia importante per la parte pubblica di un servizio, e come la velocità di un sito abbia influenza sulle sue performance economiche, ma questo è vero anche per l’interfaccia di amministrazione. Se il backoffice è lento e soprattutto se lo è nell’effettuare operazioni ripetitive, allora gli utenti saranno scoraggiati dall’usare quell’interfaccia, opporranno resistenza e questo sarà causa di continue richieste di supporto.

Risolvere i problemi di comunicazione tra gli attori in gioco nel processo di sviluppo ed includere anche gli utenti interni in tutte le fasi di progettazione tenendo presenti le loro esigenze è sicuramente la lezione principale che ho imparato (a mie spese) dai progetti a cui ho partecipato e che cerco di tenere presente.

È possibile realizzare un sistema davvero usabile senza che il cliente continui a telefonare o – peggio ancora – si rifiuti di utilizzarlo?

Se pensiamo che sia possibile realizzare un sistema o un servizio realmente usabile dagli “utenti esterni”, allora la risposta è decisamente sì, si può fare! (sono troppo ottimista?)

In fondo è quello che gli esperti di user experience cercano di insegnarci, e il trucco è cercare di tenere presenti e preoccuparsi degli utenti interni con la stessa attenzione e rispetto che abbiamo per gli utenti esterni, quindi: usabilità, velocità, obiettivi chiari.

Dal punto di vista della gestione del progetto è necessario essere in grado di identificare gli ostacoli intrinseci alle attività che si automatizzano per renderle più efficienti (smooth direbbero gli inglesi). A volte questi impedimenti sono rappresentati da persone che in maniera naturale oppongono resistenze al cambiamento nei processi a cui sono abituati, in questo caso il lavoro si complica, soprattutto per il project manager, e deve scivolare verso l’ambito dell’organizzazione e dei processi.

Non so se ci sia una ricetta specifica per evitare i problemi che conosciamo, ma possiamo cercare di adottare una serie di attenzioni che aiutino a realizzare un backoffice realmente utile:

  • non progettare il backoffice come un’interfaccia diretta sul database, ma come servizio attorno ai processi ed agli utenti (pensare agli utenti, ai loro obiettivi, …), e disegnare le interfacce di accesso e manipolazione dei dati ponendo al centro le entità logiche che compongono il modello dei dati (dal punto di vista degli utenti interni);
  • curare la velocità del backoffice e delle operazioni di routine (ad esempio permettere dove possibile operazioni dirette sulle collezioni di dati);
  • pensare al backoffice come centro di controllo del servizio e non solo come CMS, quindi cercare di offrire un’interfaccia che permetta di analizzare i dati su più livelli (dai dati aggregati in una dashboard, alle pagine di dettaglio per una singola entità).

Ma a parte questo il punto di partenza per me rimane comunque non considerare il backoffice come qualcosa d’altro, ma come un elemento organico del servizio che si sta realizzando.

Luca Mearelli ha lavorato su progetti di vario genere: sistemi di telecomunicazioni, applicazioni di gestione aziendale, servizi web, sia da solo che come parte di team piccoli e grandi, oltre che a vari livelli nell’organizzazione, da programmatore a direttore tecnico. Grazie a queste esperienze ha imparato che il successo di un sistema non dipende solo da elementi tecnologici, ma anche umani, primo fra tutti la capacità delle persone di lavorare assieme e comunicare in maniera efficace. È lead developer per miojob.repubblica.it nonchè co-fondatore e CTO di Kyberworks.

Living in the Compute Cloud – Web 2.0 Expo Berlin

Your site can have a lot of traffic, for many different reasons. Apart from that, your site can experience peaks of traffic.

To deal with this you can build your own infrastructures, but today there are other solutions available, such as the ones provided by Amazon and by Google.

Amazon web services

They are several platforms:

  • s3 is used for storage
  • ec2 is an on demand virtual server controlled with web service api (you can use your favourite linux distribution). It provides Acl for port control, you can choose datacenter (currently only in the US), and do a snapshot backup to s3
  • simpledb is a hash-like database that store items with attribute/value pairs. It is meant for small items, organized into domains, redundant and distributed, has no schema, in it everything is a strin, it allows to use list values, you use sql-like queries to retrieve data

Google apps engine

With this solutions you run your application directly on the Google infrastructure. There is no concept of hardware – you just deploy an application. For the moment it’s limited to python and for sure it has not the same flexibility of the Amazon Solutions. As a compensation for not having access to low level sockets you can use memcache, image, email, url fetch, google auth and users. The platform is limiting but takes care of scaling problems.

Bigtable is Google solution for database. It is very similar to simple db (no schema, list values) but also very different (data type support, references and multiple tables, blob files (1mb)). What is very limiting is that results can only last for a couple of second, after that they are killed by the system. On the other hand it is very easy to use. In few words, you have to accept the limitations.

With Google Apps Engine you have no background jobs, no possibility to backup/snapshot data, emails can only be sent from google accounts and it’s restricted to pure-python libraries and given apis

Considerations and usage suggestions

The impression taken from this session is that we need to use a lot of tricks to proficiently use these tools, even Amazon. The speaker illustrated some case such as uploading users data with authentication.

If the application I developed needs extra capacity for an unknown period of time with Amazon ec2 is quite easy to start additional instances. It’s a matter of using a time base systems, such as cron (amazon)

If the need is for something that is load balanced a possible solution is to itegrate ec2 usage with some monitoring tool, such as Monit. With these tools I can monitor if the load is too high and eventually add new instances. Monitoring for these solutions is the hard part to do because there is no ready solution for it

Even if the site has its own infrastructure that works it’s possible, if neededn, add extra capacity connecting to ec2, so to combine the best of both worlds. However ec2 is not available in Europe at the moment and so there could be latency problems.

Real life use cases of these platforms:

  • googbad.me
  • dawanda.com
  • g.ho.st

Final thoughts

  • get accustomed to eventual consistency (not sure that queries of few milliseonds are updated in all instances)
  • be prepared to leave relational database
  • many miss strong SLAs – most of the time u can live fine without
  • hardware is a commodity – only specialize in it if it really necessary
Jonathan Weiss
A Ruby consultant and partner at Peritor Wissensmanagement GmbH in Berlin, Germany. For the last years he has been developing and consulting large Ruby on Rails projects where he focused on Scalability and Security. He is an active member of the Ruby and Rails community and is the developer of the Open Source deployment tool Webistrano. In his spare time he maintains Rubygems and Rails in the FreeBSD Ports system.

I siti pigri sono i più veloci

Ho messo da parte in questi anni un bel po’ di materiale e documentazione relativi alla performance e ottimizzazione dei siti web, sia per quanto riguarda il cosiddetto lato server, sia per quello che viene chiamato front end.

Verrà – spero presto – il momento di compilare un elenco ragionato di tutte queste risorse (potete farvene un’idea visitando la sezione optimization del mio delicious), ma ora mi limito a citare un articolo che propone in modo molto chiaro uno dei nodi fondamentali da affrontare. Si tratta di Lazy web sites run faster scritto da Gojko Adzic.

Per aumentare le performance dei siti potete investire sull’hardware, quindi più processori e sistemi più veloci, migliore connettività, infrastruttura moderna. Vi accorgerete però che anche così facendo il web server fatica, per architettura, a gestire un sito il cui codice non sia ottimizzato.

Potete allora dedicarvi alla riscrittura (o refactoring) del codice per renderlo più veloce. Anche qui però arriverete ben presto a un limite.

Il segreto, secondo Gojko, sta invece nella progettazione di un sistema che si preoccupi di

  • delegare le operazioni più complesse a processi che girano in background;
  • non comunicare con sistemi esterni in modo sincrono, non importa quanto velocemente;
  • essere pigro: meglio lasciare per dopo tutto quello che non ha necessità di essere eseguito al momento.

Aggiungerei anche di eliminare le elaborazioni inutili, come per esempio l’esecuzione a ogni richiesta di interrogazioni esose (come quelle verso i database) per contenuti che non cambiano quasi mai. In questo caso potrebbe essere interessante sperimentare qualche meccanismo di caching.

Se ripenso ai colli di bottiglia dei progetti che ho visto da vicino, la maggior parte poteva essere evitata rimandando operazioni non immediatamente essenziali, come per esempio:

  • l’invio di un messaggio di posta elettronica di conferma;
  • la trasformazione di file (soprattutto in formato XML);
  • la comunicazione con sistemi di gestione;
  • il calcolo di statistiche.

Capita di trovare anche online degli esempi che fanno riflettere. Ogni volta che utilizzo la funzione “all time” di Feedburner per analizzare il traffico complessivo dei miei feed mi trovo ad aspettare almeno una decina di secondi. Probabilmente il sistema sta elaborando il consuntivo in tempo reale, quando avrebbe potuto farlo a priori. Non c’è nulla di male ad aspettare anche se a volte, per carico del server, viene restituito un timeout. Forse non proprio il modo ideale per gestire questa funzionalità, anche se utilizzata da una minoranza.