No es momento de descubrir el valor que ofrecen los datos en los actuales modelos de negocio, eminentemente digitales. Más bien me gustaría poner el foco en el cambio de papel que están viviendo las instalaciones SAP de las empresas, que, en muchos casos, se han convertido en una fuente de datos adicional —de información transaccional— con la que alimentar los nuevos data lakes empresariales.

Me gustaría empezar esta reflexión con una conversación que tuve hace años con alguien de SAP al que tengo en gran estima, tanto en lo personal como en su capacidad casi profética de lanzar predicciones tecnológicas que, de alguna manera, acaben cumpliéndose.

Estábamos hablando de programación y me transmitió la creencia de que existe ya una nueva generación de desarrolladores para los que SAP es solo otro legacy más.

No es que esto fuera un vaticinio en sí mismo, ya que por aquel entonces ya empezaba a escucharse el termino full-stack developer: básicamente, un programador que está capacitado para manejar tanto el desarrollo de front-end como de back-end (lógica y base de datos) de aplicaciones web y móviles, integrando múltiples tecnologías y herramientas.

Para ellos, SAP es solo otra fuente de datos adicional, otro granero desde donde poder cosechar su materia prima

El caso es que más allá de lo clarividente —o no— de ese convencimiento, lo cierto es que me hizo reflexionar sobre el hecho de que existía todo un mundo fuera de SAP que está habitado por un ingente número de profesionales para los que SAP es algo parecido a lo que para mí es un AS/400; y yo sería para ellos poco más que un dinosaurio, similar a lo que para mí era es un programador RPG.

Silo de datos

Pero dejemos el mundo del desarrollo a un lado y establezcamos un paralelismo con todo lo que tiene que ver con los datos. La sentencia de mi amigo bien podría trasladarse a este contexto, lo que nos llevaría a asegurar que hay una nueva generación de profesionales del dato (científicos, analistas, ingenieros…) para los que SAP es poco más que otro silo adicional, una fuente desde la que poder obtener algunos de los datos que necesitan.

De hecho, de un tiempo a esta parte existe un creciente interés por todo lo relacionado con la extracción del dato desde diferentes orígenes. Prueba de ello son las múltiples sesiones técnicas que se organizan para tratar este tema.

En estas sesiones me he encontrado con peticiones de todo tipo, algunas de ellas van desde algo que se podría considerar como inverosímil (“quiero extraer los datos del SAP”, basado en hechos reales), a otras que se encuentran más cercanas a la realidad: “quiero recolectar los datos de los pedidos de venta de SAP”.

Pero, más allá de todo esto, la conclusión que deberíamos sacar de todas estas peticiones es la necesidad que tienen todo ellos de acceder a los datos; ese es su dominio. Poco les importa el mecanismo utilizado para generarlo, ya sean transacciones SD (Sales and Distribution) que provengan de un SAP ECC, la información de sensores IoT proveniente de una línea de almacén, historiales de navegación de un portal… lo que sea. Ellos van al producto final, al crudo y frio dato.

Teniendo en cuenta esta premisa, para ellos SAP solo es otra fuente de datos adicional, otro granero desde donde poder cosechar la materia prima que necesitan para hacer su esotérico trabajo. Nota: si a alguien no le parece magia lo que hacen, que busque información de modelos de ensamblaje, algoritmos genéticos o redes bayesianas.

Información heterogénea

Una vez recolectada la información desde SAP, esta se guarda en almacenes de datos que son altamente escalables, superelásticos, hiperdisponibles y omniaccesibles desde cualquier lugar y dispositivo. Almacenes que soportan una gran variedad de tipos de datos, ya sean estructurados, semiestructurados o desestructurados, que van desde las tradicionales bases de datos relacionales (RDBMS) a otras de tipo NoSQL de documentos JSON, pasando por almacenes columnares, bases de datos de grafos, de almacenamiento de objetos, time series, sistemas de archivos distribuidos, etc.

Una vez recolectada la información desde SAP, esta se guarda en almacenes que soportan una gran variedad de tipos de datos

Toda esta lista —que no es exhaustiva— permite ejemplificar la heterogeneidad de información que puede convivir en las soluciones de data que inundan el mercado, y en las que el dato transaccional de SAP, aunque importante, es solo uno más. Además, se trata de un dato que ya no se encuentra en un coto privado —el de los usuarios SAP— y que también está sometido a esa tendencia emergente llamada democratización del dato.

El objetivo de este artículo no pasa por centrarse en las ventajas que ofrece la posibilidad de mezclar datos de SAP con los procedentes de otras fuentes. Hay muchos ejemplos, y más que van apareciendo cada día gracias al impulso que supone la incorporación de nuevas fuentes de datos, así como a la inagotable creatividad del sector de la analítica de datos.

Licenciamiento y cumplimiento

Más bien dirijamos nuestra atención en las dificultades comunes que aparecen a la hora de extraer los datos de los sistemas SAP. Por un lado, las inmediatas son de índole técnica: complejidad de la solución, escalabilidad, trazabilidad, monitorización o coste de mantenimiento suelen aparecer como principales barreras a la hora de recolectar datos de un sistema SAP.

Existen otros obstáculos —en ocasiones más limitantes— a la hora de alimentar con datos de SAP a nuestros flamantes data lakes de última generación. Me refiero principalmente a los relacionados con el licenciamiento o el cumplimiento normativo. Sobre este aspecto, SAP puede cambiar —sin mucho aviso— su política de accesos y uso de determinados frameworks de comunicación y dejar en fuera de juego a partners, fabricantes y, en última instancia, también a los clientes.

Por ejemplo, a finales del tercer trimestre de 2024 SAP liberó la nota 3255746 que comienza con un categórico “The usage of RFC modules of the Operational Data Provisioning (ODP) Data Replication API by customer, or third-party applications to access SAP ABAP sources (On-Premise or Cloud Private Edition) is NOT permitted by SAP”.

Este tema es particularmente espinoso; primero, porque la elección de una herramienta de extracción de datos conlleva tiempo y trabajo; y, peor aún, en muchos casos condiciona en gran medida la arquitectura general de las soluciones que, de la mañana a la noche, pueden pasar de ser válidas a ilegales.

Sobre el cumplimiento normativo, también es importante remarcar que determinados datos tienen una protección especial

Sobre el cumplimiento normativo, también es importante remarcar que determinados datos tienen, por su naturaleza, una protección especial: por ejemplo, financieros, crediticios, personales, etc. El acceso a esos datos en SAP se realiza mediante la capa de aplicación pertinente, que proporciona las herramientas necesarias para implementar el correcto acceso a esta información.

Hay que tener en cuenta que, si los extraemos y publicamos alegremente en un almacén externo, el frio dato puede llegar a convertirse en un tema muy caliente. Es, por tanto, necesario tener estas consideraciones a la hora salvaguardar estos datos fuera del origen para el que fueron diseñados.

En cualquier caso, ninguna de estas consideraciones va a evitar que los datos de SAP salgan de SAP. La realidad tecnológica en la que se mueven las empresas se ha convertido en un monstruo voraz, que necesita cantidades gigantescas de datos que provienen de múltiples fuentes, formatos y soportes. SAP es solo otro silo más de donde capturar esos datos.