Transformación hacia Clean Core · 6 de 8
Gobierno de extensiones SAP: cómo evitar volver al punto de partida
En resumen
El gobierno de extensiones es el conjunto de reglas que determina quién decide si algo se desarrolla, bajo qué criterio y quién responde de su ciclo de vida. Sin él, una limpieza de core es un esfuerzo puntual que se revierte en unos dieciocho meses, porque el proceso que generó la complejidad original sigue intacto.
Una organización puede hacer un esfuerzo enorme, retirar cientos de objetos Z y dejar el core limpio. Dieciocho meses después el problema ha vuelto.
No es falta de disciplina. Es que se cambió el resultado sin cambiar el proceso que lo producía.
Qué es realmente el gobierno de extensiones
Es el conjunto de reglas que determinan quién decide si algo se desarrolla, bajo qué criterio, dónde queda registrado y quién responde de ello a lo largo del tiempo.
Nada de esto es tecnología. Por eso suele ser lo último que se aborda y lo primero que falla.
Los cuatro elementos mínimos
1. Criterio publicado
Antes que un comité, hace falta un criterio escrito: el árbol de decisión de extensibilidad convertido en política interna.
Un criterio publicado resuelve la mayoría de los casos sin que nadie tenga que reunirse. Ese es su valor principal, y por eso va primero.
2. Evaluación previa
Toda extensión nueva debe responder por escrito, antes de construirse:
- ¿Qué necesidad de negocio la justifica?
- ¿Qué escalones del árbol se descartaron y por qué?
- ¿Qué APIs va a consumir y con qué garantía de estabilidad?
- ¿Quién responde de ella dentro de tres años?
- ¿Cuándo se revisa si sigue siendo necesaria?
Cinco preguntas. La mayoría se responden en una página. Su función no es burocrática: es que la justificación exista cuando dentro de cinco años alguien pregunte si se puede retirar.
3. Catálogo
Un registro de qué existe, para qué, qué consume y de quién depende.
Sin catálogo ocurren tres cosas de forma sistemática. No se puede evaluar el impacto de una actualización, porque nadie sabe qué depende de qué. No se puede retirar nada, porque nadie está seguro de si algo lo usa. Y cada proyecto nuevo reconstruye lo que ya existe, porque nadie sabe que existe.
El catálogo no tiene que ser una herramienta cara. Tiene que estar actualizado, que es lo difícil. La única forma de conseguirlo es que registrar la extensión sea parte del proceso de despliegue, no una tarea posterior.
4. Ciclo de vida
Cada extensión necesita fecha de revisión. Sin ella, todas son permanentes por omisión.
La revisión periódica formula una sola pregunta: ¿esto sigue siendo necesario, o el estándar ya lo cubre? La segunda parte importa especialmente: SAP publica funcionalidad continuamente, y parte de lo que se construyó hace tres años hoy viene incluido.
El comité: cuándo hace falta y cuándo estorba
Un comité de arquitectura tiene sentido cuando existe criterio publicado y su función es resolver los casos que el criterio no cubre.
Se convierte en un problema cuando es lo único que hay. Si cada decisión debe pasar por él, se forma cola, los proyectos presionan y el comité acaba aprobando por agotamiento. Peor aún: los equipos aprenden a presentar las cosas de forma que pasen, en lugar de a decidir bien.
La proporción sana es que la inmensa mayoría de los casos se resuelvan aplicando el criterio, y solo lleguen al comité las excepciones reales.
La objeción previsible
«Esto ralentiza los proyectos.»
Ralentiza la decisión inicial. Acelera todo lo demás. El coste real de una extensión no está en construirla, sino en mantenerla durante los años en que nadie recuerda por qué existe, en las pruebas de regresión que arrastra a cada actualización y en el proyecto que se complica porque hay que rodearla.
Una evaluación previa de dos días frente a cinco años de mantenimiento no necesita defensa económica.
Cómo empezar sin montar una estructura
Si hoy no hay nada, tres pasos en este orden:
- Publicar el criterio. Una página con el árbol de decisión y las cinco preguntas de la evaluación previa.
- Levantar el catálogo de lo que ya existe. Aunque sea incompleto. Un catálogo imperfecto es infinitamente mejor que ninguno.
- Exigir la evaluación solo a lo nuevo. No intentes regularizar el pasado antes de dejar de generar futuro.
En una frase
No basta con cambiar la tecnología: hay que cambiar quién decide y con qué criterio, o el sistema volverá al punto de partida por sí solo.
Diseñamos modelos de gobierno de plataforma y extensiones. Ver Gobernanza BTP o reservar una sesión.