En los años 90 SAP cambió el paradigma de trabajo en concepto de sistemas empresariales, con la introducción del SAP R/3, introduciendo la arquitectura cliente servidor, desplazando los mainframes vigentes desde los años 60 y 70. Este avance fue también apoyado en el uso de la metodología ASAP, como acelerador para la puesta en marcha de las soluciones. El landscape de 3 sistemas, DEV, QAS y PRD se impuso como un standard para todas las instalaciones SAP.
En mitad de la década 2010 surgió la necesidad de repensar y cambiar los paradigmas por la llegada de los conceptos Cloud. SAP respondió con la introducción de la base de datos HANA, con la gestión en memoria, en reemplazo de las bases relacionales tradicionales. El movimiento hacia la nube es otro cambio de paradigma. Descentralizar el gran ERP, en soluciones que hablen entre sí, especializadas, pero coordinadas, con interfases inteligentes (middleware).
Junto con esto, SAP necesitaba acercarse al concepto de agilidad en la implementación de las soluciones SAP. En la década pasada se hablaba de dos releases por año. Eso fue reemplazado por el concepto de releases periódicos (major & minor releases) con funcionalidades nuevas desplegadas en los entornos productivos respondiendo a las necesidades de los clientes. No se podía esperar 2 años para implementar una nueva funcionalidad.
Para poder permitir este enfoque SAP lanzó una nueva metodología, SAP Activate, que también cambiaba varios paradigmas establecidos en la comunidad de consultores y empresas usuarias de SAP. Entre los cambios sustanciales que introdujo fueron el cambio de Blueprint por Explore, y esto no es un mero tema de marketing, es un enfoque diferente de encarar el proceso de definición del modelo futuro. La otra modificación que introdujeron es el concepto de construcción ágil, incorporando los conceptos de agilidad ya en uso en otras tecnologías: Waves, Sprints, Scrums, para el propio mundo de SAP.
¿Cuál es el concepto entonces, que debe primar si queremos ser ágiles, y salir de las viejas prácticas de proyectos “waterfall” (cascadas)?. Es la idea de poder salir a producción con funcionalidades que puedan ser entregadas (“shipable”) a producción con cierta periodicidad, que por un lado permita responder a las necesidades del negocio, pero que también garanticen la estabilidad del sistema productivo.
Para poder sostener este andamiaje de releases, SAP introduce Focused Build en Solman por un lado, con una solución totalmente integrada por un lado, pero por otro lado plantea un nuevo landscape de cuatro sistemas, con la introducción del sistema PRE. Este sistema PRE permite realmente asegurar que la funcionalidad que se va a poner en marcha en el nuevo release es consistente, funciona, y a la vez, no “rompe” el productivo, mientras que ya se está trabajando en el próximo release.
¿Cómo llegar a producción “sanos y salvos”? Esto se resuelve con los controles previos que permite al “Release Manager” tener una visión total de lo que se va a poner a andar. “Build” del release con funcionalidades ya construidas y testeadas. El “Test Manager” va a lograr organizar y controlar la ejecución de las pruebas de integración final en un entorno símil producción, y a su vez podrá ejecutar pruebas de regresión automáticas.
En un blog de un especialista, Joerg Marenk hace referencia a un documento provisto por SAP “Manage your Conversion to SAP S/4HANA Private Cloud Edition with SAP Solution Manager and Focused Build” (https://bit.ly/S4_conversion). En este documento se introduce el siguiente concepto:
“… for the phases before and after the conversion, when a stable 4-System-Landscape is available where all four systems are on the same system version. Only in this case the handling of transports via Work Items and the Focused Build Import program is efficient and leveraging all advantages that these tools have.
En un intercambio de mails con un responsable de SAP ALM, acerca si era un standard los 4 sistemas ya indicados por SAP, recibí una respuesta “.. four systems is not SAP standard, but If you follow the agile DevOps approach, the 4 system landscape is the logical consequence”.
Claro y simple, para poder introducir la innovación tecnológica y migrar a S/4HANA, con un enfoque ágil, hay que seguir los conceptos de:
- SAP Activate,
- utilizar Solman+Focused Build,
- plantear un landscape de 4 sistemas
- y reforzar los conceptos de release y roles organizacionales de Release Manager y Test Manager.
Juntando todos estos elementos es posible lograr proyectos exitosos, con releases periódicos, agregando valor al cliente, mientras se mantiene la estabilidad del sistema productivo.