ILM + ALM: el gobierno de datos que sostiene el TCO en S/4HANA

La modernización de integración también es una fábrica de datos

En los últimos años, utilities y operadores de oil & gas en América Latina han acelerado la adopción de arquitecturas orientadas a eventos: medición inteligente (AMI), IS-U, IoT en campo y capas de integración como SAP Integration Suite, advanced event mesh (una solución de event brokering más avanzada, que coexiste con SAP Event Mesh, la oferta estándar de SAP para escenarios más simples). En Colombia, por ejemplo, la CREG ha venido consolidando el marco regulatorio de la Infraestructura de Medición Avanzada desde la Resolución 40072 de 2018 del Ministerio de Minas y Energía, profundizado luego en la Resolución CREG 101 001 de 2022, empujando a los operadores de red hacia el despliegue masivo de medidores inteligentes.

Ese despliegue es una buena noticia operativa: más visibilidad, procesos de medición-a-caja (M2C) más ágiles, menos pérdidas no técnicas. Pero tiene una consecuencia que rara vez se discute en el mismo comité donde se aprueba el proyecto de integración: cada evento, cada lectura, cada reintento y cada mensaje correlacionado es un registro más que, tarde o temprano, termina persistido en la base de datos SAP HANA. Y esa huella no crece gratis.

De la huella HANA al TCO del contrato de infraestructura

El licenciamiento de SAP HANA está atado a la memoria: el modelo tradicional se factura por bloques de memoria, y el consumo de esos bloques crece directamente con el volumen de datos que la base retiene en caliente (SAP Licensing Experts, 2025). En modelos de suscripción como RISE with SAP, esa misma relación no desaparece, simplemente cambia de forma: la infraestructura, la base HANA y la plataforma BTP se empaquetan en un tier dimensionado según el volumen de usuarios y de datos contratado (FUE, t-shirt size), de modo que un crecimiento de datos no gobernado termina empujando al cliente hacia un tier superior en la renovación (SAP RISE Negotiations, 2025).

Para una utility o un operador oil & gas de la región, esto significa algo muy concreto: la inversión que se hizo para modernizar la integración (Event Mesh, AMI, IS-U) puede terminar, de forma silenciosa, encareciendo el contrato de infraestructura que la sostiene, si nadie gobierna cuánto tiempo ese dato permanece “caliente” en memoria.

El problema de fondo: eventos desordenados, sin trazabilidad ni control de reintentos

En los proyectos de integración M2C que hemos acompañado en la región, tres síntomas se repiten con frecuencia. Primero, eventos que llegan desordenados y rompen la secuencia esperada del proceso medición-a-caja. Segundo, ausencia de una correlación clara entre publicadores y suscriptores dentro del event mesh, lo que dificulta saber qué componente originó qué transacción. Tercero, tasas de reintento mal calibradas que, ante una falla puntual, generan verdaderas tormentas de eventos duplicados.

La respuesta técnica a esto ya es conocida: usar el event mesh como capa central de desacoplamiento entre el AMI Suite y el IS-U, configurar colas de mensajes muertos (DLQ) con prioridad obligatoria para el tráfico M2C, e implementar trazabilidad cross-domain mediante identificadores de correlación en cada evento.

Esto resuelve el desorden de la integración. Pero resuelve solo la mitad del problema: cada evento correlacionado y trazado con éxito es, también, un registro más que crecerá indefinidamente en memoria si nadie decide, de forma activa, cuánto tiempo debe vivir “caliente”.

ILM y ALM: la piedra angular que falta en la conversación

Aquí es donde entra la pieza que casi nunca acompaña los proyectos de integración: SAP Information Lifecycle Management (ILM) no es una tarea de archivado ocasional que se deja para después del go-live. Es, junto con Application Lifecycle Management (ALM), el gobierno que sostiene la operación en el tiempo.

ALM gobierna el ciclo de vida de la aplicación: upgrades, conversión de código, transporte de cambios. ILM gobierna el ciclo de vida del dato: retención, bloqueo, archivado y, eventualmente, destrucción conforme a reglas de negocio y regulación. Modernizar la integración con ALM sin gobernar el dato con ILM es ganar la batalla de la arquitectura y perder, poco a poco, el TCO que esa modernización buscaba proteger.

Es importante no confundir dos mecanismos que suelen mezclarse en la conversación técnica. La agregación por antigüedad (data aging) mueve el dato frío a una partición separada dentro de la misma tabla HANA: reduce la huella en memoria, pero el dato sigue viviendo en la base y accesible por SQL. El archivado vía ILM Store, en cambio, extrae ese dato hacia almacenamiento externo de menor costo, de solo lectura, y es la base del ciclo de vida completo del dato hasta su eventual destrucción (Proceed Group, 2018). El ILM Store reduce la huella en HANA precisamente porque habilita ese almacenamiento frío fuera del motor in-memory (SAP Blogs, 2019).

La pieza que completa el cuadro es evitar que ese dato envejecido quede “perdido” en un archivo ilegible. La tendencia documentada por SAP apunta a conectar el dato frío con arquitecturas de datos externas —como SAP HANA Cloud, data lake, integrado a través de SAP Datasphere— de modo que ese histórico siga disponible para analítica sin pagar el costo de memoria HANA por él (SAP Blogs, 2023). Para un operador LATAM, esto abre una puerta relevante: el dato de años de operación de medición o de mantenimiento no tiene que sacrificarse para bajar costos; puede reubicarse en un tier más económico y seguir siendo analizable.

Qué significa esto para utilities y oil & gas en la región

Con marcos regulatorios como el de CREG empujando el despliegue masivo de medición avanzada, y con procesos M2C cada vez más automatizados vía event mesh, el volumen de eventos que terminará persistido en HANA seguirá creciendo en los próximos años. La pregunta que un CIO o un CFO de una utility latinoamericana debería hacerse no es solo “¿cómo integramos mejor?”, sino “¿quién está decidiendo, de forma activa, cuánto tiempo vive cada dato en memoria antes de moverlo?”.

En nuestra práctica SAP, la recomendación es tratar ILM y ALM como parte del mismo programa de gobierno desde el diseño de la integración —no como un proyecto de limpieza que se aborda cuando la base ya duplicó su tamaño y la renovación del contrato de infraestructura ya está sobre la mesa.

Fuentes

• SAP Licensing Experts (2025). SAP HANA Memory-Based Licensing and Sizing.
• SAP RISE Negotiations (2025). RISE with SAP and SAP Private Cloud License Models and Costs.
• Proceed Group (2018). What is the difference between Archiving and Data Aging in SAP S/4HANA?
• SAP Blogs (2019). Recommended Data Tiering Approaches for SAP and Native Applications.
• SAP Blogs (2023). Working with the Standalone SAP HANA Cloud Data Lake in SAP Datasphere.
• Ministerio de Minas y Energía (2018). Resolución 40072, mecanismos para implementar la Infraestructura de Medición Avanzada.
• CREG (2022). Resolución 101 001, condiciones para la implementación de la Infraestructura de Medición Avanzada.