LONDRA – Il Business Digitale cambia la natura delle Applicazioni, che non si scrivono più su piattaforme separate di IT Infrastructure (per il Dipartimento It) o di Talent management (per l’HR) o di Leadership (per l’ Organizzazione) ma su una piattaforma Business che si appoggia su tutte le altre (figura 1).
Con l’avvento del “Nexus di forze” (il modello teorizzato qualche anno fa da Gartner e che definisce di estremo valore per l’innovazione e il business di impresa la convergenza di social, mobile, cloud e information) ogni piattaforma è abilitata ad integrarsi con ogni altra piattaforma, in cloud, in rete social, con terminali mobili. Con l’intelligence e gli analytics, il quarto attore del Nexus, le informazioni, si insedia come superpiattaforma che arricchisce le App e i processi di ciascuna delle altre. Il mantra è “rendi il tuo business digitale e application driven, programmabile e con funzioni smart” dice Richard Marshal , Managing Vp, Gartner nel corso dell’ultimo Gartner Summit su Application, Architecture, Development e Integration svoltosi a Londra e al quale ZeroUno ha partecipato in esclusiva: Digitale, con canali IoT, mobile e qualunque oggetto con interfaccia digitale sul mondo; programmabile attraverso API, per abilitare al digitale ogni oggetto o per interagire con Ecosistemi. Smart, per assistere in real time le decisioni di ogni processo con analytics ed intelligence.
E tutto questo deve poggiarsi su una piattaforma di Software Delivery in grado di supportare un processo di produzione più economico, di miglior qualità e più veloce, per una innovazione e rinnovamento delle App “a getto continuo”.
Le trasformazioni radicali dello sviluppo software
L’ Application Delivery, chiave di volta per un business sempre più digitale, poggia su trasformazioni consistenti:
- Deve essere la concretizzazione di una chiara strategia “Digital first” applicata in modo consistente ad application, information e integration;
- Il disegno dell’App deve fortemente puntare a una Customer experience capace anche di “improvvisare” a cogliere l’elusivo Business Moment;
- Vi devono essere team specializzati in una “Lean product delivery”;
- cresce lo sviluppo del concetto self-service.
Tutto Il nuovo processo si fonda su DevOps e il progressivo ricorso all’Automazione. Le App diventano:
- Globali, interconnesse, pervasive;
- Operabili da tutte le “mani”, business e It;
- Intelligenti sia per contestualità sia in modo predittivo;
- Affidabili ossia sicure, etiche, always on;
- Scalabili on demand;
- Estendibili e modificabili;
- Responsive e reattive.
Fattori concomitanti che cambiano la natura intrinseca delle Applicazioni sono:
- la Customer experience (Cx) o la più generale User experience (Ux). E’ sempre più probabile che l’ingaggio di un potenziale cliente sia digitale per cui la Cx determina la probabilità che questa continui in parallelo all’esperienza fisica.
- gli oggetti (things). Diventano usabili a tutti i livelli dell’organizzazione come sensori per “sentire cosa intorno all’oggetto avviene”, dice Marshal.
- i servizi interni. Vanno fatti “affiorare per dipendenti, clienti, partner, in mobilità e ovunque. Dobbiamo non solo offrire i nostri servizi, ma consumare quelli di altri attraverso gli Ecosistemi”, afferma il VP Gartner: usare cose e servizi che non possediamo e accettare che altri usino nostre risorse ottenendo servizi dai nostri sistemi. Per non essere tagliati fuori.
Obiettivo delle nuove App? “Fornire una Cx in condizioni sempre più improvvisate, con risposte in grado di sfruttare i Business Moment, sviluppando la capacità di capitalizzare – sottolinea Marshal – funzionalità e servizi tradizionali, digitali, e combinazioni dei due. Servirà un digital workplace sempre più sofisticato, per assemblare il tutto”.
I 12 princìpi chiave per l’App Architecture nel Business Digitale
Come si scrive una Business App? Risponde Yefim Natis, VP & Gartner Fellow: “Think Architecture first”.
Obiettivo della Business App è un outcome con Cx agile a cogliere un effimero Momento di Business. L’Architettura applicativa ad essa funzionale deve abilitare, con velocità e facilità, un continuo “Change, Replace, Scale, Decide, (Re)Invent e Fail” dell’App, per testare l’outcome e continuamente migliorarlo.
In questa prospettiva diventa inapplicabile la progettazione monolitica: lungo l’elenco tracciato da Natis di limiti di agilità, di over provisioning di risorse, di non estendibilità che aumenta i costi di cambiamenti continui, di non supporto del multichannel che limita l’innovazione e così via. Sono invece 12 i princìpi chiave identificati per scrivere Applicazioni per il Digital Business e considerando appieno anche il fenomeno IoT:
1) Orientamento Servizi
Fondamento di tutti i principi successivi, è l’impostazione classica, ereditata dal modello Client-Server anni ‘90, di una Logica di Request (le richieste dell’utente del servizio) ospitata dal Client che opera nel front-end su differenti canali, mentre il Server ospita sia una Logica di Business, che lavora nel backend, sia i dati, collegati attraverso API al Client e al Server.
Ogni Client, inoltre, può operare in senso inverso (ossia tanti Client si rapportano a un unico Server), agendo da “Composite” (termine con il quale Gartner intende che un unico Client può diramare le sue richieste a più backend).
2) Separation of Concern
Per promuovere Agilità, Efficienza e Resilienza, le App di Business ereditano dalla SOA (Service Orientd Architecture) il principio di separazione (o di modularizzazione) dei criteri di attenzione (concern). Tale separazione è strategica perché se concern diversi sono indirizzati in moduli diversi, non è necessario ri-testare del codice già verificato solo perché si trova nella stessa App che richiede modifiche (e quindi nuovo test). Sono da tener separate ad esempio Funzioni business diverse, tipi di attività diverse o con frequenza di cambiamento diverso, con scopo di visibilità diverso (es. servizi esposti all’esterno, a un esterno condiviso per riuso, o solo interni all’App), con esigenze di sicurezza, privacy, sensitività, con dipendenze diverse.
3) Mediated Services attraverso la Mediazione delle loro API
Quando aumentano esponenzialmente le utenze dei Servizi (che possono essere App, altri Servizi, Digital twin, Event Handler), i Servizi all’interno di un App backend vengono raggiunti attraverso un API Mediator che:
- controlla la legittimità dell’accesso in base a Policy
- fornisce una serie di funzioni di valore aggiunto (traduzione, orchestrazione, routing, load balancing, ecc) (figura 2).
La stessa Integration platform è una forma di API Mediator, specializzata per l’integrazione.
Nell’API Mediation è fondamentale il rispetto della disciplina: se si lascia che delle App aggirino l’API Mediator per accedere direttamente ai servizi, se ne fa scadere il valore (per esempio nel controllo di Security).
4) Macroservizi, Miniservizi o Microservizi
I MacroServizi, nati con la SOA, facilitano il riuso per integrazioni e composizioni in ambiente multi App. I MicroServizi, non esposti all’esterno, nascono con i grandi Web provider come Twitter o Facebook le cui App in linea devono riuscire a cambiare non due volte all’anno come un SAP, ma molte volte al giorno: consentono così il massimo di iperagilità e iperscalabilità. I MiniServizi non hanno tutta la rigida disciplina dei MicroServizi, offrono un giusto compromesso fra riuso e agilità: Natis li raccomanda “alle aziende che non hanno le esigenze di iperscalabilità e iperagilità dei grandi Web provider” per le Business App che devono “pensare agilmente” per poter rapidamente cambiare onde modificare l’offerta per soddisfare la Cx (figura 3).
5) Think IoT
IoT è “una formidabile ondata di innovazione business, applicativa e architetturale”, afferma Natis. Il digital twin è lo specchio digitale di un oggetto fisico ed è circondato da API e si possono considerare come MicroServizi perché incapsulano i loro dati, presentandosi al mondo esterno a tutti gli effetti come oggetti, nel senso in cui storicamente la Object-oriented Technology (anni ‘80) definisce un Oggetto ai fini della sua programmabilità dall’esterno: un Oggetto deve essere dotato di Proprietà e Metodi d’uso e capace di Ereditarietà, di Persistenza e Polimorfisno o non è un Oggetto programmabile con tecnologia object oriented. (figura 4).
6) Think Events
In un mondo “Event Handling (EH)” dove cioè la gestione degli eventi è fondamentale in quanto un evento passato determina le azioni future. L’App riporta l’evento (per esempio un ordine ricevuto dal canale e-commerce) a un Event Broker (in pratica un’API cosiddetta “mediatrice”, vedi principio 3) che, in modo automatico e programmabile, sceglierà l’opportuno gestore dell’evento (Event Handler) (figura 5); questo, a sua volta, può aggiungere ulteriori Event Handler che non hanno impatti diretti sull’applicazione di partenza. L’Event Handling è un meccanismo open ended, aperto a scalare, per esempio su parallel computing: “È la tecnologia più avanzata, ma è al livello della SOA di 10 anni fa, scarsi ancora gli skill e i tool” (figura 6).
7) Think Digital Business
8) Think Consumer Experience
vedi approccio Design Thinking (descritto più avanti);
9) Think Cloud
la raccomandazione è “build for scale” in caso di hybrid cloud;
10) Think Integration
11) Think Real Time
12) Think in Contest
Per questi ultimi 6 princìpi, Natis ritiene inutili ulteriori raccomandazioni essendo autoesplicativi.
La riorganizzazione aziendale alla base del nuovo processo di sviluppo dell’App
Ma c’è un “13° principio” evidenziato da Natis: “Le organizzazioni rigide non creeranno mai software agile”. Il principio afferma la necessità di organizzare o riorganizzare una struttura mettendola in grado di gestire il nuovo processo di App delivery.
David Norton, Research Director, Gartner, mette in fila i passi cruciali per conferire a un’organizzazione la capacità di Software Delivery di App con innovation e renovation continue (figura 7):
- Costruire gli skill.
- Organizzarli (o riorganizzali) in team misti in grado di “auto dimensionarsi per un approccio multidisciplinare (tipicamente front-end developer orientati al business con back-end developer).
- Assegnare pratiche e policy.
- Promuovere i nuovi principi core di Architettura App Business.
- Approccio bimodale.
Se l’obiettivo è offrire App in grado di “improvvisare” una Customer experience che colga gli elusivi Business Moment, producendo un Business Outcome desiderato, è determinante che il team auto-costituitosi si organizzi per il “Design thinking”, così vengono chiamate le sessioni di lavoro del Gruppo ibrido intorno a una data Cx: dalle fasi di Empathize e di Define in cui si ricercano per empatia gli interessi del cliente, derivandone un consenso sui bisogni “compelling”, il Gruppo passa a una fase di Ideate (generazione di idee a fronte dei bisogni) e Prototype (in cui le idee da sviluppare vengono testate a tavolino e il Business generabile valutato). Il Design thinking si conclude con il Test, che è già una fase di rifinitura con la misurazione di Business Outcome sul mercato (figura 8).
Il Prodotto Software così lanciato ha naturalmente un Product Manager che guida il progressivo processo di rifinitura dell’App attraverso tutto il suo ciclo di vita, dall’allocazione di budget alla conclusione di ogni iterazione con una fase di “learn e measurment” (figura 9).
Così il ciclo di vita di un’App di Business è non più Requirement, ma Business Outcome driven. Misurare il Business Outcome di un’App capace di una data Cx (quanti Business Moments ha intercettato, con quale risultato finanziario) è cruciale quanto i KPI nelle Applicazioni tradizionali a fronte dei Requirement.
