L’Open Source nell’industria

Il tema dei prossimi Incontri Regionali del Software Libero a Tolosa sarà “l’Open Source al servizio della trasformazione digitale dell’industria“. Esperti di grandi gruppi industriali porteranno le loro testimonianze (programma completo e iscrizione). Inevitabilmente, sul blog, ci siamo detti che era una buona occasione per prendere posizione in anteprima sul tema. E’ la solita storia di potervela raccontare un po’ prima del cocktail finale…

Quando l’industria si reinventa: della competizione alla collaborazione

La chiave del successo nell’industria può riassumersi in modo molto semplice: rendere il processo di produzione più efficace per migliorare la qualità, aumentare la quantità e ridurre i costi. Facile. Evidentemente il nodo gordiano sta nel bisogno di modernizzare macchinari, strumenti e sistemi informatici senza impattare né sul ritmo di produzione né sui costi. Ahi!

Ma limitarsi a questa visione significa dimenticare la concorrenza che infuria fuori dall’azienda, poiché tutti i concorrenti sgomitano per attuare la tecnologia migliore, la più affidabile e il più rapidamente possibile.

Pertanto, si osserva dopo un po’ un fenomeno sorprendente nel «piccolo» mondo dell’industria. Piuttosto che cercare di acquisire risorse e capacità, le aziende utilizzano sempre di più delle piattaforme per accedere a ecosistemi di tecnologie, di competenze e di informazioni. Sembra che il cammino del successo non consista più nel combattere da soli fino alla cima, ma piuttosto nell’aprirsi un cammino verso il centro della rete. (sorgente)

Ricordatevi che Steve Jobs era totalmente contrario alla creazione dell’AppStore. Secondo il suo biografo Walter Isaacson, il boss di Apple non voleva permettere a soluzioni di terzi di funzionare nativamente su iPhone. Era preoccupato specificamente dell’energia necessaria a sorvegliare una moltitudine di sviluppatori esterni.

Non molto visionario su questo punto… Nel 2017 l’AppStore ha generato 38,5 miliardi di dollari, 34% più dell’anno precedente (sorgente) e i numeri dei download hanno superato le previsioni. E’ stata la condivisione delle competenze e la costruzione dell’ecosistema che ha permesso di raggiungere questi risultati.

Piaccia o no a Michaël Porter, la capacità di collaborare e creare insieme è diventata il nuovo vantaggio competitivo nel mondo dell’industria (come anche altrove, ma rimaniamo focalizzati). Esistono molti modi di collaborare come il modello americano dei “manufacturing hubs“. Si tratta di 14 istituti di innovazione industriale basati sul partenariato pubblico-privato ognuno dei quali ha un orientamento tecnologico distinto, ma che condividono tutti un obiettivo comune: garantire il futuro della prodizione agli Stati Uniti attraverso l’innovazione, l’educazione e la collaborazione.

Un’altra visione è quella seguita da Elon Musk (tra gli altri) che ha rinunciato a far rispettare l’esclusiva dei brevetti di Tesla nel 2016. Da parte loro Google, Facebook, Microsoft e IBM si orientano tutti verso l’open-source tu temi molto diversi quali la robotica, l’IA o le telecomunicazioni.

Cos’è che rende l’Open Source una soluzione ideale per l’industria ?

A domanda semplice, semplice risposta: il costo, il supporto, la flessibilità, la comunità, la piattaforma e soprattutto la mutualizzazione.

Diciamo anche che l’Open Source ispira molta più fiducia che in passato e le innovazioni prodotte sono innumerevoli. Il sw libero è al centra della maggior parte delle grandi innovazioni informatiche: Cloud, Blockchain, componenti di infrastrutture e altre applicazioni in tutti i campi.

“L’Open Source è una filiera due volte più dinamica dell’insieme del mercato informatico francese: con un tasso di crescita medio annuale dell’8,1 % tra il 2017 e il 2020, il mercato francese del software libero e dell’Open Source passerà da 4,46 miliardi di euro quest’anno (4,18 in servizi e 0,278 in applicazioni) a 5,650 miliardi entro tre anni, secondo lo studio PAC.” (sorgente)

Le movimento DevOps è parimenti un motore forte del software libero. Basato su una filosofia di sviluppo agile, questa pratica si basa sulla collaborazione e l’apertura dei gruppi di sviluppo e di amministrazione, che limita i rischi, accelera lo sviluppo e ottimizza la qualità dei rilasci.

Ciò che oggi determina il successo di un prodotto è la sua capacità di interfacciarsi con gli altri, la sua modularità e la sua interoperabilità. L’era dei software ultra-personalizzati che richiedono nuovo sviluppo non appena si tratta di funzionare con una diversa piattaforma o di realizzare una funzione non prevista inizialmente, è finito. In questo contesto l’Open Source parte con un vantaggio temporale sui suoi concorrenti proprietari: la filosofia di sviluppo è subito aperta, orientata alla condivisione, al rispetto degli standard, all’apertura e allo spirito di innovazione.

L’azienda può sviluppare la piattaforma introno alla propria visione, beneficiando di fondazioni e di soluzioni già testate e mantenendo sotto controllo la compatibilità e l’interoperabilità delle proprie applicazioni. In breve, l’Open Source permette di accedere all’innovazione molto più rapidamente! (sorgente)

E la sicurezza in tutto ciò?

L’Open Source è ancora oggi incollato all’immagine di un grande magazzino dalle porte aperte in cui siete invitati a “entrare e servirvi”. Tra i “questo funziona così?” e i “quanto costa?“, la domanda su “quali garanzie di sicurezza” interviene molto presto nelle discussioni tra produttori e clienti.

Ciò che si osserva quindi al contatto con le aziende è che il vecchio detto “la sicurezza attraverso l’oscurità” diventa sempre più obsoleto. “Nascondere il proprio codice non impedisce agli hacker di trovare delle falle”, osserva Stéfane Fermigier del CNLL in un articolo per Hello Open World.

