Fíjate que hace poco hablaba con un colega sobre qué diferencia a un “Senior que solo pica código” de un Arquitecto de Software. Muchos piensan que ser arquitecto es pasar el día haciendo diagramas en Lucidchart o decidiendo si vamos a usar Microservicios porque “está de moda”. Pero no funciona exactamente así, en el mundo real pocas veces la verdad se queda en la casilla donde queremos que esté.
¿Se puede decir que eres Senior si no tomas decisiones de arquitectura? Yo creo que no. El futuro de la empresa en gran parte depende de las decisiones de arquitectura que se tomen y ser Senior implica tomar esas decisiones de forma consciente. Así que indirectamente estás haciendo trabajo de arquitecto de software. ¿Ves lo difusa que es la línea que separa a un Senior de un Arquitecto?
Ser arquitecto es, en esencia, gestionar el caos y tomar decisiones difíciles. Es entender que cada solución que elijas hoy es una deuda técnica que vas a pagar (con intereses) mañana.
Así que la pregunta que nos hacíamos era: ¿Puedes ser arquitecto sin ser un desarrollador Senior? ¿Puedes ser desarrollador Senior sin tomar decisiones de arquitectura?
El catálogo de problemas (y por qué no reinventar la rueda)
Un error de novato es creer que nuestro problema es único en el universo. “Cheque, nadie ha hecho un sistema de inventarios como el mío”. Mentira. La experiencia hace al Senior ¿cierto? eso es porque ya has visto muchos problemas y has aprendido a resolverlos. Es justo lo que debe conocer un arquitecto, conocer los problemas comunes y saber cómo resolverlos.
La mayoría de los problemas en software ya fueron resueltos hace 20 años. La diferencia es que un buen arquitecto tiene un “catálogo mental” de patrones de diseño y los puntos en los que pueden modificarse y adaptarse a las necesidades del proyecto.
- ¿Tenés problemas de consistencia de datos? Mirá Event Sourcing.
- ¿Tu aplicación de .NET se está volviendo un monolito inmanejable? Quizás es hora de aplicar Bounded Contexts de DDD.
- ¿Vienes de React y sientes que el estado de tu app en Android es un relajo? Implementar MVI (Model-View-Intent) te va a salvar la vida.
Saber identificar el problema es el 50% del trabajo. El otro 50% es saber qué herramienta sacar de la caja sin que te cueste un ojo de la cara en mantenimiento.
¿Por qué un Arquitecto DEBE seguir programando?
Aquí es donde me pongo serio. He visto “arquitectos” que no han tocado una terminal en cinco años. Eso, para mí, es un peligro.
Si no programas, perdés la sensibilidad de lo que tus decisiones le hacen al equipo. Es fácil decir “usa Microservicios” en una pizarra, pero si no sabes lo que duele configurar un Service Mesh o debuguear una petición distribuida en Nodejs, estás mandando a tu equipo a la guerra con tenedores.
Tip de Pro: Un arquitecto que programa entiende los “Trade-offs”. Sabe que elegir una base de datos NoSQL le da velocidad de desarrollo ahora, pero le va a complicar los reportes relacionales al equipo de Data después.
La capacidad de ver “The Big Picture”
Un arquitecto es como un director de orquesta. Mientras el desarrollador está enfocado en que el botón de React haga el fetch correctamente (lo cual está de lujo), el arquitecto está pensando:
- ¿Qué pasa si la API se cae?
- ¿Cómo escalamos esto si mañana entran 100,000 usuarios de un solo?
- ¿Es esta solución mantenible por alguien que no sea yo?
Si vienes de lenguajes como Go, sabrás que la simplicidad es una característica arquitectónica. A veces, la mejor arquitectura es la que tiene menos piezas móviles.
Dato para Ingenieros: La arquitectura limpia (Clean Architecture) no es una regla de oro, es una guía. No siempre necesitas 5 capas de abstracción para un CRUD sencillo. Aprender a decir “esto es demasiado” es una habilidad senior.
Ejemplo práctico: Decisiones que duelen
Imagina que estás diseñando el backend para una App de delivery en Centroamérica. Podrías usar Express en Nodejs por la rapidez, pero sabes que el manejo de tipos en un sistema financiero es crítico.
Antes de empezar, instalas TypeScript para asegurar que esos modelos de datos sean sólidos:
// Instalación de dependencias base
// npm install express typescript @types/node @types/express ts-node
// Definición de un contrato de interfaz para pedidos
interface Order {
id: string;
total: number;
status: "PENDING" | "SHIPPED" | "DELIVERED";
createdAt: Date;
}
// Un arquitecto define la abstracción antes que la implementación
interface IOrderRepository {
save(order: Order): Promise<void>;
findById(id: string): Promise<Order | null>;
}Al definir esa interfaz IOrderRepository, le estás diciendo al equipo: “No me importa si usamos MongoDB, PostgreSQL o un archivo de texto; lo que me importa es que el dominio de la aplicación sepa cómo guardar y buscar pedidos”. Eso es arquitectura.
La arquitectura de software no es un destino, es un proceso continuo. Se trata de conocer los problemas comunes, estudiar las soluciones probadas y, sobre todo, tener la humildad de aceptar que no existe la solución perfecta, solo la solución que mejor se adapta a tus restricciones actuales.
Si quieres subir de nivel, deja de aprender solo sintaxis y empieza a estudiar por qué las cosas se rompen cuando crecen. Entre mejor programador eres, mejor arquitecto serás.
¿Qué te parece? ¿Crees que un arquitecto puede ser bueno sin haber tocado código en años o es un requisito obligatorio “estar en las trincheras”? ¡Dejamelo en los comentarios!
¿Te gustaría que escribiera sobre algún patrón de diseño específico como Observer o Factory en el próximo post? Pero así, explicado con peras y manzanas. ¡Contame!