00:00:03 Introducción a la modularización en TI y cadenas de suministro.
00:00:26 Modularidad en la cadena de suministro física.
00:02:31 Estructuras monolíticas de los primeros sistemas de TI.
00:04:08 Contexto de TI de los sistemas monolíticos.
00:05:31 Impacto de Internet en el diseño modular de software.
00:08:02 Problemas en los sistemas de software monolíticos.
00:08:48 Ineficiencias de los sistemas monolíticos.
00:11:16 Transición a sistemas modulares: ejemplos.
00:13:34 Fallas del sistema en aplicaciones modulares.
00:14:34 Redundancia, tiempo de actividad en sistemas modulares.
00:16:00 Confiabilidad de sistemas grandes, fallas en proyectos de software.
00:16:50 Ejemplo de transición de software fallida de Lidl.
00:18:09 Concepto de “fallar rápido” en proyectos de software.
00:19:30 Manejo de superposiciones, importancia del software “glue”.
00:22:46 Evitando desastres de software.
Resumen
En el episodio de Lokad TV, Joannes Vermorel, el fundador de Lokad, analiza la importancia de la modularización en la infraestructura de TI empresarial, estableciendo una comparación con la adaptabilidad de las cadenas de suministro. Se refiere a los sistemas de TI monolíticos de los años 70 y 80, caracterizados por su inflexibilidad debido a limitaciones tecnológicas. Incluso con el cambio hacia sistemas en red después de la aparición de Internet, destaca el desafío continuo para las empresas de modularizar sus sistemas de TI. Vermorel propone la Arquitectura Orientada a Servicios (SOA) como una solución potencial, enfatizando la necesidad de servicios más pequeños y bien definidos. Advierte contra emprender proyectos a gran escala y aboga por un enfoque de “fallar rápido”, enfatizando la importancia de la gestión de riesgos y la recuperación rápida en caso de fallas.
Resumen Extendido
En el episodio actual de Lokad TV, el presentador Kieran Chandler conversa con Joannes Vermorel, el fundador de Lokad, sobre la modularización en la infraestructura de TI empresarial. Vermorel describe el concepto de modularización, estableciendo paralelismos principalmente con las cadenas de suministro en el mundo físico, que considera como las creaciones más modulares de la humanidad.
Utiliza los ejemplos de camiones, paletas y contenedores para aclarar sus puntos sobre la modularidad. Vermorel enfatiza la modularidad inherente de las cadenas de suministro físicas al señalar la aplicabilidad universal de los códigos de barras, que se pueden adjuntar prácticamente a cualquier cosa.
Aunque las cadenas de suministro físicas muestran una modularidad clara, Vermorel observa que las infraestructuras de TI de las empresas a menudo carecen de una flexibilidad similar. Atribuye esta falta de modularidad a las etapas iniciales del desarrollo de TI dentro de las empresas durante los años 70 y 80, cuando las implementaciones iniciales de TI y los sistemas ERP se diseñaron como estructuras independientes y monolíticas debido a las limitaciones tecnológicas de la época.
Vermorel identifica un ‘monolito’ en términos de TI como una aplicación unificada que no se puede descomponer en partes más pequeñas. Explica cómo este enfoque monolítico contrasta con la modularidad vista en las cadenas de suministro físicas, donde varios componentes se pueden combinar o separar según sea necesario.
A pesar de su complejidad, Vermorel explica que los mainframes antiguos eran inherentemente coherentes, ya que funcionaban como una unidad única con todas las operaciones centralizadas. Señala cómo esta forma de diseño de sistemas parece desactualizada para la generación actual acostumbrada a sistemas distribuidos y aplicaciones basadas en redes, marcando un cambio significativo en el desarrollo de infraestructuras de TI a lo largo de los años.
Vermorel señala que el panorama comenzó a cambiar con la llegada de Internet a fines de los años 90, lo que llevó al diseño de software con partes aisladas conectadas por una red. Sin embargo, señala que muchas empresas todavía luchan con la modularización, a pesar de que el valor de los sistemas de TI modulares se comprende bien en teoría.
Explica cómo muchos proveedores han adaptado estas antiguas arquitecturas monolíticas a modelos de nube y Software como Servicio (SaaS), lo que resulta en sistemas que ofrecen un mantenimiento mejorado pero no mejoran la modularidad. Dice que esta falta de modularidad impide a las empresas aislar y cambiar características específicas.
Para superar este problema, Vermorel propone una Arquitectura Orientada a Servicios (SOA), un enfoque que descompone las capacidades en “trozos” más pequeños y bien definidos. Hace referencia a Amazon como ejemplo de una empresa que adoptó con éxito este enfoque modular desde el principio.
Aboga por una arquitectura orientada a servicios con API que permita exportar y aprovechar los datos en diferentes divisiones de una empresa. Aunque reconoce que un enfoque descentralizado presenta un mayor potencial de puntos de falla en comparación con un sistema monolítico, Vermorel argumenta que estos desafíos se pueden mitigar mediante redundancia e ingeniería de alta calidad.
Vermorel estima que entre un tercio y la mitad de todos los proyectos de TI de la cadena de suministro fracasan. Hace referencia al caso de Lidl en Alemania, que perdió medio billón de euros en una transición fallida de SAP. Argumenta que la transición de proveedores pequeños a proveedores grandes solo reduce ligeramente las tasas de fracaso, pero no las elimina.
En cuanto a la gestión de múltiples aplicaciones, Vermorel sugiere elegir aplicaciones con un alcance estrecho para minimizar las superposiciones y aconseja no comprar grandes marcos de trabajo a proveedores. Para gestionar eficazmente varias aplicaciones, dice que las empresas deben desarrollar una “cola” interna que vincule estas aplicaciones, facilitada por una arquitectura orientada a servicios.
Por último, Vermorel comparte consejos sobre cómo prevenir desastres como la transición fallida de SAP de Lidl. Enfatiza pensar en términos de gestión de riesgos y adoptar un enfoque de “fracasar rápido”. Aconseja no caer en el pensamiento ilusorio en la gestión de proyectos y subraya la importancia de planificar posibles fallas y encontrar formas de recuperarse rápidamente.
Transcripción completa
Kieran Chandler: Hola y bienvenidos a otro episodio de Lokad TV. Esta semana vamos a hablar sobre la modularización, el proceso de subdividir los procesos informáticos de nuestra empresa de un sistema independiente a varios subprogramas o incluso aplicaciones. Como siempre, me acompaña Joannes Vermorel. Entonces, Joannes, ¿sobre qué parte de los procesos de la empresa estamos hablando de hacer más modular hoy?
Joannes Vermorel: Hoy nos estamos enfocando especialmente en la infraestructura de TI y el paisaje aplicativo de su empresa. La modularización es interesante. Cuando piensas en el mundo físico, es evidente que las cadenas de suministro son increíblemente modulares. Probablemente sean las cosas más modulares jamás inventadas por la humanidad. Con modular me refiero a que si quieres transportar mercancías por carretera, puedes usar camiones. Los camiones son increíblemente modulares porque puedes poner prácticamente cualquier cosa que no exceda la capacidad de un camión en él, y un camión puede circular por cualquier carretera, yendo desde cualquier lugar a cualquier otro. Si necesitas camiones adicionales, podrías usar prácticamente cualquier tipo de camión, casi, y pueden agregar capacidad de transporte a tu cadena de suministro.
Lo mismo se aplica a las paletas y contenedores. Puedes poner casi cualquier cosa en una paleta o en un contenedor siempre y cuando no exceda la capacidad. Un contenedor es extremadamente modular. Puedes moverlo desde un barco de carga hasta un camión. Todas esas piezas son increíblemente modulares. Puedes poner un código de barras en prácticamente cualquier cosa que no sea demasiado pequeña. Es un invento increíblemente moderno. Si tienes algo como un diamante, probablemente lo pondrías en una caja y luego colocarías el código de barras en la parte superior de la caja. Puedes combinar todos estos elementos simples a voluntad, casi infinitamente. Es muy parecido a Lego; partes simples que puedes combinar de formas increíblemente variadas. Esa es la cadena de suministro física, que es increíblemente modular.
Sin embargo, lo interesante es que cuando pasamos al mundo de la TI, entramos en una perspectiva completamente diferente y donde frecuentemente se pierde la modularización. Creo que el origen de eso se remonta a principios de los años 70 u 80, cuando las empresas comenzaron a tener sus primeros sistemas informáticos y sus primeras implementaciones de ERP.
Kieran Chandler: Entonces, lo que estás diciendo es que esas implementaciones iniciales, esos sistemas informáticos iniciales, porque eran en gran medida un enfoque singular, eso es lo que todavía estamos usando hoy. ¿Es eso lo que estás diciendo?
Joannes Vermorel: Sí, en efecto. Cuando piensas en el software de los años 70, 80 o incluso principios de los 90, hacer cualquier cosa a través de la red era como la ciencia ficción. Era posible, pero era una pesadilla de ingeniería. Era mucho más fácil decir que tomamos una gran máquina, idealmente un mainframe de IBM de la época, y ponemos toda tu lógica en esta máquina. Luego, todos usan una terminal conectada a esta máquina, y toda la lógica se ejecuta en un monolito en esta máquina.
Kieran Chandler: Entonces, ¿qué quieres decir con monolito?
Joannes Vermorel: Con monolito me refiero a una aplicación que es un todo. No se puede desmontar. Tiene que estar junto o no es nada.
Kieran Chandler: Me temo que soy un poco milenial, por lo que esta idea puede ser anterior a mí. Pero básicamente, ¿lo que estamos diciendo es que todo está conectado a una sola máquina, ¿correcto? Y luego todos nos conectamos y trabajamos desde allí.
Joannes Vermorel: Exactamente. Los mainframes eran cosas relativamente complejas en términos de hardware, por lo que incluso si era una sola máquina.
Kieran Chandler: Principalmente estamos hablando de ERPs, es decir, sistemas de gestión de recursos empresariales. Estos sistemas suelen estar diseñados para ser extensibles, permitiendo la adición de capacidades y características adicionales. Sin embargo, no son modulares, lo que significa que no se pueden separar esas capacidades para mantenerlas completamente aisladas.
Joannes Vermorel: Lo interesante es que lo que realmente cambió fue probablemente Internet. No me refiero a la invención de Internet, sino al hecho de que a fines de los años 90, con Internet volviéndose muy popular, la gente comenzó a pensar en cómo diseñar software de manera que se tomen las partes de forma aislada, con la red en el medio. De esta manera, el flujo de trabajo no es una pesadilla de ingeniería. Antes de esto, si no sabías cómo construir un sistema de software complejo compuesto por muchas partes, tener una red en el medio era una pesadilla de ingeniería. Este conocimiento, cultura y herramientas surgieron principalmente como un subproducto de la adopción de Internet por parte del público en general.
Kieran Chandler: Internet ha estado presente durante mucho tiempo, ¿por qué seguimos hablando de modularización? ¿Por qué estos software siguen actuando de esta manera única?
Joannes Vermorel: En este momento, mi diagnóstico es que cuando tomas una empresa promedio que opera una cadena de suministro compleja o multinacional con muchas ubicaciones, todo lo físico es increíblemente modular. Sin embargo, cuando comenzamos a mirar la tecnología de la información, es completamente monolítica. Creo que las empresas y el mercado en general todavía tienen dificultades para apreciar el valor de tener algo extremadamente modular en términos de tecnología de la información. Físicamente, es bastante obvio, y las cadenas de suministro siguen mejorando su modularidad. Sin embargo, en términos del panorama de aplicaciones, es más abstracto, más difícil de percibir la modularidad como tal.
Muchos proveedores tomaron arquitecturas monolíticas antiguas, las actualizaron ligeramente hacia SaaS y la nube, pero simplemente las copiaron y pegaron. Es fundamentalmente el mismo tipo de arquitectura que tenías en un mainframe de IBM en los años 90, donde simplemente decidiste que en lugar de tener una máquina en la sede de tu empresa que ejecuta el sistema, lo delegas a un proveedor de software que opera como SaaS. Pero si el proveedor de SaaS solo tiene un monolito que se ejecuta en una máquina que está lejos de tu sede, con solo un poco de networking y una interfaz de usuario web en el medio, no agrega nada en cuanto a modernización se refiere. Solo facilita el mantenimiento. Pero cuando quieres separar las características, aún te enfrentas a un monolito donde este tipo de capacidades no pueden ocurrir.
Kieran Chandler: ¿Cuál es el problema con este enfoque monolítico? ¿Cómo está afectando a las empresas en el mundo real?
Joannes Vermorel: Imagina el equivalente físico de la falta de modularización. Imagina que en tu cadena de suministro, cada vez que quieres cambiar un camión, tienes que cambiarlos todos. Por ejemplo, si cambias de un camión a otro, necesitas un tipo diferente de gasolina. Entonces, todas tus gasolineras necesitarían ser cambiadas, lo que significa que tienes depósitos que contienen gasolina donde necesitas un segundo tipo de gasolina. Eso sería inmenso.
El dolor, ya ves, es comparable a la situación en el software. Cuando careces de modernización, es como si cambiaras una parte, necesitaras cambiarlas todas. Si cambias un camión, necesitas cambiar toda tu flota. Imagina si cambias los estantes de un almacén y necesitarías cambiar todos los estantes de todos los demás almacenes, de lo contrario, no sería compatible. Luego te das cuenta, vale, tal vez pueda decidir actualizar mi flota de camiones hacia camiones eléctricos, pero eso sería un movimiento estratégico masivo y muy complicado. Aún preferirías tener algo relativamente modular donde puedas tener camiones eléctricos y camiones de combustión coexistiendo armoniosamente durante mucho tiempo. Cuando careces de modernización, significa que no puedes tener este tipo de coexistencia. No puedes cambiar algunas partes de tu cadena de suministro sin cambiar todo.
La evidencia anecdótica más frecuente de esta falta de modernización es que para que las empresas se muden de un almacén a otro físicamente, se podría hacer en un día donde simplemente mueves las cosas que están en un almacén de los estantes del almacén A a los estantes del almacén B. Pero migrar el software que estaba conectado al almacén A para que todo sepa que todas las cosas están en el sistema que impulsa el almacén B, eso llevaría como seis meses.
Kieran Chandler: Eso es interesante. ¿Cómo hacen esto las grandes empresas si existen en este tipo de sistema monolítico? ¿Cómo migran a un sistema más modular?
Joannes Vermorel: Creo que vamos a volver a una de las empresas que mencionamos en casi todos los episodios, como Amazon. No son los únicos que adoptaron un enfoque extremadamente modular. En Alemania, Zalando, puedes seguir en los blogs, también ha adaptado completamente un enfoque muy modular y la palabra clave en TI para esto cuando quieres tener esta modularidad es probablemente Arquitectura Orientada a Servicios, SOA.
La Arquitectura Orientada a Servicios básicamente significa que quieres aislar capacidades en fragmentos que son ellos mismos como pequeños monolitos, pero mucho más pequeños, y que están muy bien delimitados para hacer una cosa y hacerla bien. Y conectas todas esas cosas a través de tu Arquitectura Orientada a Servicios, lo que significa que cada servicio, en el sentido de que es una aplicación que hace una cosa y la hace bien, expone APIs para que se pueda conectar fácilmente a tu paisaje de aplicaciones. Está diseñado para ser fácilmente enchufable programáticamente en cualquier paisaje de aplicaciones arbitrario sin hacer casi ninguna suposición sobre cuáles son las otras partes del paisaje de aplicaciones.
Jeff Bezos de Amazon publicó un memo muy famoso, creo que en 2002, donde a todos sus equipos les dijo que cada división necesita tener una arquitectura orientada a servicios con APIs, para que los datos que tienes en tu silo se puedan exportar para ser explotados en cualquier otra división de la empresa y podamos interactuar programáticamente con lo que estás construyendo.
Kieran Chandler: El problema que veo con esto es que te vuelves dependiente de muchas aplicaciones más pequeñas, programas más pequeños, empresas más pequeñas en última instancia. ¿No introduce eso muchos más puntos de falla? Mientras que si tienes un enfoque más monolítico, tienes una gran empresa sólida, un gran sistema ERP que siempre estará en funcionamiento y tienes más confianza en él.
Joannes Vermorel: Es cierto, y hasta cierto punto ese es uno de los desafíos de un sistema distribuido. Si tu hardware falla el 1% del tiempo, eso significa si tienes un mainframe.
Kieran Chandler: Has mencionado que el software puede fallar tres veces al año. Si tienes 10 aplicaciones, cada una con un uno por ciento de probabilidad de estar fuera en cualquier día dado, significa que aproximadamente cada 10 días algo está fuera en tu red. Es ciertamente un desafío. ¿Qué soluciones sugerirías para esta situación?
Joannes Vermorel: La redundancia es lo primero que me viene a la mente, pero me gustaría discutir las implicaciones en términos de computación distribuida, y tal vez luego podamos hablar sobre empresas pequeñas versus grandes y la disparidad dentro de los proveedores. Desde el punto de vista de la computación distribuida, el objetivo es asegurar que cada bloque sea altamente redundante. Esta es la esencia de la computación en la nube. Quieres tener un software altamente redundante para que tu tiempo de actividad sea muy alto.
La buena noticia es que debido a que tus aplicaciones son más pequeñas y simples, es mucho más fácil lograr un tiempo de actividad muy alto con una aplicación pequeña y simple que con una aplicación muy compleja. Hay muchos servicios componentes en Internet que están literalmente siempre encendidos. Google Mail, por ejemplo, está literalmente siempre encendido. El sitio web de Yahoo está básicamente siempre encendido. Facebook también está siempre encendido. Entonces, es posible diseñar estas propiedades “siempre encendidas” para tus aplicaciones, lo que aborda la confiabilidad de tu sistema en su conjunto.
Kieran Chandler: ¿Qué hay de la transición de un gran proveedor a muchos proveedores pequeños?
Joannes Vermorel: La realidad es que las tasas de falla en el software son altas. La gente no se da cuenta de que tal vez la mitad del tiempo, las iniciativas de software fallan. Mi estimación sería que entre un tercio y la mitad de todos los proyectos de TI de la cadena de suministro fallan para empresas de casi cualquier tamaño. Hace unas semanas, Lidl en Alemania básicamente perdió medio billón de euros en una transición fallida de SAP. Fue un proyecto de siete años que terminó en fracaso, y finalmente se rindieron. Pero no es el único ejemplo; esto sucede con bastante frecuencia.
Los grandes proveedores probablemente tienen una mejor tasa de éxito, pero si estamos hablando de cifras aproximadas, estamos hablando de pasar de un proveedor pequeño con una tasa de falla del 50%, que es bastante malo, a un proveedor grande con una tasa de falla del 30%. Entonces, cuando pasas de una empresa pequeña a una grande, tu riesgo disminuye ligeramente, pero solo un poco.
Si optas por un enfoque altamente modular, sí, tendrás muchas cosas que fallarán, pero tendrás la oportunidad de intentarlo de nuevo y repetir hasta que tengas éxito. Cada componente tiene la posibilidad de fallar, pero debido a que el alcance es más simple, la aplicación en sí es más pequeña, puedes fallar rápidamente y volver a intentarlo.
Lo que sucedió con el enfoque de Lidl es que estoy bastante seguro de que inicialmente no estaban planeando una migración de siete años. Probablemente fue una migración de dos años que se convirtió en tres, luego en cuatro, y así sucesivamente porque estaban fallando, reiterando y volviendo a fallar. Siete años después, finalmente decidieron rendirse, probablemente porque todos habían perdido cualquier esperanza de que el proyecto tuviera éxito.
Kieran Chandler: Entonces, si estamos de acuerdo en que estas aplicaciones, una vez que encuentras la correcta y quizás iteras un poco, pueden ser confiables… Parecen funcionar y parecen hacer el mismo trabajo que un sistema más grande. ¿Qué hay de la intersección entre esas aplicaciones? Porque muchas veces, una aplicación hará algo más bien y puede haber un poco de intersección y conflicto dentro de ese sistema. ¿Cómo gestionas eso?
Joannes Vermorel: Primero, cuando eliges la composición de tu paisaje aplicativo, realmente quieres elegir aplicaciones que tengan un alcance estrecho. Este enfoque va completamente en contra de lo que la mayoría de las Solicitudes de Propuestas (RFP) hacen. Cuando las empresas buscan adquirir un software, a menudo van por una RFP y quieren todo, todas las características, todas las campanillas y silbatos. Pero eso es lo contrario de lo que deberías buscar. Quieres algo extremadamente estrecho, para que, por diseño, minimices tus superposiciones.
Si estás comprando grandes marcos de trabajo, es una receta para tener superposiciones. Los proveedores empresariales están interesados en venderte grandes marcos de trabajo porque pueden ampliarlos con muchas características. Te venden algo y luego te venderán los complementos encima de eso. Entonces, diría a las personas que dirigen grandes cadenas de suministro, que tengan mucho cuidado cuando les vendan una plataforma.
Una plataforma es buena, pero dos plataformas pueden ser una pesadilla. Tan pronto como tienes varios proveedores que te venden plataformas, terminarás con un mar de superposiciones. La solución es elegir cuidadosamente la composición de tus ingredientes.
En cuanto a “pegamento”, el enfoque es que típicamente es algo que quieres desarrollar internamente. Esto puede ir en contra de la intuición de por qué querrías desarrollar cualquier tipo de software interno. La respuesta es que si eres una empresa de cierto tamaño, tu paisaje aplicativo es completamente único para ti.
Incluso si usas todas las aplicaciones estándar, necesitarás múltiples aplicaciones. No hay forma de que tengas un ERP hoy en día que pueda hacer correos electrónicos, videoconferencias y demás. No puedes incluir todas las características de software que necesitas en una sola aplicación. Probablemente usarás Microsoft Excel como todos los demás, por lo que necesitarás tener un lugar para almacenar archivos, etc.
No es realista decir que tenemos una sola pieza de software. Cualquier empresa de tamaño significativo va a ser una colección de software de todos modos. La receta exacta, es decir, la lista de software que literalmente hace funcionar tu empresa, va a ser completamente única para ti de todos modos. Ninguna otra empresa está organizada exactamente como tú.
Kieran Chandler: Es completamente único, es tu ADN. Puedes tener este pegamento que implementas internamente. Ese es todo el punto de la arquitectura orientada a servicios, hacer que este pegamento sea simple y liviano de implementar, para que puedas tener un equipo de TI muy ágil que haga esfuerzos mínimos. Para crear este software personalizado que simplemente une las cosas. Entonces, para resumir, si soy un CEO, ¿cómo evito otro desastre como el de Lidl?
Joannes Vermorel: Primero, creo que es esencial pensar en el riesgo en lugar de minimizarlo. El desastre tipo Lidl fue la gente diciendo: “No queremos correr ningún riesgo”, y así van por el proveedor más grande que hay e intentan tener el producto que hace de todo. Esencialmente, es el enfoque en el que decimos que queremos algo que sea correcto por diseño y queremos implementar algo que actualice toda la empresa de una vez. Este es el peor tipo de enfoque en términos de gestión de riesgos.
Necesitas pensar completamente lo contrario, es decir, “¿Cómo puedo tener algo que falle rápidamente si tiene que fallar?” Verás, el problema con el riesgo es que cuando tienes este proyecto masivo, no sabes durante mucho tiempo si has fallado o no. Lo que quieres es tener algo que falle más rápido, donde sepas si has fallado y el fallo sea a pequeña escala. Y si necesitas tener un reemplazo, tienes un alcance que se puede manejar, y lo haces con muchos fragmentos pequeños.
Entonces, piénsalo como algo opuesto a prevenir el riesgo. Estoy diciendo que al pasar de un proveedor grande a uno pequeño, es posible que aumentes el riesgo del 50% de probabilidad de fallo al 50%. Al final, si un 30% de probabilidad de fallo significa que tu empresa quiebra o que la cadena de suministro se detiene, no es un riesgo que puedas tomar. Así que tienes que planificar el fallo de todos modos.
Mi pensamiento es que debido a que un alto grado de riesgo es inevitable, ve directamente a un plan para el fallo. Intenta tener fallos pequeños, rápidos y bien definidos para que puedas iterar, en lugar de decir que vamos a hacer todo bien la primera vez, lo cual es un pensamiento ilusorio. Luego, embarcate en un viaje que probablemente dure siete años, para finalmente perder medio billón de euros en el proceso. Ese es el tipo de pensamiento ilusorio sobre la gestión de proyectos.
Kieran Chandler: Genial, me gusta. El consejo de Lokad del día: Si vas a fallar, falla rápido. Brillante. Eso es todo por esta semana. Volveremos la próxima semana con otro episodio. Hasta entonces, gracias por vernos.
