Case Study: un anonimo Cloud Customer

L’azienda AAA di cui stiamo per parlare potrebbe essere rappresentata da qualunque abbia fatto investimenti ingenti nelle architetture Cloud, si sia affidata ad un provider di servizi e proceda sempre seguendo i consigli del fornitore considerandolo esperto per poi realizzare, a discapito delle proprie finanze e delle proprie esigenze di business, che numerose scelte tecniche erano sbagliate ed ora comportano costi inutili e problemi operativi.

Lo scenario applicativo ed economico

Il caso studio è reale ma preferiamo mantenere anonimi l’azienda ed i fornitori di servizi coinvolti, come anche altri dettagli tecnici, perchè ciò che è interessante non sono il chi ed il cosa ma il come ed il perchè.

L’azienda AAA ha affidato al fornitore FFF lo sviluppo del software di punta e di core business, un progetto complesso che ha all’interno tutti gli elementi di un’organizzazione matura come: Customer Relationship Management(CRM), Content Management System(CMS), anagrafiche integrate, soluzioni ad hoc aziendali, Knowledge Management System(KMS) e molto altro. Il software in questione è uno strumento importante che AAA sfrutta per il suo mercato.

L’architettura applicativa è in Cloud ed FFF, ad ogni nuova richiesta di estensione delle funzionalità, implementa nuovi servizi Cloud Based effettuando scelte senza documentarle tecnicamente. L’architettura, con il passare del tempo, diventa sempre più complessa, meno manutenibile, più costosa e meno adatta all’ambiente di mercato dinamico in cui AAA opera da tantissimi anni.

I costi iniziano a diventare insostenibili e spesso sembrano ingiustificati, quelli che a prima vista sono semplici bug si trasformano in settimane di lavoro ed in malfunzionamenti critici, non è possibile estendere l’applicazione senza che si verifichino problemi. Siamo allo stallo: l’applicazione funziona ma non può essere modificata per adattarsi ai nuovi scenari di business di AAA, i costi per l’evoluzione sono esosi e quelli per l’operatività hanno un continuo aumento nel tempo.

L’approccio di Glue Labs ed i risultati dell’analisi

AAA contatta Glue Labs per una consulenza architetturale grazie alle specifiche competenze in ambito sviluppo, Solution Architecture e Cloud Engineering. Dopo un’attenta analisi che ha ripercorso le fasi di sviluppo, ha effettuato il code review, ha visionato i documenti disponibili, Glue Labs ha individuato gli elementi critici che hanno portato alla situazione di stallo dello sviluppo ed al sostenimento di costi in perenne crescita:

1. L’assenza di documentazione tecnica: documentare è un aspetto fondamentale, lo abbiamo indicato in tantissimi articoli come “Documento dei Requisiti: perchè è importante e cosa scrivere” e “Il Documento di Progetto: a cosa serve e quali informazioni contiene” e non finiremo mai di dirlo e suggerirlo a tutti i nostri Clienti perchè la documentazione rende non solo professionale l’applicazione ma il Cliente libero di effettuare qualsiasi scelta nel futuro e di operare sempre su solide basi;
2. L’utilizzo di tecnologie Cloud per scopi per cui non erano adatte: i fornitori spesso tendono a promuovere e seguire le mode del momento e così facendo puntualmente effettuano scelte sbagliate sul lungo periodo. In Glue Labs amiamo il progresso e la tecnologia ma scegliamo le architetture Cloud avendo una visione almeno a 3 anni del prodotto in modo da renderlo compatibile con qualsiasi scenario futuro. Le tecnologie avanzate vanno usate per scopi specifici e vanno inserite in contesti di possibile cambiamento ed evoluzione. Sottovalutare questo aspetto si traduce, come in questo Caso Studio, in uno stallo applicativo ed in costi incontrollabili perchè è necessario sempre trovare un workaround( la “pezza”) per far funzionare tutto;
3. Il mancato utilizzo di Best Practices architetturali per lo sviluppo di applicazioni Cloud Native: seguire le Best Practices è sempre il modo migliore per evitare errori e fare le cose giuste, elementi di innovazione possono essere aggiunti ma occorre sempre partire da Best Practices consolidate per essere certi del successo del progetto.
4. Il lock-in su specifici prodotti di sviluppo e Cloud based: usare Software Development Kit(SDK) di uno specifico prodotto all’interno di tutto il codice sorgente si può tradurre in un disastro se quel determinato prodotto non è più adatto allo scopo. Il software va sviluppato per essere mantenuto nel tempo senza drammi e problemi, è così che ragioniamo in Glue Labs, software modulari, linguaggi di programmazione ben noti, framework con una lunga storia e supporto alle spalle, architettura di cui può essere fatto il deploy ovunque da on premise a qualsiasi fornitore Cloud.
5. Assenza di separazione logica delle componenti: far sì che tutte le componenti dipendano una dall’altra significa che ogni modifica ad una componente ha un impatto diretto su tantissime altre. E’ la cosa peggiore da fare in uno scenario dinamico come quello moderno. Attraverso la separazione logica delle componenti è possibile non solo stabilire layer di sicurezza ma anche ridurre drasticamente il rischio di problemi oltre che ottenere una maggiore flessibilità nell’evoluzione del software.

Contattaci subito e senza impegno per verificare la qualità della tua architettura Cloud e scoprire se stai pagando costi inutili.

Conclusioni

E’ chiara, alla fine dell’analisi, la necessità di una ristrutturazione dell’architettura applicativa ma la soluzione non può essere quella di iniziare da zero perchè comporta un investimento importante e tempi troppo lunghi per essere portata in produzione tout court.

Pertanto occorre, in casi simili, individuare gli elementi critici e tutte le relazioni tra i vari elementi in modo da scegliere un piano di migrazione che tenga nella giusta considerazione le necessità operative dell’applicazione.

Alla fine, attraverso dettagliate tappe tecniche, l’architettura e l’applicazione diventano sempre più moderni, flessibili e resilienti.

Contattaci subito e senza impegno per verificare e ristrutturare la tua architettura applicativa.