El trabajo real
Gran parte del trabajo de un arquitecto de software no tiene que ver con diseñar sistemas desde cero ni con tomar grandes decisiones visibles.
La mayor parte del tiempo se va en lidiar con un sistema que ya existe, con restricciones que no elegimos y con un contexto que cambia más rápido de lo que nos gustaría.
Diseñar ocurre, pero es una parte pequeña del trabajo. Lo habitual es navegar la incertidumbre, gestionar compromisos y ayudar al equipo a avanzar sin romper más cosas de las necesarias.
Traductores de contextos
Una parte inmensa del trabajo es puramente lingüística. Nos convertimos en un traductor entre mundos que, por defecto, no se entienden.
Pasamos el día traduciendo necesidades de negocio (que suelen hablar de tiempo, coste y oportunidad) a realidades técnicas (que hablan de latencia, consistencia y deuda). Y viceversa.
El reto no es solo traducir palabras, sino intenciones y riesgos.
Es explicarle a un manager por qué ese “cambio pequeño” implica reescribir el modelo de datos sin que suene a excusa. Y a su vez, es explicarle al equipo técnico por qué hay que lanzar una solución aceptable la próxima semana en lugar de la solución perfecta dentro de tres meses. Y todo esto, sin desmotivar a nadie y sabiendo que ni siquiera tú terminas de estar de acuerdo.
A menudo, el mayor valor que aportamos es detectar que algo que parece un problema técnico es, en realidad, un problema de definición de producto.
El arte de elegir el problema
En el trabajo real, casi nunca tenemos toda la información necesaria para tomar una decisión. Y cuando la tenemos, solemos encontrarnos con que no hay opciones buenas.
El día a día consiste en elegir conscientemente qué problema preferimos tener.
A veces se trata de decidir entre la complejidad de un sistema distribuido o el cuello de botella de uno monolítico. Otras veces entre duplicar datos o acoplar servicios. En otros casos, entre asumir ahora un coste de licencia o pagar más adelante el mantenimiento de una solución propia.
Muchas más veces de las que nos gustaría nos toca firmar decisiones impopulares. Aceptamos una deuda técnica visible hoy para evitar un bloqueo invisible mañana. No buscamos la solución perfecta, sino el mal menor que nos permita seguir avanzando.
Guardianes de la simplicidad
La experiencia no te aleja del código, pero sí te hace más consciente del coste de cada línea que añades.
No se trata de rechazar la innovación. Al revés: si la última versión del framework o la nube nos permite hacer más con menos, bienvenida sea. El problema no es lo nuevo, es lo innecesario.
Gran parte de nuestra labor consiste en proteger al equipo de la complejidad accidental.
Eso implica hacer de barrera ante la “ingeniería orientada al currículum” o ante la presión por adoptar patrones por pura moda. Nuestro trabajo es aplicar KISS con rigor, usando la tecnología porque resuelve un problema real del negocio, no porque quede bien en el diagrama.
Convivir con el pasado
Casi nunca empezamos desde cero. Lo normal es aterrizar en un sistema con historia, con parches de hace cinco años y con decisiones que tenían sentido entonces pero que hoy duelen.
Es fácil caer en la crítica y juzgar a quienes lo construyeron. Pero el trabajo real consiste en entender el legacy como contexto, no como un error. Lo habitual es que ese código “feo” haya pagado las nóminas hasta hoy.
Nuestra responsabilidad no es reescribirlo todo por purismo (eso suele ser un suicidio comercial), sino trazar una estrategia de convivencia. Decidir qué partes se pueden salvar, cuáles hay que aislar y cuáles hay que dejar morir lentamente.
Es un trabajo de arqueología y de diplomacia tanto como de ingeniería.
El trabajo invisible y el ego
Lo más difícil de este rol es que, si lo haces bien, a veces parece que no has hecho nada.
Los problemas que evitas antes de que ocurran no salen en los informes.
La complejidad que lograste no introducir no se puede medir.
Las reuniones donde alineaste a varios equipos para que no chocaran entre sí no generan código.
Esto requiere dejar el ego en la puerta. No estamos aquí para tener razón ni para ser la persona más lista de la sala. Estamos para que el sistema sea sostenible y el equipo pueda trabajar sin fricción.
A veces eso implica decir “me equivoqué” y cambiar el rumbo cuando los datos demuestran que la hipótesis inicial era incorrecta. Rectificar una decisión propia duele menos que arrastrar al equipo por un precipicio solo por orgullo.
Al final, la arquitectura no es lo que dibujas. Es lo que sobrevive cuando tú no estás mirando.