I software proprietari non sono al riparo dai cyber-attacchi più dei software liberi. In realtà ne sono ancora più vulnerabili visto che solo il produttore potrà essere in grado di rilevare e correggere le falle. Dal lato dei software liberi, la costante vigilanza dei contributori e l’occhio attento degli utenti più esperti su un codice accessibile a tutti dovrebbe garantire di rispondere più rapidamente all’attacco.

In materia di sicurezza soprattutto, l’Open Source offre delle garanzie di trasparenza e di audit che le soluzioni proprietarie non possono fornire. Il codice sorgente è visibile a tutti, il software non ha “back door” segrete, né comportamenti indesiderati o comunque nascosti. Si può dire che l’Open Source è portatore di confidenza. Del resto quando la CNIL ha voluto dotarsi di un software per l’analisi di impatto sulla protezione dei dati, in conseguenza del RGPD, ha logicamente scelto un software libero.

Possiamo prendere l’esempio più comune del vostro SI attraverso il quale passano milioni di informazioni sensibili e che le aziende (come molti altri del resto) affidano allegramente a soluzioni proprietarie americane: la posta.

Non lo si ripeterà mai abbastanza, poco conta che i vostri dati siano archiviati in mezzo al Texas o in un pascolo svizzero, se l’azienda che li gestisce è americana, allora i dati sono accessibili a terzi, è la legge americana …

Personalizzare sì … ma fino a che punto?

Piccola confidenza che collega da vicino innovazione e sicurezza. Se la dolce brezza dell’Open Source già soffia sul vostro collo e già immaginate tutte le cose meravigliose che potrete imbastire specificamente per la vostra azienda. Non dimenticate che come tutte le novità, l’adozione delle tecnologie Open Source deve essere accompagnata affinché possa essere adottata dai vostri utenti. Fare “su misura” non vi salverà dal passaggio “gestione del cambiamento”. Esempio eclatante di questa verità: la posta. In questo contest non si cerca di personalizzare all’estremo per rispondere a tutte le condizioni possibili ma piuttosto a semplificare al massimo l’utilizzabilità, rispettando le abitudini degli utenti.

La posta è un “luogo” molto particolare in azienda, si tratti o meno di un’industria: si tratta dell’applicazione più consultata ed utilizzata, anche se c’è la tendenza a dimenticarlo completamente. Pertanto, quando si cambia azienda, si è rassicurati dal trovare un sistema di posta familiare. E’ facile, lo si padroneggia, ci vorrà solo una breve fare di adattamento.

E’ la sfida che si è lanciata BlueMind lavorando per cinque anni per arrivare a supportare Outlook al 100%. Cosa significa concretamente? Consentendo alle aziende di mantenere senza degrado il client Outlook, ma al contempo di utilizzare in modo complete e collaborativo il altri client, quali Thunderbird, il web o i dispositivi mobili, BlueMind garantisce che il suo software si integrerà in modo del tutto trasparente nei diversi contesti di utilizzo, rispettando le abitudini degli utenti.

E’ importante sottolineare il ruolo determinante del produttore nei software liberi. Si ha spesso la tendenza a pensare all’Open Source in termini di infrastruttura e di metodi di lavoro e si immagina che il resto verrà naturalmente. Oggi l’Open Source sale più in alto e arriva alla postazione utente e agli utilities. Ciò rilancia appieno il ruolo del produttore. E’ lui che trasforma un codice sorgente in una soluzione che risponde alle esigenze e porta la visione del prodotto agli occhi dell’utente: ergonomia, integrazione, supporto, documentazione, affidabilità, sostenibilità nel tempo, ecc.

Far emergere il cambiamento dall’interno

Certe aziende hanno preso la decisione di coltivare l’Open Source anche all’interno stesso della loro struttura tra i gruppi di lavoro dedicati all’avvio delle start-up interne.

Noi prendiamo esempio da Airbus che ha per l’appunto creato delle start-up IT, basate sulla modalità del volontariato e il cui funzionamento è completamente indipendente dall’approccio gerarchico tradizionale. Per Peter Schoonjans, direttore dell’infrastruttura IT di Airbus: “si trattava di accelerare l’implementazione di un’applicazione ITSM, ma l’obiettivo principale di questo progetto era di poter contare su un esempio concreto che ci avrebbe consentito di promuovere l’uso di Open Source all’interno, dimostrare a tutti che si tratta di un approccio serio e di evidenziare i vantaggi che si hanno ad appoggiarsi sull’Open Source. E’ un modo per essere innovativi, di procedere più rapidamente e anche di ridurre il ‘vendor locking’.” (sorgente)

In Francia si può poi sempre citare Renault e il suo Laboratoire Collaboratif d’Innovation.

Sul fronte americano General Motors è uno dei numerosi esempi, avendo integrato FirstBuild, che si descrive come “una camera di decompressione tra innovazione, movimento maker e produzione tradizionale.”

Infine, forse avete già sentito parlare di “innersource”, un termine che per il momento si diffonde soprattutto tra le aziende anglosassoni. Rappresenta il tentativo di integrare le pratiche di sviluppo del software libero e di stabilire una cultura di tipo Open Source all’interno della propria organizzazione. L’apertura del progetto riguarda numerosi gruppi ma sempre all’interno della stessa azienda. Ciò permette di occuparsi di temi sensibili senza il timore che possano essere rivelati a terzi, approfittando al contempo della creatività e della diversità di prospettiva offerte da persone di settori diversi.

In conclusione

L’adozione dell’Open Source nelle industrie è diventato un vantaggio competitivo indispensabile per beneficiare della flessibilità e dell’efficacia nell’esecuzione dei progetti con vantaggi, quali la riduzione dei costi, la riduzione dei ritardi nella pubblicazione, la semplificazione dell’interoperabilità e anche la mutualizzazione dei costi.

