Quando un software enterprise è pronto ad affrontare il futuro?

Quando si vuole andare su architetture moderne e scalabili è necessario che queste fondamenta, ovvero quelle funzioni di abilitazione tecnologica che permettono di costruire applicazioni, possano funzionare anche in ambienti cloud multi server, multi cloud e server less e che possano appoggiarsi poi a tecnologie che quando queste cose sono state pensate non esistevano neanche.

Ma non solo: un fattore ancora più complesso è rappresentato dal fatto che è necessario costruire le applicazioni con dei linguaggi DSL, ovvero Domain Specific Language, che si appoggiano a delle tecnologie che continuano a cambiare.
Questo perché all’interno delle aziende sono presenti esperti del dominio applicativo, esperti di contabilità, esperti di magazzino, esperti di solleciti, esperti di ambiti funzionali applicativi ma che essendo esperti di queste cose non sono anche esperti di tutta la tecnologia che ci sta sotto, quindi per poter fornire un supporto adeguato a queste persone si rende necessario un ulteriore livello di astrazione. 

Il  contesto delle applicazioni enterprise è così complesso proprio perché ci sono tante figure, altrettante necessità e le aziende si aspettano sempre di più che le soluzioni a questa necessità siano fornite “chiavi in mano” direttamente dalla software house.

Per approfondire il tema dei sistemi distribuiti e delle architetture scalabili, ascolta l’intervento di Mauro Sanfilippo, CTO di smeup, durante una lezione tenuta presso l’Università di Brescia.

Cosa abbiamo fatto in smeup?

Sì, come vi abbiamo anticipato poco, fa, in smeup abbiamo stratificato l’applicazione. 

Come?  

Solitamente si parla di applicazioni a tre livelli: presentation, business e dati. In smeup abbiamo inserito un livello di astrazione in più e abbiamo separato tutta la parte di presentazione in due: view e presentation.

Sono infatti presenti la parte di presentation, ovvero la parte che stabilisce cosa succede in base a cosa viene cliccato e si occupa quindi della navigazione che è separata dalla visualizzazione, e la parte cosiddetta di “view”, che si occupa solo ed esclusivamente della visualizzazione. La parte di astrazione è molto importante perché consente di non essere legati a dove risiedono fisicamente i dati.

Gli oggetti

In smeup quando parliamo di oggetti non ci riferiamo agli oggetti del Software Object Oriented, ma parliamo di oggetti applicativi, che sono quelli che vengono utilizzati direttamente dall’utente quindi sono oggetti come ad esempio  il contatto, l’ordine, la banca.

La differenza di smeup data platform rispetto ad altri sistemi, risiede nel fatto che rende l’oggetto applicativo quello che viene definito un first class citizen, qualcosa di veramente importante tanto che è codificato in maniera rigorosa all’interno del sistema ed è questo che fa la grande differenza rispetto alla classica accezione di software object oriented, tanto che smeup è sviluppato in software non object oriented.

Un fattore chiave di questo tipo di architettura risiede nel fatto ogni attributo di un oggetto è a sua volta tipizzato come oggetto: questo determina un reticolo di collegamenti che poi noi utilizziamo in maniera molto efficiente. 

Un esempio concreto? Il cancello della sede smeup di Erbusco!

Questo reticolo di informazioni ci permette infatti di realizzare delle navigazioni in maniera molto veloce, per esempio nella sede di smeup di Erbusco quando arriva una macchina davanti al cancello rileviamo la targa e la mandiamo al gestionale, il gestionale riceve soltanto la targa ed ha a disposizione tutto il suo reticolo per poter decidere se aprire o meno il cancello, che di fatto si apre solo per i dipendenti di smeup.

Ti abbiamo incuriosito con l’esempio del cancello? Approfondisci meglio come funziona cliccando qui.

I Microservice, ovvero l’architettura dei sistemi del futuro

Il concetto di API (Application Programming Interface) indica il modo in cui un software o il sistema operativo espone dei servizi richiamabili da altri programmi. Oggi il termine API è più comunemente utilizzato per indicare il fatto che un software espone le sue funzioni all’esterno, è un servizio. La fruibilità remota di queste funzioni è quasi sempre legata alla tecnologia dei webservice, dei sistemi software che comunicano tramite il protocollo http, da cui il prefisso web, ed è su questo si poggia l’integrazione di sistemi.

L’integrazione è la chiave per costruire delle soluzioni complete. Ma non è tutto, non basta: un sistema software complesso, mission-critical, ha anche al suo interno il problema dell’integrazione tra i suoi stessi componenti.

Per risolvere questo problema è stata introdotta una delle più importanti rivoluzioni dell’informatica moderna, che si poggia sulle API e sui webservice: l’architettura a microservice.

