De Agilidad y otras hierbas

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

Han visto que siempre cuando uno sale con paraguas porque el cielo parece el fin del mundo, termina volviendo a la casa con el paraguas seco y la frente quemada por el sol. Curiosa costumbre humana esa de prepararse para la tormenta que nunca llega. En los puestos de jefatura pasa algo parecido. He conocido personas que siempre esperan el peor resultado posible. Si un proyecto va bien, imaginan que algo explotará. Si el equipo está motivado, sospechan que pronto aparecerá un problema. Si los números mejoran, creen que es cuestión de tiempo para que todo se derrumbe. Y ojo, no siempre nace del pesimismo. Muchas veces nace de la responsabilidad. Cuando te toca responder por otros, aprendes a mirar los riesgos. Aprendes a preguntarte qué podría salir mal. Es una habilidad necesaria. El problema aparece cuando la prevención se transforma en residencia permanente y uno termina viviendo en el peor escenario imaginable. Un líder que solo ve catástrofes termina transmitiendo catástrofes. El eq...

Han visto que siempre cuando en una casa hay un solo control remoto bueno… aparece el guardián supremo del aparato. El individuo que lo esconde entre cojines como si protegiera códigos nucleares. Y cuando alguien pregunta: “¿dónde está el control?” responde con una sonrisa sospechosa: “yo lo tengo… ¿qué quieren ver?” Pequeñas dictaduras domésticas. En las organizaciones pasa exactamente igual. Existen herramientas increíbles: información, sistemas, accesos, automatizaciones, conocimiento, contactos, experiencia. Cosas capaces de acelerar equipos completos. Pero de pronto aparece alguien que tiene “la llave”… y transforma el acceso en mecanismo de poder personal. No comparte. No enseña. No documenta. No habilita. Porque en el fondo tiene miedo. Miedo a dejar de ser indispensable. Y ahí comienza una de las corrupciones más silenciosas del trabajo moderno: secuestrar el conocimiento para alimentar el ego. Lo disfrazan de: “es que es delicado” “es que nadie más sabe usarlo” “es que después...