Catálogo de extensiones SAP: decidir una vez, no en cada ticket

Un analista de facturación pide un campo adicional para marcar las cuentas con reclamo abierto. El arquitecto de la utility tiene la sensación de haber tenido esa conversación hace unos meses, con otro campo y otro key user. Nadie recuerda qué se decidió ni por qué, y el debate vuelve a empezar: ¿alcanza con extender in-app o hay que ir a SAP BTP?

La pieza anterior de esta serie mostró el costo de forzar dentro del core lo que no cabe ahí. Esta cierra el arco con la capa que evita repetir el error en cualquiera de las dos direcciones: un catálogo vivo de decisiones de extensibilidad.

El debate que se repite es un problema de memoria, no de criterio

En nuestra práctica SAP vemos que muchos equipos de utilities en América Latina ya tienen algún criterio para decidir dónde construir una extensión. Lo que suele faltar es el registro de cómo se aplicó ese criterio en cada caso.

La guía de arquitectura de Microsoft lo formula sin rodeos: una decisión tomada pero nunca registrada probablemente se olvide, y eso lleva a debates repetidos o a cambios que contradicen sin saberlo la intención original (Microsoft Azure Well-Architected Framework, 2026). Google Cloud agrega que un registro de decisiones ayuda a evitar la repetición de los mismos puntos de discusión y da contexto histórico cuando el equipo retoma un tema (Google Cloud Architecture Center, 2024).

En una utility, el costo de esa amnesia no es solo tiempo de reunión. Es inconsistencia: la misma necesidad termina resuelta in-app en facturación y side-by-side en reclamos, sin una razón que alguien pueda explicar. La propia SAP señala que muchos entornos ERP terminan cargados de código a medida, cambios no documentados e integraciones difíciles de mantener (SAP News Center, 2025).

Lo que recomiendan SAP y el mercado

SAP ya entregó el vocabulario. Su concepto de niveles clasifica las extensiones en cuatro niveles (A, B, C y D) según integridad arquitectónica, seguridad ante upgrades y alineación con el clean core (SAP News Center, 2025). Asignar un nivel a cada extensión da a TI, arquitectura y negocio un vocabulario compartido para decidir con transparencia dónde invertir (SAP News Center, 2025). Para elegir entre on-stack y side-by-side, SAP pide decidir según el caso de uso y con una estrategia BTP-first (SAP News Center, 2025).

Lo que falta es convertir esa clasificación en memoria institucional. IgniteSAP describe el hábito concreto: documentar cada decisión de extensión en el momento en que se toma, con las alternativas evaluadas, el nivel asignado y el plan de remediación para todo lo que quede por encima del nivel B (IgniteSAP, 2026). El mismo análisis observa un efecto cultural: cuando los desarrolladores saben que cada decisión quedará registrada con su clasificación y su justificación, la discusión sobre el nivel correcto ocurre antes y con más rigor (IgniteSAP, 2026). Y ubica al dueño: donde existe un Centro de Excelencia SAP, es este el que gestiona el catálogo de decisiones de extensión (IgniteSAP, 2026).

Fuera del mundo SAP, la industria llama a esta práctica registro de decisiones de arquitectura (ADR). El catálogo de extensiones es, en esencia, un ADR aplicado a la extensibilidad.

Anatomía de una entrada útil

Una entrada que sirva dentro de dos años necesita más que un «se hizo en BTP». Nuestra práctica SAP recomienda estos campos como mínimo:

• Requerimiento y proceso. Qué pidió el negocio y en qué proceso vive: facturación, reclamos o mantenimiento.
• Opciones evaluadas, incluido el estándar. Qué alternativas se descartaron y por qué. Microsoft pide documentar también las opciones que se descartaron (Microsoft Azure Well-Architected Framework, 2026).
• Decisión y nivel. Dónde se construyó (in-app, on-stack o side-by-side) y en qué nivel A-D quedó clasificada.
• Criterio determinante. La razón que inclinó la balanza: acoplamiento al proceso, integración con terceros o ciclo de despliegue propio.
• Nivel de confianza. Microsoft recomienda registrarlo, porque una decisión tomada con baja confianza es candidata natural a revisión (Microsoft Azure Well-Architected Framework, 2026).
• Estado. Estados como Propuesta, Aceptada o Reemplazada hacen visible qué decisión rige hoy (Microsoft Azure Well-Architected Framework, 2026).
• Disparadores de revisión y vínculos. Qué evento obligaría a reabrirla, y qué transportes y exenciones de ABAP Test Cockpit dependen de ella.

Del caso aislado al precedente

---
config:
  theme: base
  fontFamily: 'Inter Variable, system-ui, sans-serif'
  themeVariables:
    darkMode: true
    fontFamily: 'Inter Variable, system-ui, sans-serif'
    fontSize: '15px'
    background: '#111113'
    primaryColor: '#1A1A1D'
    primaryTextColor: '#F4F5F8'
    primaryBorderColor: '#B89C5C'
    secondaryColor: '#242428'
    tertiaryColor: '#1A1A1D'
    mainBkg: '#1A1A1D'
    secondBkg: '#242428'
    tertiaryBkg: '#2E2E33'
    lineColor: '#B89C5C'
    textColor: '#F4F5F8'
    titleColor: '#F4F5F8'
    nodeBorder: '#B89C5C'
    clusterBkg: '#1A1A1D'
    clusterBorder: '#2E2E33'
    edgeLabelBackground: '#242428'
    pie1: '#B89C5C'
    pie2: '#f59e0b'
    pie3: '#22c55e'
    pie4: '#d1bf95'
    pie5: '#f97316'
    pie6: '#ef4444'
    pieTitleTextColor: '#F4F5F8'
    pieSectionTextColor: '#F4F5F8'
    pieLegendTextColor: '#F4F5F8'
    pieStrokeColor: '#111113'
    pieOuterStrokeColor: '#111113'
