00:00:03 Introducción a la modularización en TI y supply chain.
00:00:26 Modularidad del supply chain físico.
00:02:31 Estructuras monolíticas de los primeros sistemas de TI.
00:04:08 Contexto de TI de sistemas monolíticos.
00:05:31 Impacto del Internet en el diseño modular de software.
00:08:02 Problemas en 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 de sistemas en aplicaciones modulares.
00:14:34 Redundancia, tiempo de actividad en sistemas modulares.
00:16:00 Fiabilidad de sistemas a gran escala, fallas en proyectos de software.
00:16:50 Ejemplo de la transición fallida de software de Lidl.
00:18:09 Concepto de “fail fast” en proyectos de software.
00:19:30 Gestionar solapamientos, importancia del software “glue”.
00:22:46 Evitando desastres de software.
Resumen
En el episodio de Lokad TV, Joannes Vermorel, el fundador de Lokad, discute la importancia de la modularización en la infraestructura de TI empresarial, estableciendo una comparación con la adaptabilidad de los supply chain. 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 tras la aparición del Internet, subraya el desafío continuo que enfrentan las empresas para modularizar sus sistemas de TI. Vermorel propone Service Oriented Architecture (SOA) como una solución potencial, destacando la necesidad de servicios más pequeños y bien definidos. Advierte contra la realización de proyectos a gran escala y aboga por un enfoque “fail fast”, enfatizando la importancia crítica de la gestión de riesgos y la recuperación rápida en caso de fallos.
Resumen Ampliado
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 expone el concepto de modularización, estableciendo paralelismos principalmente con los supply chain del mundo físico, que considera como las creaciones más modulares de la humanidad.
Utiliza los ejemplos de trucks, pallets y contenedores para aclarar sus puntos sobre la modularidad. Vermorel enfatiza la modularidad inherente de los supply chain físicos al señalar la aplicabilidad universal de los códigos de barras, que pueden ser adheridos a prácticamente cualquier cosa.
Aunque los supply chain físicos muestran una modularidad evidente, Vermorel observa que las infraestructuras de TI de las empresas a menudo carecen de una flexibilidad similar. Remonta esta falta de modularidad a las primeras etapas del desarrollo de TI en 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 puede ser desglosada en partes más pequeñas. Explica cómo este enfoque monolítico contrasta con la modularidad observada en los supply chain físicos, donde diversos componentes pueden combinarse o separarse según se necesite.
A pesar de su complejidad, Vermorel explica que los primeros mainframes eran inherentemente coherentes al funcionar como una unidad única con todas las operaciones centralizadas. Señala cómo esta forma de diseño de sistemas resulta anticuada para la generación actual, acostumbrada a sistemas distribuidos y aplicaciones basadas en red, marcando un cambio significativo en el desarrollo de la infraestructura de TI a lo largo de los años.
Vermorel señala que el panorama comenzó a cambiar con la llegada del Internet a finales de los 90, lo que llevó al diseño de software con partes aisladas conectadas por una red. Sin embargo, comenta que muchas empresas aún luchan por modularizar, a pesar de que en teoría se comprende bien el valor de los sistemas de TI modulares.
Explica cómo muchos proveedores han adaptado estas antiguas arquitecturas monolíticas a modelos de computación en la nube y Software as a Service (SaaS), resultando en sistemas que ofrecen un mantenimiento mejorado pero no incrementan la modularidad. Afirma que esta falta de modularidad impide a las empresas aislar y modificar características específicas.
Para superar este problema, Vermorel propone una Service Oriented Architecture (SOA), un enfoque que descompone las capacidades en “chunks” más pequeños y bien definidos. Menciona a Amazon como un ejemplo de empresa que adoptó con éxito este enfoque modular desde temprano.
Aboga por una arquitectura orientada a servicios con APIs que permiten que los datos sean exportados y aprovechados a lo largo de las diferentes divisiones de una empresa. A pesar de reconocer que un enfoque descentralizado presenta potencial para más puntos de fallo en comparación con un sistema monolítico, Vermorel sostiene que estos desafíos pueden mitigarse mediante la redundancia y una ingeniería de alta calidad.
Vermorel estima que entre un tercio y la mitad de todos los proyectos de TI de supply chain fracasan. Hace referencia al caso de Lidl en Alemania, que perdió medio billón de euros en una transición fallida de SAP. Sostiene que pasar de proveedores pequeños a grandes solo reduce ligeramente las tasas de fracaso, pero no las elimina.
En lo que respecta a la gestión de múltiples aplicaciones, Vermorel sugiere elegir aplicaciones con un alcance reducido para minimizar solapamientos y desaconseja comprar grandes frameworks de proveedores. Para gestionar eficazmente múltiples apps, dice que las empresas deberían desarrollar un “glue” interno que una estas aplicaciones, facilitado por una arquitectura orientada a servicios.
Finalmente, Vermorel comparte consejos sobre cómo prevenir desastres como la transición fallida de SAP de Lidl. Enfatiza la importancia de pensar en términos de gestión de riesgos y adoptar un enfoque “fail fast”. Aconseja no dejarse llevar por ilusiones en la gestión de proyectos y subraya la importancia de planificar para posibles fallos y encontrar maneras de recuperarse rápidamente.
Transcripción Completa
Kieran Chandler: Hola y bienvenidos de nuevo a otro episodio de Lokad TV. Esta semana vamos a discutir la modularización, el proceso de subdividir los procesos informáticos de nuestra empresa de un sistema independiente a varios subprogramas o incluso apps. Como siempre, me acompaña Joannes Vermorel. Entonces, Joannes, ¿de qué parte de los procesos de la empresa estamos hablando de hacer más modulares hoy?
Joannes Vermorel: Hoy nos estamos enfocando especialmente en la infraestructura de TI y el paisaje aplicativo de tu empresa. La modularización es interesante. Cuando piensas en el mundo físico, es evidente que los supply chain son increíblemente modulares. Probablemente sean las cosas más modulares jamás inventadas por la humanidad. Con modular quiero decir que, si deseas transportar mercancías por carretera, puedes usar camiones. Los camiones son increíblemente modulares porque puedes poner prácticamente cualquier cosa que no supere la capacidad de un camión, y un camión puede circular por cualquier carretera, yendo de cualquier lugar a cualquier otro. Si necesitas camiones adicionales, prácticamente podrías usar casi cualquier tipo de camión, y estos pueden añadir capacidad de transporte a tu supply chain.
Lo mismo se aplica a pallets y contenedores. Puedes poner casi cualquier cosa en un pallet o en un contenedor siempre que no exceda la capacidad. Un contenedor es extremadamente modular. Puedes moverlo de un buque de carga a un camión. Todas esas piezas son increíblemente modulares. Puedes colocar un código de barras en prácticamente cualquier cosa que no sea demasiado pequeña. Es una invención increíblemente moderna. Si tienes algo como un diamante, probablemente lo colocarías en una caja y luego pondrías el código de barras encima de la caja. Puedes combinar todos estos elementos simples a voluntad, casi infinitamente. Ese es el supply chain físico, que es increíblemente modular.
Sin embargo, lo interesante es que cuando pasas al mundo de la TI, entras 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 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 primeros sistemas de TI, debido a que eran una especie de enfoque singular, son todavía lo que usamos hoy en día. ¿Es eso lo que dices?
Joannes Vermorel: Sí, en efecto. Cuando piensas en la informática o el software de los años 70, 80 o incluso de principios de los 90, hacer algo a través de la red era como ciencia de cohetes. Era posible, pero era una pesadilla de ingeniería. Era mucho más fácil decir: tomamos una gran máquina, idealmente un mainframe de IBM de la época, y ponemos toda tu lógica en esa máquina. Luego, todos usan un terminal conectado a esa máquina, y toda la lógica se ejecuta en un monolito en esa máquina.
Kieran Chandler: Entonces, ¿a qué te refieres con monolito?
Joannes Vermorel: Con monolito, quiero decir que es como una aplicación que es un todo. No se puede desarmar. Tiene que estar unida o no es nada.
Kieran Chandler: Me temo que soy un poco millennial, así que este tipo de idea puede que me sea anterior. Pero básicamente, lo que estamos diciendo es que todo se conecta a una sola máquina, ¿correcto? ¿Y luego todos nos conectamos y trabajamos desde allí?
Joannes Vermorel: Exactamente. Los mainframes eran dispositivos de hardware relativamente complejos, así que aunque fuera una sola máquina.
Kieran Chandler: Principalmente estamos hablando de ERPs, es decir, sistemas de Enterprise Resource Management. Estos sistemas generalmente están diseñados para ser extensibles, permitiendo la adición de capacidades y funciones extra. Sin embargo, no son modulares, lo que significa que no puedes separar esas capacidades para mantenerlas completamente aisladas.
Joannes Vermorel: Lo interesante es que lo que realmente cambió fue probablemente el Internet. No me refiero a la invención del Internet, sino al hecho de que a finales de los 90, con el Internet volviéndose muy popular, la gente empezó a pensar en cómo diseñar software de manera que tomes las partes en aislamiento, con la red en el medio. De este modo, 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 de muchas partes, tener una red en el medio era una pesadilla de ingeniería. Este saber hacer, cultura y herramientas surgieron en gran medida como un subproducto de la adopción del Internet por el público en general.
Kieran Chandler: El Internet ha existido por mucho tiempo ya, entonces ¿por qué seguimos hablando de modularización? ¿Por qué estos software siguen actuando de manera tan singular?
Joannes Vermorel: En este momento, mi diagnóstico es que cuando tomas a la empresa promedio que opera un supply chain complejo o una multinacional con muchas ubicaciones, todo lo físico es increíblemente modular. Sin embargo, cuando comenzamos a mirar la TI, es completamente monolítica. Creo que las empresas y el mercado en general aún tienen problemas para apreciar el valor de tener algo que sea extremadamente modular en términos de TI. Físicamente, es bastante obvio, y los supply chain todavía están mejorando su modularidad. Sin embargo, en cuanto al panorama de aplicaciones, es más abstracto, más difícil percibir la modularidad como tal.
Muchos proveedores tomaron antiguas arquitecturas monolíticas, las actualizaron ligeramente hacia modelos SaaS y la computación en la nube, pero simplemente 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 decidías que en lugar de tener una máquina en la sede de la empresa que ejecutara el sistema, lo delegabas a un proveedor de software que operara como SaaS. Pero si el proveedor de SaaS solo tiene un monolito que opera en una máquina que está lejos de tu sede, con solo un poco de networking y una interfaz web en el medio, no aporta nada en cuanto a modernización se refiere. Simplemente facilita el mantenimiento. Pero cuando quieres desglosar las funcionalidades, sigues enfrentándote a un monolito en el que 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: Solo imagina el equivalente físico de la falta de modularización. Imagina que en tu supply chain, cada vez que quieras 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 estaciones de servicio tendrían que cambiarse, lo que significaría que tendrías depósitos de gasolina donde necesitarías un segundo tipo de gasolina. Eso sería inmenso.
El dolor, verás, es comparable a la situación en el software. Cuando careces de modernización, es como si al cambiar una parte, tuvieras que cambiarlas todas. Si cambias un camión, necesitas cambiar toda tu flota. Imagina si cambias los estantes de un almacén y necesitaras cambiar todos los estantes de todos los demás almacenes, de lo contrario, no son compatibles. Luego te das cuenta de que, bueno, tal vez pueda decidir actualizar mi flota de camiones a camiones eléctricos, pero eso va a ser 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 conviviendo armoniosamente durante un largo periodo de tiempo. Cuando careces de modernización, significa que no puedes tener este tipo de coexistencia. No puedes cambiar algunas partes de tu supply chain sin cambiarlo todo.
La evidencia anecdótica más frecuente de esta falta de modernización es que, para que las empresas se trasladen de un almacén a otro físicamente, podría hacerse en un día, simplemente moviendo las cosas que están en un almacén desde 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 opera el almacén B, eso tomaría como seis meses.
Kieran Chandler: Eso es interesante. ¿Cómo hacen las grandes empresas esto si operan 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 prácticamente cada episodio, como Amazon. No son los únicos que adoptaron un enfoque extremadamente modular. En Alemania, Zalando, como se puede seguir en los blogs, también han adaptado completamente un enfoque muy modular y la palabra clave en TI para esto, cuando se quiere tener esta modularidad, es probablemente arquitectura orientada a servicios, SOA.
La arquitectura orientada a servicios básicamente significa que se quiere aislar capacidades en fragmentos que son como pequeños monolitos, pero mucho más pequeños, y que tienen un alcance muy definido para hacer una cosa y hacerla bien. Y se conectan todas esas partes a través de la 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 integrar muy fácilmente en el panorama de aplicaciones. Está diseñada para integrarse de forma programática y sencilla en cualquier panorama de aplicaciones arbitrario sin hacer casi ninguna suposición sobre cuáles son las otras partes del mismo.
Jeff Bezos de Amazon publicó un memorando muy famoso, creo que en 2002, en el que a todos sus equipos les dijo que cada división necesita tener una arquitectura orientada a servicios con APIs, de modo que los datos que tienes en tu silo puedan ser exportados para ser aprovechados 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 terminas dependiendo de muchas aplicaciones más pequeñas, programas más pequeños, y en última instancia, empresas más pequeñas. ¿No introduce eso muchos más puntos únicos de fallo? Mientras que si tienes un enfoque más monolítico, cuentas con una sólida empresa grande, un gran sistema ERP que siempre estará en funcionamiento y en el que tienes más confianza.
Joannes Vermorel: Es cierto, y en cierta medida ese es uno de los desafíos de un sistema distribuido. Si tu hardware falla el 1% del tiempo, eso significa que 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 1% de probabilidad de estar inoperativa en un día dado, significa que aproximadamente cada 10 días algo falla en tu red. Es, de hecho, un desafío. ¿Qué soluciones sugerirías para esta situación?
Joannes Vermorel: La redundancia es lo primero que se me viene a la mente, pero me gustaría discutir las implicaciones en términos de computación distribuida, y quizá luego podamos hablar sobre pequeñas versus grandes empresas y la disparidad entre proveedores. Desde el punto de vista de la computación distribuida, el objetivo es garantizar que cada bloque sea altamente redundante. Esta es la esencia de computación en la nube. Quieres tener un software fuertemente 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 activos. Google Mail, por ejemplo, está literalmente siempre activo. El sitio web de Yahoo básicamente siempre está activo. Facebook también siempre está activo. Por lo tanto, es posible diseñar estas propiedades de “siempre activo” para tus aplicaciones, lo que mejora 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 fallo en el software son altas. La gente no se da cuenta de que quizá la mitad de las iniciativas de software fracasan. Mi estimación sería que entre un tercio y la mitad de todos los proyectos de TI de supply chain fracasan en empresas de prácticamente cualquier tamaño. Hace unas semanas, Lidl en Alemania básicamente perdió medio billón de euros en una transición SAP fallida. 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 tengan una mejor tasa de éxito, pero si hablamos de cifras aproximadas, estamos pasando de un proveedor pequeño con una tasa de fallo del 50% —lo cual es bastante malo— a un proveedor grande con una tasa de fallo del 30%. Entonces, cuando haces la transición de una empresa pequeña a una grande, tu riesgo disminuye ligeramente, pero solo un poco.
Si optas por un enfoque altamente modular, sí, habrá muchas cosas que fallarán, pero tendrás la oportunidad de intentarlo de nuevo y repetir hasta lograr el éxito. Cada componente tiene la posibilidad de fallar, pero debido a que el alcance es más simple y la aplicación en sí es más pequeña, puedes fallar rápido y reintentar.
Lo de la estrategia de Lidl es que estoy bastante seguro de que inicialmente no planearon una migración de siete años. Probablemente se trataba de 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 la esperanza de que el proyecto tuviera éxito.
Kieran Chandler: Entonces, si estamos de acuerdo en que estas aplicaciones, una vez que encuentras la adecuada y quizá iteras un poco, pueden ser confiables… Parecen funcionar y parecen estar haciendo el mismo trabajo que un sistema de mayor envergadura. ¿Qué hay de la intersección entre esas aplicaciones? Porque muchas veces, una aplicación podría hacer otra cosa bien y podría haber un poco de intersección y conflicto dentro de ese sistema. ¿Cómo se maneja eso?
Joannes Vermorel: Primero, cuando eliges la composición de tu panorama de aplicaciones, realmente quieres elegir aplicaciones que tengan un alcance reducido. Este enfoque va completamente en contra de lo que hacen la mayoría de las Solicitudes de Propuesta (RFPs). Cuando las empresas buscan adquirir una pieza de software, a menudo optan por un RFP y quieren todo —todas las características, todos los adornos y campanas. Pero eso es lo opuesto a lo que se debe buscar. Quieres algo que sea extremadamente reducido, de modo que, por diseño, minimices tus traslapes.
Si compras grandes frameworks, es una receta para tener traslapes. Los proveedores empresariales están interesados en venderte grandes frameworks porque pueden extenderlos con muchas características. Te venden algo, y luego te venderán los complementos adicionales encima. Así que, diría a las personas que gestionan grandes supply chains, tengan mucho cuidado cuando se les venda una plataforma.
Una plataforma es buena, pero dos plataformas pueden ser una pesadilla. En cuanto tienes varios proveedores vendiéndote plataformas, terminas con un mar de traslapes. La solución es elegir cuidadosamente la composición de tus ingredientes.
En términos de “pegamento”, el enfoque es que, típicamente, es algo que deseas desarrollar internamente. Esto podría ir en contra de la intuición de por qué querrías desarrollar cualquier tipo de software internamente. La respuesta es que, si eres una empresa de cierto tamaño, tu panorama de aplicaciones es completamente único para ti.
Incluso si utilizas todas las aplicaciones estándar, necesitarás múltiples aplicaciones. No es posible que hoy en día tengas un ERP que pueda gestionar correos electrónicos, videoconferencias y demás. No puedes incorporar todas las funcionalidades de software que necesitas en una sola aplicación. Probablemente usarás Microsoft Excel, como todos los demás, por lo que necesitarás 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, de todos modos, una colección de software. La receta exacta, es decir, la lista de software que literalmente dirige tu empresa, será, de todas formas, completamente única para ti. Ninguna otra empresa está organizada exactamente como tú.
Kieran Chandler: Es completamente único, esa es tu ADN. Puedes tener ese pegamento que implementas internamente. Ese es el punto de la arquitectura orientada a servicios: hacer que ese pegamento sea lo más simple y esbelto de implementar, de modo que puedas tener un equipo de TI muy ágil con esfuerzos mínimos para desarrollar ese software a medida que simplemente une las cosas. Entonces, para resumir, si soy un CEO, ¿cómo evito otro desastre tipo Lidl?
Joannes Vermorel: Primero, creo que es esencial pensar en el riesgo en lugar de minimizarlo. El desastre tipo Lidl fue producto de que la gente dijera, “No queremos asumir ningún riesgo”, y así optaron por el proveedor más grande disponible e intentaron tener el producto que lo hiciera 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 del riesgo.
Necesitas pensar completamente lo contrario, es decir, “¿Cómo puedo tener algo que falle rápido si tiene que hacerlo?” Mira, el problema con el riesgo es que, cuando tienes un proyecto tan masivo, no sabes durante mucho tiempo si has fallado o no. Lo que deseas es tener algo que sea más de “fail fast”, donde se sepa si fallaste, y el fallo sea a pequeña escala. Y si necesitas un reemplazo, tienes un alcance manejable, y lo haces con muchos fragmentos pequeños.
Así que, piénsalo como lo opuesto a prevenir el riesgo. Estoy diciendo que, al pasar de un proveedor grande a uno pequeño, podrías aumentar el riesgo del 50% de probabilidad de fallo al 50%. Al final, si una probabilidad de fallo del 30% significa que tu empresa se declare en quiebra o que la supply chain se detenga, no es un riesgo que puedas asumir. Por lo tanto, tienes que planear para el fallo de todas maneras.
Mi idea es que, dado que un alto grado de riesgo es inevitable, opta directamente por un plan para el fallo. Intenta tener fallos pequeños, rápidos y con un alcance bien definido para que puedas iterar, en lugar de decir que vamos a hacer todo bien a la primera, lo cual es un pensamiento ilusorio. Luego, emprendes un camino 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. Así que eso es todo por esta semana. Volveremos nuevamente la próxima semana con otro episodio. Hasta entonces, gracias por ver.
