Hay un concepto que se repite en conversaciones, presentaciones y documentación de SAP cuando se habla de sistemas cloud. Clean Core. Se presenta como algo que hay que alcanzar, mantener y defender. Como una buena práctica, casi como una actitud. Pero detrás del nombre hay algo más concreto: es una condición operativa sin la cual el modelo cloud de SAP no funciona. La evangelización existe precisamente porque no es obvio para quien viene de un mundo on-premise (aunque vamos a ver que es más obvio de lo que parece)
Qué significa realmente
Clean Core es el principio por el cual el núcleo de una solución SAP cloud debe mantenerse estable, actualizado y sin modificaciones clásicas al estándar. Las extensiones, adaptaciones y desarrollos propios deben construirse únicamente mediante los puntos de extensión, APIs y modelos liberados por SAP: extensibilidad in-app para key users y developers, ABAP Cloud, RAP, integraciones vía SAP Integration Suite, y extensiones side-by-side en BTP cuando el caso lo requiere. El núcleo se respeta como núcleo estándar, no se modifica de forma clásica, se extiende mediante los mecanismos que SAP pone a disposición para ello.
Dicho así suena restrictivo, y para alguien que ha trabajado en proyectos on-premise, puede sonar incluso arbitrario. (Spoiler: no lo es.)
Un matiz importante: BTP no es el único camino ni el destino de todo lo que antes vivía en el core. Es una de las piezas del modelo, junto con la extensibilidad on-stack y las APIs públicas. SAP plantea explícitamente que ambas opciones se complementan, y que la elección depende del caso concreto.
Lo que existía antes
El principio no es nuevo, en los proyectos SAP on-premise ya existía la recomendación de no tocar el estándar. No tenía un nombre tan redondo, pero cualquier consultor con experiencia la conocía y la transmitía. Para extender el sistema sin modificar el código estándar, SAP proporcionaba mecanismos controlados: las user-exits y los BADIs. Puntos liberados por SAP donde el cliente podía añadir lógica propia, con las reglas del juego claras.
Modificar objetos estándar más allá de esos puntos era técnicamente posible, pero requería ser un terrorista registrarlos explícitamente en SAP. Ese registro tenía una consecuencia concreta: SAP retiraba la garantía sobre ese objeto. A partir de ese momento, el cliente era propietario de esa modificación y responsable de su mantenimiento, incluyendo cualquier conflicto con futuras actualizaciones o support packages.
No era caos, era un mecanismo con reglas claras. El cliente tomaba una decisión técnica con consecuencias conocidas y asumidas. En muchos casos era la decisión correcta: el estándar no cubría un proceso crítico, la modificación estaba justificada, y la deuda técnica resultante era manejable. Lo que ha cambiado no es el principio, es el contexto que convierte ese principio en innegociable.
Por qué ese modelo no funciona en la nube
La diferencia no es filosófica, es estructural. En on-premise, el cliente gestionaba su propio sistema. Si decidía modificar objetos estándar y asumir la deuda, era su sistema y su problema. SAP entregaba el software y el cliente hacía con él lo que necesitaba dentro de las reglas establecidas.
En la nube, SAP gestiona la plataforma, no para un cliente, sino para todos. Cada actualización, cada parche de seguridad, cada nueva funcionalidad de IA que SAP despliega tiene que funcionar en miles de sistemas simultáneamente. Eso solo es posible si esos sistemas son homogéneos. Si cada cliente tuviera objetos estándar modificados de forma distinta, SAP no podría garantizar que una actualización no rompe algo en algún sistema. El mantenimiento se volvería inviable a escala. El contrato implícito es claro: SAP mantiene y evoluciona el estándar, el cliente renuncia a modificarlo.
El nombre hace algo más que describir
«Clean» tiene carga semántica, implica que lo anterior era sucio. Pero un sistema on-premise con modificaciones registradas, documentadas y justificadas no era un sistema sucio, era un sistema con decisiones técnicas deliberadas. El término es eficaz para comunicar el concepto a nuevos clientes, pero puede resultar injusto para quienes gestionaron durante años sistemas complejos con criterio. Al final en el On-Premise los clientes eran dueños de su sistema y, todos hemos visto mucha suciedad, sin duda, pero también muchas decisiones con sentido que ahora mismo no serían «Clean».
La pregunta que sí tiene sentido hacerse
Si en on-premise había casos donde modificar el estándar era la respuesta correcta, la pregunta legítima es si los mecanismos actuales, BTP, APIs públicas, extensibilidad side-by-side, cubren esa misma necesidad.
En la mayoría de casos, sí. Pero eso no significa que siempre sea igual de sencillo. Hay escenarios donde replicar una lógica que antes vivía en el core implica más piezas, más diseño y más disciplina técnica. Lo que antes era un user-exit de veinte líneas (con unos cuantos IFs), ahora puede ser una conversación de arquitectura. No es malo, es diferente. El ecosistema de extensibilidad de SAP ha madurado significativamente, pero hay casos donde esa madurez todavía está en desarrollo. SAP lo sabe, y por eso el catálogo de APIs públicas y las capacidades de BTP siguen creciendo con cada release.
Clean Core no es el punto de llegada. Es la condición de partida. Sin eso, todo lo demás, las actualizaciones continuas, la IA embebida, la integración nativa, simplemente no escala.
Clean Core no elimina la complejidad. La obliga a estar donde debe estar.
para activar el seguimiento a la colección concretos. También podremos crear una nueva Improvement Request pulsado en botón 
. Pero lo normal es entrar dentro y ver la pantalla de inicio de la colección.
se abrirá la siguiente pantalla.
Jorge Ocampos 