De Agilidad y otras hierbas

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...

Han visto que siempre cuando alguien compra una cocina nueva, cree que automáticamente se convirtió en chef. La cocina ayuda. Pero el estofado todavía puede quedar horrible. Con DevOps y la automatización pasa exactamente lo mismo. Muchas organizaciones creen que porque tienen pipelines, scripts, despliegues automáticos o infraestructura como código ya son DevOps. No. Eso es automatización. Y la diferencia es mucho más importante de lo que parece. La automatización consiste en que las máquinas hagan tareas repetitivas por nosotros. Desplegar aplicaciones. Crear servidores. Ejecutar respaldos. Configurar ambientes. Actualizar sistemas. Todo eso es valioso. Y mientras más repetitiva sea una tarea, más sentido tiene automatizarla. Pero DevOps es otra cosa. DevOps es una cultura. Es una forma de trabajar donde desarrollo, operaciones, seguridad y negocio dejan de actuar como islas enemigas que se lanzan problemas por encima de un muro. Porque seamos honestos. Durante años el modelo fue más...

Han visto que siempre cuando alguien decide ponerse en forma después de quince años sin hacer ejercicio, al segundo día ya está mirando zapatillas profesionales, relojes deportivos de última generación y videos de atletas olímpicos. Todavía no logra subir una escalera sin jadear, pero ya está comparándose con quienes llevan años entrenando. Las organizaciones atrasadas digitalmente suelen caer en la misma trampa. Un día despiertan y descubren que están quince años detrás del mercado. Los procesos siguen en planillas eternas, los correos reemplazan sistemas completos, las aprobaciones pasan por cinco escritorios y todavía existen documentos que parecen haber sobrevivido a varias eras geológicas. Entonces aparece la gran idea: "Tenemos que estar al nivel de los líderes de la industria en doce meses." Y ahí comienza la carrera. Compran plataformas gigantescas. Contratan consultoras. Hablan de inteligencia artificial, automatización, analítica avanzada y transformación digital co...