De Agilidad y otras hierbas

Han visto que siempre cuando alguien se compra un teléfono nuevo, hay dos tipos de personas. La primera aprieta botones, investiga, se equivoca, pregunta y en una semana ya domina funciones que ni el fabricante sabía que existían. La segunda usa el mismo equipo durante cinco años exactamente igual que el primer día y se enoja cuando algo cambia de lugar. En tecnología pasa algo parecido. Nadie está obligado a saberlo todo. De hecho, es imposible. Las tecnologías cambian más rápido que los organigramas y aparecen herramientas nuevas antes de que terminemos de aprender las anteriores. Por eso, no saber algo jamás debería ser motivo de crítica. Lo preocupante aparece cuando una persona decide que tampoco quiere aprenderlo. Porque ahí el problema deja de ser técnico. Se transforma en cultural. He visto profesionales con décadas de experiencia reinventarse varias veces durante su carrera. Y también he visto personas quedarse detenidas durante diez años defendiendo el mismo conocimiento mien...

Han visto que siempre cuando alguien guarda una receta solamente en su memoria, está convencido de que jamás la olvidará. Hasta que llega el día en que intenta repetirla y descubre que faltan ingredientes, pasos y detalles que parecían imposibles de olvidar. En tecnología ocurre algo parecido. Por eso la pregunta muchas veces no debería ser: "¿Por qué utilizar Infraestructura como Código?" Sino más bien: "¿Por qué seguir sin utilizarla?" Porque cuando una organización decide administrar infraestructura manualmente, está aceptando una serie de riesgos que suelen pasar desapercibidos. Cada servidor configurado a mano puede terminar siendo distinto. Cada cambio manual puede introducir errores difíciles de rastrear. Cada procedimiento no documentado puede transformarse en dependencia de una sola persona. Cada emergencia puede convertirse en una expedición arqueológica para descubrir cómo fue configurado algo años atrás. Como viejo gruñón tecnológico, he escuchado varias...

Han visto que siempre cuando alguien tiene que armar un mueble por segunda vez, piensa: "Ahora sí me acuerdo cómo era." Y termina mirando el manual nuevamente porque la memoria humana tiene una relación bastante creativa con la realidad. Durante décadas, gran parte de la infraestructura tecnológica funcionó de forma parecida. Servidores configurados a mano. Redes creadas siguiendo instrucciones guardadas en correos antiguos. Cambios realizados a las tres de la mañana por alguien que prometió documentarlos después. Y todos sabemos cómo termina esa historia. Con un archivo llamado "versión_final_definitiva_ahora_si_v12.xlsx". La Infraestructura como Código llegó para resolver ese problema. Transformó configuraciones manuales en código reutilizable, versionado y reproducible. Pero ahora estamos entrando en una nueva etapa. La Infraestructura como Código asistida por Inteligencia Artificial. Y no, no significa que una IA administrará sola todo el centro de datos mientra...

Han visto que siempre cuando alguien deja las llaves en un lugar "para no olvidarlas", termina olvidando dónde las dejó. Y después pasa media hora buscando algo que podría haberse evitado con una simple costumbre. Las organizaciones hacen algo parecido todos los días. Repiten errores conocidos. Olvidan lecciones aprendidas. Ignoran señales tempranas. Y vuelven a tropezar con problemas que ya habían resuelto antes. Por eso aparece una pregunta interesante: ¿Podemos utilizar Inteligencia Artificial para prevenir errores? La respuesta corta es sí. Pero probablemente no de la forma que muchos imaginan. La IA no es una bola de cristal. No puede predecir el futuro con certeza. No sabe qué ocurrirá mañana. Lo que sí puede hacer es detectar patrones que los seres humanos suelen pasar por alto. Puede identificar comportamientos anómalos. Puede encontrar tendencias. Puede advertir desviaciones. Puede analizar miles o millones de registros mucho más rápido que cualquier equipo humano. Y...

Han visto que siempre cuando alguien quiere construir una casa, pasa horas eligiendo el color de las paredes, la terraza soñada y el tamaño de las ventanas. Pero rara vez pregunta primero cómo está el suelo donde piensa construirla. Y después vienen las sorpresas. Porque una casa espectacular construida sobre un terreno inestable sigue siendo un problema espectacular. En tecnología ocurre algo parecido entre la Arquitectura de Soluciones y la Arquitectura de Infraestructura. Desde lejos parecen similares. Desde cerca tienen responsabilidades muy distintas. La Arquitectura de Soluciones mira el negocio y los sistemas como un todo. Se preocupa por responder preguntas como: ¿Cómo resolvemos esta necesidad? ¿Qué aplicaciones participan? ¿Cómo se integran? ¿Qué experiencia tendrá el usuario? ¿Qué datos viajarán entre sistemas? ¿Cómo generamos valor para la organización? Su foco está en la solución completa. La Arquitectura de Infraestructura, en cambio, mira los cimientos. Se preocupa por l...

Han visto que siempre cuando alguien compra un terreno, lo primero que hace es imaginar la casa terminada. Ve la terraza, el jardín, la cocina y hasta dónde irá la parrilla. Pero entre esa idea y la casa construida existe una pequeña diferencia llamada realidad. Y esa realidad necesita planos, cálculos, materiales y mucha gente trabajando en conjunto. En tecnología ocurre algo parecido. Muchas veces se confunde Arquitectura de Soluciones con Desarrollo de Software, como si fueran la misma disciplina con distinto nombre. Pero no lo son. El arquitecto de soluciones mira el problema completo. Entiende el negocio. Evalúa restricciones. Analiza sistemas existentes. Define integraciones. Considera seguridad, escalabilidad, costos, operación y sostenibilidad. Su pregunta principal es: "¿Cuál es la mejor forma de resolver este problema?" El desarrollador, en cambio, transforma esa visión en realidad. Diseña componentes. Escribe código. Construye funcionalidades. Prueba soluciones. Co...