Más allá de SAP Build

La propuesta de valor que falta en SAP Build: No hay un enfoque de desarrollo de código bajo para todos

El desarrollo eficiente de aplicaciones de software es fundamental en el mundo de los negocios digitales. Un examen detallado de las ventajas, los retos y las limitaciones de SAP Build y su impacto en el desarrollo de aplicaciones revela hasta qué punto SAP puede estar a la altura de su propuesta de valor, especialmente en lo que respecta al enfoque de código reducido.

SAP Build promete a las empresas un entorno fácil de usar en el que se pueden desarrollar aplicaciones sin conocimientos de programación. La plataforma se basa en el software de Appgyver, que fue adquirido por SAP en 2021. Ofrece potentes herramientas de prototipado y diseño que permiten a los desarrolladores crear rápidamente interfaces de usuario interactivas. La participación temprana de los usuarios y la retroalimentación continua están diseñadas para optimizar las apps y obtener la mejor experiencia de usuario.

Una de las principales ventajas de Build, como ocurre con cualquier plataforma de bajo código, es que acelera el desarrollo de aplicaciones. Para ello, la plataforma ofrece componentes y plantillas de interfaz de usuario listos para usar que hacen que el proceso de desarrollo sea más eficiente. Al reutilizar los componentes existentes, los tiempos de desarrollo pueden acortarse considerablemente, lo que se traduce en una mayor rapidez en la salida al mercado de las aplicaciones.

La colaboración y la comunicación eficaces son fundamentales para el éxito de los proyectos de desarrollo. Por ello, SAP Build también ofrece funciones como comentarios, notificaciones y uso compartido de borradores para apoyar una colaboración fluida entre desarrolladores, diseñadores y usuarios. Esto permite intercambiar comentarios y trabajar conjuntamente en mejoras para desarrollar aplicaciones que satisfagan las expectativas de los usuarios.

Se demandan conocimientos de programación

Sin embargo, a pesar de las ventajas, también existen varios retos a la hora de utilizar Build en el proceso de desarrollo. Mientras que las ventajas consisten en que las aplicaciones centradas en el usuario pueden desarrollarse de forma rápida y eficaz, las limitaciones se encuentran principalmente en el uso del desarrollo de código bajo para los creadores de aplicaciones sin conocimientos de programación.

En la práctica, se hace evidente que esta plataforma requiere en realidad considerables conocimientos de programación. Por lo tanto, es necesaria una familiarización intensiva con la plataforma a través de la formación, especialmente para los usuarios, desarrolladores y diseñadores que no estén familiarizados con la plataforma. Las diversas funciones y posibilidades de SAP Build requieren una formación adecuada para aprovechar todo el potencial de la plataforma.

Otro problema de Build es la falta de internacionalización del editor Wysiwyg. Mientras que el contenido de las aplicaciones creadas puede traducirse a diferentes idiomas, la herramienta en sí permanece exclusivamente en inglés. Esto supone un obstáculo especialmente para las empresas de países de habla no inglesa y dificulta el uso de la plataforma.

Uno de los principales problemas es la limitada función de exportación de SAP Build. Aunque la plataforma promete la creación de aplicaciones móviles, actualmente sólo es posible la generación de aplicaciones web. En otras palabras, actualmente no es posible desarrollar apps nativas para iOS o Android directamente con Build.

La exportación de las apps a una aplicación web también tarda un tiempo inusualmente largo y falta la anunciada notificación por correo electrónico al finalizar. Las aplicaciones web generadas tampoco se basan en el marco UI5 interno de SAP, sino que utilizan React Native. Esto genera una dependencia que SAP no puede controlar y dificulta la edición y reutilización del código, ya que Build carece del lenguaje de diseño familiar de SAP Fiori. Aunque la integración con los servicios móviles de SAP puede ser posible en el futuro, actualmente no hay indicaciones claras al respecto en la documentación ni en la hoja de ruta de SAP Build.

La integración de Build en los entornos corporativos existentes es también un reto importante. Aunque la plataforma está diseñada como una solución de bajo/ningún código, la conexión back-end es compleja y, por tanto, afecta especialmente al aspecto del Citizen Developer. Resulta evidente que la vinculación y el procesamiento de datos que son habituales en el entorno SAP no son para el Citizen Developer.

Conocimientos sobre OData

Para conectar y mostrar datos de sistemas empresariales como S/4 Hana Cloud u On-premises, se requieren conocimientos específicos sobre el protocolo OData, el mapeo de variables y su integración en el ciclo de vida de la app. Los mecanismos y el editor de fórmulas proporcionados van más allá del concepto de bajo código o sin código. Esto dificulta a los desarrolladores ciudadanos la realización de dichas conexiones y la creación de fórmulas complejas sin amplios conocimientos.

