Segunda fuente

Durante mucho tiempo me resistí al centralismo intensivo. Siempre he estado a favor de la libertad, la autonomía y la responsabilidad individual. Desgraciadamente, las ventajas económicas contradicen con demasiada frecuencia una organización distribuida.

Un ejemplo ridículamente pequeño, pero indicativo de nuestra situación: en la cantina conocí a un antiguo compañero de tenis que ahora trabaja para nosotros en la central de compras de TI. Me habló de bastidores de unidades para nuestros servidores IBM y Fujitsu.

El armazón admite unidades SAS/SATA de 2,5 pulgadas y consta de un poco de metal, mucho plástico y un mecanismo de bloqueo.

En nuestro distribuidor alemán de la lista, una pieza cuesta bastante más de 100 euros. Un proveedor de San Francisco ofrece exactamente la misma pieza por menos de 20 dólares.

Esta fuente fue encontrada por un aprendiz de compras a través de Amazon.

Son anécdotas simpáticas, pero me han hecho reflexionar: Tenemos una infraestructura informática redundante con varios proveedores de energía, servidores, almacenamiento y gasóleo; este último para los generadores de emergencia.

La lista de nuestros segundos y terceros proveedores llenaría fácilmente toda una revista E-3.

Los planes de seguridad contra fallos y catástrofes son algo natural en nuestra arquitectura informática global. Y, por su propia naturaleza, no es un tema que concierna únicamente a las TI.

La seguridad de la planta, la seguridad, los directores de planta y muchos otros se combinan aquí en equipos de recuperación de desastres. ¡No existe ningún plan para el fallo de una plataforma en nube singular como SuccessFactors, Ariba, Concur, HEC o HCP!

La situación es más compleja de lo que podría parecer a primera vista: es posible hacer funcionar en todo el mundo una arquitectura de centro de datos redundante que incluso reaccione en "tiempo real". Pero si hay un fallo en el software que lleva al algoritmo a un punto muerto, entonces ningún hardware a prueba de fallos servirá de ayuda.

Naturalmente, también hay soluciones para esto, pero no pueden organizarse y financiarse en un entorno comercial normal: Una tarea es elaborada por dos equipos de programación independientes.

La probabilidad de que ambos equipos desarrollen exactamente el mismo algoritmo y cometan exactamente los mismos errores en él es muy baja. Pero incluso este doble esfuerzo no resuelve todos los problemas.

En caso de fallo de un algoritmo, es de esperar que el otro siga funcionando, con lo que estarás suficientemente protegido. Pero, ¿y si ambos programas no fallan pero dan resultados diferentes? Entonces necesitaríamos un tercer programa para aproximarnos al resultado final correcto.

Lamentablemente, no puedo presentar aquí una solución para la comunidad SAP y sólo puedo reflejar algunas reflexiones de nuestros debates internos: Teniendo en cuenta el desarrollo técnico y la viabilidad actuales, no parece justificable la dependencia total de un cliente existente a través del software como servicio, como representan HEC, HCP y muchas filiales de SAP. Una aplicación IoT con HCP parece factible.

Pero, ¿qué ocurre en el caso K? ¿Dónde están las copias de seguridad de los datos? Después de una descarga: ¿Se pueden seguir procesando los datos? ¿En qué formato están disponibles? ¿Qué programas informáticos están disponibles a nivel local e in situ para leer los datos?

Naturalmente, hay buenas razones para las soluciones en la nube como Business ByDesign y HEC o S/4 en la nube. Quienes no necesiten infraestructura informática, pocos recursos y una solución de inmediato, probablemente estén bien asesorados con estas soluciones instantáneas: ¡La computación en nube también tiene derecho a vivir!

Pero si usted ha sido un cliente fiel de SAP durante 30 años, ha acumulado muchos conocimientos y experiencia y además puede considerar suya la arquitectura ERP necesaria, dará un amplio margen a los modelos SaaS. Nubes híbridas e infraestructura hiperconvergente sí, pero computación en nube con SuccessFactors, Hybris, Concur, etc. probablemente no.

Mis muchos años de experiencia profesional me demuestran que muchos problemas pueden resolverse desde un ángulo diferente. Nos tomaremos nuestro tiempo y nos replantearemos el problema de la segunda fuente de software. Pero, del mismo modo, nuestro SAP también debería darse o permitirse un poco más de tiempo.

Todavía hay historias de miedo sobre Hana y las anomalías de la computación en memoria. Al informático no le sorprende porque el buen software pasa por un proceso de maduración.

A día de hoy, uno de los mayores misterios de la comunidad SAP es por qué quieren introducir Hana en el mercado a golpe de palanca. Empujar la fecha límite de 2025 a 2030 y permitir a S/4 Finanzas y Logística las revisiones necesarias no es un signo de debilidad, sino de soberanía y previsión.

Mientras escribo estas líneas, las noticias de televisión informan de que VW tampoco dispone de una segunda fuente para determinadas piezas del Golf.

Hasta ahora no podía imaginarme a un fabricante de automóviles sin una segunda fuente; obviamente, la hay. SAP ya tuvo que aprender por las malas que no existe una segunda fuente para SuccessFactors.