La richiesta di modelli di business flessibili da parte delle aziende è ai massimi storici, ri-comporre e ri-assemblare prodotti digitali ad un ritmo sempre più veloce diventa la massima priorità per gli stakeholder.
Le applicazioni più standardizzate non sono in grado di tenere il passo, per questo motivo è necessario un application layer che fornisca una personalizzazione attiva delle capacità aziendali per soddisfare le aspettative dei clienti ed è fondamentale per il raggiungimento di un modello di azienda rinominata da MuleSoft “composable”.
Funzioni aziendali, processi, organizzazioni, relazioni e tecnologia sono visti come un insieme di componenti riutilizzabili che possono essere configurati come richiesto.
Sfida #1: Trovare il Giusto Equilibrio per l’Ambito di Applicazione
La scomposizione in ambito software non è una novità. SOA, microservizi, persino l’era del Mainfraime hanno come approccio architetturale comune a quello della divisione “in blocchi”.
Nell’ultimo decennio, con il successo di API RESTful e microservizi, questo obiettivo è più vicino che mai. Tuttavia, relativamente alla corrente ondata di microservizi, è emerso un concetto che li critica in quanto “monoliti distribuiti” inefficaci.
Questo paradigma afferma che sono diventati troppo piccoli, le spese generali di gestione sono diventate impraticabili e alcuni servizi non sono abbastanza indipendenti.
Trovare il giusto equilibrio nella composizione di “applicazioni packaged” è fondamentale per la progettazione e lo sviluppo.
In un’azienda cosiddetta “composable”, un’applicazione deve essere ben definita dal punto di vista funzionale; deve essere riutilizzabile e sufficientemente autonoma, ma l’ambito di applicazione deve essere limitato all’interno di un’unica funzionalità di business.
Sfida #2: Team per l’Innovazione
Sviluppatori e altri ruoli in ambito IT all'interno di un'unità aziendale stanno diventando la norma. Ogni anno, sempre più aziende stanno adottando una struttura decentralizzata, creando un “team per l’innovazione” all’interno dei team presenti in azienda.
Tuttavia, con allineamenti interni ed esterni, crescono le sfide relative a barriere linguistiche e facilità di utilizzo.
Ruoli aziendali come il Product Manager non sono sufficientemente collaborativi con gli sviluppatori durante la creazione di funzionalità del prodotto e della user experience end-to-end. È ancora presente una “disconnessione” pratica in questa tipologia di team, e il livello di difficoltà nel collaborare è evidente dalla qualità delle applicazioni sviluppate dal team.
La questione linguistica è radicata culturalmente nella mentalità project-centric, creando team per l’innovazione attraverso la riorganizzazione, inserendo figure IT nelle linee di business a tempo pieno con la prospettiva di ottenere grandi risultati che però non sono realistici.
Programmi di cultural transformation che indirizzano verso una mentalità di delivery product-centric sono quelli che funzionano. La complessità dello stack di software è un fattore di produttività importante, l’adozione di strumenti da “citizen developer” è fondamentale.
Lo sviluppo low-code o no-code potrebbe alleviare il carico, altrimenti i team dovrebbero concentrarsi eccessivamente su dettagli relativi a tecniche low-level. Lo sviluppo con codifica manuale di molteplici attività come data mapping, affidabilità della connessione, ecc. non sono più praticabili.
Sfida #3: Il Potere di Gestire Tutto
Un’azienda “composable” sostiene un’architettura di sistema distribuita per ottenere un rapido sviluppo ed essere in grado di incrementare velocemente l’innovazione attraverso la decentralizzazione, che include la libertà di stack di applicazioni e software tra team.
La governance è un aspetto critico per un’azienda “composable” insieme a interoperabilità, orchestrazione, sicurezza e analytics. È essenziale disporre di una piattaforma con piena visibilità per gestire le interazioni di dati tra applicazioni, sia in tempo reale che offline.
È fondamentale cercare una piattaforma tecnologica che soddisfi le esigenze dell’azienda durante ogni fase del ciclo di vita dell’applicazione. Ciò significa che è raccomandabile identificare una piattaforma ricca di funzionalità e completamente nativa all’interno di tutte le fasi, dalla progettazione, allo sviluppo, ai test, al deploy.
Di seguito è riportato un esempio di moduli di una piattaforma aziendale “composable” con ciclo di vita completo.
La Luce in Fondo al Tunnel
> Integrazione è Fondamentale: molte organizzazioni si limitano a raccolte di dati di 1-2 sistemi di record application o considerano l'integrazione solo come seconda opzione. L’integrazione deve essere parte integrante dell’innovazione del prodotto dove l’aggregazione di dati tra sistemi non è una limitazione.
> Adattare Continuous Delivery Indipendente: la propria applicazione “packaged” autonoma dovrebbe avere comunque delle dipendenze minime. Dovrebbe essere duplicata e rilasciata senza avere effetti su altre applicazioni/prodotti.
> Promuovere i team per l’innovazione all’interno delle attività: attuare misure pratiche per gestire team IT. Assumere e investire nella formazione di utenti business innovativi verso strumenti con i quali possono contribuire.
Rimodellare la tecnologia all’interno dell’azienda non è la preoccupazione principale in un tale sforzo di trasformazione. Persone, cultura e policy sono ugualmente coinvolte per avere successo. La velocità del cambiamento dipende dal livello di maturità e dall'agilità dell'organizzazione.
Un'azienda realmente “composable”, tuttavia, è un'organizzazione preparata per eventuali interruzioni, in grado di fornire esperienze alla velocità della richiesta dei clienti e guidare attivamente l'innovazione mentre il mercato cambia a un ritmo senza precedenti.
Scopri di più su come trasformare la tua organizzazione per competere e avere successo nella digital economy. Invia una mail a cio@florence-consulting.it o chiama lo (055) 538-3250 per ricevere maggiori informazioni.
In alternativa, puoi compilare il form sottostante con la tua domanda.