L’Open Source si è introdotto all’inizio come un disgregatore, guardato con diffidenza, un’idea strampalata del laboratorio interno, un POC poco serio di una qualche startup … ma infine rappresenta ora l’avvenire informatico dell’innovazione industriale.

Raggiungeteci in occasione dei RRLL 2018 di Tolosa per affrontare il soggetto dell’Open Source nell’industria con i grandi attori del settore. E siccome siamo simpatici (e visto che avete letto fino alla fine) avete diritto al codice supersegreto che permette di beneficiare dell’entrata gratuita: RRLL2018.

DevOps e Integrazione continua: focus sulla procedura qualità di BlueMind

BlueMind ha integrato la metodologia DevOps nella sua procedura qualità. Grazie all’integrazione continua riusciamo a produrre più rapidamente e con una più elevata qualità.

BlueMind ha integrato la metodologia DevOps nella sua procedura qualità. Grazie all’integrazione continua riusciamo a produrre più rapidamente e con una più elevata qualità.

Il termine DevOps è apparso solo recentemente nel panorama informatico mondiale ma si è già imposto come una delle pratiche più efficaci. Dopo il rapporto Gartner del 2015, il 25% dei 2000 maggiori gruppi mondiali si sono orientati ad adottare DevOps. Più che di un metodo di lavoro, si tratta soprattutto di un cambiamento culturale che mira, come dice il nome, ad avvicinare lo sviluppo all’operatività. L’obiettivo è duplice: ridurre il ritardo della messa in produzione degli aggiornamenti e garantire un elevato livello qualitativo.

Il segreto del processo consiste in cooperazione e condivisione; gli sviluppatori ed i responsabili del rilascio dei sistemi collaborano per rilasciare il software in continuo. I cicli di sviluppo sono più corti, la qualità è valutata durante tutto il progetto e i rilasci sono più frequenti.

“DevOps è un insieme di pratiche e di valori culturali può aiutare le organizzazioni di tutte le dimensioni a migliorare i loro cicli di rilascio del software, la loro qualità, la sicurezza e la capacità di ottenere rapidamente un feedback sullo sviluppo.”Puppet Labs, rapporto «State of DevOps», 2017

BlueMind ha scelto di adottare DevOps su tutto il processo di integrazione continua, focalizzandosi sulle poste in gioco e sui benefici.

Un nuovo paradigma

Tradizionalmente, gli sviluppatori non condividevano il loro lavoro con il resto del gruppo e procedevano individualmente per lunghi periodi. L’integrazione delle loro modifiche al codice avveniva solo al termine del loro lavoro. Lo sviluppatore non aveva la visione del reale impatto di un aggiornamento sull’insieme dell’applicazione. Di conseguenza è possibile identificare i problemi solo alla fine del ciclo ed è più difficile localizzarli con precisione, ritardando quindi il rilascio degli aggiornamenti.

D’altro canto il settore operativo deve attendere talvolta parecchi mesi che i test ed il rilascio siano infine soddisfacenti prima di poter rispondere ad un’esigenza dell’utilizzatore … che probabilmente nel frattempo è cambiata. I due gruppi, sviluppo e operatività, non condividono gli stessi obiettivi e quindi non hanno le stesse priorità.

Sulla carte le esigenze del software sono chiare, definite e stabili. Gli sviluppatori si occupano del codice, i gruppi operativi dell’implementazione sui sistemi aziendali. Sulla carta…

Nel mondo reale l’informatica si evolve troppo rapidamente per permettere di mantenere fisse le specifiche durante l’intero progetto. Nella prospettiva di un fornitore di software il “progetto” non finisce mai! Le applicazioni devono poter essere rilasciate più rapidamente, ma devono anche poter evolvere continuamente. Nuove funzionalità devono poter essere aggiunte il più semplicemente possibile e gli errori rilevati devono poter essere corretti quanto prima. Le novità non devono compromettere l’esistente e devono tenere conto di tutte le configurazioni ed i casi possibili. Non c’è più il giorno “X” per rilasciare il prodotto come avveniva un tempo.

DevOps e le sue procedure (di qui l’innovazione continua) sono finalizzate a mettere fine a questa guerra tra Dev e Ops – per pervenire all’equilibrio tra innovazione e stabilità.

DevOps: un dialogo migliore tra i gruppi

L’adozione di DevOps consiste nell’attuare un processo globale che coinvolge tutti gli interessati indipendentemente dal loro ruolo iniziale. Dimenticati gli individui isolati e super-specializzati, i gruppi di sviluppo e di implementazione lavorano insieme su tutto il ciclo di vita dell’applicazione, dalla sua ideazione al test fino al suo rilascio ed alla gestione.

I gruppi condividono numerose responsabilità ed incrociano i loro workflow. Ciò permette loro di limitare le perdite di efficacia e di risparmiare tempo.

Dominique Eav – Direttore d’orchestra della qualità BlueMind

“In BlueMind nessuno va avanti da solo nel suo angolino. Coltiviamo la collaborazione e la condivisione per favorire l’efficacia operativa. Abbiamo un obiettivo comune e un piano – garantito dal responsabile del prodotto o della funzionalità – da raggiungere insieme. Tutto il gruppo può seguire i progetti, le idee e le difficoltà di ciascuno.”

Il tempo passato a condividere il saper-fare, le idee e le conoscenze deve garantire ampiamente la redditività del processo in termini di miglioramento dell’efficacia nella qualità dei rilasci, di anticipazione dei problemi/errori e di rapidità della risoluzione.

Integrazione continua

In parole semplici, l’integrazione consiste nell’assemblare pezzi di codice e farli lavorare insieme. Spesso è una vera a propria missione! In effetti, i progetti e gli ambienti sono molteplici, ciascun ambiente con una diversa organizzazione dei moduli coinvolti, dei passi di costruzione, di test, di validazione e di rilascio. L’integrazione continua permette di risolvere questi problemi facendo collaborare tutti gli attori del progetto dallo sviluppo alla gestione.