---
flowchart TD
  A([Llega el requerimiento del key user]) --> B[Buscar precedente en el catálogo]
  B --> C{¿Precedente vigente?}
  C -->|Sí| D[Aplicar la misma decisión]
  D --> E[Referenciar la entrada existente]
  C -->|No| F[Evaluar opciones y decidir]
  F --> G[Registrar una entrada nueva]
  E --> H{¿Ocurre un disparador?}
  G --> H
  H -->|Sí| I[Nueva entrada enlazada que la reemplaza]
  I --> J([La anterior se conserva])
  H -->|No| K([Precedente vigente en el catálogo])
  class A inicio
  class C,H decision
  class B,D,E,F,G,I proceso
  class J,K bueno
classDef inicio fill:#3a352b,stroke:#B89C5C,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef bueno fill:#193e2b,stroke:#22c55e,color:#ffffff

El valor del catálogo aparece con la segunda solicitud parecida. Cada entrada funciona como un precedente: antes de abrir el debate, el equipo busca si ya existe una decisión para un requerimiento equivalente.

Con el tiempo emergen patrones por proceso. Una validación transaccional estrechamente acoplada al proceso tiende a resolverse on-stack, mientras que las aplicaciones más grandes, la automatización de flujos o todo lo que tenga un ciclo de despliegue independiente tiende a ir side-by-side en BTP (IgniteSAP, 2026). Un flujo de reclamos que coordina canales externos, por ejemplo, encaja en el segundo grupo. El catálogo convierte esas tendencias en reglas locales verificables, no en opiniones de quien esté en la reunión.

Cuándo una decisión vieja deja de valer

Un catálogo que nunca se revisa se vuelve tan peligroso como no tenerlo. Muchos requerimientos que hace cinco años justificaban código a medida hoy los cubre el estándar (IgniteSAP, 2026), y el ritmo con que SAP libera nuevas APIs se aceleró como parte del programa clean core (IgniteSAP, 2026). Cuando no existe una API liberada, cualquier solución interina de nivel C debe tratarse como temporal (IgniteSAP, 2026).

Por eso cada entrada necesita disparadores explícitos, no solo una fecha de revisión en el calendario:

• un nuevo release de S/4HANA;
• la liberación de una API que antes faltaba;
• un cambio de modelo operativo;
• un cambio relevante en el volumen o en las integraciones del proceso.

Cuando la decisión cambia, no se edita: se escribe una nueva entrada que reemplaza a la original y se enlazan ambas (Microsoft Azure Well-Architected Framework, 2026). Google Cloud recomienda además dejar constancia de la decisión previa y del motivo del cambio (Google Cloud Architecture Center, 2024).

El catálogo también detecta la deriva. Un registro de exenciones de ABAP Test Cockpit que crece sin revisión es uno de los indicadores tempranos más claros de deriva de gobierno (IgniteSAP, 2026). Una exención sin entrada de catálogo que la respalde es una señal de alerta inmediata.

Por dónde empezar sin crear burocracia

Para una utility con IS-U heredado, el punto de partida no es una hoja en blanco. Microsoft indica que el registro de decisiones debe iniciarse también en cargas brownfield y generarse de forma retroactiva a partir de las decisiones pasadas conocidas (Microsoft Azure Well-Architected Framework, 2026). La semilla natural son las últimas solicitudes de facturación, reclamos y mantenimiento que ya pasaron por el debate in-app versus side-by-side.

El catálogo no es un producto que haya que licenciar: es una práctica. Puede vivir en una wiki central accesible también para los dueños de negocio (Google Cloud Architecture Center, 2024). El dueño es el Centro de Excelencia donde exista, o quien ya aprueba las excepciones donde no lo haya.

La regla que lo mantiene vivo es sencilla: cada transporte debe llevar un vínculo al requerimiento de origen en la herramienta de gestión de cambios (IgniteSAP, 2026). Nuestra práctica SAP extiende esa regla a la entrada del catálogo que justifica la extensión.

EvoTech Consulting acompaña a utilities y empresas de oil & gas de LATAM en ese paso: sembrar el catálogo con las decisiones existentes, definir sus campos y disparadores, y conectarlo con el gobierno del core que ya opera.

Fuentes

• Microsoft. «Maintain an architecture decision record (ADR)». Azure Well-Architected Framework, 2026. https://learn.microsoft.com/en-us/azure/well-architected/architect-role/architecture-decision-record
• Google Cloud. «Architecture decision records overview». Cloud Architecture Center, 2024. https://docs.cloud.google.com/architecture/architecture-decision-records
• Hois, R.; Panda, P.; Pietsch, S. «Discover How to Extend SAP S/4HANA Cloud the Right Way». SAP News Center, 2025. https://news.sap.com/2025/08/extend-sap-s4hana-cloud-right-way-clean-clear/
• Macaulay, A. «SAP’s Clean Core in Practice». IgniteSAP, 2026. https://ignitesap.com/saps-clean-core-in-practice/