SAP Business Technology Platform (SAP BTP)

SAP describe SAP BTP como una oferta única que reúne varias carteras tecnológicas. En la práctica, un equipo de SAP S/4HANA entra en contacto con ella a través de unos pocos servicios:

• Desarrollo de aplicaciones: runtimes para código personalizado, SAP Business Application Studio, el SAP Cloud Application Programming Model (CAP) y el entorno ABAP de SAP BTP.
• Automatización y low-code: la familia SAP Build, que incluye SAP Build Process Automation y SAP Build Work Zone.
• Integración: SAP Integration Suite, además de los servicios de conectividad y de destinations que llegan a los sistemas on-premise a través de SAP Cloud Connector.
• Datos y analítica: SAP HANA Cloud y los servicios de analítica construidos sobre ella.
• IA: SAP AI Core y su generative AI hub, para incorporar modelos de IA en las aplicaciones.

Cada servicio tiene sus propios entitlements, su propia administración y su propio ciclo de vida. Por tanto, SAP BTP es un catálogo de servicios de plataforma que comparten cuentas, identidad y facturación, no una aplicación única.

Todo landscape de SAP BTP sigue el mismo modelo de cuentas:

1. Una cuenta global representa el contrato con SAP y contiene los entitlements que el cliente ha adquirido.
2. Los directorios agrupan opcionalmente las subcuentas, por ejemplo por unidad de negocio o por proyecto.
3. Las subcuentas son donde se trabaja. Cada subcuenta se ubica en una región y recibe una parte de los entitlements como cuota.
4. Dentro de una subcuenta, los administradores habilitan entornos: Cloud Foundry para aplicaciones políglotas, Kyma para cargas de trabajo basadas en Kubernetes y el entorno ABAP para el desarrollo con ABAP Cloud.
5. Los servicios se consumen como instancias dentro de un entorno o como suscripciones a aplicaciones SaaS como SAP Build Work Zone.

Desarrollo, pruebas y producción suelen ser subcuentas separadas, y los transportes entre ellas pueden realizarse mediante SAP Cloud Transport Management. El modelo de cuentas de SAP BTP es ante todo una decisión de gobierno y, en segundo lugar, una configuración técnica.

• Servicios que conocen SAP: las destinations, SAP Cloud Connector y los servicios de identidad están diseñados para llegar a SAP S/4HANA y a otros sistemas SAP, incluidos los on-premise.
• Ciclo de vida desacoplado: las extensiones side-by-side se ejecutan con su propio runtime y su propio ciclo de releases, de modo que una actualización de SAP S/4HANA no obliga a volver a desplegar todas las extensiones.
• Soporte a clean core: SAP posiciona SAP BTP como el lugar estándar para las extensiones que no deben residir en el núcleo del ERP.
• Una plataforma, varios perfiles: desarrolladores pro-code, especialistas en integración y creadores low-code trabajan sobre el mismo modelo de cuentas y la misma configuración de identidad.
• Servicios centrales compartidos: un site de launchpad, una bandeja de entrada de tareas o un flujo de integración pueden dar servicio a la vez a varios sistemas SAP y no SAP.

Para las extensiones que deben quedar fuera del ciclo de actualización de SAP S/4HANA, SAP BTP es la plataforma a la que apunta la propia guía de extensibilidad de SAP.

• Una plataforma, no una solución. SAP BTP proporciona runtimes y servicios. Qué extensión construir, y quién será su responsable tras la puesta en producción, se decide fuera de la plataforma.
• La lógica de los documentos permanece en el núcleo. Los precios, las contabilizaciones, las aprobaciones de documentos de SAP S/4HANA y su estado permanecen en SAP S/4HANA. Una extensión en SAP BTP llama a esa lógica mediante API; no se hace cargo de ella.
• Cada servicio es un producto en sí. Cada servicio trae su propia administración, sus roles, su supervisión y sus límites. Un landscape con muchos servicios necesita operaciones de plataforma que muchos equipos de ERP no necesitaban antes.
• El coste sigue al uso. En los contratos basados en consumo, cada instancia y cada usuario consumen créditos, por lo que la transparencia de costes exige una supervisión activa.
• La integración se diseña, no viene dada. Un caso de negocio que afecta a varios servicios y sistemas solo es tan visible como la integración y la supervisión que se construyen a su alrededor.

Estos límites son el precio de la flexibilidad: SAP BTP amplía lo que se puede construir en torno a SAP S/4HANA sin que esas construcciones se gobiernen solas.

Un criterio de decisión práctico es el acoplamiento entre la extensión y la transacción de SAP S/4HANA:

Un error habitual es abrir subcuentas proyecto por proyecto sin un diseño del landscape, lo que más adelante bloquea las destinations, la identidad y los transportes compartidos. SAP BTP rinde frutos cuando el modelo de cuentas se planifica antes de la primera extensión.

El lado de SAP BTP es el mismo en todas las opciones de implementación. Lo que difiere es la conexión con el ERP:

• On-premise y Private Edition: SAP Cloud Connector abre un túnel controlado desde la red del cliente hasta la subcuenta, y las destinations apuntan a través de él al sistema SAP S/4HANA.
• Public Edition: SAP S/4HANA Cloud expone API liberadas mediante communication arrangements, y las destinations de SAP BTP las llaman a través de internet.
• Identidad: SAP Cloud Identity Services es una forma habitual de reconocer al mismo usuario en SAP BTP y en el back-end; la configuración de confianza difiere según la opción de implementación.

Los servicios de la plataforma no cambian con la opción de implementación del ERP; solo cambia la configuración de conectividad y de confianza entre SAP BTP y SAP S/4HANA.