Clean Core

A menudo se reduce clean core a "nada de código personalizado", que no es lo que describe SAP. El principio trata de cómo se desvía un sistema del estándar, no de si lo hace:

• Las extensiones usan API y puntos de extensión liberados, para que SAP pueda cambiar los elementos internos sin romperlas.
• La configuración se prefiere al código siempre que el estándar ofrezca un ajuste.
• La integración pasa por interfaces liberadas y documentadas en lugar de acceder directamente a las tablas.
• Los datos y las operaciones siguen los estándares actuales, de modo que el sistema siga siendo soportable.

Un sistema puede tener muchas extensiones y seguir siendo clean, siempre que cada una dependa solo de lo que SAP se ha comprometido a mantener estable. Por tanto, clean core es una regla sobre dependencias, no una prohibición de diferenciarse.

La guía actual de SAP clasifica los objetos personalizados en cuatro niveles, que SAP Cloud ALM usa para informar de una cuota de clean core:

Material anterior de SAP describe un modelo de extensibilidad de tres niveles con una intención comparable, y ambos vocabularios siguen apareciendo en la documentación de SAP. Los niveles de clean core convierten el principio en algo que un equipo puede medir objeto por objeto.

• Actualizaciones predecibles: las extensiones que solo usan API liberadas siguen funcionando entre releases, lo que reduce las pruebas de regresión y los proyectos de actualización.
• Compatibilidad con la nube: las mismas reglas se aplican en SAP S/4HANA Cloud Public Edition, de modo que un equipo on-premise que las sigue mantiene abiertas sus opciones.
• Una escalera de decisión compartida: primero el estándar, luego la extensibilidad key user, luego la extensibilidad de desarrollador y luego side-by-side, lo que da a arquitectos y consultores un lenguaje común.
• Medibilidad: las comprobaciones de ABAP Test Cockpit y la clasificación por niveles hacen visible el avance en lugar de anecdótico.
• Menor coste a largo plazo: menos modificaciones significan menos ajustes en los cambios de support package y de release.

Para cualquier organización que quiera mantenerse en releases actuales de SAP, clean core es la política de extensiones que las propias herramientas y la guía de SAP están diseñadas para respaldar.

• No decide qué construir. Clean core gobierna cómo depende una extensión de SAP, no si merece la pena construir el requisito que hay detrás.
• Desplaza la complejidad en lugar de eliminarla. Una extensión side-by-side es clean para el núcleo, pero añade integración, identidad, supervisión y un segundo ciclo de vida.
• La cobertura de API es desigual. Donde no existe una API liberada, los equipos recurren al nivel C o esperan, y esa brecha es una queja frecuente en las comunidades de profesionales.
• El código heredado lleva años. Las grandes bases de código de la época de ECC avanzan nivel a nivel; la medición muestra la distancia, no el camino.
• La responsabilidad queda fuera del alcance. Una extensión puede ser perfectamente clean y aun así carecer de responsable, de documentación o de un vínculo con el proceso al que da soporte.

Clean core mantiene el ERP actualizable; la responsabilidad, el diseño de procesos y el coste del landscape que lo rodea siguen siendo cuestiones aparte.

Recorra esta escalera de arriba abajo y deténgase en la primera opción que cumpla el requisito:

1. Estándar o configuración. ¿Puede cubrirlo un ajuste, un business role o una aplicación suministrada?
2. Extensibilidad key user. ¿Es un campo personalizado, una comprobación, un valor por defecto o una adaptación de UI? La necesidad de Alder Manufacturing de un campo de valoración del proveedor en los pedidos de compra termina aquí.
3. Extensibilidad de desarrollador. ¿Necesita ABAP personalizado cerca de los datos y las transacciones de SAP S/4HANA? Constrúyalo con ABAP Cloud on-stack.
4. Side-by-side en SAP BTP. ¿Da servicio a usuarios externos, combina varios sistemas o necesita su propio ciclo de vida? Un portal de autoservicio para Cedar Office Supply pertenece a este nivel.
5. Extensión clásica. Solo con una excepción documentada, un responsable y un plan para subir de nivel.

La decisión de clean core se toma por requisito, y el motivo de cada elección debe registrarse donde los arquitectos puedan encontrarlo más adelante.

1. Tratarlo como una limpieza puntual. Sin comprobaciones en el proceso de desarrollo, aparecen nuevos objetos de nivel C y D después de que termine el proyecto.
2. Prohibir el nivel C por completo. Algunos requisitos aún no tienen una API liberada; un objeto de nivel C supervisado puede ser la elección honesta.
3. Contar objetos en lugar de riesgo. Una modificación en una rutina central de contabilización pesa más que muchos reports sin uso.
4. Trasladarlo todo a SAP BTP. Side-by-side no es automáticamente más clean si la extensión sigue necesitando interfaces no liberadas.
5. Olvidar la capa de UI. Las aplicaciones SAP Fiori copiadas y modificadas conllevan su propio riesgo en las actualizaciones; los mecanismos de extensión de UI de SAP, como los adaptation projects, son la vía más segura.

La mayoría de los fracasos de clean core son fallos de gobierno que se manifiestan más tarde como esfuerzo de actualización.