Migración a la integración en la nube: ¿Es ahora el momento?
Hace casi dos años y medio, me sentaba delante de una página en blanco para escribir un blog sobre si era el momento adecuado para iniciar la migración a la integración en la nube; en aquel momento se trataba de la integración en la plataforma en la nube (CPI).
Cuando releí aquel artículo, me di cuenta de que muchas cosas han cambiado, pero también de que algunos problemas detectados entonces no se abordaron adecuadamente. (Consulte el artículo aquí)
En su día, me entusiasmaba emprender proyectos de integración en la nube porque tenía sentimientos encontrados con mis experiencias con SAP Cloud Integration. Echaba de menos muchas cosas que tenía en SAP PI/PO, pero veía otras posibilidades de integraciones orquestadas que no tenemos con SAP PI/PO. Tenía ganas de decir: “es hora de pasar a la nube”.” Pero no fue...
Allá por enero de 2021, en medio de una pandemia de COVID que parecía no tener fin, tenía muchas expectativas puestas en la evolución de la herramienta SAP Cloud Integration, algunas de ellas son ahora una realidad y otras...
A mí, como consultor de integración de alto nivel, siempre centrado en las necesidades del cliente, me cuesta entender por qué se tarda tanto en publicar SAP Neuron Edge y por qué no hay una declaración clara sobre cómo la modelo de precios para los mensajes será cuando se procesen en una infraestructura local (o hiperescala)...
SAP tiene que entender que para enviar un mensaje, de un sistema local a otro, no hace falta irse a la nube, a pesar de todas las desventajas que conlleva. Competidores como Boomi, entendido esto, y desde hace mucho tiempo, hemos tenido átomos ejecutándose en Kubernetes locales.
¿Significa esto que la integración en la nube es un fracaso? ¡En absoluto!
Sinceramente, es una gran plataforma para hacer integraciones, pero requiere experiencia para utilizarla con eficacia.
Al decir que requiere experiencia, no quiero decir que haya que ser un genio para crear una integración en CI. Al contrario, es sencillo, pero el reto surge cuando quieres construir una arquitectura sólida como base para los próximos 20 años de integración.
SAP CI ya no es una herramienta de integración punto a punto, para mí es un lienzo vacío en el que diseñar sus patrones de integración, mecanismos de reactivación, gestión de errores, etc.
En nuestro caso, después de más de 20 implementaciones de diferentes proyectos de SAP CI, coincidimos en que esto lo llevamos a una estructura de 4 niveles para mensajes asíncronos, basada en colas JMS, implementamos procedimientos de manejo de errores e integración con las más renombradas herramientas ITLT, todo esto empaquetado en lo que orgullosamente llamamos el Code10 CI Accelerator, Pero, sinceramente, no es por eso por lo que escribo ahora, casi a medianoche, mientras los niños duermen.
Ventajas del Acelerador Code10
La verdadera razón de este blog es expresar que Realmente siento que ahora es el momento para iniciar el viaje a la Nube y explicaré por qué lo veo así.
Como he escrito antes, veo la IC como un lienzo vacío en el que tenemos que diseñe el futuro de la integración de su empresa para los próximos 20 años o más, y esto requiere tiempo para digerirlo...
Recuerdo que cuando empecé mi andadura profesional no paraba de hacer integraciones de archivo a archivo. Las empresas no estaban preparadas para los protocolos HTTP/SOAP aunque la tecnología estaba ahí. Llevaba tiempo digerirla y utilizarla. Lo mismo ocurre con todo lo que rodea a SAP BTP, la industria necesita tiempo para aprenderlo y digerirlo.
Además, las expectativas del mercado son que tenemos que migrar las interfaces existentes a la nube... Esto es exactamente lo que deberíamos NO ¡¡hazlo!!
Cuando hablamos de la Migraciones S/4 todos estamos de acuerdo en que es una gran oportunidad para reconstruir algunos de los procesos de la empresa, algunos de los antiguos códigos ABAP aquí y allá, etc... Nadie quiere tener un R/3 funcionando en un flamante S/4 HANA, ¿verdad? Pero, por desgracia, muchas empresas lo tendrán, debido a las limitaciones de tiempo y dinero.
El mismo caso se aplica a la migración del middleware, si quieres simplemente ejecutar la herramienta de migración y tener todo listo, ¡¡¡buena suerte!!! Por favor, hazme saber cómo vas a reprocesar los mensajes y cómo vas a comprobar la carga útil cuando tengas errores.
Estudio de caso
Hace unos meses estaba haciendo una evaluación para hacer un Migración SAP PI/PO para uno de nuestros clientes, cuyos sistemas conozco muy bien, tienen alrededor de 150 interfaces (afortunadamente sólo 150 y no 1000s como otros clientes que tenemos) y estaba pensando cómo proceder:
- Instalemos nuestro Code10 CI Accelerator y en 1 o 2 semanas tendremos un sistema con todo lo básico para empezar a migrar a la velocidad de la luz (mis pensamientos iniciales).
- Comprobemos lo que tenemos en SAP PI/PO:
- 50 interfaces de sincronización: Podemos trasladarlas a la nube fácilmente con pequeños ajustes.
- Otras 50 interfaces Async que con la herramienta de migración + algo de retrabajo manual ajustaremos fácilmente al diseño de 4 niveles de Code10.
- ¡¡¡Y otras 50 interfaces que no quiero migrar!!!
¿No quieres migrar 33% de las interfaces???
Sí, migrar estas interfaces tal y como están, será muy difícil (imposible no es nada pero...) y será lo mismo que si instalamos los viejos asientos de un Fiat 127 en un flamante Tesla.
Mi consejo a este cliente es muy honesto, no espere que SAP venga a resolver sus problemas con estas 50 interfaces porque no lo harán, la mayoría de estas interfaces tienen 15 años y siguen malas prácticas, así que es hora de reimplementarlas.
Si yo fuera tú, lo que haría es empezar a mover a la nube los otros 100, probarlos, ahora sí que tenemos bonitos herramientas de prueba como Escudo INT4 para hacer este proceso menos doloroso. Cuando tengas estas 100 interfaces podrás decidir si quieres ejecutarlas en la Nube o en tu SAP PI hasta 2027.
Y sobre las otras 50 interfaces, por favor aprovechar la oportunidad para rediseñarlas, no más búsquedas (ni RFC, ni JDBC), no más cientos de UDFs, no más mapeos JAVA evitables (o mapeos ABAP en algunos casos), ahora llevará tiempo, pero lo será durante otros 20 años, así que sí, merece la pena.
Desgraciadamente, “la regla de un tercio”: 1/3 Sync listo para migrar, 1/3 Async fácil de migrar y 1/3 Async (o Sync) que no quiero migrar, es la regla general para todos los clientes que tienen SAP PI/PO, Así que si cree que es uno de ellos, empiece cuanto antes.