Si tratta di uno stile architetturale, evoluzione del SOA, che ha iniziato a diffondersi tra il 2011 e il 2013 nella comunità mondiale degli ingegneri del software, che definisce un sistema complesso come un insieme di webservice “piccoli” e stateless, indipendenti, isolati, capaci di sopravvivere all’indisponibilità degli altri, replicabili, sostituibili “a caldo”. La grande sfida è che questi servizi sono spesso fisicamente distribuiti su macchine hardware differenti, quindi portano il concetto di disponibilità ad un livello più alto: una di queste macchine può spegnersi, senza inficiare il funzionamento del sistema, anche perché ogni microservice è replicabile, non avendo uno stato, quindi ridondato.

I microservice parlano tramite le API: devono dichiarare la propria interfaccia, ossia i loro dati di input e di output . Così si rendono incapsulati, sono una scatola nera e possono cambiare internamente senza che il mondo esterno se ne accorga.

Perché diciamo questo?
Perché questo è il futuro di tutti i sistemi con ambizione enterprise, quindi anche dei sistemi gestionali complessi, se vogliono garantire scalabilità e affidabilità.

In smeup le funzioni generali, che possono essere utilizzate in più posti e richiamate, dette /copy, sono state catalogate e definite in maniera rigorosa, come i contratti delle API (per essere precisi in smeup le /copy sono sempre state definite API).

smeup è stato progettato in questo modo quando i microservice non erano stati ancora pensati, perché i vantaggi dell’incapsulamento e del contratto tra funzioni erano già evidenti, quindi è già intrinsecamente pronto per l’architettura a microservice. Le /copy sono disaccoppiate, isolabili e remotizzabili. Verranno man mano rese dei microservice, finché l’intero sistema non potrà essere distribuito su più server, diventando sempre più scalabile e affidabile. 

Interfacce evolute e rich client

Un sistema software che si pone l’obiettivo di interagire con gli utenti deve necessariamente avere un’interfaccia ricca, veloce, evoluta. Questa interfaccia deve cambiare spesso, perché deve adattarsi alle necessità di efficienza degli utenti, alla disponibilità di componenti e all’isteria delle tecnologie. E’ la parte di qualunque sistema software più incline al cambiamento.

Nel 2015 nasce un progetto capitanato dal gigante Google, denominato Angular 2. Si tratta di un framework, cioè un insieme di strumenti e tecniche per costruire software, il cui seguito è immediato e globale. Angular propone un modello per costruire interfacce utente evolute, veloci, manutenibili, testabili, basato sul concetto di componente, che è molto comune, ma con alcune caratteristiche peculiari. Ogni componente è responsabile solo dei suoi dati e della sua visualizzazione, lancia eventi e qualcuno li ascolta (tipicamente un componente di più alto livello). Il componente chiede i dati a servizi.

E’ emblematico come questo tipo di rappresentazione dei componenti rispecchi il modello di componenti adottato da smeup ERP, in cui la schermata principale (scheda) è divisa in componenti, ognuno capace da solo di reperire i propri dati tramite servizi (le FUN), di disegnarsi e di inviare eventi, che altri componenti ascolteranno.

Perché questo è importante?
Perché se i componenti hanno queste caratteristiche, la loro evoluzione è garantita: essendo isolati sono semplici da realizzare e da sostituire. E’ semplice trovare componenti già pronti. E’ semplice testarli.

Questa architettura ha permesso a smeup ERP di cambiare velocemente la tecnologia per la realizzazione dei propri client e di realizzarne per diverse necessità e piattaforme, senza cambiare il modello e concentrandosi sui componenti. Ovviamente smeup sta usando anche Angular per realizzare il nuovo client grafico.

Internet of Things: il sistema informativo distribuito

L’acronimo IOT indica l’Internet delle Cose, perché le cose, gli oggetti fisici, sono interconnessi, si scambiano dati ed eseguono operazioni.

L’IOT è una grande opportunità per il mondo produttivo, non è il caso di elencarne qui le possibilità; basti pensare che è possibile, ad esempio, dotare oggetti prodotti in uno stabilimento di sensori che comunicheranno con la sede centrale anche dopo che l’oggetto sarà venduto. Questo cambia l’ordine della cose: la vita di un articolo all’interno del sistema informativo, che in molti casi sarebbe finita nel momento in cui è stato consegnato, continua. Si può pensare quindi che i sensori che sono a bordo dell’articolo, fanno anch’essi parte del sistema informativo stesso, rendendolo un sistema distribuito.

Solo un ERP flessibile e ben progettato, incentrato sulle entità, può adattarsi a un cambiamento simile. Questa descrizione è la base per il controllo e l’evoluzione: non è possibile gestire una rete di oggetti interconnessi senza una rappresentazione organica delle loro caratteristiche statiche (cosa sono) e dinamiche (come si stanno comportando).

L’ERP del futuro non sarà più relegato al freddo della sala server o in un datacenter tra le montagne: sarà sparso per il mondo insieme agli oggetti che lo compongono.

Ti abbiamo incuriosito?
Per approfondire ascolta l’intervento di Mauro Sanfilippo,
CTO di smeup, a Codemotion 2020.