Incluso los sistemas nuevos y complejos pueden ser estables
El objetivo primordial de todas las organizaciones SAP del mundo es la estabilidad. Siguiendo el lema "Nunca toques un sistema en funcionamiento", siguen recopilando parches, adaptaciones y desarrollos individuales, los combinan en una versión principal, la someten a pruebas exhaustivas y repetidas y la ponen en producción una o, como mucho, dos veces al año. Esto no debería cambiar en el nuevo mundo S/4. No en vano, muchos clientes actuales de SAP reducen inadmisiblemente el debate sobre la nube a la cuestión del lugar ideal de implantación y funcionamiento de la nueva generación de software de Walldorf.
Para SAP, la nube es ante todo una cuestión de arquitectura óptima para el software y el desarrollo de software del futuro. Esto significa servicios específicos de funciones y reutilizables en lugar de monolitos de software y la publicación de correcciones, cambios y ampliaciones en grandes cantidades tan pronto como estén disponibles. Atrás quedaron los días de grandes lanzamientos a intervalos igualmente grandes.
Esto va de la mano del lema de SAP "Keep the core clean". Walldorf anima a los clientes actuales de SAP a desarrollar y ofrecer adaptaciones individuales sólo como extensiones. Y para evitar una yuxtaposición de cambios rápidos y flexibles en el núcleo por un lado y en las extensiones por otro, SAP recomienda a sus clientes que sigan el camino dorado de su Modelo de Programación de Aplicaciones en la Nube (CAP). En este modelo, los desarrolladores pueden concentrarse en sus tareas específicas y desarrollar código en lenguajes de programación distintos de Abap. Todo va en la dirección de los estándares abiertos para una mayor compatibilidad y reutilización, también y sobre todo en la interacción con aplicaciones de terceros.
Cada vez más cambios en un tiempo cada vez más corto, muchos lanzamientos pequeños con gran frecuencia, más lenguajes de programación, separación coherente de los niveles de base de datos, aplicación y presentación: el mundo SAP es cada vez más complejo en la nueva generación. Pero más complejidad significa más esfuerzo y más fuentes de error, el horror para las organizaciones SAP que se aferran con mayor tenacidad al statu quo.
La línea divisoria entre partidarios y detractores del cambio no discurre entre TI y el resto de la empresa, sino dentro de TI, entre desarrollo y operaciones. Pedido ayer, entregado hoy: eso es lo que esperan no sólo los usuarios empresariales, sino también los desarrolladores. No quieren esperar a que esté listo el entorno de pruebas para sus cambios y ampliaciones creados con métodos ágiles, ni quieren detenerse en sus efectos sobre el funcionamiento y la estabilidad del entorno productivo.
Su ideal es la normalización y la automatización. Pero para eso necesitan a sus colegas de operaciones informáticas. Y necesitan entenderlos mejor. Este es precisamente el objetivo del concepto DevOps, que crea la base necesaria para ello mediante una estrecha colaboración en equipos interdisciplinarios.
DevOps es ante todo una cuestión de cultura. Y como esta falta en muchas organizaciones SAP, no hay confianza en este enfoque. Sin embargo, sin esta confianza no existe un movimiento de base que acabe alcanzando una masa crítica y provoque por sí solo el cambio necesario. Esto es lo que ha demostrado la experiencia de los últimos tres a cinco años, en contra de lo esperado.
La dirección debe pisar el acelerador y forzar el Dev-Ops. Porque sin agilidad, un "sistema en funcionamiento" en la era de la nube se convierte rápidamente en un "sistema que falla". Una cadena de herramientas de extremo a extremo -desde el desarrollo y la resolución iterativa de problemas hasta las pruebas y la entrega del código- ayuda a promover la aceptación de esta decisión: Para que la confianza ganada en la colaboración no se rompa contra la dura realidad de los sistemas productivos, sino que ambos -desarrollo y operaciones- se beneficien de una entrega de software rápida y frecuente, pero de bajo riesgo.
