Plataforma tecnológica empresarial

Además, la Plataforma Tecnológica Empresarial, BTP, ofrece nuevas posibilidades que no existen en el sistema local. Sin embargo, las empresas deben planificar estratégicamente si desean utilizar la plataforma y cómo. Los objetivos que las empresas quieren alcanzar con una migración de los sistemas ERP a S/4 son múltiples: procesos racionalizados, la posibilidad de una mayor innovación y una mayor capacidad de respuesta al cambio, mejores opciones de optimización, así como nuevos y más amplios escenarios de integración con clientes y proveedores, y muchos más. A menudo, la conversión a S/4 también tiene por objeto acercar de nuevo el propio entorno SAP al estándar SAP, de modo que las futuras actualizaciones y cambios de versión puedan completarse con mayor facilidad y rapidez. 

Algunas empresas tienen la opción de reducir sus propios desarrollos y quizás incluso las modificaciones del sistema. De hecho, parece ser una buena oportunidad para desprenderse de desarrollos y modificaciones individuales antiguos, posiblemente obsoletos y que ya no son necesarios durante un salto de software tan importante. Esto es especialmente cierto para las implementaciones greenfield, donde el nuevo sistema S/4 Hana se inicia metafóricamente en un sitio greenfield, es decir, no sólo una actualización técnica (conversión brownfield) del sistema ERP anterior a S/4.

Otras empresas, sin embargo, necesitan muchos desarrollos y modificaciones internos, incluso después del cambio a S/4. Trasladarlos al nuevo sistema es una idea obvia. Pero eso dejaría todo como está y el estándar SAP muy lejos. Para ellas, BTP puede ser una solución.

Con la BTP, que hasta otoño de 2020 se conocía como SCP, SAP Cloud Platform, SAP ofrece una plataforma en la nube que proporciona numerosos bloques de construcción y servicios para proyectos de desarrollo, ampliación e integración, además de muchas otras funciones. Esto abre nuevas vías para seguir el enfoque "Keep the Core clean", es decir, mantener los sistemas SAP propios lo más cerca posible del estándar. Esto se debe a que los desarrollos que, por falta de alternativas dentro del sistema SAP
sistemas locales, los clientes existentes pueden en cambio implantarlos y ejecutarlos en el BTP.

Además de un rápido desarrollo mediante numerosos servicios y mejores prácticas, esto permite un acoplamiento flexible entre las extensiones propias y el estándar de SAP. Esto contribuye al objetivo ya mencionado de poder llevar a cabo futuras actualizaciones y cambios de versión con mayor facilidad y rapidez. Pero, ¿cuándo tiene sentido utilizar BTP y cómo deben proceder las empresas con su implantación?

Poder implantar extensiones en el BTP, utilizar servicios empresariales ofrecidos a través del BTP o integrar socios o sistemas a través del BTP abre un amplio abanico de posibilidades: Sin embargo, si la atención se centra en los desarrollos en la BTP, es necesario tener en cuenta consideraciones fundamentales a pesar de todas las ventajas. Al fin y al cabo, no todas las empresas confiarán completamente en S/4 Hana Cloud (Public) y, por tanto, desarrollarán exclusivamente a través de la BTP. Además, en el futuro también habrá sistemas S/4 como on-prem. Para tomar una decisión cualificada, los siguientes criterios son relevantes: Costes, infraestructura e integración.

Costes de entrada en BTP

Los costes se dividen en tres áreas: Costes de desarrollo, costes de funcionamiento y cuota de nube. Especialmente en los primeros intentos, el desarrollo en la BTP tenderá inicialmente a causar más esfuerzo, ya que los desarrolladores se están moviendo sobre todo en un territorio nuevo. Aquí es crucial crear una curva de aprendizaje pronunciada mediante medidas de formación adecuadas y una composición hábil del equipo. Los futuros desarrollos se benefician de ello y todos los desarrolladores aprecian los aceleradores conocidos de SAP. 

