Quando un software enterprise è pronto ad affrontare il futuro?

Quando un software enterprise è pronto ad affrontare il futuro?

Quando parliamo di software enterprise stiamo parlando di un software che permette la gestione strutturata di tutti gli ambiti di un’impresa, un sistema informatico in grado di gestire e pianificare tutte le risorse e ottimizzare i processi, anche trasversalmente alle diverse aree aziendali.
Anche per il futuro, i sistemi software enterprise saranno uno strumento fondamentale per le aziende. Anzi: saranno lo strumento che consentirà l’evoluzione digitale delle imprese. Ma anche i software devono fare i conti con il futuro: la direzione, per questo tipo di sistemi, è quella della modernizzazione attraverso il rinnovamento delle tecnologie e dei servizi utilizzati. Ma non tutti i sistemi enterprise sono adatti all’evoluzione: ci sono alcuni requisiti fondamentali per far sì che un sistema possa esserlo, a partire dall’architettura.    

Perché dobbiamo parlare dell’architettura del software e della sua importanza? 
La domanda può sembrare complessa ma la risposta è semplice: perché le aziende oggi chiedono un sistema enterprise che sia distribuito e che sia concentrato sulla gestione dei dati.

Un sistema distribuito

Distribuito perché, come già succedeva negli anni ‘90 a volte le aziende non erano informatizzate ma quando lo erano avevano dei sistemi preesistenti e il modo in cui si inseriva un nuovo sistema gestionale era quello di aggiungerlo ai sistemi preesistenti. Questo non è diverso da ciò che avviene oggi. La differenza risiede nel fatto che oggi invece che essere tutto all’interno di un mainframe, di un server, di un’unica architettura che oggi viene definita legacy, i sistemi sono distribuiti e sono veramente eterogenei. Con eterogenei si fa riferimento ad integrazioni di qualunque genere, in cui le interfacce sono multiple: web, native… Oggi esistono più interfacce utente, nonché una serie di oggetti da cui le applicazioni prendono i servizi, senza che l’utente se ne accorga.

Come ottenerlo? Per poter ottenere questo è necessario innanzitutto disporre di un sistema in grado di evolvere sia dal punto di vista applicativo che dal punto di vista tecnologico, perché anche se la vita media di un software gestionale in un’azienda arriva spesso ai 10 anni e oltre, le tecnologie mutano molto più velocemente dei processi aziendali. Quello che si rende necessario quindi è disporre di una piattaforma che comprenda al proprio interno la tecnologia pura e sulla quale si possano appoggiare degli enabler che rappresentano uno strato di astrazione che si appoggia a questa tecnologia. E’ quello che abbiamo fatto in smeup! Ecco una rappresentazione grafica.


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 del
le 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.



Qual è la direzione per i sistemi enterprise?

E’ per tutti i  tutti i motivi elencati finora che oggi si rende necessario creare un’infrastruttura che permetta all’utente finale di decidere qual è il percorso all’interno di questo reticolo per poter far sì che il gestionale prenda la decisione giusta.

Con l’evolvere delle tecnologie si andrà sempre più verso l’astrazione dei dati, che non saranno più locali, ma dovranno essere multi database, multi prodotto, sempre più integrati e delocalizzati, proprio per rispondere all’esigenza delle imprese che hanno i propri dati situati in posizioni differenti.

Vediamo quindi alcune tecnologie che riguarderanno con buona probabilità i software enterprise nei prossimi anni, e rappresentano quindi il banco di prova per identificare se un sistema ERP è pronto ad affrontare il futuro.
smeup ERP è stato progettato per l’evoluzione, quindi è già pronto anche per questi cambiamenti. Ecco come.

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: larchitettura 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 Sme.UP 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 Sme.UP le /copy sono sempre state definite API).

Sme.UP è 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 Sme.UP 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.


Le chiamate basate su pattern testuali

Una parte fondamentale di internet sono le URI, gli indirizzi, quelle stringhe di testo che, basandosi su semplici convenzioni permettono di identificare qualunque risorsa (Universal Resource Identifier) tra miliardi.

Lanciare una URI significa far avvenire diverse operazioni di identificazione e instradamento fino alla risposta del server che possiede la risorsa, tendenzialmente un testo, in un formato, HTML, che in base a semplici convenzioni diviene una pagina su uno schermo. Questo modello permette efficienza, scalabilità, disaccoppiamento, evoluzione.

Ad esempio, se oggi a

http://api.smeup.com/servizi/lista_articoli/viti.html

risponde un server e domani un altro, per chi chiama è trasparente. E se la pagina viti.html è generata da un programma, scritta a mano, letta da un dispositivo o chiesta a un terzo elemento, è lo stesso: dietro una URI può esserci un mondo.

Bene, le FUN in Sme.UP si basano sugli stessi principi ed hanno gli stessi vantaggi: stringhe di testo che, in base a una convenzione semplice, permettono di chiamare qualunque servizio e rispondono tendenzialmente con un testo, XML, che sempre in base a semplici convenzioni viene interpretato e genera un componente visuale su schermo.

F(EXB;*LIS;) 1(AR;VIT;)  //leggi Lista Articoli di tipo Vite


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


Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *