Architettura cloud di SAP: pubblico, privato e RISE with SAP

L’architettura cloud di SAP si articola su modelli distinti (cloud pubblico, cloud privato, RISE con SAP) pensati per esigenze aziendali diverse. SAP ECC on-premise terminerà il supporto nel 2027, spingendo le aziende a migrare verso SAP S/4HANA basato su cloud.

S/4HANA è progettato per l’innovazione continua su infrastrutture cloud, offrendo maggiore agilità e integrazione. Nei paragrafi seguenti descriviamo la composizione tecnica di ciascun modello (multi-tenant/public, single-tenant/private, RISE), gli strati architetturali coinvolti e le implicazioni in termini di deployment, scalabilità, sicurezza e integrazione.

Cloud Pubblico (SAP S/4HANA Cloud, edizione pubblica)

Nel cloud pubblico SAP (ad es. SAP S/4HANA Cloud, Public Edition) l’ERP è erogato come servizio multi-tenant su infrastrutture condivise dei grandi hyperscaler (AWS, Azure, Google Cloud, ecc.). Tecnicamente, il sistema si compone di uno strato infrastrutturale virtualizzato (server, storage, rete) fornito dal CSP, un database SAP HANA in-memory e i core engine applicativi ABAP/Java di S/4HANA.

L’integrazione applicativa avviene tramite SAP Business Technology Platform (BTP), che fornisce runtime Cloud Foundry, ambiente ABAP on BTP e servizi middleware (Integration Suite, API Management, Event Mesh, ecc.). La presentazione è basata su SAP Fiori/UI5. Essendo un SaaS, l’aggiornamento del software è gestito centralmente (rilasci periodici trimestrali/annuali), riducendo il burden operativo sul cliente.

Nel modello cloud pubblico la scalabilità è elevata: le risorse vengono allocate dinamicamente e l’autoscaling consente di adattarsi ai picchi di carico senza tempi di attesa. I tempi di implementazione sono rapidi grazie a servizi preconfigurati; il modello di costo è tipicamente pay-as-you-go o subscription, con basso investimento iniziale. La personalizzazione è limitata: si può configurare il sistema entro i parametri standard SAP, ma cambiamenti profondi del codice non sono ammessi. Dal punto di vista della sicurezza, si fa affidamento sulle protezioni del provider cloud (cifratura dei dati a riposo e in transito, IAM, audit continuo). In sintesi, il cloud pubblico offre tempi rapidi, elasticità e costi operativi flessibili, adatto alle aziende che privilegiano agilità e aggiornamenti automatici.

Cloud Privato (SAP S/4HANA Cloud Private Edition, SAP HANA Enterprise Cloud)

Nel cloud privato SAP (es. SAP S/4HANA Cloud, Private Edition o l’ex SAP HANA Enterprise Cloud) il sistema ERP viene ospitato su risorse dedicate, gestite o dal cliente o da SAP in un data center riservato. L’architettura rimane simile (server, HANA, ABAP/Java, Fiori), ma l’intero stack è isolato per il singolo cliente. Questo garantisce piena flessibilità hardware, di rete e di sicurezza: ad esempio si può scegliere il tipo di server, dimensione dei cluster HANA, policy di sicurezza specifiche e localizzazione geografica precisa.

In un cloud privato si possono applicare personalizzazioni più profonde (anche codice ABAP custom) rispetto al modello pubblico. Lo svantaggio è che la scalabilità dipende dalla capacità del setup dedicato: per aumentare CPU o memoria occorre spesso interventi manuali o l’aggiunta di nuovo hardware virtuale.
Anche i costi solitamente prevedono investimenti iniziali superiori (set-up dell’infrastruttura) e canoni fissi, sebbene gli OPEX possano risultare prevedibili nel tempo.

L’implementazione richiede in genere più tempo (configurazione dedicata dell’infrastruttura) rispetto al pubblico. Dal punto di vista della sicurezza, il cliente ha libertà di definire protocolli e controlli su misura (ad es. dettagli di cifratura o compliance locali), ma anche la responsabilità di gestirli. Questo modello è indicato quando servono elevate customizzazioni, conformità specifiche o integrazione nativa con sistemi legacy controllati dal cliente.

Riassumendo, confronto pubblico vs privato:

• Infrastruttura: nel cloud pubblico SAP utilizza infrastrutture cloud di terze parti condivise
  , mentre il cloud privato dispone di risorse dedicate gestite dal cliente o da SAP..

• Scalabilità: il cloud pubblico si adatta automaticamente grazie all’autoscaling; il privato richiede capacity planning e interventi manuali per scalare.

• Personalizzazione: il cloud pubblico ammette solo configurazioni standardizzate
  , il privato consente personalizzazioni estese (sia infrastrutturali sia applicative).

• Costi e deployment: il pubblico adotta costi pay-per-use e attivazioni rapide, il privato può richiedere capitali iniziali maggiori e tempi di setup più lunghi.