L’integrazione continua definisce l’insieme delle pratiche che permettono agli sviluppatori di integrare regolarmente le loro modifiche di codice in un repository centralizzato, di creare e gestire automaticamente delle sessioni di test automatici, quindi di rilasciare i risultati se tutti gli indicatori sono verdi. Questo processo permette di individuare e correggere p rapidamente i problemi, di migliorare la qualità e di ridurre i tempi di validazione e di rilascio dei nuovi aggiornamenti.

Storia dei risultati dei test.
P
er un dato test si vede la situazione attuale e storica, un FAIL su un test che prima era OK è segno di una regressione.

Ciò permette di verificare, in seguito ad ogni modifica del codice sorgente, che il risultato non produca regressione o errori nelle parti non modificate dell’applicazione. Gli errori sono identificati e quindi corretti più rapidamente, i tempi di validazione e di pubblicazione sono ridotti e, di conseguenza, la qualità complessiva è migliorata.

“Noi utilizziamo largamente il principio di pull request. Si tratta di un meccanismo che permette di condividere e di validare il proprio lavoro senza che questo sia necessariamente concluso. Lo sviluppatore può proporre in qualsiasi momento una “pull request” per sollecitare una revisione delle persone implicate. E’ molto più di una semplice validazione – si tratta di una vera discussione sulla parti tecniche coinvolte con la funzionalità proposta. Inoltre ci assicuriamo, da una parte che tutto il gruppo possa seguire le evoluzioni tecniche e dall’altra dell’integrità delle scelte.”

— Dominique Eav responsabile della qualità BlueMind.

Cruscotto sulla creazione di un ramo (master)
Questo diagramma presenta i risultati dei test, le differenti tappe della creazione e le versioni precedenti

L’automazione: chiave di volta dell’integrazione continua

Compilazione, test unitari e funzionali, validazione del prodotto, test prestazionali … sono attività essenziali ma dispendiose in termini di tempo, senza parlare dell’errore umano, sempre possibile. Il principio dell’integrazione continua si basa sulla loro automazione per risparmiare tempo e garantire sempre il miglior livello possibile di qualità.

Inoltre, man mano che lo sviluppatore produce del codice, il sistema verifica automaticamente che esso rispetti le regole comuni definite per tutto il gruppo. Questa procedura garantisce la qualità del codice prodotto e la sua stabilità nel tempo grazie al rispetto delle buone pratiche di sviluppo.

Questa funzione di analisi del codice permette di verificare la copertura del test sul codice. Bisogna tendere alla massima copertura possibile.

BlueMind utilizza Jenkins per guidare la catena di integrazione continua. Questo programma permette di testare e di riferire sui cambiamenti effettuati su un ampio spettro di codice in tempo reale per rilevare rapidamente i problemi.

Jenkins ci permette di costruire e testare i nostri rami di sviluppo (funzioni o correzioni), i cui cambiamenti integrano in continuo i nostri release (3.0, 3.5, 4.0), e ciò su tutte le distribuzioni linux supportate (8 per BlueMind 3.5.9). Il nucleo di BlueMind comprende oltre 500 moduli, e interagisce con numerosi AddOns disponibili nel Marketplace, anch’essi costruiti, testati e rilasciati dalla nostra catena di integrazione continua, con gli stessi vincoli di compatibilità e di qualità. Oltre 3000 controlli sono eseguiti su ogni versione. Questo grado di complessità sarebbe impossibile da gestire manualmente! Tutta l’intelligenza dell’integrazione continua risiede nel concatenamento automatico dei vari passi in una logica di industrializzazione dei processi.

“Noi abbiamo un approccio consensuale e pragmatico. Attuiamo e miglioriamo i nostri processi in modo da facilitare la vita dei membri del gruppo, non per rispondere a un elenco di obblighi che ci vengono imposti. L’automazione che ne risulta permette di procedere rapidamente e di far emergere gli eventuali problemi al più presto. Ogni mattone della nostra catena di integrazione continua è una cintura di sicurezza.

— Dominique Eav responsabile della qualità BlueMind.

Questa funzione di analisi statica che esamina le varie classi, misura il debito tecnico, cioè il tempo necessario a correggere i problemi presenti in questa o quella parte del codice.

Oltre ad eliminare dei compiti fastidiosi, questa automazione permette di rendere affidabile il processo di rilascio al contempo aumentando la frequenza dei rilasci. I gruppi possono quindi dedicarsi e migliorare le funzioni esistenti o garantire una migliore qualità piuttosto che effettuare dei test manuali.

I benefici concreti

L’integrazione continua fa guadagnare enormemente tempo ai gruppi di sviluppo poiché ogni modifica del software è immediatamente testata. Un codice compilato regolarmente permette di identificare rapidamente le modifiche che creano problemi in caso di errore. Lo sviluppatore ha una percezione rapida delle regressioni che può aver causato. Le incompatibilità tra il codice e l’ecosistema nel quale si dovrà integrare vengono anch’esse rilevate molto presto.

Durante tutto il processo di sviluppo e di rilascio, tutto il gruppo collabora strettamente verso una meta comune: la riuscita del progetto nella sua globalità, e non unicamente di sue parti.

Quando tutto il gruppo del progetto è agile, lo sviluppo di una nuova funzione o la correzione di un errore possono essere rapidamente messe in produzione – o annullate se necessario. Une versione funzionante del software è sempre disponibile e non è necessario attendere che il software sia messo in produzione per accorgersi che non funziona. Nel caso di BlueMind, noi per primi mettiamo in produzione queste nuove funzionalità all’interno. Un modo di procedere che chiamiamoeating your own dog food“, il che significa che siamo i primi utilizzatori della nostra soluzione.

Dal punto di vista dei nostri clienti, l’integrazione continua permette di rilasciare p rapidamente e più di frequente gli aggiornamenti nel contempo garantendo il più alto livello possibile di qualità.

Per concludere