Por lo tanto, la conexión sin fisuras a los datos en la nube o locales de S/4 Hana sigue siendo un reto dentro de la plataforma de construcción. La autenticación, la autorización y la conexión de fuentes de datos tampoco están maduras y sólo ofrecen posibilidades limitadas a los desarrolladores profesionales. También faltan la asignación de roles y un sistema completo de roles y derechos.

La escalabilidad y el rendimiento de las aplicaciones empresariales son fundamentales. Al utilizar Build, es importante revisar a fondo la arquitectura, desarrollar un código eficiente y realizar pruebas en el mundo real para identificar y resolver a tiempo los cuellos de botella o los problemas de rendimiento.

Seguridad y protección de datos

La seguridad y la protección de datos son otros aspectos importantes del desarrollo de aplicaciones empresariales. Al utilizar Build, las empresas deben asegurarse de que se cumplen todos los requisitos de protección y seguridad de los datos, especialmente cuando se procesan datos sensibles de la empresa.

Una de las principales desventajas para los equipos de TI y los desarrolladores profesionales de SAP es que construir con SAP Build no es tan flexible como programar en Abap, por ejemplo. Abap permite a los desarrolladores implementar lógicas empresariales muy complejas y abordar requisitos específicos. Con la plataforma de bajo código SAP Build, es difícil implementar lógicas tan complejas y solicitar personalizaciones o soluciones adicionales.

Un factor no desdeñable es también la aceptación dentro de la comunidad SAP, conocida por su potente lenguaje de programación Abap. Sin embargo, dentro de la comunidad también se han debatido diversos enfoques en el ámbito del desarrollo de bajo código/sin código. Se han impulsado con fuerza varias cooperaciones y adquisiciones de SAP en el pasado próximo en el ámbito del bajo código y sin código, pero no han logrado convencer realmente a la comunidad SAP. La comunidad SAP ha desarrollado un cierto escepticismo cuando se trata de plataformas de bajo código/sin código.

Un aspecto que ha causado debate en la comunidad SAP en este contexto es la cancelación de una cooperación con Microsoft y el producto Power Apps. Muchos miembros de la comunidad SAP se sintieron decepcionados, ya que Power Apps cuenta con una comunidad amplia y activa. Sin embargo, esta cancelación también significó que otros proveedores de plataformas de bajo/ningún código, como Simplifier, tienen ahora la oportunidad de ganarse a los clientes y socios existentes de SAP presentando de forma convincente el valor añadido de sus soluciones para el desarrollo de aplicaciones centradas en SAP. 

Por lo tanto, merece la pena que las empresas examinen alternativas de bajo código más ágiles y flexibles, como Simplifier, junto con los usuarios y equipos de desarrollo de SAP, para cotejar sus propios requisitos con las posibilidades y funcionalidades de las plataformas, con el fin de encontrar en última instancia una tecnología de bajo código adecuada que satisfaga sus propias necesidades.

En general, se puede afirmar que SAP Build no puede cumplir su promesa como plataforma de desarrollo de bajo código. Existen varias limitaciones y deficiencias tanto para los usuarios empresariales como para los desarrolladores de código profesional. La plataforma aún no está lo suficientemente madura y no ofrece un enfoque de solución integral y, sobre todo, uniforme para el desarrollo de aplicaciones empresariales. En un principio, SAP Build se promocionó como una solución que permitiría a las empresas crear sus propias aplicaciones y procesos sin conocimientos de programación. Pero en la práctica, resulta que esta plataforma requiere en realidad considerables conocimientos de programación.

Alternativa magra

Simplifier es un proveedor de bajo código que ahora se conoce en el mundo SAP como una "alternativa lean a SAP Build" y que ha convencido a muchas empresas que han llegado a sus límites con la cadena de herramientas SAP y BTP. Con su moderna tecnología basada en el marco UI5 popular en la comunidad SAP, la plataforma de bajo código ha sido capaz de inspirar a muchos desarrolladores SAP y Abap. Las ventajas de utilizar Simplifier incluyen las versátiles opciones de integración estandarizadas, la interfaz de usuario más flexible para el uso de aplicaciones en todos los dispositivos finales (incluidos los wearables), un alto grado de reutilización de todos los contenidos creados y existentes y un concepto operativo ágil a la hora de desplegar y utilizar aplicaciones y aplicaciones móviles.