• Sicurezza e compliance: nel pubblico ci si affida ai meccanismi standard del provider cloud
  (certificazioni internazionali, cifratura gestita, patch), mentre nel privato si può implementare una governance più stringente per soddisfare requisiti verticali o regionali, a scapito di maggior onere gestionale
  .

RISE with SAP: architettura e offerta integrata

Il programma RISE with SAP non è una nuova piattaforma tecnica, ma un’offerta commerciale integrata di “Business Transformation as a Service”. In pratica, RISE mette insieme un ERP cloud modulare (solitamente S/4HANA Cloud Private Edition), la piattaforma SAP BTP con servizi gestiti, strumenti di migrazione e supporto continuo, il tutto in un unico contratto (“one offer, one contract"). Dal punto di vista architetturale, RISE sfrutta gli stessi strati visti sopra: il cliente mantiene la scelta del provider IaaS (Azure, AWS, GCP, o un data center SAP), utilizza SAP HANA in-memory e gli application server di S/4HANA come nei cloud dedicati, e si appoggia a SAP BTP per estendere ed integrare il sistema. In sostanza, RISE aggiunge un livello di servizi professionali (come tool di trasformazione dati, pacchetti Best Practices, consulenza) affiancati all’ERP cloud e alle funzionalità di business network (ad es. SAP Ariba, SAP Concur, SAP SuccessFactors).

Casi reali evidenziano i benefici di RISE. Il Gruppo farmaceutico Chiesi ha adottato S/4HANA Cloud Private Edition tramite RISE, completando la migrazione in 9 mesi con “zero issue” in fase di go-live.Nella sua architettura SAP sono stati integrati SAP BW, SuccessFactors, Concur e la SAP Business Technology Platform per estendere i processi ERP.

Allo stesso modo, il Cirque du Soleil ha abbracciato RISE con SAP per ottenere una piattaforma cloud ERP scalabile e pronta all’AI: grazie a S/4HANA Cloud e all’integrazione con soluzioni come Ariba e Concur via SAP BTP, l’azienda ha costruito “una piattaforma in cloud con la sicurezza, la flessibilità e la scalabilità necessarie” alla crescita futura.

In entrambi i casi si è sfruttata la componente infrastrutturale di un hyperscaler (cloud privato) insieme ai servizi gestiti di SAP, semplificando la governance (un unico interlocutore per SLA e supporto) e abilitando nuove funzionalità di intelligence aziendale tramite SAP BTP.

Strati architetturali e integrazione

Tecnicamente, le soluzioni SAP in cloud si suddividono in vari layer:

• Infrastructure (IaaS): server virtuali, storage e networking gestiti come servizio dal cloud provider. In cloud pubblico queste risorse sono shared e scalano automaticamente; in cloud privato sono dedicate ed isolate.

• Database: SAP HANA in-memory (oppure SAP HANA Cloud DBaaS) costituisce il motore dati. Supporta operazioni OLTP/OLAP integrate e consente repliche/disaster recovery geografiche.

• Applicativo: moduli ERP di S/4HANA (Finance, SCM, QM, ecc.) eseguiti su server applicativi ABAP e/o Java. In RISE questi servizi sono accessibili via sottoscrizione come Software-as-a-Service.

• Piattaforma (PaaS): SAP Business Technology Platform include runtime Cloud Foundry e ABAP per sviluppi custom, oltre a servizi integrati (Integration Suite, API Management, SAP Analytics Cloud, AI Core, ecc.). BTP agisce da hub per estensioni e integrazione: ad esempio, consente di collegare in tempo reale l’ERP con SAP SuccessFactors, Ariba, Concur o sistemi esterni.

• Presentazione: interfacce SAP Fiori/UI5 che girano su browser o dispositivi mobili, fruibili via web. Anche in cloud SAP fornisce SAP Fiori Launchpad come front-end unificato.

Questa architettura garantisce elevata interoperabilità. SAP Integration Suite (parte di BTP) offre un’infrastruttura iPaaS per creare flussi di integrazione tra sistemi on-premise e cloud. Ad esempio, nelle realizzazioni di Chiesi e Cirque BTP è stato utilizzato per orchestrare integrazioni con soluzioni SAP esterne (BW, Concur, Ariba, SuccessFactors).
Una comparazione tra cloud pubblico e privato evidenzia inoltre che l’integrazione con sistemi legacy è più agevole nel cloud privato (perché si controlla l’intera rete), mentre nel cloud pubblico sono necessari componenti aggiuntivi (SAP Cloud Connector, middleware) per collegare in sicurezza l’ERP SAP al mondo on-premise.

In ogni caso, SAP Cloud Connector e l’Integration Suite consentono di gestire gli scenari ibridi e multi-cloud in modo standard, mantenendo la coerenza dei dati e i requisiti di sicurezza.

Scalabilità

Il cloud abilita una scalabilità elastica del sistema SAP. Nel cloud pubblico la piattaforma sfrutta la capacità illimitata del provider: è possibile aumentare o ridurre risorse di calcolo, memoria e I/O via autoscaling in base al carico.
Ad esempio, in un picco di traffico ERP i server applicativi possono essere automaticamente replicati. Nel cloud privato, la scalabilità è limitata dalla capacità installata: un aumento di risorse implica la creazione di nuove VM o l’acquisto di ulteriori licenze HANA, operazioni che richiedono tempo. In architetture ibride è possibile spostare carichi non critici sul cloud pubblico, mantenendo in sede dati sensibili per questioni di compliance.

Nei modelli multi-cloud SAP (adottati da grandi enterprise), i workload SAP possono essere distribuiti su più provider; questo attenua il vendor lock-in e aumenta resilienza e performance complessive. In tutti i casi SAP supporta scenari di alta disponibilità (cluster Linux, HANA System Replication) sia nel cloud pubblico che nel privato (vedi reference architectures su AWS/Azure/GCP), garantendo la continuità di servizio in caso di guasti.

Sicurezza e conformità

SAP applica un rigoroso framework di sicurezza per i suoi servizi cloud. Il provider cloud implementa misure infrastrutturali (logging centralizzato, cifratura TLS e at-rest, intrusion detection, patch management), mentre SAP provvede all’hardening dei server applicativi, all’isolamento dei tenant e all’analisi continua delle vulnerabilità.
Ad esempio, i dati sensibili vengono cifrati end-to-end: solo l’organizzazione cliente può configurare gli accessi ai propri dati applicativi.

SAP mantiene inoltre un Security Operations Center attivo 24/7 e offre servizi di monitoraggio avanzato (Security Posture Management, bug bounty, penetration test) per proteggere le istanze cloud. Nel cloud pubblico SAP condivide la responsabilità della sicurezza con il cliente: il modello di “shared responsibility” prevede che SAP (e il CSP) gestiscano infrastruttura, piattaforma e cicli di patch, mentre il cliente controlla la configurazione dell’ERP, i permessi utente e la protezione dei propri dati.

Nel cloud privato, oltre a queste misure, l’azienda può implementare anche policy aggiuntive (ad es. firewall avanzati, network segmentati, compliance locali) che soddisfano vincoli normativi specifici. In generale, il livello di sicurezza ottenuto in cloud è spesso superiore a quello realizzabile internamente,ma richiede una chiara responsabilizzazione tra fornitore e cliente.

Gestione on-premise vs cloud

Rispetto a un’architettura on-premise tradizionale, il passaggio al cloud cambia radicalmente i compiti dell’IT. In un deployment on-premise l’azienda acquista hardware, gestisce i data center, la rete, i backup e tutto lo stack software (OS, DB, middleware, ERP) autonomamente. Gli aggiornamenti di SAP richiedono downtime pianificati e competenze tecniche interne. Nel cloud, invece, gran parte di questi compiti sono delegati al provider. Come osserva la letteratura di settore, con il cloud “l’azienda non dovrà più preoccuparsi della manutenzione dei propri sistemi IT”, pagando solo l’utilizzo effettivo.

In concreto, nel cloud pubblico i server e i sistemi SAP core sono gestiti come servizio: SAP (insieme al CSP) si occupa di provisioning, patch, backup e monitoraggio della parte infrastrutturale. All’IT interno rimane la configurazione applicativa (es. customizing di S/4HANA), la gestione degli utenti e il supporto agli utenti finali. Ciò riduce sensibilmente il TCO operativo e libera risorse per attività a valore aggiunto (analisi dati, sviluppo di estensioni, innovazione di processo).

Tuttavia, l’azienda rinuncia a un controllo totale su ogni singolo componente (ad es. il luogo fisico dei server) e dipende dalla connettività di rete per accedere ai servizi. Nel complesso, i modelli cloud (specialmente con RISE) consentono implementazioni più rapide e modelli di licensing basati su abbonamento, a fronte di un minor impegno iniziale di capitale e di un burden operativo molto più leggero rispetto alla gestione on-premise tradizionale.

In sintesi, l’architettura cloud di SAP si basa su strati infrastrutturali e applicativi ben definiti (infrastruttura IaaS, database HANA, applicazioni S/4HANA, piattaforma BTP, UI Fiori) che possono essere erogati in modalità pubblica o privata. Il cloud pubblico offre il massimo dell’elasticità e della standardizzazione, il cloud privato massima personalizzazione e controllo, mentre RISE with SAP integra questi elementi in un’offerta unica di trasformazione digitale.

In tutti i casi, vengono sfruttate funzionalità di scalabilità automatica e sicurezza avanzata tipiche del cloud, con forti investimenti da parte di SAP e degli hyperscaler. Aziende come Chiesi e Cirque du Soleil hanno dimostrato che, scegliendo il modello più adatto, è possibile migrare con successo il proprio ERP al cloud – raggiungendo agilità, innovazione continua e scalabilità globale, pur mantenendo solidi livelli di sicurezza e integrazione.

Fonti: documentazione SAP e case study ufficiali. Queste fonti illustrano architettura, responsabilità e risultati operativi dei diversi modelli cloud SAP.