Los costes de funcionamiento interno de una aplicación BTP pueden considerarse menores porque la plataforma se ofrece íntegramente como un servicio. A cambio, sin embargo, se incurre en tasas por el uso de los servicios. Una herramienta de estimación puede predecirlos muy bien. Luego sigue siendo cuestión de encontrar una combinación inteligente de suscripción, pago por uso y CPEA (Cloud Platform Enterprise Agreement) para optimizar los costes.

Por otro lado, se ahorran los costes de futuras actualizaciones del sistema on-prem. Cualquier desarrollo individual que no exista allí tampoco puede ocasionar gastos. En función del caso de uso, también pueden surgir otras ventajas de costes, por ejemplo en los procesos de extremo a extremo con socios externos integrados.

Infraestructura más ágil

Especialmente las aplicaciones que se utilizan externamente se benefician de estar mapeadas en el BTP. En este caso, las cuestiones del acceso seguro a la aplicación, la conexión a los sistemas locales y la conexión de datos ya tienen respuesta en los servicios correspondientes. Para las aplicaciones que procesan una gran cantidad de datos de sistemas locales, las empresas tienen que tomar decisiones arquitectónicas inteligentes. Hay varias formas y medios de replicar grandes cantidades de datos -incluso casi en tiempo real- en la BTP. Pero esto tiene que estar bien pensado para conseguir realmente un acoplamiento flexible y no gastar los datos en otro silo.

Los servicios disponibles pueden habilitar algunos casos de uso y acelerar considerablemente otros. Por ejemplo, las posibilidades de utilizar modelos de IA para predicciones solo son posibles en sistemas locales con una versión actual de S/4. A través del BTP, también pueden utilizarse en sistemas ERP más antiguos. Otro ejemplo es el desarrollo de un bot de chat, para el que el BTP proporciona un servicio correspondiente a desarrollar.

Eficacia en la integración

Por último, hay que tener en cuenta todo el flujo del proceso y la arquitectura global. Si una nueva aplicación debe acceder de forma útil a muchas funciones (módulos de funciones, clases y métodos, etc.) disponibles en el sistema SAP local, esto puede hablar más a favor de una implementación en el sistema local que en el BTP. Del mismo modo, si la nueva función es sólo un pequeño módulo de un procesamiento masivo en el sistema local. Tampoco es probable que un "ping" constante (llamada a una función) del sistema local al BTP, repetido para muchos miles de registros de datos, sea una solución especialmente eficaz. Todas estas consideraciones tienen sentido y son necesarias para una decisión bien meditada. La evaluación también puede guardarse en los correspondientes árboles de decisión o documentos de estrategia para los próximos casos, de modo que se establezca una cierta rutina a la hora de decidir si desarrollar on-prem o en el BTP en un caso concreto. Si la balanza se inclina a favor del BTP, las primeras actividades reales de desarrollo van precedidas de consideraciones sobre la arquitectura adecuada dentro del BTP y la estructura de la nube o arquitectura global.

Cloud Foundry, Kyma, Abap 

Además de los criterios que suelen distinguir entre desarrollo en la BTP y on-premises, las empresas también deben encontrar la arquitectura dentro de la BTP que más les convenga. Para ello existen tres entornos: Cloud Foundry, Kyma y Abap. Esta decisión depende de los requisitos que se vayan a aplicar y de las competencias existentes de los arquitectos y desarrolladores. Cloud Foundry, por ejemplo, puede utilizarse para proporcionar aplicaciones Fiori interna y externamente de forma muy ligera en poco tiempo. El entorno Abap en el BTP es relativamente pesado y, entre otras cosas, obliga a tener una BD Hana dedicada en la nube. Por otro lado, ofrece la posibilidad de trabajar en el conocido lenguaje de programación de SAP y de implementar una integración muy estrecha con las funciones on-prem. Las aplicaciones en contenedores pueden desarrollarse y desplegarse en el entorno Kyma. Común a todos los entornos es la buena integración en el entorno SAP.