Installare uno schedulatore come Jenkins non è sufficiente per fare dell’integrazione continua. Come specifica il Manifesto de l’Agilité logicielle, gli individui e le interazioni prevalgono sui processi e i sistemi. L’adozione di DevOps dipende dunque dalla responsabilità di tutti. La cultura DevOps implica di adottare un approccio trasparente basato sulla comunicazione e la collaborazione tra i gruppi informatico/operativi e di sviluppo. DevOps è un’eccellente approccio per le aziende che innovano senza posa!

BlueMind si è strutturata fin dall’inizio intorno a questi principi per assicurare il miglior livello di qualità in un contesto complesso. Grazie a questa agilità riusciamo a rilasciare prodotti stabili e performanti attraverso processi industrializzati tra gestione e sviluppo.

Suggestion box – un nuovo approccio per gestire le nuove funzionalità

Our job as a software publisher is to listen to our users’ expectations and enhance our product to meet them.

Being open source is what makes BlueMind unique. Yet openness can sometimes be detrimental to its development.

As a result of our product’s success, we’ve had enormous amounts technical and functional feedback and we’ve had to organise ourselves in order to process it.

Business model

Before moving on to the thick of things, we should explain what our job as a software publisher means, our business model and its impact on our organisation.

As software publishers, we focus on software development, product enhancement and technological partnerships. Our target market isn’t country or business-specific. Today, everyone needs email, and BlueMind responds to this need whether you are an SME or a multinational corporation.

To achieve global coverage, we work with a distribution network made up of partners who implement the projects for our clients and/or set up SAAS platforms.

Our network of partners enables us reach a must greater number of potential clients.

This has two consequences:

  • most clients come through our partners, which means we don’t know all of them
  • our number of clients is going to keep growing

As a result, we must set up a series of tools and methods to collect our clients’ feedback and requests in order to process them as best we can.

Organising Development

In the DevOps sense, as shown in this chart by our Normation colleagues, in the process from application development to production implementation, two parts are involved: BUILD and RUN.

The job of a software publisher is to BUILD, i.e. to take business requirements to create “application binaries”. In the Agile sense, business requirements can take different forms (stories, epics, etc.)

BlueMind’s R&D team has been using agile methods since the product’s early days. This has allowed us to develop features quickly, within a specific context. A whole series of automations and tests allow us to deliver new versions with new features quickly.

This article looks at the issue of handling large amounts of business requirements: how can we process them and incorporate them into our R&D appropriately?

Managing business requirements

Why manage them? People ask for things and we do them!

If only things were that simple. We’d need endless resources and all requests would have to be consistent, among themselves and with our vision. In the meantime, we have had to sort through requests and select them to feed a roadmap with a set of features that go into a Backlog.

The backlog contains a number of features which have to be sorted through and validated by a Product Owner. The features at the top of the backlog are processed by our R&D team first.

A simple qualification process

We had set up the following simple and comprehensive feature qualification process (as the young Padawans we were!).

  1. Understand the request
  2. Validate or reject the request
  3. Search for duplicates (who knows whether other users may have made the exact – or not so exact – same request!)
  4. Create a story for the backlog
  5. Place it in the backlog according to its priority status set by the Product Owner
  6. Link it to an Epic, if the story is too big

In theory, this process had 6 steps “only”.

This seems straightforward enough, but it becomes infinitely more complicated when you’re dealing with a large inflow of requests (entered by people who must be clients, but whom you don’t know, much less do you know their vocabulary and their expectations which tend to be too vague). As a result, your backlog becomes, well, backlogged. Looking for duplicates can be time consuming when you’re dealing with a hundred features or so.

In our case, requests come from various sources:

  • end clients
  • our partners
  • internally (developers, sales people, pre-sales people, etc.)
  • the software user community

This adds up to huge amounts of people potentially sending feedback and requests.

people

Most people believe that their requirements are generic, but in most cases they aren’t. Requests aren’t always expressed in the most straightforward manner and everyone thinks their feature is indispensable to their everyday software uses!

Our backlog: on hold

As at January 2015, this was our backlog’s status:

  • 140 features not sorted
  • 470 stories in the backlog

Among these stories:

  • some were important (implementation of a major, structuring feature)
  • others were less important (e.g. evolution of an existing feature)
  • others were small but legitimate (being able to sort by column: feasible, interesting, but high-priority?)
  • others were irrelevant, and possibly clutter (with all due respect to our users “the button would be better in yellow”)

The main issue isn’t so much the flow of feature requests but rather the way they were created and we processed them.

As for all IT projects, we’d set up a bug tracker. In most bug trackers — if not all, as far as we know –, bugs and features are essentially processed in the same way (by default). Typically, the request form is almost identical and a drop-down menu allows users to set the request as “issue”, “bug” or “new feature”.

7-differences

This is where the trouble is: a bug isn’t a feature! They are two distinct processes with different objectives!

Unfortunately, in bug trackers, the difference between a bug and a feature isn’t clear enough.

A feature ends up having the same level of time constraint — and possibly requirement — as a bug, which shouldn’t be the case.

A bug:

  • must have a resolution time-frame and depending on the type of service offered, must follow an SLA
  • must be corrected. It is a fault that must be entered into a correction cycle.
  • a specific workflow must follow its progress (open, pending feedback, corrected, deployed, “won’t fix”, etc.)
  • is critical
  • significantly impacts users, who must be informed of its progress.

A feature:

  • is a request for an enhancement
  • does not have a deadline (contractually)
  • is not critical (contractually)
  • does not require feedback to users
  • can be considered and accepted…  or not

This means that by nature, bugs and features are processed in a dramatically different way.

The Suggestion Boxlogo-sb

This is why we’ve decided to work differently, to reconsider how we handle features completely. First, we won’t call them “new features” or functionalities, from now on we’ll call them suggestions.

As a result of our analysis, we’ve concluded that to optimise how “suggestion requests” are processed, it is important for the requirement to be described as well as possible by the submitters themselves.

