Qué hace un arquitecto: responsabilidades, habilidades y tipos de arquitecto

Para qué sirven los arquitectos

Si la arquitectura es el conjunto de decisiones y estructuras significativas de un sistema (Sección 1.1), el arquitecto es quien asume la responsabilidad de que esas decisiones se tomen bien, los demás las entiendan y se mantengan vigentes a medida que cambia el sistema. Parece sencillo, pero el rol es uno de los que se definen de forma menos coherente en el software. En una empresa, un arquitecto es un ingeniero sénior que sigue escribiendo código a diario; en otra, un miembro de un equipo central que revisa diseños y mantiene estándares; en una tercera, una persona que sobre todo habla con los líderes de negocio y los proveedores.

Detrás de esta variedad hay un núcleo común. Los arquitectos toman o guían decisiones costosas de revertir, cuidan las cualidades del sistema completo y no de una sola parte, y conectan las decisiones técnicas con los objetivos de negocio. El resto de esta sección describe lo que eso implica, qué habilidades requiere y cómo se organiza el rol.

Ocho expectativas de un arquitecto

Mark Richards y Neal Ford, en Fundamentals of Software Architecture (O'Reilly, 1.ª edición 2020, 2.ª edición 2025), describen ocho expectativas fundamentales de un arquitecto, sea cual sea el cargo o la empresa. A continuación se parafrasean, con un ejemplo de cada una tomado de una empresa de reparto de comida.

Fíjate en qué pocas de las ocho son puramente técnicas. Richards y Ford insisten en que casi todas las decisiones que toma un arquitecto serán cuestionadas por alguien (desarrolladores, otros arquitectos, propietarios del producto, jefes de proyecto), así que la negociación y la persuasión son habilidades centrales, no extras. Una arquitectura correcta sobre el papel, pero que no se entiende ni se acepta, no se construirá como se pretendía.

La visión de iSAQB sobre las tareas de los arquitectos

El International Software Architecture Qualification Board (iSAQB), cuyo plan de estudios de nivel Foundation (CPSA-F) se usa ampliamente en Europa, describe las tareas y responsabilidades de los arquitectos de forma parecida. En resumen, los arquitectos: aclaran y examinan a fondo los requisitos y las restricciones; deciden cómo descomponer el sistema en bloques de construcción con sus dependencias e interfaces; deciden sobre inquietudes transversales (cross-cutting concerns) como la persistencia, la comunicación y la interfaz de usuario; comunican y documentan la arquitectura; acompañan su realización e implementación; la analizan y evalúan, sobre todo en cuanto a los riesgos para cumplir los requisitos; y explican las consecuencias de las decisiones arquitectónicas a otras partes interesadas.

El plan de estudios también insiste en que estas tareas son iterativas: los arquitectos trabajan en ciclos y revisan los requisitos y las decisiones a medida que llega la retroalimentación, en lugar de diseñar una vez y pasar el trabajo a otros. La Sección 1.8 examina cómo encaja esto en la entrega iterativa y continua.

Tipos de arquitecto

Los cargos siguen los niveles de arquitectura descritos en la Sección 1.2. Las responsabilidades exactas varían mucho entre organizaciones, así que considera la tabla siguiente como típica más que definitiva.

¿Un rol o un cargo?

La arquitectura es un conjunto de responsabilidades antes que un cargo. En muchas organizaciones, sobre todo en las más pequeñas y en las organizadas en torno a equipos de producto autónomos, nadie tiene el cargo de "arquitecto". El trabajo arquitectónico se sigue haciendo, a cargo de los líderes técnicos, de los ingenieros sénior o del equipo en su conjunto. Lo que importa es que alguien sea claramente responsable de las decisiones significativas y de las cualidades de todo el sistema. Cuando nadie lo es, se sigue produciendo arquitectura, pero por accidente.

Muchas empresas tecnológicas ofrecen una carrera técnica para los contribuidores individuales sénior, con niveles como staff engineer y principal engineer. Staff Engineer (2021), de Will Larson, describe cuatro arquetipos habituales de estos roles, uno de los cuales se llama explícitamente Architect (arquitecto): una persona responsable de la dirección y la calidad de un área técnica crítica. Los demás (Tech Lead, Solver y Right Hand) también asumen una responsabilidad arquitectónica considerable. En estas organizaciones, el trabajo del arquitecto lo hacen personas que también son ingenieros.

El artículo de Martin Fowler de 2003 Who Needs an Architect? contrapone dos caricaturas: un arquitecto que toma en solitario todas las decisiones importantes y otro que trabaja codo con codo con el equipo, hace de mentor de los desarrolladores y les ayuda a tomar buenas decisiones por sí mismos. Fowler defendió con firmeza el segundo. Hoy la mayoría de los profesionales coincide en que los arquitectos que dictan desde lejos suelen producir diseños que los equipos esquivan discretamente.

Amplitud técnica frente a profundidad

A los desarrolladores se les suele recompensar por la profundidad: conocer extremadamente bien un lenguaje, un framework o una plataforma. Los arquitectos necesitan un perfil distinto. Richards y Ford describen una pirámide del conocimiento con tres capas: lo que sabes (donde tienes verdadera experiencia), lo que sabes que no sabes (sabes que existe y, a grandes rasgos, para qué sirve, pero hoy no podrías construir nada con ello) y lo que no sabes que no sabes. La experiencia de la capa superior hay que mantenerla, y eso lleva tiempo. La capa intermedia es barata de ampliar y es la que te permite reconocer opciones.

El valor de un arquitecto reside en gran medida en la amplitud técnica: saber que existen cinco formas de resolver un problema, en qué es buena y en qué es mala cada una y cuál merece un análisis más detenido. Un arquitecto que solo conoce una base de datos la recomendará siempre. La amplitud tiene un precio, porque el tiempo dedicado a ensanchar la capa intermedia no se dedica a profundizar en la superior; por eso los arquitectos dejan deliberadamente que se desvanezca parte de su antigua experiencia e invierten en saber de más cosas. Richards y Ford advierten del fallo contrario: el arquitecto cuyas opiniones se formaron a partir de una mala experiencia de hace años y que rechaza toda opción que se le parezca.

¿Deberían escribir código los arquitectos?

Aquí los profesionales discrepan de verdad, y el desacuerdo es útil porque los dos lados tienen razón en algo.

Argumentos a favor de programar. Los arquitectos que programan entienden el costo real de sus decisiones, notan cuándo un principio resulta penoso en la práctica, mantienen al día su criterio técnico y conservan el respeto de los desarrolladores que deben implementar sus diseños. Los arquitectos que dejan de programar durante años corren el riesgo de diseñar sistemas elegantes en una pizarra y torpes en un editor.

Argumentos en contra. El tiempo de un arquitecto se reparte entre muchos equipos, reuniones y decisiones. Un arquitecto que se hace cargo de funcionalidades de la ruta crítica se convierte en un cuello de botella: el equipo espera un código que se retrasa por las otras obligaciones del arquitecto. Su atención también es necesaria en inquietudes que afectan a varios equipos y de las que ningún equipo se ocupará por sí solo.

La solución habitual. La mayoría de las voces experimentadas, entre ellas Richards y Ford, recomiendan que los arquitectos sigan implicados en el código de maneras que no los pongan en la ruta crítica. Por ejemplo: construir una prueba de concepto para probar una opción arriesgada antes de que el equipo se comprometa con ella; escribir funciones de aptitud (fitness functions), comprobaciones automáticas que verifican reglas arquitectónicas como "el módulo de dominio no debe depender del framework web"; corregir bugs y hacer pequeñas tareas de deuda técnica; crear herramientas y automatizaciones para el equipo; y revisar código con regularidad, lo que muestra cómo se están implementando realmente las decisiones.

import pathlib, re

FORBIDDEN = re.compile(r"^\s*(from|import)\s+flask\b", re.M)

def test_domain_does_not_depend_on_web_framework():
    offenders = []
    for path in pathlib.Path("shop/domain").rglob("*.py"):
        if FORBIDDEN.search(path.read_text(encoding="utf-8")):
            offenders.append(str(path))
    assert not offenders, f"Domain code imports Flask: {offenders}"