SAP proporciona a cada cliente que ha optado por el BTP una cuenta global. Ésta forma un corchete alrededor de las llamadas subcuentas, como áreas cerradas, por ejemplo, para separar proyectos o etapas. Las subcuentas son el elemento estructural más importante dentro del BTP, ya que contienen parámetros que se definen una sola vez cuando se crean. Una cuenta global puede contener una o varias subcuentas, para cada una de las cuales se define individualmente en qué región geográfica, por ejemplo Norteamérica, Europa Occidental u otras, y con qué proveedor de infraestructuras se implanta físicamente la subcuenta.

Actualmente son: AWS, Microsoft Azure, Google Cloud Platform, Alibaba Cloud y SAP Cloud Infrastructure. Aunque SAP deja al cliente la elección de los hiperescaladores, la relación contractual es exclusivamente con SAP. Además, las empresas deben determinar si quieren utilizar la subcuenta para desarrollos en el estándar Cloud Foundry, para arquitecturas de microservicios en contenedores basadas en Kyma o para desarrollos en Abap.

Es aconsejable diseñar un modelo de subcuentas desde el principio de la utilización de la BTP para permitir efectos sinérgicos y poder reutilizar servicios y datos. Por supuesto, una estructura adecuada, transparente y comprensible también es absolutamente necesaria para las plataformas en crecimiento. Es importante comprobar qué aplicaciones similares pueden compartir una subcuenta (por etapa) en caso necesario y cuán estricta debe ser la separación. Las aplicaciones individuales no pueden o no pueden "ver" y utilizar fácilmente los recursos como servicios o datos de otra subcuenta. Por lo tanto, las siguientes preguntas desempeñan un papel fundamental a la hora de elegir el modelo de subcuenta adecuado:

¿Es necesario un entorno de desarrollo por etapas -Dev, Cons, Prod- en el BTP? ¿Deben almacenarse los datos del BTP de forma centralizada en una o distribuida en varias subcuentas?

¿Las aplicaciones que utilizan arquitecturas comparables - CF, Kyma, Abap - deben ejecutarse todas en una, en las menos posibles o en subcuentas separadas? ¿Las interfaces o API se mantienen en una cuenta central o en cada subcuenta individual? 

¿Es necesario por razones organizativas (por ejemplo, protección de acceso) separar ciertas aplicaciones y/o datos de otros mediante subcuentas dedicadas?

Seguridad

El modelo de seguridad debe definirse en coordinación con el modelo de subcuentas. Los aspectos de autenticación y autorización de usuarios son especialmente relevantes en este caso.

Cuando se desarrolla una aplicación, es necesario considerar qué capas (interfaz de usuario, lógica de negocio, persistencia) se ven afectadas o se implementan en la BTP. Cuantas más capas asigne una empresa al BTP, más importante será la elección del modelo de programación. Para una aplicación UI5 que utilice datos de un sistema SAP on-prem, esta decisión es muy sencilla. Para una aplicación más compleja que pueda necesitar muchos datos, los requisitos del modelo de programación también aumentan. Para la elección del lenguaje de programación y las herramientas, existen los tres enfoques mencionados anteriormente: Cloud Foundry, Kyma y Abap.

Mientras que los entornos Cloud Foundry y Kyma permiten diversos lenguajes de programación, como Java, Node.js o Python, los entornos Abap en la BTP están pensados naturalmente para el desarrollo de código Abap. Por tanto, la elección correcta depende de varios factores. Deben tenerse en cuenta tanto las posibilidades técnicas de cada plataforma como los respectivos conocimientos técnicos disponibles en la organización, por ejemplo, de los desarrolladores.

Así pues, aunque lo más probable es que los desarrolladores SAP clásicos del BTP sigan encontrándose en entornos Abap, Cloud Foundry y Kyma también ofrecen ahora enfoques técnicos que permiten a los "desarrolladores no SAP" crear aplicaciones en el contexto SAP.

En ambos casos, los responsables deben planificar actividades de formación adicionales para dominar las innovaciones técnicas de la plataforma en la nube. Unos conocimientos sólidos de OData, SAPUI5, Fiori Elements, Abap CDS y, en general, una buena comprensión del modelo de programación de aplicaciones RESTful de Abap son indispensables para crear desarrollos fullstack (con el modelo RAP). 