This isn’t a technical issue! But how can we get submitters to be more proactive? The vocabulary we use is important, and it is a first step in conditioning users:

  • users will “suggest” rather than “request”!
  • “I want” becomes “I suggest that”, “at some point, I’d like”

This is how the Suggestion Box was created. This dedicated UI is principally designed to browse through existing suggestions.

Credit and discipline

The Suggestion Box must encourage users to ask themselves several questions before they submit their suggestion:

Functional questions:

  • What is the use of my proposed feature and what will it do?
  • What will be its impacts on the BlueMind software as a whole?

Planning questions:

  • Has another user already made this suggestion?
  • Is there a similar existing suggestion?

If a suggestion can be created immediately, it doesn’t encourage users to think about their expectations. Therefore, each requirement turns into a request, with no prior analysis. And it will have to be analysed before the feature is turned into a story (how it is broken down).

This is exactly what used to happen when we allowed the creation of a “new feature” in our bug tracker: “all I have to do is select from a drop-down list and fill in a title”…

We must therefore guide our users through the process, via a suggestion self-service: the Suggestion Box!

Comment

The Suggestion Box was created with the following specifications which are deliberately basic in order to keep the procedure simple:

blueprint-suggestionbox

  • Search

The search is important as the UI’s purpose is to go through existing suggestions. We therefore need a powerful search tool.

  • Suggestion not created if no prior search

To encourage users to search for a similar request, suggestions cannot be created from the home page. A suggestion can be added only if a search doesn’t produce any relevant results.

  • Category

Still in an attempt to get as much information as possible, suggestions must be categorised to help group requests logically and facilitate searches.

  • Votes

Votes are designed to help rank requests. They will help identify the most popular requests.

  • Comments

If a request is similar to an existing suggestion, comments allow users to give another view on the suggestion and provide new arguments rather than create a new one. Adding to existing demands rather than creating a new one is more useful and it allows a suggestion to collect more votes.

  • No status

The point is to allow suggestions to evolve with the community of users and let them become more specific, better-defined and respond to the expectations of as many people as possible. Anyone can add a comment and enhance their vision at any time. BlueMind takes it over at the appropriate time and sets it as “accepted” to draw up the final specifications and carry out the suggestion.

How does BlueMind use the Suggestion Box?

Designing a software RoadMap is a publisher’s job. The Suggestion Box is a component that contributes to the RoadMap among many others. The Suggestion Box is not the absolute basis for the RoadMap, but it will serve to complement the feedback and planned internal projects.

The number of votes for a suggestion tells us how popular a request is. However, BlueMind may decide not to give priority to a suggestion with a large number of votes and prefer a less popular suggestion.

This is because for technical, planning, consistency or strategic reasons, the Product Owner is the one who makes the final decision on a sprint R&D.

Moreover, “internal” tasks, not requested by users (change in API, development library, etc.) may be given priority in order to plan for the possible development of an advanced feature at a later time.

When we decide to upgrade a component (calendar, administration, contacts, etc.), the Suggestion Box is used to find out our users’ expectations and what improvements can be made given a variety of constraints.

Categorising the Suggestion Box allows us to restrict the analysis of suggestions to the module we have chosen to upgrade.

Bottom line

Two years after the Suggestion Box was launched, feedback is extremely positive.

Today our backlog includes 78 stories broken down into 22 EPIC while previously, we were struggling with 470 stories in backlog and another 170 non-analysed features.

The Suggestion Box includes 224 suggestions, 662 votes have been made  on 134 suggestions. 50 suggestions have been carried out, some with many votes (up to 46), some with fewer votes but that were considered high-priority.

Additional Information

You can find BlueMind’s Suggestion Box at https://community.bluemind.net/suggestions/

Our development is OpenSource and you can find everything you need to know about this project at http://www.suggestion-box.io

The Suggestion Box is the result of a lot of in-house discussion and reflection, in particular with Dominique Eav, our quality manager and developer of the Suggestion Box.

And, as we keep updating the Suggestion Box, you’re welcome to create a suggestion for the Suggestion Box!

Integrare facilmente gli eventi Doodle con BlueMind!

BlueMind v3.5 permette ad ogni utente di creare calendari multipli per organizzare le proprie attività.

Questi calendari posso essere gestiti manualmente ma anche alimentati da una sorgente esterna di calendari quali Doodle o Gmail.

Ecco i 4 nuovi usi oggi possibili di questa funzionalità:

  • la visualizzazione dei vostri eventi Doodle direttamente nel vostro calendario
  • l’inserimento delle vostre disponibilità registrate su BlueMind nelle applicazioni Doodle
  • la visualizzazione di un calendario esterno in BlueMind, senza che questo influenzi le vostre disponibilità
  • la creazione di un calendario condiviso alimentato da una sorgente esterna (come le vacanze scolastiche, per esempio)

agenda_doodle_bm

Questo documento affronta i primi due casi.

Leggi tutto “Integrare facilmente gli eventi Doodle con BlueMind!”

BlueMind trasforma Thunderbird in un vero client collaborativo!

bluemind-thunderbirdUn ostacolo frequente all’adozione di un server di posta Open Source è la predominanza di Outlook come client, poichè Outlook funziona sempre in modo diverso (quindi peggio) con un server diverso da Exchange… in attesa dell’innovazione di BlueMind con il supporto nativo di Outlook!
E’ una questione di abitudine (o di assuefazione) degli utenti, ma anche perchè l’offerta di validi client di posta (e di collaborazione) Open Source e multi-piattaforma è quasi nulla.

Il client Open Source di riferimento è Thunderbird di Mozilla, che è disponibile per Windows, Mac, Linux & altri.
Tuttavia, se Thunderbird è un buon client di posta, è scadente come client collaborativo. La funzione di calendario è gestita con una estensione, Lightning, che non è mai stata soddisfacente a livello azioendale (questione di ergonomia, prestazioni, etc.): l’utente non comprende il motivo di 2 interfacce differenti, così come l’ergonomia e le funzionalità differenti a seconda del metodo d’accesso (web o client).

