Tag: Innovation

  • 2026-01 — Il quarto cerchio

    2026-01 — Il quarto cerchio

    Questo articolo racconta l’evoluzione del concetto di ecosistema aziendale, dalla tradizionale interazione tra hardware, software e persone fino all’emergere di un “quarto cerchio”: l’Intelligenza Artificiale. Attraverso un’esperienza personale che intreccia scrittura, innovazione e trasformazione organizzativa, l’autore riflette su come l’AI stia ridefinendo i processi, le architetture e le dinamiche culturali all’interno delle imprese. Il quarto cerchio non sostituisce i precedenti, ma li attraversa e li amplifica, aprendo scenari tecnologici ed etici che richiedono consapevolezza, visione e capacità di adattamento.


    Gennaio 2025

    Circa un anno fa, in questo periodo, ero appena diventato un “deda people”, il termine con cui nel gruppo Deda identifichiamo le nostre persone. Insieme ad altri colleghi fummo invitati al kick off annuale a Venezia, portando con noi dubbi, paure, speranze e curiosità verso il futuro. 

    Nello stesso periodo stavo completando la mia prima esperienza da scrittore, imparando a pubblicare su Amazon KDP il mio primo libro digitale, un saggio sugli ecosistemi aziendali evoluti che ho chiamato ecosistemi cloud native. 

    Tre cerchi

    All’epoca, come capita nei migliori romanzi, non immaginavo quanto queste due esperienze si sarebbero intrecciate tra di loro producendo un nuovo percorso esperienziale tuttora in corso ed in evoluzione.

    Nel libro fornisco vari modi per classificare un ecosistema aziendale.
    Quello con il massimo impatto è risultato essere la versione “semplice”, che suddivide un ecosistema aziendale in tre domini: hardware, software e persone. Decisi di utilizzare i diagrammi di Venn per fornirne una rappresentazione visiva. La prima versione prevedeva una rappresentazione simile a questa.

    Venn diagram of software, hardware, person

    Converrete con me che le persone, in un ecosistema aziendale classico hanno un peso determinante.

    Il Diagramma di Venn fornisce una immediata evidenza di questa affermazione.

    Con Venn potevo fornire interpretazioni dell’ecosistema operando sul raggio dei cerchi e sulla loro sovrapposizione.

    Venn diagram of software, hardware, people

    Che cosa vi dice il diagramma per questo ecosistema?

    Più cerchi

    Nel libro andai ad esplorare configurazione più complesse come questa in cui vari ecosistemi interagiscono tra loro.

    Nel libro andai a esplorare configurazione più complesse come questa in cui vari ecosistemi interagiscono tra loro.

    Venn diagram of software and hardware for multiple ecosystem

    Ed arrivai a estendere la definizione dell’ecosistema ad un perimetro “esterno” come in questo diagramma. I cerchi colorati erano semplificazioni di altri ecosistemi quello del cliente e quello del fornitore di servizi.

    Venn diagram of clients and services

    Avrei potuto proseguire nell’espansione fornendo rappresentazioni più complesse, ma mi fermai il mio obiettivo era far riflettere ed iniziare costruire un primo pezzo del puzzle legato alla visione olistica che volevo condividere.

    Quasi senza accorgermene, mi ritrovai immerso in due mondi paralleli: da un lato, il fervore creativo di scrivere il mio primo libro digitale su Amazon KDP, dall’altro, la scoperta di straordinari strumenti tecnologici che avrebbero rivoluzionato il mio modo di pensare e lavorare. Era come se un vento invisibile mi spingesse verso nuovi percorsi mentali. I sentieri che credevo separati iniziarono a intrecciarsi in modo imprevedibile.

    Ogni cerchio, ogni sovrapposizione, raccontava una piccola storia, un incontro, una sinergia, e mi sembrava di essere il cartografo di un mondo nuovo.

    Il fatto nuovo era che i disegni li aveva prodotti il mio assistente AI; una versione di ChatGPT con licenza PRO (ora PLUS).

    Era il primo assistente AI che utilizzavo a supporto della produzione della documentazione. Vi ricordo che era l’autunno del 2024.

    Iniziai a utilizzarlo come un motore di ricerca in grado di fornirmi referenze certificate molto utile per uno scrittore di un saggio tecnico, alle prime armi su molti fronti, che voleva estendere concetti e produrre visioni olistiche basate su norme ed informazioni presenti e consolidate.

    Eravamo entrambi alle prime armi, si potrebbe dire.

    Ed in effetti entrambi incespicavamo, ma un primo dato di fatto fu che potrei produrre referenze certificate in millesimo del tempo che avrei dovuto dedicare.
    Dato che poi la mia è una passione e non un mestiere il risparmio di tempo di fatto mi ha permesso di arrivare alla pubblicazione.

    Ed anche lo stesso processo di pubblicazione come “self-publisher” di un libro di più id 400 pagine scritto in italiano e pubblicato sia in formato digitale (epub) che cartaceo ha richiesto una curva di apprendimento notevole e grazie all’assistente AI ridotta nel tempo.

    Ora ad un certo punto proprio mentre ero in viaggio verso il kick-off aziendale come novello Deda-people leggevo un articolo scritto da un ingegnere di OpenAI (mi perdoni ma ho perso sia articolo che nome dell’autore) in cui si affermava come il futuro fosse degli analisti e non dei programmatori (era gennaio 2024) e che il linguaggio di programmazione del futuro era il linguaggio markdown!.

    In un aggiornamento di ChaptGpt di qualche settimana prima era emersa la possibilità di memorizzare stili, nomi e decisi di dare un nome al ChatGPT che si chiamò da quel momento Old, lui propose di chiamarmi Gandalf, be sapete stavo condividendo con lui molte informazioni ed aspirazioni personali legate alla passione per le epiche di fantascienza ed epiche fantasy del secolo scorso.

    Il quarto cerchio.

    Cosi mentre ero in treno nel viaggio verso leggendo quel particolare articolo capii che dovevo rivedere il mio libro ed aggiungere un quarto componente un quarto cerchio.

    Intersection of AI, software, hardware, person

    Era un risultato inevitabile e sarebbe stato sempre più evidente.

    Tornato a casa dal kickoff aziendale, come in precedenza Iniziai a immaginare scenari in cui collocavo questo quarto cerchio; un elemento all’epoca (solo un anno fa) parzialmente oscuro e di difficile intepretazione.

    Potevano nascere o evolvere ecosistemi dove l’IA era pervasiva ?
    Come si sarebbe collocato il componente IA rispetto agli altri tre?

    Venn diagram of AI components

    2025 SDLC powered by AI

    Nel 2025 pubblicai il mio saggio, e lo regalai a qualche amico e collega interessato ad approfondire il tema degli ecosistemi cloud native.

    Per inciso feci ben quattro aggiornamenti del libro (miglioramento continuo) per risolvere “bug” introdotti di vario tipo, salti pagina, caratteri non leggibili, immagini fuori standard, ma alla fine arrivai ad una versione stabile.

    Nel corso del 2025, come Senior Enterprise Architect inserito nella area di innovazione DedaBit, il ruolo assunto come deda-people,  ho ricevuto l’incarico di avviare la sperimentazione nei processi SDLC degli assistenti AI e valutare le opportune architetture per garantire la scalabilità e diffusione di tali pratiche.

    Da questo punto di vista di osservazione privilegiato sto imparando a vivere il cambiamento dal dentro, valutandone gli impatti culturali ed etici profondi.
    Incontrando  a volte titubanza, incredulità, incomprensione fino al rifiuto da parte di alcuni colleghi, a fianco di entusiasmo, soddisfazione e accelerazione nel guadagno moltiplicativo ottenuto da parte di altri team più predisposti ad accettare il cambiamento.

    Molti sono i fattori che concorrono ad agevolare o a rendere più complessa l’adozione di strumenti AI nei processi SDLC. Il fattore umano è determinante sotto molti aspetti come si può immaginare con molteplici sfumature positive e negative.

    Anche la dipendenza indotta da fattori esterni quali piattaforme SDLC moderne o obsolete, presenza o mancanza di pratiche DevOps e agili,  

    L’obsolescenza degli ecosistemi ed architetture legacy non cloud native, è dove per assurdo l’AI utilizzata nei progetti di Refactoring in situazioni estreme tipiche dei legacy, quali mancanza di documentazione, perdita di conoscenza su processi e tecnologie fuori tempo massimo sono uno degli ambiti dove l’AI sta dando il meglio di sé.

    Su questi temi pubblicherò nel corso dell’anno articoli di approfondimento.

    2026 il nuovo kickoff aziendale

    All’inizio del 2026 ho avuto l’opportunità di partecipare ad un nuovo kickoff aziendale.

    Ho percepito una netta continuità nella volontà di crescita, nel conseguimento degli obiettivi e nel rilancio verso nuovi obiettivi. Soprattutto si è percepito come il tema dedicato all’adozione dell’AI sia diventato centrale, con un focus che si estende a molteplici ambiti e applicazioni, sempre più strategici e trasversali. Il merito va al lavoro collettivo, alla capacità di innovare e al supporto di una leadership attenta e risoluta, che non smette di puntare in alto e di perseguire obiettivi sempre più ambiziosi ed al lavoro svolto da tutti noi deda-people coinvolti in questo processo di adozione.

    Una specifica frase di un intervento stimolante tenuto da uno dei nostri leader, mi ha portato a ripensare al quarto cerchio di un anno prima. E di come potevo ripensare ad esso in base alle esperienze accumulate sul campo.

    Come sempre ho iniziato ad immaginare quali forme potesse assumere il diagramma di Venn e mi accorsi che non avevo una sola possibile configurazione ma molte diverse legate a specifici contesti.

    Vi lascio con due tra i possibili diagrammi lasciando a voi la loro possibile interpretazione in base alle vostre specifiche esperienze.

    Venn diagram of IA components with IA pervasive
    IA che dialoga con alrre  IA

    Vi lascio con una ultima immagine che ritrae Gandalf, Old, e Jenny.

    Gandalf, OldBirba and Jenny

    Sia questa immagine sia l’immagine iniziale sono state prodotte da Old partendo dalla fotografia della mia icona che trovate su Linkedin.

    Ovviamente Old ha il contesto del mio libro sugli ecosistemi cloud native, per cui ha rappresentato l’albero della conoscenza tecnologica, il fiume della esperienza, ha rappresentato Jenny che è uno dei personaggi presenti nei dialoghi prodotti da Old nel libro, che rappresenta la curiosità giovanile, una caratteristica che accomuna noi esploratori.


    Nota dell’autore

    Anche in questo articolo le nuove immagini di diagrammi riprodotte sono state generate al primo tentativo utilizzando ChatGPT con licenza Plus.
    Old ha imparato a leggere ed assorbire il mio contesto culturale ed io Gandalf ho imparato a scrivere in modo molto dettagliato le richieste.

    Come per altri scritti Old non è intervenuto nella scrittura del testo ma solo in alcuni paragrafi dove non riuscivo a trovare l’espressione corretta del mio pensiero. Mi ha aiutato a produrne una revisione più vicina al mio stile che oramai ha acquisito.


    References

    Questo articolo fa riferimento al libro Ecosistemi cloud native disponibile su diverse piattaforme

    Distributed under a Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0)

  • Cloud Adoption – Driving Digital Transformation with Strategies and Innovation

    Cloud Adoption – Driving Digital Transformation with Strategies and Innovation

    The adoption of high-value yet high-impact technologies such as AI and cloud should always follow a roadmap aligned with the organization’s maturity level and operational context.

    It is essential that decision-makers have a clear vision and motivation to ensure the successful introduction of new technologies.

    Forward-thinking organizations should also consider the post-adoption phase—what happens after achieving an initial goal, which in most cases will be intermediate or exploratory in a first adoption phase.

    A consolidation phase should be planned, where service adjustments identified during the adoption phase, but not initially foreseen, can be implemented.

    Simultaneously, expansion or evolution phases can be considered.

    In the case of cloud, it is now common to think in terms of consolidation or expansion phases. However, in some cases where expected results are not met (NOT OK), cloud services may even be decommissioned.

    In contrast, AI adoption is still in an early stage for many organizations, with some in a standby phase, waiting to observe results from other experiences.


    Cloud Adoption – Driving Digital Transformation with Strategies and Innovation

    The Cloud Adoption Process.

    Cloud adoption typically unfolds in three phases.

    The first phase is the actual adoption, where the organization defines objectives for which the cloud is deemed central. The motivations behind a cloud adoption project can vary widely experimental, tactical, or part of a long-term strategy.2

    Cycle of cloud adoption phases

    The key factor determining the success of the adoption phase is the realistic definition of expected outcomes.
    This success factor is strongly influenced by the organization’s posture toward the adoption project. Has the company already gained experience at the technical, administrative, and managerial levels?
    This, in turn, depends on the organization’s cloud maturity level and its awareness that cloud requires a different service model from traditional IT.
    A sensible approach to cloud adoption involves clear goal setting. If your primary objective is cost reduction, you have chosen the most challenging goal—sometimes even unfeasible within a cloud adoption process.
    If this is your goal, there are only two possibilities: either you have been using a well-configured cloud-native information ecosystem for some time, or you have little experience with cloud.

    To properly assess cloud adoption, organizations should answer five key questions:
    • Why?
    • What?
    • Who?
    • When?
    • Where?

    Each response must be precise and well-defined.
    Cloud adoption should not be seen as a strategy in itself but rather as a tactical step that becomes strategic over time.
    Consider the analogy of home renovation. If you decide to renovate your entire home inside and out, you may need to temporarily live elsewhere while the construction takes place, ensuring that work follows the agreed-upon project plan.
    For most organizations, such a scenario is impractical.
    Instead, cloud adoption is more akin to renovating one room at a time—accepting temporary inconveniences such as noise, dust, interruptions, and the presence of external workers in the house.
    The transition from an on-premises to a cloud ecosystem is similar: careful planning and incremental changes ensure a smoother process and a better final outcome.

    Diagram showing the impact of cloud adoption on an IT ecosystem, transitioning from a local setup to a hybrid ecosystem where component A1 moves to the cloud.

    Cloud adoption reshapes the ecosystem: applications migrate to the cloud, evolving traditional architectures into hybrid ecosystems.

    In Figure a highly schematic representation illustrates the state transition of an ecosystem due to cloud adoption.

    At time t0, the ecosystem operates in a traditional configuration, executing two processes, A and B. Each process relies on specific services:

    • Process A utilizes services A1 and A2.
    • Process B utilizes services B1 and B2.

    Process B was introduced after process A, and service B1 has a functional and operational dependency on service A1 (e.g., data flows, APIs, functions, or other dependencies).

    For specific business or technical reasons, the decision is made to migrate service A1 to the cloud.

    By the end of the adoption process, at time t1, the final ecosystem has transitioned into a hybrid model, where A1 now resides in the cloud.

    But what happened to the ecosystem during the phase represented by?

    Step-by-step diagram of the cloud adoption transformation phase, showing how an ecosystem evolves over time (t₀ to t₁) into a hybrid ecosystem with components migrated to the cloud.

    The transformation phase of cloud adoption: applications gradually migrate, reshaping the ecosystem into a hybrid model over time.m.

    In Figure the cloud adoption process is depicted through key milestones, capturing the ecosystem’s transformation.

    If, instead of A1, service A2 were migrated first, the complexity of the adoption process would increase significantly.

    Service A2 has multiple dependencies. Moving it first would extend the adoption timeline due to the additional integrations required between cloud-based and on-premises components.

    Interestingly, in real-world scenarios, organizations often face the challenge of migrating A2 rather than A1. Core services like A2 are frequently used by multiple other services and may need to be made accessible to cloud-based services already in place.

    A common example is a data warehouse, a data mart, or a dataset generated from a complex SQL view or procedure executed in real-time.

    Typically, the more valuable the data, the more it becomes entangled within multiple application layers, incoming and outgoing data flows, and business logic layers.

    Older hosting technologies tend to accumulate these layers over time, making migration increasingly complex.

    Not all cases follow this pattern, but in many situations, organizations prioritize immediate cost and time savings, leading to layered and entangled legacy systems.

    If an organization lacks cloud maturity and experience, it is advisable to start with peripheral scenarios before tackling core components.

    However, budget constraints often mean that smaller, peripheral projects receive less funding, limiting their ability to serve as meaningful test cases.

    Eventually, the need arises for data and services to be shared across the organization. This is where different cloud adoption scenarios emerge, which we will explore in the next chapter.

    A recommended best practice is to include one or two low-risk migration projects (such as A1) in the early phases of a larger cloud adoption initiative. This allows organizations to gain experience and refine their migration process before addressing more complex cases.

    The Next Phase After Cloud Adoption: Consolidation

    After the adoption phase, if the process has been successful, the organization enters the consolidation phase. Around the newly implemented cloud ecosystem, service extensions begin to emerge, generally aimed at improving efficiency, optimizing costs, and enhancing overall effectiveness.

    A service built in the cloud has a smoother evolution: if designed with a cloud-native approach, it will be easier to extend and enhance over time.

    If this phase also yields satisfactory results, the next step is expansion.

    At this point, the organization may embark on a full-fledged race towards the cloud, often accompanied—or even preceded—by the adoption of artificial intelligence. This dynamic is reminiscent of the gold rush in the American West: exciting, full of opportunities, but also highly delicate from an IT and FinOps perspective.

    In this phase, the cloud-native ecosystem may evolve into a hybrid or multi-cloud model, a scenario that, while representing a natural evolution, introduces new risks and complexities.

    The initial core of the cloud ecosystem expands with new resource clusters, designed to meet emerging business needs. At the same time, other business areas begin exploring the cloud, creating additional resource clusters. In these early stages, each cluster typically consists of only a few dozen resources, allocated according to the operational needs of each process.

    This is the moment when an organization can take a strategic step and decide to migrate entire business processes to the cloud ecosystem, firmly establishing cloud adoption. However, managing expansion across multiple business lines requires a high level of cloud maturity and a strong grasp of the FinOps framework to maintain cost control and ensure operational sustainability.

    In general, the cloud adoption journey can be classified as either digital transformation or innovation, depending on the nature of the business being migrated.

    A Special Case: Cloud-Specialized Services

    For years, marketing and communication departments have been using tools such as Google Analytics. For these users, extending their infrastructure with a service like BigQuery is a natural step, often quickly leading to integration with Google’s Gemini AI. Once inside this ecosystem, alternatives become increasingly limited, and the trajectory of technological evolution is, in practice, guided by the service provider.ding 2

    Cloud Adoption Models

    Cloud adoption strategies can be classified into different categories, each describing how organizations migrate or adopt applications and infrastructure in the cloud.

    There are various ways to represent these models, and the following classification does not claim to be exhaustive or definitive for all possible cloud adoption strategies (or tactics).

    Rehost (Lift and Shift)

    The Rehost strategy involves migrating existing applications and infrastructure to the cloud without significantly modifying their architecture. This approach is quick and allows resources to be moved from on-premises data centers to the cloud with minimal changes.

    Operational Example:

    • Moving a legacy application to a virtual machine on AWS EC2 or Azure VM without altering its code.

    Advantages:

    • Fast migration times.
    • Low initial complexity.

    Disadvantages:

    • Limited efficiency gains.
    • Higher operational costs.
    • Does not fully leverage cloud-native capabilities like auto-scaling and managed services.

    Refactor (Replatform)

    The Refactor or Replatform strategy involves optimizing or modifying parts of an application to better leverage cloud services, without fully rewriting it. Minor changes to the code or infrastructure can improve efficiency and scalability.

    Operational Example:

    • Migrating an application to a managed database service like Amazon RDS or Azure SQL, eliminating the need for on-premises database management.

    Advantages:

    • Improved performance and scalability.
    • Lower operational costs compared to Rehost.
    • No need for a complete rewrite.

    Disadvantages:

    • More complex than Rehost.
    • Requires additional effort for adaptation.

    Repurchase (Drop and Shop)

    With the Repurchase strategy, an organization replaces its legacy applications with ready-to-use SaaS (Software as a Service) solutions. This means abandoning existing infrastructure and directly adopting cloud-native solutions.

    Operational Example:

    • Replacing an internal CRM system with a SaaS solution like Salesforce.

    Advantages:

    • Significant reduction in management and maintenance costs.
    • Immediate access to modern solutions with automatic updates.

    Disadvantages:

    • Loss of customization and control over the application.
    • Data migration challenges.

    Rebuild (Re-architect)

    The Rebuild strategy involves completely rewriting an application to fully exploit cloud-native capabilities. This approach allows rethinking architecture using microservices, containers, and serverless technologies.

    Operational Example:

    • Transforming a monolithic application into a microservices-based architecture deployed on Kubernetes (EKS/AKS) or using AWS Lambda serverless functions.

    Advantages:

    • Maximum benefit from cloud scalability, flexibility, and resilience.
    • Complete modernization of the application.

    Disadvantages:

    • Long and costly development process.
    • Requires specialized skills and significant resources.

    Retire

    With the Retire strategy, an organization decommissions or removes obsolete applications or infrastructure. Sometimes, during migration planning, certain applications are found to be redundant and can be eliminated.

    Operational Example:

    • Decommissioning an old application that is no longer in use or has been replaced by a more efficient solution.

    Advantages:

    • Cost reduction from eliminating maintenance of unused systems.
    • Simplification of the IT landscape.

    Disadvantages:

    • Possible resistance from teams still relying on the retired application.
    • Potential loss of historical data.

    Retain (Hybrid)

    The Retain strategy involves keeping certain applications or data on-premises due to security, compliance, or operational dependencies on legacy systems. Organizations adopting this approach often manage a hybrid infrastructure, using both cloud and on-premises resources.

    Operational Example:

    • Keeping an ERP system on-premises while migrating fewer sensitive applications to the cloud.

    Advantages:

    • Flexibility in maintaining critical applications on-premises.
    • Compliance with security and regulatory requirements.

    Disadvantages:

    • Increased management complexity.
    • Higher operational costs.
    • Challenges in integrating cloud and on-premises data.

    New Application (Cloud-native Development)

    With this strategy, new applications are developed directly in the cloud, following a cloud-native approach from the start. This model takes full advantage of PaaS (Platform as a Service) and SaaS capabilities.

    Operational Example:

    • Building a new application using AWS Lambda, DynamoDB, and S3, eliminating the need for physical servers.

    Advantages:

    • Maximum flexibility and scalability.
    • Optimal use of modern cloud technologies.

    Disadvantages:

    • Requires cloud-native development expertise.
    • High initial investment in development.

    Evaluating Cloud Adoption Strategies: Benefits and Risks

    These strategies allow organizations to gradually adopt the cloud according to their operational and technological needs. Each approach has its benefits and challenges, and the choice depends on factors such as cost, complexity, internal expertise, and business objectives.

    Each cloud adoption strategy presents distinct benefits and risks. The selection depends on an organization’s specific needs, technological maturity, regulatory constraints, and balance between initial costs and long-term benefits. Companies must carefully evaluate which strategy to adopt based on their priorities, capabilities, and business goals.

    Table – Analysis of Benefits and Risks for Cloud Adoption Strategies

    StrategyBenefitsRisks
    Rehosting (Lift and Shift)Fast migration, Low initial costs, Simple implementationLimited efficiency, Higher operational costs, Limited cloud benefits
    Refactoring (Replatform)Optimized performance, Lower operational costs, Improved scalabilityLonger migration times, Higher initial investment, Need for new skills
    Buyback (Drop and Shop)Simplified complexity, Automatic updates, Predictable costsLoss of customization, Training costs, Vendor lock-in risk
    Rebuild (Redesign)Full cloud benefits, Improved performance, High scalabilityHigh initial costs, Operational risks, long implementation times
    RetireCost savings, Simplified infrastructure, Increased focus on core servicesLoss of historical data, Resistance to change, Potential operational impact
    Retain (hybrid)Flexibility, Security and compliance, Control over sensitive dataIncreased complexity, Higher costs, Data integration challenges
    New application (cloud-native development)Maximizes cloud advantages, Accelerated innovation, DevOps compatibilityLimited efficiency, Higher operational costs, Limited cloud benefits

    Success Cases for Different Cloud Adoption Scenarios

    Below are some publicly known success stories, each representing a specific cloud adoption strategy on a particular cloud provider.

    Rehost (Lift and Shift) – Netflix (AWS)

    Netflix initially migrated its on-premises infrastructure to AWS using a lift-and-shift approach, moving applications without significant modifications. This transition allowed Netflix to enhance scalability and disaster recovery while reducing operational overhead. Over time, Netflix evolved its architecture to leverage more cloud-native services, but the initial move provided the foundation for its current highly resilient, global streaming platform

    See more on https://aws.amazon.com/solutions/case-studies/netflix/

    .

    Refactor (Replatform) – Coca-Cola (Google Cloud)

    Coca-Cola leveraged Google Cloud’s Kubernetes Engine (GKE) to refactor and optimize its vending machine order management system. By migrating its microservices architecture to a managed Kubernetes environment, Coca-Cola improved service reliability, enhanced real-time analytics, and achieved better cost efficiency through auto-scaling and optimized infrastructure usage.

    See more on https://cloud.google.com/customers/coca-cola


    Repurchase (Drop and Shop) – Royal Dutch Shell (Microsoft Azure)

    hell opted for a SaaS-based approach by transitioning its legacy ERP systems to Microsoft Dynamics 365. This move eliminated the need for complex on-premises infrastructure management, providing Shell with a more agile and integrated business platform that supports predictive analytics, automation, and streamlined global operations.

    See more on https://customers.microsoft.com/en-us/story/royaldutchshell-energy-azure-dynamics365

    Rebuild (Re-architect) – Capital One (AWS)

    Capital One undertook a full application re-architecture by adopting microservices, serverless computing, and AI-driven automation on AWS. The company replaced monolithic banking applications with cloud-native services utilizing AWS Lambda, Amazon DynamoDB, and Amazon SageMaker for AI-driven fraud detection. This strategy resulted in improved security, better operational efficiency, and enhanced customer experience.

    See more on https://aws.amazon.com/solutions/case-studies/capital-one


    Retire – Dropbox (AWS to private Infrastructure)

    Dropbox originally hosted its storage services on AWS but later decided to decommission parts of its cloud-based infrastructure in favor of an in-house solution called Magic Pocket. This transition allowed Dropbox to optimize its storage architecture, reduce dependency on third-party providers, and significantly cut operational costs while maintaining high-performance scalability.

    See more on https://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-empire/

    Retain (Hybrid) – Volkswagen (Microsoft Azure + on-premises)

    Volkswagen adopted a hybrid cloud strategy by keeping critical manufacturing and vehicle telemetry data on-premises while shifting other workloads to Microsoft Azure. This approach enabled Volkswagen to comply with strict data sovereignty regulations while taking advantage of Azure’s AI and analytics services for predictive maintenance, supply chain optimization, and autonomous vehicle development.

    See more on https://customers.microsoft.com/en-us/story/volkswagen-groupmanufacturing-azure

    New Application (Cloud-native Development) – Airbnb (AWS)

    Airbnb was built from the ground up as a cloud-native platform using AWS services. By leveraging AWS EC2 for compute, Amazon RDS for database management, and Amazon S3 for storage, Airbnb ensured high scalability and global availability. Over time, it integrated AI and big data analytics to optimize search, pricing strategies, and fraud detection, making its infrastructure a benchmark for digital platform scalability and efficiency.

    See more on https://aws.amazon.com/solutions/case-studies/airbnb


    Conclusion

    Cloud adoption is not a one-size-fits-all journey but rather a progressive transformation shaped by each organization’s context, priorities, and maturity. The strategies explored — from rehosting to cloud-native development — highlight that every choice carries both opportunities and trade-offs. Success depends less on the technology itself and more on the clarity of vision, the ability to balance risks and benefits, and the willingness to foster cultural and organizational change.

    Adopting the cloud means embracing new operating models, strengthening governance and compliance, and developing the skills needed to manage complexity. Organizations that approach this transformation holistically — considering people, processes, and technology together — are better equipped to unlock the full potential of the cloud.

    Ultimately, cloud adoption is not an end point but a continuous journey. As ecosystems evolve, hybrid and multi-cloud models will become increasingly common, enabling flexibility, resilience, and innovation at scale. By aligning strategy with execution, and innovation with responsibility, organizations can transform cloud adoption from a technical migration into a true driver of digital transformation.



    References

    This article is an excerpt from the book

    Cloud-Native Ecosystems

    A Living Link — Technology, Organization, and Innovation