El pasado 26 de abril de 2026, SAP publicó su nueva política de APIs: SAP API Policy
En realidad, antes de ese día, ya había gente comentando en redes lo que venía:
A primera vista puede parecer un cambio técnico más, una actualización de normas, algo que afecta a integraciones y poco más, pero no es así.
Lo que SAP ha hecho es mucho más relevante: ha dado el (pen)último paso en una estrategia que empezó hace más de una década.
Y si no se entiende esa historia, no se entiende lo que está pasando ahora; vamos paso a paso…
🟩 2010: SAP HANA
Cuando SAP lanzó HANA, no estaba sacando solo una base de datos en memoria, estaba lanzando la base para una nueva plataforma, con múltiples capacidades: almacenamiento columnar, compresión avanzada…
Algo que después fueron haciendo otros fabricantes; mientras SAP empezó a probar sus productos sobre esa base datos: primero SAP BW, después el ERP…
Una vez pasadas esas validaciones, empezamos a ver los primeros brotes de S/4HANA, con SAP Simple Finance.
💡 «Si quiero aprovechar la potencia de HANA, lo mismo tengo que hacer las cosas de otra forma…»
🟩 2012: HCP → SCP → SAP Business Technology Platform (BTP)
El mundo está como loco con el «cloud» y si quiero hacer algo con mi flamante HANA, debería tener una plataforma propia… lo tengo: HANA Cloud Platform (HCP).
Vamos a diseñar una infraestructura en mis propios centros de datos y ya tengo otra fuente de ingresos.
Uy, resulta que esto de la infraestructura no es tan sencillo y el mundo va por otro lado, con una cosa que se llama Cloud Foundry; bueno, no pasa nada, me apunto también a eso.
Eso sí, no dejo lo que tenía y, además, «lo viejo» lo llamo Neo, para que la gente se líe más… ya me lo cargaré dentro de unos años.
Resulta que hay por ahí unos señores (AWS, Azure, Google) que dicen que saben más que yo de infraestructura… tendré que hablar con ellos.
Además, como a la gente lo de HANA le suena a caro, le quito la «h» y paso a llamarlo SCP (SAP Cloud Platform), hasta que me doy cuenta de que la gente de marketing también tiene derecho a comer y le vuelvo a cambiar el nombre a Business Technology Platform (BTP).
💡 «Vale, no puedo hacerlo todo solo; aunque seguro que hay forma de meterle mano a esto…»
🟩 2013: SAP HANA Enterprise Cloud (HEC)
Me ha quedado claro que hay gente que sabe más que yo a la hora de gestionar una plataforma de servicios (PaaS), pero no van a saber más que yo de gestionar mi software, ¿no?
Vamos a convencer a los clientes de que se olviden de sus «obsoletos» centros de datos y les alojo yo el software, aparte de darles una serie de servicios asociados.
💡 «Mmm… va a ser que esto de gestionar infraestructura no va a ser tan sencillo como pensábamos…»
🟩 2015: S/4HANA
Dejemos de lado el hierro, por un tiempo, y vamos a volcarnos en el software.
Una vez chequeado que HANA podía funcionar como base de datos en los productos (BW, ERP, Simple Finance…) vamos a dar el siguiente paso.
Dado que tenemos una base de datos en memoria (como otros fabricantes, a estas alturas), vamos a reescribir el producto para aprovechar las capacidades de ESA base de datos; no de las bases de datos en memoria, de ESA.
Decisión clave: S/4HANA sólo puede correr sobre una base de datos HANA.
💡 «¿Por qué le vas a dar dinero por tu base de datos a otro, cuando me lo puedes dar a mí?».
🟩 2021: HEC → RISE with SAP → Cloud ERP
Ya tenemos las aplicaciones, tenemos la base de datos, una plataforma… pero me queda la espinita de la infraestructura.
Tengo claro que no puedo competir contra los hyperscalers, pero… algo me tengo que inventar para «elevar» a la gente a la nube y hacerla «crecer».
Vamos a darle a la manivela de los «palabros» y… RISE y GROW aparecen en nuestras vidas.
💡 «No puedo poner la infraestructura, pero sí te puedo poner un peaje, disfrazado de una serie de servicios, para pillar parte de este pastel».
🟩 2023: SAP Joule
La gente anda loca con eso de la IA y una cosa que se llama ChatGPT, algo tendremos que hacer.
A alguien se le ocurre mencionar la palabra prohibida «Leonardo»… es despedido fulminantemente.
💡 «No sabemos lo que es, pero poner Joule en todas las presentaciones de producto, ya vamos viendo».
🟩 2025: SAP Business Data Cloud
Aplicaciones, base de datos, algo de la infra, IA… ¡necesitamos controlar los datos!
Sí, tenemos parte, pero hay gente que tiene la poca vergüenza de almacenar datos en otros sitios, vamos a sacar algo que nos permita tener controlado todos los datos.
Y aquí aparece SAP Business Data Cloud.
💡 «Datos estructurados, no estructurados y medio pensionistas, si quieres, pero ya te los guardo yo, que luego tú no sabes dónde pones las cosas».
🟩 2026: API Policy
La gente está loca, se ha puesto a crear cosas, para acceder a SU información, desde herramientas que no son mías, con lo peligroso que es eso… y lo poco rentable que es para mí 😉
¿Por qué no utilizan mis herramientas? Bueno, no son las mejores pero lo serán.
¿Qué no son las más baratas? ¿Cómo lo sabes, si es imposible saber lo que te va a costar?
💡 «Mira, mientras solucionamos esos detallitos, vamos a poner un peaje, para que tengan que pasar por nosotros, sí o sí».
🧠 Resumen
La cosa está así:
- SAP controla la base de datos (HANA)
- SAP controla las aplicaciones (S/4HANA)
- SAP controla la plataforma (BTP)
- SAP controla la infraestructura (RISE / Cloud ERP)
- SAP controla los datos (BDC)
- SAP controla el acceso (APIs /Joule)
No es casualidad.
⚖️ ¿Es bueno o malo?
Depende de cómo se mire.
👍 Ventajas
- Mayor estabilidad.
- Integraciones soportadas.
- Menos “inventos” difíciles de mantener.
👎 Inconvenientes
- Pérdida de flexibilidad.
- Dependencia total de SAP.
- Costes (tiempo, migraciones, rediseño…)
Esto no va sólo de APIs, es el cierre de un ciclo:
- Primero controló dónde viven los datos.
- Luego cómo se procesan.
- Después dónde se ejecutan los sistemas.
- Y ahora controla cómo puedes acceder a todo eso.
Es una estrategia perfectamente coherente, de una empresa que, como la mayoría, lo que quiere principalmente es ganar dinero.
Ahora sólo falta ver si los clientes, que creo que también quieren ganar dinero, están dispuestos a pasar por el aro… 😉
PD.- Amenazo (desde hace más de un año) con lanzar una newsletter; si quieres apuntarte, aquí te dejo el enlace: No Lo Sabemos Todo.
Platicando con un compatriota Mexicano/Canadiense, que vive y trabaja en Canadá en tecnología (SalesForce); Me comentaba sobre como las empresas prefieren, por «seguridad» el NO migrar su ERP al 100% a la nube, con el temor de poder ser renes, ante una política imperialista de los principales proveedores de este servicio (AWS, Azure, IBM, etc.)
¿Donde alojarías la información de tu negocio? ….
Como consultor, podría ser una vulnerabilidad el depender de la nube para operar
Creo es la razón por la que la mayoría de las empresas optan por un modelo híbrido antes que un ONLINE y que decir de las empresas que utilizan el software como arma (Palantir)
Saludos y gracias por la refección