En el caso de desarrollos Cloud Foundry, el personal involucrado con BTP debería aprender OData, SAPUI5 y, si procede, Fiori Elements para el desarrollo de apps Fiori. Para aplicaciones fullstack, SQLscript, Node.js y, por supuesto, el modelo CAP también son relevantes. Para muchos de los desarrolladores actuales, este debería ser un camino de formación exigente, pero definitivamente también interesante y orientado al futuro.

Es bien sabido que el desarrollo y el funcionamiento de aplicaciones basadas en la nube también plantean exigencias especiales en materia de seguridad, protección de acceso y funcionamiento técnico. La Plataforma Tecnológica de Busi-ness no es una excepción. Al igual que las aplicaciones dentro de la propia red de la empresa, que se encuentran detrás del cortafuegos de la empresa, las aplicaciones en la BTP también deben asegurarse mediante mecanismos de autenticación y autorización. Si se producen errores, el riesgo de daños en la nube es, por supuesto, mucho mayor. Por lo tanto, la seguridad de todas las aplicaciones a lo largo de todo el ciclo de vida debe asumir un papel central, garantizando que todos los implicados observen e interioricen los conceptos y directrices.

El uso de la Plataforma como Servicio como base para las aplicaciones empresariales también abre nuevas perspectivas para las empresas en términos de funcionamiento. Se puede crear una nueva "infraestructura" en la nube con solo pulsar un botón, se puede crear una nueva subcuenta en cuestión de minutos y ya está lista para funcionar. El proveedor de la nube -en el caso de BTP, el operador de la infraestructura correspondiente, como Microsoft, Amazon, Google u otros mencionados anteriormente- y, por supuesto, la propia SAP también se ocupan de la estabilidad técnica del "hardware" y de los servicios básicos de la nube (borde superior del sistema operativo).

Por otro lado, también se renuncia a algunos hábitos que se han convertido en evidentes, como la posibilidad de determinar libre y autodeterminadamente los ciclos de lanzamiento de todas las pilas de software, incluso "por debajo" de la capa de aplicación. En el BTP (como presumiblemente en prácticamente todos los demás entornos de nube), SAP suele especificar esto de forma centralizada y garantiza una base constantemente actualizada para las aplicaciones propias.

Conclusión

Además de las ventajas esperadas en el funcionamiento, un desarrollo más rápido y una muy buena integración en el mundo SAP, el BTP como entorno de desarrollo para aplicaciones SAP SaaS es a veces la única forma de realizar sus propias mejoras. Tal y como nos tiene acostumbrados la empresa, SAP pone a disposición de los desarrolladores numerosas herramientas para facilitar el día a día y acelerar el proceso de desarrollo.

Pero incluso más allá del desarrollo de aplicaciones, BTP es la plataforma estratégica para los usuarios de SAP. Un pequeño ejemplo es un servicio para la provisión de tipos de cambio incluso sin tener ya S/4 en el sistema ERP. Pero también se incluyen en la oferta llave en mano otros servicios empresariales como la integración central de datos maestros o la factura X.

Por último, pero no por ello menos importante, la Plataforma Tecnológica Empresarial abre a las empresas oportunidades y posibilidades antes inexistentes para establecer procesos empresariales completamente nuevos. Gracias a la apertura organizativa e informática de las aplicaciones BTP y a las amplias herramientas de integración disponibles en SAP BTP, ahora es posible implementar escenarios de forma mucho más sencilla y rápida. De este modo, los proveedores, clientes y otros socios pueden conectarse (más) estrechamente en red con sus propios datos y procesos, de modo que se dispone de verdaderos procesos de extremo a extremo. 

Los servicios inteligentes (servicios de IA) en constante crecimiento del BTP, que las empresas pueden vincular y combinar de forma excelente con sus propias aplicaciones, ayudan a crear valor a partir de los datos. Si se implementa y utiliza de forma coherente, SAP BTP ayuda a las empresas a ponerse en forma para los retos actuales y futuros y a adaptarse con agilidad a los cambios en la situación del mercado.