Qué es una arquitectura de software

Cuando se construye una casa, lo primero que se hace no es mezclar cemento. Lo primero es contratar un arquitecto, que diseña los planos. Los planos definen dónde van las paredes, dónde están las puertas, cómo circula la luz, dónde pasan las cañerías y los cables. Sin planos, la casa puede construirse, pero lo más probable es que tenga problemas: habitaciones mal distribuidas, filtraciones, cables que cruzan donde no deben, y dificultad para ampliarla después.

La arquitectura de software es exactamente eso: los planos de un sistema. Define cómo se organizan los componentes del software —los módulos, las bases de datos, los servicios, las interfaces— y cómo se relacionan entre sí. Es la estructura fundamental sobre la que se construye todo lo demás.

¿Por qué debería importarle a un empresario?

Esta es la pregunta clave. La arquitectura de software suena a un tema puramente técnico, y en parte lo es. Pero las decisiones arquitectónicas tienen consecuencias directas sobre el negocio:

• Velocidad de desarrollo. Una arquitectura bien diseñada permite que varios equipos trabajen en paralelo sin pisarse. Una mal diseñada hace que cada cambio requiera modificar muchas partes del sistema, ralentizando el desarrollo.
• Costo de mantenimiento. Una arquitectura limpia es más barata de mantener. Los bugs se encuentran y corrigen más rápido. Agregar nuevas funcionalidades es predecible. Una arquitectura enmarañada hace que cada cambio sea una aventura.
• Capacidad de escalar. Como se explica en el artículo sobre qué significa escalar un software, la arquitectura determina si el sistema puede crecer sin degradarse. Una arquitectura monolítica —todo en un solo bloque— es difícil de escalar. Una arquitectura modular permite escalar solo las partes que lo necesitan.
• Tiempo de respuesta al mercado. Si la arquitectura está bien pensada, agregar una nueva funcionalidad puede tomar días. Si está mal, puede tomar meses.
• Riesgo técnico. Una arquitectura frágil aumenta la probabilidad de que un cambio chico rompa algo inesperado.

La analogía de la casa, extendida

Sigamos con la analogía de la casa porque funciona muy bien para entender distintos conceptos de arquitectura.

Arquitectura monolítica es como construir una cabaña de un solo ambiente. Todo está en el mismo espacio: la cocina, el living, el dormitorio. Es simple de construir y funciona bien para una o dos personas. Pero si querés ampliarla —agregar un baño, un segundo piso—, hay que romper paredes, rehacer instalaciones, y probablemente sea más fácil demoler y reconstruir.

Muchos sistemas empiezan como monolitos. Es la forma más natural y rápida de construir. El problema aparece cuando el sistema crece y todos los cambios afectan a todo.

Arquitectura modular es como una casa con habitaciones separadas. Cada ambiente tiene su propósito y está conectado con los demás a través de puertas (interfaces bien definidas). Podés remodelar la cocina sin tocar el baño. Podés agregar un dormitorio nuevo sin modificar el living.

En software, la arquitectura modular organiza el sistema en módulos independientes que se comunican a través de interfaces claras. Cada módulo puede modificarse o reemplazarse sin afectar al resto.

Arquitectura de microservicios es como un conjunto de casas pequeñas conectadas por caminos, en lugar de una casa grande con muchas habitaciones. Cada casa tiene una función específica y puede construirse, mantenerse y escalarse de forma independiente. Si la "casa de pagos" necesita más recursos, se escala sin tocar la "casa de usuarios".

Los microservicios son flexibles y escalables, pero también más complejos de coordinar. No todas las aplicaciones los necesitan.

¿Qué hace que una arquitectura sea buena o mala?

No existe una arquitectura "correcta" universal. La buena arquitectura depende del contexto: el tamaño del equipo, la etapa del proyecto, los requisitos de escalabilidad, el presupuesto. Pero hay principios que aplican en casi todos los casos:

Separación de responsabilidades. Cada componente del sistema debería tener una responsabilidad clara y limitada. El módulo que maneja usuarios no debería también generar facturas. Esto facilita entender, modificar y probar cada parte por separado.

Bajo acoplamiento. Los componentes deberían depender lo menos posible unos de otros. Si cambiar algo en el módulo A obliga a cambiar también el módulo B, C y D, el acoplamiento es alto y la arquitectura es frágil.

Alta cohesión. Dentro de un componente, todo debería estar relacionado con su propósito. Las funcionalidades de un módulo deberían tener sentido juntas. No mezclar lógica de facturación con lógica de envío de correos dentro del mismo componente.

Capacidad de prueba. Una buena arquitectura permite probar cada componente de forma aislada. Si para probar una funcionalidad necesitás tener todo el sistema funcionando, la arquitectura no está bien diseñada.

Evolucionabilidad. La arquitectura debería facilitar agregar nuevas funcionalidades sin romper las existentes. La pregunta no es solo "¿funciona hoy?" sino "¿qué tan fácil va a ser modificarlo el próximo año?".

Arquitectura y equipo técnico

La calidad de la arquitectura de un sistema está directamente relacionada con la calidad del equipo que la diseñó —y con el tiempo que se le dedicó. Una arquitectura apurada, hecha sin pensar en el mediano plazo, tarde o temprano genera problemas.

Esto no significa que todo proyecto deba pasar meses diseñando la arquitectura perfecta antes de escribir una línea de código. El enfoque moderno es diseñar lo suficiente para los próximos meses, sabiendo que la arquitectura va a evolucionar. Pero evitar ciertas malas decisiones tempranas —como elegir una tecnología que se sabe que no escala, o no separar responsabilidades que claramente van a crecer— marca una diferencia enorme.

La deuda técnica arquitectónica

Cuando la arquitectura se descuida, se acumula deuda técnica. Es como tener una casa donde se fueron posponiendo reparaciones: la gotera en el techo se parcha, el enchufe que no funciona se ignora, la puerta que traba se fuerza. Cada parche funciona por un tiempo, pero eventualmente la casa se vuelve inhabitable.

En software, la deuda técnica arquitectónica se manifiesta como:

• Código que da miedo modificar porque no se sabe qué puede romper.
• Funcionalidades que tardan cada vez más en implementarse.
• Bugs que aparecen en lugares inesperados.
• Incorporar un nuevo desarrollador al equipo requiere meses.

El artículo sobre qué métricas técnicas debería conocer un founder ofrece indicadores para detectar si la arquitectura de tu sistema está acumulando deuda técnica que después va a costar cara.

La arquitectura de software no es un tema que debas delegar ciegamente. Sin necesidad de entender los detalles técnicos, como empresario deberías poder reconocer si el equipo que construye tu sistema está pensando en la arquitectura o solo en "que funcione hoy". La diferencia se nota —tarde o temprano— en el bolsillo.