sin código
![](https://e3mag.com/wp-content/uploads/2023/06/shutterstock_2019217019_dordek.jpg)
![](https://e3mag.com/wp-content/uploads/2023/12/pmf_RGB_400x400_2-150x150.png)
A la cabeza está Abap en la BTP con el nombre en clave Steampunk. Pero también hay numerosas ofertas low-code/no-code. Java también sigue siendo demandado y también existe el concepto de "Bring Your Own Programming Languages" (traiga sus propios lenguajes de programación).
Hay un refrán que dice que muchos cocineros estropean el caldo. Al final, el cliente SAP existente podría quedarse sin código alguno, o como dice el refrán: muchos caminos llevan a Roma. En la cumbre SAP Competence Centre Summit 2023 celebrada en Salzburgo, el equipo editorial de E-3 sondeó las preferencias de los clientes y socios actuales. Abap sigue encabezando la lista. No son muchos los participantes en la cumbre que dan una oportunidad a Build, la oferta low-code/no-code de SAP. No obstante, existen buenos enfoques de bajo código en la comunidad SAP; véase el siguiente informe de Simplifier en este artículo de portada.
Para evitar un desastre sin código, los clientes actuales de SAP se enfrentan a un doble reto: ¿Cómo llevar las modificaciones de Abap del espacio de nombres Z a S/4 y cómo realizar la personalización futura en la SAP Business Technology Platform? Abap RESTful Application Programming (RAP), Cloud Application Programming (CAP), Low Code/No Code con SAP Build y Steampunk como Embedded Abap son sólo una pequeña selección de las posibilidades de cómo un cliente SAP existente puede modificar su sistema ERP en el futuro. En consecuencia, no solo es necesario estudiar diversos conceptos, desde el código abierto y GitHub hasta el código steampunk propietario, sino también aprender los propios lenguajes de programación. Una tarea nada fácil para los programadores, en qué lenguaje tendrán que codificarse los algoritmos en el futuro... ¡y Java sigue existiendo!
La respuesta a Steampunk fue muy positiva en los grupos de trabajo del DSAG en las Jornadas Tecnológicas de Mannheim. En su mayoría, sin embargo, se trataba de clientes de SAP que habían pasado la mitad de su vida profesional con Abap. ¿Qué nos depara el futuro? ¿Debería un nuevo cliente para la nube privada o pública aprender también Abap con vistas al steampunk? Karl Kessler, VP Product Management Abap Platform de SAP, responde a esta pregunta en una entrevista exclusiva para E-3: "Abap sigue siendo relevante y lo seguirá siendo en el futuro. Para los clientes de S/4, tanto existentes como nuevos, SAP ofrece un moderno modelo de desarrollo Abap Cloud. Abap Cloud permite construir soluciones y extensiones actualizables y habilitadas para la nube. Dependiendo del escenario, los clientes o partners pueden construir su extensión Abap Cloud directamente sobre la pila S/4 o sobre la Plataforma Tecnológica Empresarial. Dentro de la comunidad, esto también se conoce como embedded steampunk o steampunk. El modelo de desarrollo de Abap Cloud está disponible en la BTP y en todas las ediciones de S/4, es decir, nube pública, nube privada y on-prem, en la última versión."
Modificaciones Abap
Muchos sistemas R/3 de éxito se basan también en amplias modificaciones de Abap. La cuestión del coste total de propiedad (TCO) en la codificación Abap rara vez se planteaba. Con la llegada de NetWeaver y las nuevas posibilidades de personalización del sistema, también en el espacio de nombres Z, las consideraciones relativas a los costes de programación adquieren mayor relevancia. A más tardar cuando se cambie a S/4 Hana, todo cliente SAP existente debería vigilar muy de cerca el "TCO de la codificación".
Con el auge de la llamada Composable Enterprise, también aumenta la demanda de componentes de software reutilizables con los que desarrollar soluciones de forma rápida y eficiente. Así lo postula la asociación digital Bitkom: Las empresas digitalizadas van por delante de la competencia. En las empresas alemanas crece la preocupación por perder terreno frente a sus competidores digitales. Una clara mayoría de empresas prevé actualmente competidores que han apostado por la digitalización en una fase temprana. Se trata de un valor máximo. Hace un año, sólo el 52% de las empresas veía que sus competidores digitales se alejaban, hace cinco años era sólo el 37%. En la actualidad, dos tercios consideran que su propia empresa ha llegado tarde a la digitalización, mientras que un tercio se ven a sí mismas como pioneras. Estos son los resultados de una encuesta representativa de 602 empresas con 20 o más empleados en Alemania encargada por la asociación digital Bitkom.
Importancia de la digitalización
"Las empresas han reconocido la importancia de la digitalización para su propio futuro. Sin embargo, aparentemente no saben cómo abordar la digitalización. Para cada empresa individual, así como para la economía alemana en su conjunto, el lema debe ser: ¡hagamos de la década de 2020 la década digital!", exige el nuevo presidente de Bitkom, Ralf Wintergerst, con motivo de la presentación del estudio. "En el pasado, Alemania fue tierra de poetas y pensadores. En el futuro, Alemania debe ser la tierra de poetas, pensadores y digitalizadores".
La IA no es la única tecnología en la que existe una discrepancia entre la importancia percibida para la competitividad global y el uso en la propia empresa. Por ejemplo, el 92% de las empresas considera que el análisis de datos y el big data son muy importantes, pero sólo el 39% los utiliza. El 86% considera importante la robótica, pero sólo el 40% utiliza esta tecnología. La situación es similar para el Internet de las Cosas (84 por ciento de gran importancia, 36 por ciento de uso), 5G (82 por ciento a 23 por ciento), vehículos autónomos (76 por ciento a 17 por ciento), impresión 3D (74 por ciento a 23 por ciento) y realidad virtual y aumentada (67 por ciento a 24 por ciento).
Y el uso de tecnologías más nuevas es aún más raro: por ejemplo, sólo el 4% utiliza la tecnología blockchain, aunque el 67% le atribuye gran importancia. Y prácticamente ninguna empresa utiliza tecnologías metaversas (1%), aunque el 36% les atribuye gran importancia. "Tenemos que posicionar a Alemania de forma sobresaliente en la economía digital. Necesitamos más coraje para digitalizarnos, también en las empresas", afirma Wintergerst.
![](https://e3mag.com/wp-content/uploads/2023/06/PK-Digitalisierte-Unternehmen.jpg)
El mayor obstáculo para la digitalización desde el punto de vista de las empresas es la protección de datos, que el 77% considera que les dificulta su transformación digital. Hace un año era el 71 por ciento. También se agudiza la escasez de trabajadores cualificados (64 por ciento; 2022: 55 por ciento). Le siguen los requisitos de seguridad técnica de TI, la falta de tiempo y la falta de recursos financieros, cada uno con un 54 por ciento, por lo que la escasez de recursos se menciona como motivo con bastante más frecuencia que en 2022, con un 43 por ciento. Por el contrario, la falta de voluntad de los trabajadores (12%) y la incertidumbre sobre los beneficios económicos de la digitalización (5%) no son obstáculos generalizados.
Composibilidad
Un paso esencial hacia la digitalización para los clientes actuales de SAP será la individualización, adaptación y componibilidad de su propio sistema ERP, ECC o S/4. Las modificaciones siempre han representado un valor añadido para los usuarios de SAP, lo que ha impulsado repetidamente al líder mundial del mercado ERP hacia nuevos modelos de programación, incluso más allá de Abap. En 2020, SAP presentó un primer experimento low-code con el framework Ruum, que debería permitir a los usuarios sin conocimientos de programación crear procesos departamentales en cuestión de horas en lugar de días o semanas.
Poco después, en 2021, SAP anunció la adquisición de AppGyver. AppGyver es una start-up en el campo de las plataformas de desarrollo sin código que permiten a los usuarios sin conocimientos de programación crear aplicaciones móviles, así como aplicaciones para la web. Y de nuevo SAP dijo: "Con la adquisición de AppGyver, SAP puede apoyar mejor a sus clientes y socios existentes en la adaptación eficiente de los sistemas de TI a sus propias necesidades específicas y en la optimización de la facilidad de uso de sus aplicaciones. Las soluciones de AppGyver pasarán a formar parte de SAP Business Technology Platform (BTP). AppGyver está diseñado para ampliar la oferta de inteligencia de procesos empresariales de SAP y complementar la oferta de bajo código de SAP, que proporciona el socio Mendix y forma parte de Siemens. En su día, el framework de bajo código de Mendix estuvo incluso en la lista de precios de SAP y hubo ferias de congresos conjuntas entre SAP y Mendix. Entretanto, esta asociación se ha roto, pero Ruum y AppGyver también han desaparecido en el olvido, por lo que la comunidad habla de "sin código" en este sentido.
Cualquiera puede desarrollar aplicaciones, declaró SAP, promoviendo una experiencia unificada de bajo código/sin código basada en la Plataforma Tecnológica Empresarial. Tanto los desarrolladores profesionales como los especializados pueden crear nuevas aplicaciones con ella. Las aplicaciones existentes pueden mejorarse y las tareas complejas pueden automatizarse, según SAP. AppGyver ofrece desarrollo sin código y automatización, mientras que SAP Business Application Studio aumenta el desarrollo de bajo código. El argumento que se escucha una y otra vez: con low code, la complejidad técnica es mucho menor que con los métodos de programación convencionales.
Desarrollo de aplicaciones
Un estudio actual de Techconsult en cooperación con Neptune Software muestra que las plataformas de bajo código ya se han convertido en una opción relevante dentro del desarrollo de aplicaciones SAP de las empresas alemanas. Más de dos tercios de todas las empresas (68%) afirman que ya están trabajando activamente en las soluciones correspondientes. Las soluciones de software flexibles y modernas, como el marco de soluciones Intelligent Enterprise de SAP, que también incluye el nuevo mundo ERP en torno a S/4, son un factor central de éxito para una mayor digitalización y la base de los procesos digitales.
Estos retos se afrontan cada vez más con métodos y tecnologías de desarrollo ágiles e innovadores que hacen que el software sea más flexible y rentable. Se está pasando de las grandes implantaciones de software, que requieren mucho tiempo y dinero, a un desarrollo ágil con procesos y métodos de desarrollo totalmente automatizados, que son necesarios para el rápido entorno de la digitalización con el fin de poder desarrollar y proporcionar software con la calidad, velocidad y eficiencia requeridas, incluso en tiempos de presupuestos y recursos limitados. En el entorno SAP, las plataformas de bajo código ofrecen diferentes enfoques para apoyar el desarrollo de aplicaciones SAP individuales o el desarrollo y la adaptación de aplicaciones existentes.
UI5 y Fiori
Por ejemplo, ofrecen la posibilidad de desarrollar apps Fiori basadas en UI5 en la infraestructura SAP existente durante la transición a S/4 y seguir haciéndolo después. Mediante el uso de herramientas de modelado gráfico, los desarrolladores no necesitan conocer HTML5 o JavaScript, y los desarrolladores de Abap pueden utilizar la pila tecnológica estratégica de SAP en el sistema digital central para desarrollar aplicaciones personalizadas y proporcionar funciones empresariales como API sin necesidad de herramientas o conocimientos adicionales.
Aunque las ventajas son evidentes, es probable que en la propia SAP aún no se haya encontrado el marco definitivo, porque después de Ruum y AppGyver, el pasado otoño llegó Build, otra oferta de bajo código para la Business Technology Platform. La nueva herramienta informática está diseñada para permitir a los usuarios crear y ampliar aplicaciones empresariales, automatizar procesos y crear prototipos de interfaces web simplemente arrastrando y soltando con unos conocimientos técnicos mínimos. "SAP Build reúne las aplicaciones empresariales más potentes del mundo en una plataforma diseñada específicamente para capacitar a los usuarios empresariales en el menor tiempo posible", ha declarado Jürgen Müller, miembro de la Junta Directiva y Director de Tecnología de SAP.
![](https://e3mag.com/wp-content/uploads/2023/06/eBook_seite_16-16.jpg)
Debería ser posible trazar el ciclo de vida completo de una aplicación en una sola plataforma de bajo código.
"La demanda de soluciones digitales avanzadas es significativamente mayor que la capacidad de los desarrolladores profesionales para ofrecerlas", afirma Arnal Dayaratna, Vicepresidente de Investigación de Desarrollo de Software de IDC. "IDC espera que más de 100 millones de usuarios empresariales de todo el mundo participen en el desarrollo de soluciones digitales durante la próxima década. Con las soluciones de desarrollo low-code de SAP Build, los usuarios empresariales pueden aprovechar su experiencia para desarrollar y optimizar soluciones digitales rápidamente y a escala."
Pero también hay dos razones de peso que hablan en contra de SAP Build, la última oferta de no-código/bajo-código de Walldorf: GRC y MS Power Apps. Si todos los usuarios de SAP se convierten en desarrolladores de aplicaciones con Build, el caos de gobernanza, riesgo y cumplimiento no durará mucho. Y con Microsoft Power, existe una comunidad mucho mayor que es en gran medida compatible con Hana y S/4. ¿Por qué SAP no coopera con Microsoft y lleva Power al BTP?
Microsoft Power
Hace dos años, Holger Bruchelt, empleado de Microsoft, escribió en E-3 Magazine: "Low Code/No Code ha sido la comidilla de la comunidad SAP, y no sólo desde las diversas adquisiciones de SAP. Low Code/No Code permite a nuevos grupos de personas desarrollar las aplicaciones necesarias no sólo más rápido, sino también de forma más rentable". Hace unos años, Gartner ya había informado sobre la enorme escasez de desarrolladores de aplicaciones, y muchas empresas habían observado en las suyas que faltaban los desarrolladores necesarios o que el tiempo de espera para el desarrollo de una nueva aplicación era largo.
Ya no es posible seguir el ritmo. Así que, por necesidad, se crean soluciones provisionales propensas a errores y los datos se transfieren "a mano" al sistema SAP. Los recursos disponibles suelen eludir la seguridad, la gestión de la calidad y los procesos reales. Esto conlleva a veces grandes riesgos, hasta la pérdida de datos. Esta es probablemente una de las razones por las que muchas empresas han establecido un "Excel crítico para el negocio" con el que (tienen que) trabajar en paralelo a su entorno SAP. OData hace que sea relativamente fácil mantener los datos sincronizados con la "única fuente de verdad" del sistema SAP y mapear procesos más complejos con numerosas macros de Excel, pero ese nunca fue el propósito de estos programas.
Con SAP Ruum, SAP Intelligent RPA, SAP Conversational AI o el nuevo AppGyver, los clientes actuales de SAP disponen ahora de diversas herramientas que les permiten desarrollar nuevas interfaces de usuario y automatizar los flujos de procesos. La SAP Store para iRPA, por ejemplo, ofrece un excelente punto de partida y muestra cómo los procesos de SAP pueden automatizarse ahora más fácilmente.
Un sistema SAP clásico consta de tres niveles jerárquicos: Desarrollo, prueba y sistema productivo, ¡y eso es bueno! Primero tiene lugar el desarrollo, en el pasado con Abap y Java, en el futuro obviamente con Build on BTP, la Business Technology Platform; a continuación tiene lugar el transporte al sistema de prueba y se realiza una comprobación de la realidad con datos de prueba anonimizados; si todo va bien, entonces tiene lugar el transporte y la activación en el sistema productivo. Esta hoja de ruta de décadas de antigüedad ha demostrado su eficacia. En los albores de la era de la construcción, no se sabe nada de ella.
Obviamente, surgen dos preguntas: ¿Cómo puede Build on the BTP garantizar la coherencia de los datos en la base de datos Hana si todo el mundo puede modificarlos y manipularlos aquí? ¿Cómo garantizar que el vecino no implemente la misma idea sólo que con una interfaz de usuario diferente? Build tendría que tener un repositorio muy inteligente para alertar de antemano a los usuarios creativos de la redundancia y la falta de coherencia.
En general, puede decirse que SAP Build no puede cumplir la promesa de una 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. En la práctica, sin embargo, es evidente que esta plataforma requiere considerables conocimientos de programación.
Escepticismo y valor añadido
Habida cuenta de la evolución registrada hasta la fecha y del escepticismo que suscitan las plataformas low-code/no-code, resulta difícil convencer a la comunidad de que la solución propietaria low-code puede ofrecer un verdadero valor añadido. Muchos miembros de la comunidad SAP tienen un fuerte apego a Abap y pueden considerar el desarrollo de bajo código/sin código como una desviación de las prácticas y normas establecidas. Sin embargo, las reservas de la comunidad SAP pueden superarse. Esto se debe a que el enfoque de bajo código ofrece muchos valores añadidos, que muy a menudo confirman las empresas que utilizan alternativas de bajo código fuera de BTP. Sin embargo, el bajo código no debe ser sólo una tecnología. El bajo código es una forma de pensar que debe formar parte del ADN de las empresas.
![](https://e3mag.com/wp-content/uploads/2021/04/Download-Coverstory.jpg)