La arquitectura de software ¿es un rol o una habilidad? - Santiago Sánchez

Cuando hablamos de arquitectura de software, solemos pensar en diagramas, roles específicos y años de experiencia. Sin embargo, la realidad es que todas las personas que construyen software ya están tomando decisiones de arquitectura, muchas veces sin darse cuenta. Entender esta premisa cambia por completo la forma en que los equipos crecen y escalan sus productos.

¿Cuál es la diferencia entre arquitectura, patrón y estilo arquitectónico?

Uno de los primeros retos es distinguir tres conceptos que suelen confundirse [0:12]. La arquitectura es el mecanismo que describe los diferentes elementos de un sistema creado para resolver una necesidad de negocio. Esos elementos pueden ser servicios de backend, frontend, bots o pipelines de datos. Lo importante es que la arquitectura habla de descripciones e interacciones, no de detalles de implementación. Se apoya en herramientas como diagramas UML, entidad-relación o el modelo C4.

Un patrón arquitectónico, en cambio, es una solución recurrente a un problema recurrente de arquitectura [1:42]. Por ejemplo:

• El patrón MVC (modelo vista controlador) busca separar responsabilidades entre la interfaz de usuario y el modelo de datos.
• Los patrones hexagonales buscan reducir el acoplamiento entre el negocio, la infraestructura, los drivers y las tecnologías.

Finalmente, un estilo arquitectónico le da forma y nombre a un mecanismo de implementación, pero no necesariamente resuelve un problema específico [2:37]. Ejemplos claros son los monolitos, los microservicios, los micro frontends, los mono repos o el estilo pipeline filter en datos.

¿Cómo se relacionan estos tres conceptos?

La relación es jerárquica: las arquitecturas están compuestas de estilos arquitectónicos, y cada estilo puede emplear diferentes patrones arquitectónicos [3:14]. Esa estructuración es lo que permite dar forma al software de manera coherente.

¿Por qué la arquitectura debería ser una habilidad y no solo un rol?

En plataformas de empleo vemos constantemente posiciones de software architect. Esto responde muchas veces a modelos empresariales que necesitan crear un path de crecimiento profesional [3:50]. El problema surge cuando las personas que ocupan estos roles se enfocan exclusivamente en describir cómo se comportan las cosas, pero no en cómo producir ese pensamiento en el resto del equipo.

La pregunta clave es: ¿cómo logramos que una persona que recién comienza su carrera en desarrollo de software también pueda tomar decisiones de arquitectura? [4:18]

¿Qué tres habilidades nos acercan al pensamiento arquitectónico?

Se identifican tres capacidades fundamentales que cualquier persona puede desarrollar:

• Pensar en atributos de calidad. No basta con construir funcionalidades visibles. Cada vez que escribimos código deberíamos preguntarnos cómo lo vamos a testear, cómo será el proceso de release y despliegue, si el flujo de trabajo colaborativo funciona —ya sea trunk-based development, GitFlow o ForkFlow— e incluso considerar el performance [5:06]. Pensar en mantenibilidad es fundamental para la introducción de features y la solución de bug fixes.

• Entender el ciclo de desarrollo completo. Desde el backend hasta el frontend, pasando por QA, infraestructura y datos [7:02]. No se trata de ser experto en todo, sino de comprender qué sucede en cada parte del sistema. Si estamos en un on call y cae un pipeline de datos, no podemos simplemente decir "yo soy backend, no me corresponde".

• Identificar los trade-offs. Todo en el software tiene un costo asociado [8:00]. No existen implementaciones perfectas. Cada herramienta, tecnología o decisión que tomamos conlleva un problema potencial. La habilidad está en identificar esos compromisos para presentar soluciones que, aunque no eliminen el problema por completo, simplifiquen su resolución a corto, mediano o largo plazo.

¿Cómo democratizar las decisiones de arquitectura en equipos ágiles?

El objetivo es que todos los integrantes del equipo sean partícipes de las decisiones que se toman [8:42]. Esto abarca desde los requerimientos de producto hasta la mantenibilidad y escalabilidad del código. Cuando el conocimiento se horizontaliza, el entorno se vuelve escalable: todas las personas crecen profesionalmente y, como consecuencia, los productos y las empresas también lo hacen.

El software exige estudio constante. Leer sobre incidentes, aprender a contextualizar lo que construimos y dedicar aunque sea una hora al día a expandir nuestro conocimiento nos dará la capacidad de tomar mejores decisiones. La arquitectura no es un título reservado para unos pocos, es una habilidad que se cultiva todos los días.