SAP Business Technology Platform (SAP BTP)

SAP décrit SAP BTP comme une offre unique qui réunit plusieurs portefeuilles technologiques. En pratique, une équipe SAP S/4HANA la rencontre à travers une poignée de services :

• Développement d'applications : des runtimes pour le code spécifique, SAP Business Application Studio, le SAP Cloud Application Programming Model (CAP) et l'environnement ABAP de SAP BTP.
• Automatisation et low-code : la famille SAP Build, dont SAP Build Process Automation et SAP Build Work Zone.
• Intégration : SAP Integration Suite, ainsi que les services de connectivité et de destination qui atteignent les systèmes on-premise via SAP Cloud Connector.
• Données et analytique : SAP HANA Cloud et les services analytiques construits sur cette base.
• IA : SAP AI Core et son generative AI hub, pour intégrer des modèles d'IA dans les applications.

Chaque service a ses propres droits, son administration et son cycle de vie. SAP BTP est donc un catalogue de services de plateforme qui partagent comptes, identité et facturation, et non une application unique.

Chaque paysage SAP BTP suit le même modèle de comptes :

1. Un compte global représente le contrat avec SAP et contient les droits que le client a achetés.
2. Des répertoires regroupent éventuellement les sous-comptes, par exemple par entité ou par projet.
3. Les sous-comptes sont l'endroit où le travail s'effectue. Chaque sous-compte se situe dans une région et reçoit une part des droits sous forme de quota.
4. Au sein d'un sous-compte, les administrateurs activent des environnements : Cloud Foundry pour les applications polyglottes, Kyma pour les charges de travail basées sur Kubernetes et l'environnement ABAP pour le développement ABAP Cloud.
5. Les services sont consommés soit comme instances au sein d'un environnement, soit comme abonnements à des applications SaaS telles que SAP Build Work Zone.

Le développement, le test et la production sont généralement des sous-comptes distincts, et les transports entre eux peuvent passer par SAP Cloud Transport Management. Le modèle de comptes SAP BTP est d'abord une décision de gouvernance, et ensuite seulement une configuration technique.

• Services adaptés à SAP : les destinations, SAP Cloud Connector et les services d'identité sont conçus pour atteindre SAP S/4HANA et d'autres systèmes SAP, y compris on-premise.
• Cycle de vie découplé : les extensions side-by-side s'exécutent avec leur propre runtime et leur propre cycle de release, de sorte qu'une mise à niveau de SAP S/4HANA n'impose pas de redéployer chaque extension.
• Soutien au clean core : SAP positionne SAP BTP comme l'emplacement standard des extensions qui ne doivent pas résider dans le cœur de l'ERP.
• Une plateforme, plusieurs profils de compétences : développeurs pro-code, spécialistes de l'intégration et créateurs low-code travaillent sur le même modèle de comptes et la même configuration d'identité.
• Services centraux partagés : un site de launchpad, une boîte de réception de tâches ou un flux d'intégration peut servir plusieurs systèmes SAP et non SAP à la fois.

Pour les extensions qui doivent rester en dehors du cycle de mise à niveau de SAP S/4HANA, SAP BTP est la plateforme vers laquelle orientent les recommandations d'extensibilité de SAP.

• Une plateforme, pas une solution. SAP BTP fournit des runtimes et des services. Quelle extension construire, et qui en est responsable après le go-live, se décide en dehors de la plateforme.
• La logique des documents reste dans le cœur. La détermination du prix, les comptabilisations, les approbations des documents SAP S/4HANA et leur statut restent dans SAP S/4HANA. Une extension sur SAP BTP appelle cette logique via des API ; elle ne la reprend pas.
• Chaque service est un produit à part entière. Chaque service apporte sa propre administration, ses rôles, sa supervision et ses limites. Un paysage comptant de nombreux services nécessite une exploitation de plateforme dont beaucoup d'équipes ERP n'avaient pas besoin auparavant.
• Le coût suit l'usage. Avec les contrats à la consommation, chaque instance et chaque utilisateur consomment des crédits ; la transparence des coûts exige donc une supervision active.
• L'intégration se conçoit, elle n'est pas fournie. Un dossier métier qui touche plusieurs services et systèmes n'est visible que dans la mesure où l'intégration et la supervision construites autour le permettent.

Ces limites sont le prix de la flexibilité : SAP BTP élargit ce qui peut être construit autour de SAP S/4HANA sans rendre ces constructions autogouvernées.

Un critère de décision pratique est le couplage entre l'extension et la transaction SAP S/4HANA :

Une erreur fréquente consiste à ouvrir des sous-comptes projet par projet sans conception du paysage, ce qui bloque ensuite le partage des destinations, de l'identité et des transports. SAP BTP porte ses fruits lorsque le modèle de comptes est planifié avant la première extension.

Le côté SAP BTP est identique pour toutes les options de déploiement. C'est la connexion à l'ERP qui diffère :

• On-premise et Private Edition : SAP Cloud Connector ouvre un tunnel contrôlé entre le réseau du client et le sous-compte, et les destinations pointent à travers lui vers le système SAP S/4HANA.
• Public Edition : SAP S/4HANA Cloud expose des API libérées via des communication arrangements, et les destinations sur SAP BTP les appellent via internet.
• Identité : SAP Cloud Identity Services est un moyen courant de reconnaître le même utilisateur dans SAP BTP et dans le back-end ; la configuration de confiance diffère selon l'option de déploiement.

Les services de plateforme ne changent pas avec l'option de déploiement de l'ERP ; seule la configuration de connectivité et de confiance entre SAP BTP et SAP S/4HANA change.