Clean core: por qué la disciplina de arquitectura se ha convertido en un asunto de dirección general.

El principio cabe en una frase. En un sistema limpio, el núcleo se mantiene conforme al estándar del fabricante; todo lo que la empresa añade vive al lado, en plataformas de extensión previstas para ello, detrás de interfaces documentadas. SAP lo ha convertido en la doctrina oficial de S/4HANA y de RISE, y sería un error ver en ello solo un argumento de venta: la promesa de actualizaciones regulares solo se sostiene si nadie ha soldado el núcleo desde dentro. Pero la verdadera razón para interesarse por el tema no está en el fabricante. Está en sus cuentas.

Cada desarrollo a medida es una deuda

Un desarrollo a medida nace siempre de una buena intención. Un proceso que se atasca, una pantalla mal resuelta, una petición del negocio que se quiere atender rápido: unos días de desarrollo y asunto zanjado. En el momento de programarlo, un desarrollo a medida parece casi gratuito. Es después cuando empieza a costar.

Cuesta en cada subida de versión: todo lo que toca el núcleo debe analizarse, adaptarse y volver a probarse, y la factura se repite mientras el código viva. En un mundo RISE, donde el fabricante lanza sus actualizaciones a su propio ritmo, esa carga deja de ser un acontecimiento cada cinco años para convertirse en un peaje recurrente. Cuesta en innovación: las capacidades que SAP entrega, la IA integrada en primer lugar, se apoyan en los procesos y en las estructuras de datos estándar; un núcleo plagado de excepciones las ve pasar de largo. Y cuesta, por último, en dependencia: con los años, el conocimiento de un desarrollo a medida se concentra en dos o tres cabezas, y el día en que se van, la empresa descubre que ya no sabe explicar su propio sistema.

Ninguno de esos costos figuraba en el presupuesto del desarrollo inicial. Ahí está toda la dificultad del asunto: el gasto es visible y modesto, la deuda es invisible y larga. Una dirección general que la ignore la pagará igualmente.

La prueba: un diferenciador demostrado, o el estándar

¿Hay que prohibir entonces el desarrollo a medida? No, y los integristas del todo estándar se equivocan tanto como los demás. Algunos procesos ganan clientes, márgenes o días de tesorería precisamente porque no se parecen a los del vecino. Esos merecen defenderse, desarrollarse limpiamente fuera del núcleo y mantenerse como activos.

Todo está en el criterio. El nuestro es fácil de enunciar e incómodo de aplicar: un desarrollo a medida se justifica si el proceso que sostiene es un diferenciador de negocio demostrable. Demostrable, no intuido: ¿quién puede decir qué perdería la empresa, en concreto, al pasar al estándar? Si nadie sabe responder, la respuesta es el estándar, y es el proceso el que se adapta. Nuestra experiencia con los inventarios de desarrollos a medida es constante en este punto: la gran mayoría suspende la prueba. Reproducen una costumbre, rara vez una ventaja.

La buena pregunta no es «¿qué hace este desarrollo?», sino «¿qué valdría la empresa sin él?». Si la respuesta es «lo mismo», no pinta nada en el núcleo.

Lo que la disciplina exige del gobierno

Un criterio no basta; hace falta alguien que lo sostenga. Aquí es donde el asunto abandona definitivamente la esfera técnica, porque sostener un criterio es decir que no. No a un director de negocio con prisa, no a un proyecto que ya ha prometido, no a la solución fácil que volvería a abrir el núcleo. Una autoridad de arquitectura que no pueda apoyarse en la dirección general cederá. Con educación, y sistemáticamente.

El gobierno que funciona descansa en tres prácticas, que encontramos en todos los que perduran. Una instancia de decisión donde el negocio acude a defender su petición, con la prueba del diferenciador como regla del juego anunciada de antemano. Un registro de excepciones, después: cada desarrollo aceptado queda inscrito con su propietario, su justificación y su fecha de revisión, porque una deuda se gestiona mal cuando no se lleva su contabilidad. Y una revisión en cada subida de versión, por último: un desarrollo debe ganarse de nuevo su sitio en cada cita, o sale. Sin ese encuentro periódico, la deriva vuelve en pocos años, por acumulación de pequeñas excepciones, todas razonables una a una.

2027, la purga que no volverá a pasar

Queda el calendario, y es él quien da urgencia al asunto. El fin del mantenimiento mainstream de ECC, fijado para finales de 2027 con una extensión posible hasta 2030, impone a cada empresa el paso a S/4HANA. Y una conversión es el único momento en que purgar cuesta menos que conservar: de todos modos hay que inventariar, analizar y volver a probar cada desarrollo. Cribar en esa ocasión es un esfuerzo marginal; llevárselo todo es convertir la deuda al mismo tiempo que el sistema, y pagarla durante diez años más. La ocasión no volverá a presentarse al precio de 2027.

Por eso defendemos que la doctrina del desarrollo a medida se fije desde el encuadre, antes de elegir escenario e integrador, en lugar de descubrirse a mitad de programa, cuando cada arbitraje retrasa un hito. La empresa que llega a la negociación con sus reglas del juego, su registro y su lista de purga elige su programa. La otra lo padece.

Para seguir: nuestra lectura de la fecha límite de 2027, nuestra oferta S/4HANA y nuestro enfoque de la transformación SAP, donde esta disciplina se decide y se instrumenta.