Porque incluso los sistemas más estructurados pueden evolucionar si se los piensa como parte de algo más grande.
Cuando hablamos de DevOps, enseguida pensamos en integración continua, testing automatizado, despliegues rápidos, pipelines y feedback constante. Todo ágil, iterativo, versionado. Pero cuando el core del negocio es SAP, el panorama cambia. Porque SAP no fue pensado para esto. No es su naturaleza. SAP viene de otro mundo: entornos rígidos, control absoluto, transportes secuenciales, jerarquías estrictas de ambientes, procesos de cambio burocráticos. Todo tiene una razón, claro: la estabilidad. Pero esa lógica choca con la dinámica DevOps, que propone equivocarse rápido, aprender y mejorar de forma continua.
Entonces surge la pregunta: ¿puede SAP adaptarse al paradigma DevOps? En mi experiencia, sí. No es simple ni directo, pero se puede. La clave está en no intentar forzar a SAP a ser lo que no es, sino encontrar cómo integrarlo de forma inteligente a una arquitectura más flexible. Entender sus límites, respetar su core, y a la vez aprovechar todo lo que se puede hacer por fuera del monolito.
Muchas veces veo que se habla de “automatización” en SAP, pero lo que hay son scripts sueltos que hacen tareas puntuales: importar transportes, lanzar un job, crear un usuario. Eso no es automatizar en serio. Eso es mecanizar tareas repetitivas, que está bien, pero no escala. No tiene versionado, no tiene rollback, no tiene trazabilidad, no hay feedback automático. En el mejor de los casos, ganás tiempo. Pero no estás construyendo un proceso.
La automatización que propone DevOps es otra cosa: procesos enteros versionados, integrados en pipelines, auditables, con validaciones automáticas, que se puedan repetir igual en todos los ambientes. En SAP clásico eso cuesta. Requiere creatividad, conocimiento técnico profundo, y muchas veces ir más allá de lo que el producto ofrece de forma estándar.
¿Dónde sí veo avances concretos? En SAP BTP, por ejemplo, donde ya podés trabajar con microservicios, Node.js, Python, herramientas modernas, integración continua real. También en extensiones desarrolladas por fuera del ERP, que se conectan por API: ahí sí podés tener todo el ciclo DevOps completo, desde el repo hasta el deploy. Si tenés SAP en cloud, podés usar Terraform, Ansible o CloudFormation para levantar entornos, gestionar infraestructura como código, escalar o clonar sistemas. Y con ABAP Unit podés automatizar pruebas, integrarlas con pipelines y empezar a tener algo de CI en el desarrollo tradicional.
Obviamente hay mucho por hacer. SAP todavía tiene que abrir más su ecosistema, mejorar las integraciones nativas con herramientas como Jenkins, Prometheus, Grafana, GitHub Actions, etc. Y nosotros también tenemos que cambiar el enfoque. No se trata solo de operar el sistema y que funcione. Se trata de integrarlo al resto de la arquitectura, pensar flujos, automatizar todo lo posible y reducir la fricción entre desarrollo y operación.
¿Puede SAP integrarse a una cultura DevOps? No de forma tradicional ni con los enfoques que se aplican en entornos más flexibles, pero sí desde una lógica propia y bien adaptada. Se trata de reconocer sus limitaciones sin resignarse al “esto siempre fue así”. Cuando dejamos de tratar a SAP como un sistema cerrado y lo integramos como una pieza más dentro de una arquitectura moderna, empiezan a aparecer oportunidades concretas de mejora.