BlueMind propone una gestione completa di Thunderbird, orientata all’utente, che risponde esattamente a queste problematiche.

Scoprite Thunderbird come client naturale per BlueMind!

Leggi tutto “BlueMind trasforma Thunderbird in un vero client collaborativo!”

Tutorial: come scrivere un add-on per BlueMind

Eccoti di fronte al setup del tuo nuovissimo BlueMind. Hai sentito parlare della sua notevole architettura interna, di possibilità di estensione, di piattaforma p2 e REST API, ma non sai bene da dove cominciare. Eccoti! Questo tutorial è stato scritto proprio per te.

Devi conoscere un po’ di java ed essere più o meno familiare con maven (e con l’inglese…)

Your goal: a dummy scheduled job

Let’s say your BlueMind add-on will be a scheduled job. You can view the BlueMind scheduler as an internal CRON that will execute jobs when planned, which is pretty handy to assist you in administrating your server.

This scheduled job will log some dummy stats – basically what we’ll do is just a placeholder to demonstrate how to glue the REST API bricks together. Doing something more meaningful will be left as an exercise to the reader 🙂

Your scheduled job will list all mobile devices for all users for all domains of your BlueMind server. Just because you can. We’ll call it MobileDevicesListingJob.

A word of caution

Don’t forget that when you’re using the REST API with a BlueMind server, you’re dealing with real users data and it’s pretty easy to make mistakes, since everything you can do in BlueMind can be done using the REST API. There won’t be a confirmation screen like we do in the Administration Console: when in doubt, just don’t. Or better: do your API tests on a sandbox server. We won’t be modifying data in this tutorial, so you should be safe, but you’ve been warned.

Bootstrapping a maven project

If you take a peep into BlueMind internals, it’s OSGi bundles all over the place. Since we want to build a BlueMind add-on, we depend on BlueMind target platform.

This target platform is published as a p2 repository, and you can find it at http://pkg.blue-mind.net/p2/latest/

As the URL implies, this is the latest and greatest BlueMind target platform. It will get updated every time we publish a new BlueMind release – and hopefully upgrading won’t break your work.

We’ll be using Tycho, which makes it easy to build your bundles with maven. Here is the simplest project_structure. Download it and extract it somewhere.

This project is restricted to the bare minimum. I won’t delve into the details of the configuration files since they are not BlueMind specific, but I want to emphasize two points:

  • pom.xml declares where to find the BlueMind target platform
  • plugin.xml declares what extension point we’ll be using, namely scheduledjob_provider, along with the name of our soon-to-be-written java class: org.example.mobiledeviceslistingjob.MobileDevicesListingJob

The rest is just boilerplate configuration.

Alternatively, you could also use our maven archetype to bootstrap your project. Or clone bluemind-samples to find an existing add-on to adapt. There are more than one way to skin a cat. Or a duck. Well…

In the project directory, you can run:

mvn install

Et voilà! You’ve built your project, but it won’t work yet: there’s no code.

Eclipse to the rescue

You may just go ahead and write the java code using your favorite editor, but here is how you’ll do with Eclipse:

  1. Import your maven project into your workspace
  2. Tell eclipse about the BlueMind target platform: go to Preferences, search for “Target Platform”, and add a new target platform definition. You need to start with an empty target definition, pick up some name (for instance “BM target platform”), then add the URL above as a new Software Site location:

screenshot-from-2017-03-29-17-43-39

Select all (the “Uncategorized” checkbox in the previous screenshot), click on Finish and you’re done. Careful, you need to select the target platform we’ve just defined before you close the Preferences window.

Setting up the dependencies

We need to declare what parts of the BlueMind target platform we’ll actually use in the MANIFEST.MF. Our REST API online documentation for will help you to cherry-pick the parts you’ll need. If you’ve installed the optional bm-docs package and given the Api docs permission to your user, this documentation should be available right in the BlueMind UI:

screenshot-from-2017-03-30-09-36-52

Icing on the cake: this inline documentation is interactive, so you can execute calls using the javascript client. Beware, the previous caution notes also apply! (the harm you’ll be able to do depends on your logged-in user’s rights)

The BlueMind source code is also be a good place to find inspiration.

Here are the dependencies we’ll need, just add these lines at the end of the MANIFEST.MF:

Require-Bundle: net.bluemind.domain.api,
 net.bluemind.user.api,
 net.bluemind.device.api,
 net.bluemind.scheduledjob.scheduler,
 net.bluemind.core.rest,
 net.bluemind.slf4j
  • net.bluemind.*.api : the REST apis we’ll need to explore domains, users and mobile devices
  • net.bluemind.scheduledjob.scheduler: to make use of the extension point
  • net.bluemind.core.rest: to setup authentication to the REST API
  • net.bluemind.slf4j: logging classes – since we won’t do much more than log some information at the end of the day

Have fun with the REST API

So go ahead and create the class we’ve declared in plugin.xml: org.example.mobiledeviceslistingjob.MobileDevicesListingJob. It has to implement IScheduledJob for scheduledjob_provider to be able to plug it in. Here is the complete code. I will only include here the actual business logic:

// logger will write in bm core logs (/var/log/bm/core.log)
logger.info("Executing MobileDevicesListingJob");
// sched will write in the execution report, that you can send by mail in the Job setup UI
sched.info(slot, "en", "Collecting mobile devices data for all users...\n");
// write header row for the data to come
sched.info(slot, "en", "device; isWipe; lastSync; user; domain");
// initialize client for domain service
IDomains domainService = ServerSideServiceProvider.getProvider(SecurityContext.SYSTEM)
    .instance(IDomains.class);
