COSA HO CAPITO DI HANA AL SAP SIMPLE TOUR 2015 - ALTEA ....
Tutti
noi percepiamo HANA come il nuovo DATABASE di SAP ma in effetti sembra
assolutamente non corretto: HANA è in realtà la nuova piattaforma su cui si
appoggiano gli applicativi, compreso l'ERP S4HANA che sarà
"degradato" a uno degli applicativi gestiti dalla piattaforma, in
particolare quello che si occupa dei dati "di accounting" aziendali,
mentre altri contesti di gestione di dati possono essere gestiti dalla
piattaforma sia come store sul DB che come strumenti di programmazione /
interrogazione / manipolazione.
HANA
è quindi un server DB, un application server (per tutte le applicazioni tra cui
S4HANA) e un ambiente di sviluppo autonomo che integra anche il
"vecchio" ABAP.
Le
caratteristiche del DB di HANA sono molto particolari, principalmente perchè è
un database COLONNARE con una gestione "IN MEMORY" delle tabelle.
Rapidamente,
un database colonnare cambia radicalmente la visione dei dati rispetto ad un
database relazionale perchè sposta la struttura fisica delle informazioni dalle
righe alle colonne.
Un data base relazionale
fonda la propria struttura fisica sulle tabelle che sono "righe" di
dati omogenei per "appartenenza": una tabella cliente contiene
informazioni che appartengono al cliente, quindi ragione sociale, indirizzo,
località, partita IVA, etc. etc. Poi può collegare tramite viste e indici
diverse tabelle per allargare logicamente l'ambito di "appartenenza",
quindi la tabella del fatturato dei clienti può essere collegata con viste
logiche alla tabella del master data clienti.
Un data base colonnare invece
sposta la struttura fisica del DB sulle colonne, quindi sui dati che hanno lo
stesso "significato". Una tabella di conseguenza conterrà le ragioni
sociali di tutti i clienti in colonna, un'altra gli indirizzi, un'altra i
fatturati, etc. Con questa struttura si ottimizzano gli accessi per consultazione
perchè tendenzialmente è difficile che una query sui dati cliente riporti in
risultato contemporaneamente i dati della tabella relazionale fisica relativa,
ma magari si limita a ragione sociale sociale e fatturato. Il data base
colonnare scorre per colonna le informazioni ed accede quindi fisicamente a
quelle strettamente necessarie alla query, senza fare "fetch" di dati
inutili come farebbe un relazionale.
Chiaro
che c'è un prezzo da pagare: le applicazioni di tipo transazionale che
utilizzano SQL per accesso ai dati sono impossibilitate ad utilizzare una
struttura "NON SQL" di questo genere, quindi il data base colonnare
deve ricostruire le "ex-tabelle fisiche" tramite puntatori sui dati
distribuiti sulle varie colonne. La gestione "IN MEMORY" di HANA
dovrebbe aiutare a minimizzare l'effetto di questa
"disottimizzazione". E' evidente comunque che chi sceglie un DB
Colonnare pensa che l'utilizzo prevalente del DB sia per consultare e
manipolare i dati, e questo già dice qualcosa.
Un
altro messaggio forte è che sembra che uno dei pilastri delle applicazioni
degli ultimi 15 anni, la DATABASE INDEPENDENCY, stia venendo meno nelle
strategie di SAP (e forse non solo).
L'area
di compatibilità tra i diversi database di mercato (SQL/Server, ORACLE, DB/2,
etc.) è rimasta quella degli anni '80, quindi la parte ANSI/SQL. I data base
hanno evoluto enormemente nel frattempo incorporando funzionalità molto
avanzate (snapshots, stored procedures, triggers, etc. etc.) che però non sono
mai state standardizzate dai vari produttori, così che chi voleva mantenersi
indipendente dal DB poteva sfruttare un set ridottissimo di funzionalità
disponibili nei data base moderni, quelle "standard"; paradossalmente
vengono escluse proprio le funzionalità più avanzate che generano efficienza e
performance nell'accesso ai dati. Quindi chi mantiene DB independency usa poco
del DB e probabilmente rinuncia a ottimizzazioni prestazionali importanti.
Secondo
SAP questo mondo sembra al capolinea e dovendo aumentare la performance dei
sistemi, sopratutto nell'ambito dell'analitycs e della data manipulation, SAP
ha scelto di abbandonare la "indipendenza" della piattaforma e
saltare su un ambiente aperto ma proprietario.
Sembra
talmente vero questo che HANA è non solo una struttura dati e un ambiente che
ospita applicazioni totalmente proprietario, ma necessita per l'ottimizzazione
prestazionale di un hardware pensato "ad hoc".
Per
alcuni aspetti i “vecchi” come me potrebbero rivedere la storia dell’AS/400 di
IBM iniziata nel 1988: anche lì per introdurre efficacemente uno dei primi data
base relazionali usato in modo estensivo per applicazioni gestionali, IBM creò
una piattaforma ad-hoc che incorporava HW dedicato, Data Base, ambiente di
sviluppo, sistema operativo e per alcuni aspetti anche gli applicativi (le ACG
…) in un’unica entità. Ha funzionato per più di 20 anni ….
Questo
comporta alcuni radicali cambi di pensiero rispetto a come pensiamo SAP oggi,
ad esempio:
-
l' ERP diventa uno dei contenitori dei dati, in particolare i dati con
rilevanza fiscale e gestionale aziendali. Poi c'è un altro mondo potenzialmente
più ampio su cui l'ERP non è necessariamente coinvolto. Il workbench
applicativo si sposta anche fuori dal contenitore ERP
-
quasi un corollario quindi il fatto che il nostro normale assunto che per
caricare dati dentro SAP si passa per tools del sistema R/3 (I.Doc, web
services, etc.) può venire meno. Ci sono altri tools e workbench disponibili in
piattaforma con HANA. Solo se carichiamo dati con rilevanza contabile dobbiamo
farli passare per l'ERP per la validazione formale e di processo
-
perde di senso la distinzione tra reporting operativo (brutto come layout, che
lavora a dettaglio e con forti limiti di range di estrazione), reporting
direzionale (bello come layout ma che lavora per sintesi con estrazioni anche
ampie ma senza dettagli) e manipolazione di dati (budget, analisi di trend,
etc). Il data base colonnare aumenta di ordini di grandezza la performance dei
tools di analisi e manipolazione, e rende possibile lavorare su dati di dettaglio,
senza sintesi pre-calcolate e con range ampi di estrazione
-
la manipolazione dati diventa molto più facile e performante
HANA
inoltre è un data base multicontainer, quindi in una unica installazione
possono convivere agevolmente molte istanze di data base e non serve più il
tradizionale "splitting" dei DB server per le diverse istanze
applicative (R/3, BW, BO, etc.).
Sulla
applicazioni ERP: S4HANA dovrebbe convivere con R/3 per 10 anni, fino al 2025
secondo le dichiarazioni di SAP. In questo tempo avverrà la riscrittura di
tutte le applicazioni che andranno verso la interfaccia "Fiori",
quindi HTML5. Questo comporta una interfaccia adattiva e responsiva verso i
diversi devices come smartphone, tablets e PC che si adatta automaticamente
alle diverse dimensioni dello schermo e alla rotazione del dispositivo.
Tutti
i moduli di S4HANA avranno l'acronimo "simple", al momento SAP ha
rilasciato SOLO SIMPLE FINANCE (ex SAP/FI) sulla nuova interfaccia Fiori e con
un data base che vede una drastica riduzione delle tabelle impiegate,
soprattutto quelle di riepiloghi e totali pre-calcolati, lasciando tutti i dati
“a dettaglio”. La performance di HANA dovrebbe colmare il GAP e consentire di
avere sempre dati sintetizzati in tempo reale senza pre-calcoli.
Sempre riguardo le
prestazioni, infine, anche manipolare dati con tools ad hoc per fare budget,
analisi di trend, etc dovrebbe smettere di essere un problema di performance e
complesse elaborazioni di pre-calcolo di tabelle di distribuzione per diventare
solo un problema di permissions e rispetto della integrità delle informazioni (togliere
integrità di contenuto alla tabella dell'IVA non sarebbe una buona idea neanche
su HANA ...).
Nessun commento:
Posta un commento