// loop on all domains
domainService.all().stream().forEach(domain -> {
  // initialize client for user service
  IUser userService = ServerSideServiceProvider.getProvider(SecurityContext.SYSTEM)
      .instance(IUser.class, domain.uid);
  // loop on all users
  userService.allUids().stream().forEach(userUID -> {
    // grab full details for user
    ItemValue<User> user = userService.getComplete(userUID);				
    // initialize device service for each user
    try {
      IDevice deviceService = ServerSideServiceProvider.getProvider(SecurityContext.SYSTEM)
          .instance(IDevice.class, userUID);
      // loop on all devices
      deviceService.list().values.stream().forEach(device -> {
        // collect info for this device
        List<String> deviceInfo = new ArrayList<>();
        deviceInfo.add(device.displayName);
        deviceInfo.add(Boolean.toString(device.value.isWipe));
        deviceInfo.add(device.value.lastSync.toString());
        deviceInfo.add(user.displayName);
        deviceInfo.add(domain.displayName);
        // write a line in the report					
        sched.info(slot, "en", String.join("; ", deviceInfo));
      });;
    } catch (ServerFault exception){
      // Skipping this user since she doesn't have a "device" container
    }
  });
});

 

Deploy to your BlueMind server

You can compile this code with

mvn clean install

Then drop the resulting jar (target/org.example.mobiledeviceslistingjob-1.0.0-SNAPSHOT.jar) in the folder /usr/share/bm-core/extensions of your BlueMind server. Then you can restart bm-core

/etc/init.d/bm-core restart

And your job should appear among the Scheduled Jobs in the Administration console. You can then execute it, schedule it, send the report to your best friend, it’s all yours.

Caveat: if you need to recompile/redeploy your extension, you may need to delete bm-core’s cache to be sure the fresh jar is picked up:

rm -Rf /var/lib/bm-core

Talking REST from the outside world

You’ve noticed we’ve used a ServerSideServiceProvider to initialize the REST API services, but you can of course talk REST from the outside world, for instance by using our python client. You need a BlueMind API key to do so.

Share your work!

Don’t bother sharing your MobileDevicesListingJob, but once you’ve done something useful you may want to share it on BlueMind Marketplace. We’ll be looking forward to your contributions!

Integrazione di BlueMind e Salesforce

Uno dei punti forti di BlueMind è la sua architettura aperta, che permette facilmente l’integrazione con altre componenti ed applicazioni del sistema informativo.
Un esempio classico è l’integrazione con applicazioni CRM (Customer Relationship Management) quali E-deal e Salesforce.

Questo articolo presenta l’integrazione con Salesforce, attraverso un caso reale di un cliente.

———————————————————

Integration with Salesforce essentially involves:

• The synchronization of BlueMind data with Salesforce data,
• The CRM being fed the email messages in connection with current business,
• simple and easy access to the CRM’s contacts and companies in the BlueMind Contacts application.

This client has been using BlueMind for over a year and its sales teams use Outlook with BlueMind. Sales staff must, from Outlook, interact and feed Salesforce. Communications with prospects and clients essentially go through email.

In the course of their sales work, users themselves currently identify the email communications that are useful to the CRM software. They therefore need an easy way to enrich the CRM using their emails’ data. New user interfaces are needed for this as well as for organizing, sorting and qualifying the information received by email.

Having looked at several Outlook plugins, we chose LinkPoint Connect for Salesforce. Unlike the plugin provided by Microsoft, it does not require the presence of an Exchange server. It is therefore fully compatible with BlueMind.

Configuration of the plugin

Outlook is already configured to use the BlueMind connector for Outlook, which is described here: The Outlook connector.
The LinkPoint Connect for Salesforce plugin must then be installed in Outlook. In terms of configuration, all that is required is the SalesForce log in credentials.

Outlook/Salesforce synchronization

By default, the plugin synchronizes events, contacts and tasks between SalesForce and Outlook. Through the Outlook for BlueMind connector, this same data (events, contacts, tasks) is automatically synchronized with the BlueMind server.

bluemind-salesforce_01

Using the LinkPoint Connect plugin

This plugin enables the following scenarios:
• You receive an email message about a business lead or sales opportunity: you can simply attach it to an opportunity.
• This message is expected to lead to interactions in the future: set up an appointment, get back to them, send information, etc.:  You can set up an action straight from Outlook which will be added to the CRM and fed back to the BlueMind Calendar or Tasks application.
• You want to contact one of your prospects in the CRM database. You can, in BlueMind, look for their contact card, send them an email message or, if you use unified messaging (such as BlueMind – Xivo), call them through a simple click.

Connecting a message to a contact

Say you are connected to BlueMind and SalesForce as John Doe and you receive an email from John Smith initiating a sales lead. If that person is not known to the CRM software, you can simply create a contact for them (and their company if necessary).

Once it is created or if it already exists, the plugin displays a pane showing its contact card and related information. In this pane, you can:
• access the full contact and company card, in SalesForce:

bluemind-salesforce_02

  • connect the email you’ve received to an opportunity (or lead depending on the CRM software’s terminology) or to the contact:
    bluemind-salesforce_03
  • start a new opportunity, connect the email to it and specify:
    • other contacts in the company
    • company/ies related to the opportunity
    • attachment(s) that need to be keptbluemind-salesforce_04
  • create new interactions (actions) related to the opportunity such as appointments, follow-ups, etc.
  • synchronize these interactions with Outlook and BlueMind:

bluemind-salesforce_05

Simplified access to Salesforce contacts

Finally, you can synchronize contacts and companies from the Salesforce CRM in BlueMind address books:

• Either by feeding salesperson-specific address books with their own contacts (prospects, clients)
• Or by feeding a single address book for the entire sales team.

As a result, Salesforce contacts can be viewed and accessed in BlueMind to send email messages or use click2call.

bluemind-salesforce_06

BlueMind and its APIs: accessible IT app integration!

Here is an example of how easy integration with BlueMind can be. Thanks to our APIs, which are open source and documented, such integration is easy and accessible for our partners and end clients alike.
Our marketplace includes new integrations and gateways that help make BlueMind and the IS easier to use for users.
In the next few weeks we’ll talk to you about the integration project with the E-Deal solution which is underway for a major French insurance company…

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer