Arquitecto de software: mercado

Vacante

un empleo abierto que superó el filtro de calidad y menciona al menos dos tecnologías

Candidato observado

un candidato cuyo stack contiene esta tecnología; es un agregado: ni un solo registro sale del perímetro

Candidato emparejable

aún no contabilizado

Ventana

empleos abiertos en el momento en que se generó el snapshot

Importante: Architect no es un rol de entrada. «Junior Architect» apenas existe como puesto: los roles de arquitecto empiezan desde el nivel de Senior Engineer (5+ años de programación práctica, obligatorio: no se puede diseñar un sistema sin entender el código a un nivel profundo). Las cifras de niveles inferiores en la muestra probablemente reflejan «Architect» en títulos de puestos junior (mal titulados); para referencias realistas, mira Senior / Lead. Trayectoria: Senior Software Engineer (5-8 años) → Software Architect (demostrando diseño de sistemas en varios proyectos + liderazgo técnico) → Senior / Principal Architect → o bien Staff / Distinguished Engineer (vía de contribuidor individual: arquitectura sin gestión de personas), Chief Architect / Head of Architecture, Engineering Manager → Director / VP Engineering (vía de gestión), Solutions Architect (giro hacia el trato con clientes), o CTO en una startup.

Stack / skills principales: aws, nodejs, cloud, java, python. Experiencia profunda en al menos un stack: Java (domina la arquitectura enterprise + banca, ecosistema Spring), .NET (enterprise de Microsoft), Python, Go, Node.js / TypeScript + comprensión de frontend. No se puede diseñar un sistema sin entender el código a nivel de Senior Engineer. Estilos y patrones de arquitectura: monolito / monolito modular (renacimiento 2024–2026) / microservicios / event-driven / CQRS / event sourcing / serverless / hexagonal / clean architecture / por capas. Domain-Driven Design (DDD), bounded contexts + aggregates + ubiquitous language + DDD estratégico + táctico (Eric Evans «blue book» + Vaughn Vernon «red book» + «Implementing DDD»). Patrones de diseño: clásicos GoF + Fowler PoEAA (Patterns of Enterprise Application Architecture) + cloud design patterns. Modelo C4 (Simon Brown, Context / Container / Component / Code, estándar de diagramación 2026) + Structurizr (C4 como código) + PlantUML / Mermaid (diagramas como código) + draw.io / Excalidraw / Miro + arc42 (plantilla de documentación). ADR (Architecture Decision Records), práctica obligatoria 2026 (documentar decisiones + contexto + alternativas + consecuencias, cada decisión significativa). Diseño de API: REST (Richardson Maturity Model + OpenAPI) + GraphQL + gRPC + AsyncAPI + patrones de API gateway + versionado. Sistemas distribuidos: teorema CAP + modelos de consistencia + consenso (básicos de Raft / Paxos) + idempotencia + saga pattern + outbox pattern + distributed tracing + manejo de eventual consistency. Arquitectura de datos: trade-offs SQL vs NoSQL + polyglot persistence + database-per-service + read models CQRS + partitioning / sharding + Kafka event streaming. Messaging: Kafka + RabbitMQ + NATS + cloud-native (SQS / SNS / Pub-Sub). Caché: Redis + CDN + estrategias de caché de aplicación. Diseño de observabilidad: diseñar la observabilidad en el sistema (OpenTelemetry, logs / métricas / traces) + definición de SLI / SLO. Atributos de calidad (requisitos no funcionales): escalabilidad + rendimiento + disponibilidad + seguridad + mantenibilidad + testabilidad, análisis de trade-offs entre ellos. Evaluación de arquitectura: ATAM (Architecture Tradeoff Analysis Method) + fitness functions (arquitectura evolutiva, Neal Ford «Building Evolutionary Architectures») + gobierno de arquitectura. Cloud: arquitectura AWS / GCP / Azure (Well-Architected frameworks). Soft skills críticas: comunicación técnica (explicar las decisiones a distintas audiencias, de juniors a nivel C), influencia sin autoridad, mentoring, articulación de trade-offs, documentación.

Software Architect (esta página): enfoque en la arquitectura interna de un sistema de software: componentes + patrones + elección de tecnología + requisitos no funcionales para un sistema / producto. Con profundidad en el código. Solutions Architect: enfoque en una solución de extremo a extremo para un problema de negocio / cliente concreto: a menudo de cara al cliente + con participación en preventa; diseña una solución a partir de piezas existentes (a menudo servicios en la nube), puente entre los requisitos de negocio y la implementación técnica. Ver Solutions Architect. Enterprise Architect: enfoque en el panorama tecnológico de toda la organización: alinea la estrategia IT con la estrategia de negocio, estandarización tecnológica, gestión del portfolio, gobernanza. Menos código, más estrategia + política. A menudo usa frameworks (TOGAF / Zachman). Staff / Principal Engineer: contribuidor individual de nivel arquitecto en empresas de producto (escalera estilo FAANG: Staff → Senior Staff → Principal → Distinguished). Hace arquitectura, pero sigue siendo IC (no gestión): escribe código cuando hace falta y dirige la dirección técnica mediante la influencia. Realidad 2026 (solapamiento): Software Architect ↔ Staff Engineer: 70% de solapamiento (a menudo el mismo rol con distinto título: las empresas de producto lo llaman Staff Engineer; las empresariales / de outsourcing, Architect). Software Architect ↔ Solutions Architect: 50% (Solutions, más de cara al cliente + composición de servicios en la nube; Software, más diseño de sistemas internos). Software Architect ↔ Enterprise Architect: 30% (Enterprise: estrategia a nivel de organización; Software: diseño a nivel de sistema). Elección de carrera: Software Architect / Staff Engineer si quieres diseño técnico profundo de sistemas + seguir cerca del código, Solutions Architect si te gustan el trato con clientes + la nube + la amplitud frente a la profundidad, Enterprise Architect si te interesan la estrategia + la gobernanza + el nivel de organización + estás dispuesto a alejarte del código. Antipatrón: el «arquitecto de torre de marfil»: diseña sin entender la realidad actual del código. Los arquitectos modernos conocen el código y son lo bastante prácticos.

Árbol de decisión para el estilo de arquitectura 2026: 1) Monolito modular: la opción recomendada por defecto en 2026 para la mayoría de los proyectos. Una única unidad desplegable, pero por dentro con límites claros entre módulos (como los bounded contexts de DDD) y dependencias controladas. Pros: simplicidad de despliegue + depuración + transacciones, sin la complejidad de los sistemas distribuidos, límites fáciles de refactorizar. Contras: una única unidad de escalado, dependencia tecnológica (un solo stack). Caso de uso: startups, equipos pequeños y medianos (hasta ~30-50 ingenieros), proyectos nuevos donde el dominio aún no es estable. Renacimiento en 2024–2026: el sector se dio cuenta de que se abusó de los microservicios. 2) Microservicios: servicios desplegables de forma independiente, cada uno dueño de sus datos. Pros: escalado independiente + despliegue independiente + autonomía de los equipos + diversidad tecnológica + aislamiento de fallos. Contras: complejidad de los sistemas distribuidos (fallos de red + consistencia eventual + trazado distribuido + sagas para las transacciones), sobrecarga operativa (hacen falta DevOps maduro + K8s + observabilidad), retos de consistencia de datos. Caso de uso: grandes organizaciones (50+ ingenieros, varios equipos autónomos), necesidades de escala demostradas, cultura DevOps madura. No es caso de uso: startup, equipo pequeño, dominio poco claro: los microservicios matarán la velocidad. «Hay que tener esta altura para usar microservicios» (Martin Fowler). 3) Arquitectura orientada a eventos: los componentes se comunican mediante eventos (Kafka / mensajería). Pros: bajo acoplamiento, escalabilidad, rastro de auditoría (log de eventos), desacoplamiento temporal. Contras: el flujo es más difícil de razonar, consistencia eventual, depuración compleja. Caso de uso: flujos asíncronos de alto throughput, sistemas con muchas integraciones, pipelines de datos en tiempo real, sistemas donde el desacoplamiento es crítico. A menudo combinada con microservicios. 4) CQRS + Event Sourcing: modelos de lectura / escritura separados + los eventos como fuente de verdad. Pros: modelos de lectura optimizados, rastro de auditoría completo, consultas temporales, escalar lectura / escritura por separado. Contras: complejidad significativa, consistencia eventual, curva de aprendizaje empinada. Caso de uso: dominios complejos con lógica de negocio rica + requisitos de auditoría (fintech / trading), NO para apps CRUD. Se abusa de él: aplícalo de forma selectiva a bounded contexts concretos, no a todo el sistema. 5) Serverless: FaaS (Lambda / Cloud Functions) + servicios gestionados. Pros: sin gestión de infraestructura, autoescalado, pago por uso, rapidez de salida al mercado. Contras: dependencia del proveedor, cold starts, límites de ejecución, depuración más difícil, coste impredecible a escala. Caso de uso: cargas orientadas a eventos, tráfico esporádico, código de unión, prototipos, equipos pequeños sin capacidad de operaciones. 6) Monolito por capas / N-tier: clásico (capas de presentación / negocio / datos). Caso de uso: aplicaciones CRUD simples, mantenimiento legacy. 7) Arquitectura hexagonal / Clean Architecture: NO es un estilo de despliegue, sino una organización interna del código (aplicable a un monolito O a un microservicio): aísla la lógica de dominio de la infraestructura mediante puertos / adaptadores. Recomendada para cualquier base de código no trivial. Recomendaciones por defecto 2026: Proyecto nuevo / startup → monolito modular con estructura interna Clean / hexagonal. Escala demostrada + grandes equipos autónomos → microservicios (pero extraídos poco a poco del monolito modular, no desde cero). Muchas integraciones / flujos asíncronos → orientada a eventos (sobre cualquier estilo de despliegue). Dominio complejo con mucha auditoría (un subconjunto) → CQRS + Event Sourcing para bounded contexts concretos. Cargas esporádicas / de unión → serverless. Principio principal 2026: «primero el monolito» (Martin Fowler): empieza con un monolito modular y extrae microservicios cuando haya un dolor concreto (no de antemano). La arquitectura debe evolucionar, no ser un gran diseño previo.

Sí, el 58% de los empleos de Software Architect son full-remote o híbridos. El trabajo de arquitectura — diseño + documentación + comunicación = ideal para el remoto. Outsourcers — casi siempre remotos en proyectos enterprise de EE. UU. / UE. Las empresas de producto rusas — híbrido o remoto tras el periodo de prueba. Los bancos rusos — híbrido (las reuniones de architecture review a menudo on-site). Las empresas tecnológicas internacionales (track de arquitecto Staff / Principal Engineer) — full-remote estándar para la mayoría. Salvedad: el rol de arquitecto requiere mucha comunicación / influencia — el remoto solo-async es más difícil para arquitectos que para ICs (se necesitan reuniones de design review, whiteboarding, alineación de stakeholders). El híbrido suele ser óptimo para arquitectos. Hubs de relocación: Polonia / Alemania (la arquitectura enterprise es fuerte — ecosistema SAP) / Canadá / Serbia / EAU. Inglés para el remoto internacional de Architect — obligatorio (la arquitectura — rol con mucha comunicación, el inglés es más crítico que para un IC puro; documentación + design reviews + gestión de stakeholders en inglés).

Software Architect: título habitual en el entorno empresarial + outsourcing + bancos. A menudo es un rol formal con responsabilidades definidas (documentos de arquitectura, gobernanza, puntos de control de revisión). Puede estar separado de la programación diaria (riesgo de «torre de marfil»). Staff / Principal Engineer: título habitual en empresas de producto (sobre todo en la tecnología de EE. UU. + las influidas por FAANG). Contribuidor individual de nivel arquitecto: hace arquitectura, pero mediante la influencia, no la autoridad; sigue siendo práctico (escribe código para rutas críticas / prototipos / desbloquear equipos). Escalera IC de FAANG: Senior → Staff → Senior Staff → Principal → Distinguished → Fellow. Diferencias clave: 1) Programación: el Staff Engineer programa con regularidad (10-40% del tiempo); el Software Architect a menudo programa menos (o nada en algunas empresas). Tendencia moderna: los arquitectos deben seguir siendo prácticos. 2) Modelo de autoridad: el Architect suele tener autoridad formal de aprobación (aprobar la arquitectura). El Staff Engineer lidera mediante la influencia + la credibilidad técnica. 3) Alcance: el alcance del Staff Engineer crece con el nivel (Staff: equipo / unos pocos equipos; Principal: organización; Distinguished: toda la empresa). El alcance del Architect suele estar ligado a un sistema / portfolio concreto. 4) Modelo de carrera: la vía Staff+ es una escalera de carrera IC explícita, paralela a la de gestión. Architect: a veces un rol final, a veces un paso hacia Enterprise Architect. Realidad 2026: los roles convergen: el sector se mueve hacia el modelo de Staff Engineer (liderazgo técnico práctico sin gestión) y se aleja del «arquitecto de torre de marfil». Buenos libros: «Staff Engineer» de Will Larson, «The Staff Engineer's Path» de Tanya Reilly, «Fundamentals of Software Architecture» de Mark Richards / Neal Ford (canónico 2026). La elección de carrera depende más del tipo de empresa (empresa de producto → título Staff Engineer; empresarial / outsourcing → título Architect) que del trabajo real.

Hoja de ruta (Architect no es un puesto de entrada; el camino pasa por Senior Engineer): 1) Conviértete en un Senior Software Engineer sólido: es un requisito previo, no un atajo. Mínimo 5+ años programando en la práctica, experiencia profunda en un stack (Java / .NET / Python / Go / Node.js), experiencia llevando sistemas a producción. 2) Dominio de los patrones de diseño: los clásicos de GoF (Gang of Four) + entender cuándo aplicarlos y cuándo no. Libros: "Design Patterns" de GoF (un clásico) + "Head First Design Patterns" (accesible). 3) Domain-Driven Design: "Domain-Driven Design" de Eric Evans (el libro azul, canónico) + "Implementing Domain-Driven Design" de Vaughn Vernon (el libro rojo, práctico) + "Learning Domain-Driven Design" de Vlad Khononov (introducción moderna y accesible, 2021). El DDD estratégico (bounded contexts + context mapping) es más crítico para un arquitecto que el táctico. 4) Fundamentos de arquitectura: "Fundamentals of Software Architecture" de Mark Richards / Neal Ford (canónico en 2026, lectura obligada) + "Software Architecture: The Hard Parts" de Ford / Richards / Sadalage / Dehghani (compromisos de la arquitectura distribuida). 5) Sistemas distribuidos: "Designing Data-Intensive Applications" de Martin Kleppmann (lectura obligada en 2026: el libro más importante para un arquitecto) + entender CAP / modelos de consistencia / consenso. 6) Patrones enterprise: "Patterns of Enterprise Application Architecture" de Martin Fowler + "Enterprise Integration Patterns" de Hohpe / Woolf. 7) Modelo C4 + diagramas: el modelo C4 de Simon Brown (c4model.com, gratis) + Structurizr + PlantUML / Mermaid (diagramas como código). 8) Práctica de ADR: empieza a escribir Architecture Decision Records en tus proyectos actuales (formato ADR de Michael Nygard). 9) Práctica de diseño de sistemas: "System Design Interview" de Alex Xu (vol. 1 + 2) + ByteByteGo + practica el diseño de sistemas en la pizarra (aunque no sea para entrevistas: es una habilidad central del arquitecto). 10) Arquitectura cloud: los frameworks Well-Architected de AWS / GCP / Azure + una certificación de Solutions Architect en una nube (se valora AWS SA Professional). 11) Arquitectura evolutiva: "Building Evolutionary Architectures" de Neal Ford (fitness functions). 12) Habilidades blandas: comunicación técnica, influencia sin autoridad, mentoría, facilitación, saber explicar los compromisos. Libros: "The Software Architect Elevator" de Gregor Hohpe (el rol de arquitecto + comunicación, lectura obligada en 2026), "Staff Engineer" de Will Larson, "The Staff Engineer's Path" de Tanya Reilly. 13) Practica en tu rol actual: asume de forma proactiva tareas de nivel de arquitectura como Senior Engineer (proponer diseños, escribir ADR, dirigir revisiones de diseño, mentorizar): demuestra trabajo de arquitecto antes de tener el título. Internacional (EN): "Fundamentals of Software Architecture" (O'Reilly), developertoarchitect.com de Mark Richards (lecciones gratuitas, un recurso excelente), ByteByteGo (diseño de sistemas), "Software Architecture Monday" de Mark Richards en YouTube (lecciones semanales gratuitas). Senior Engineer (5+ años) + trabajo de arquitectura demostrado (diseños + ADR + liderazgo de revisiones de diseño) → Software Architect.

559 active open Software Architect positions with explicit software-architect scope in our sample. The real market is wider — many architect-level roles classified as Staff / Principal Engineer (product companies) or Lead / Senior+ Engineer (titles vary — "Architect" vs "Staff Engineer" vs "Tech Lead" often overlap). Geography: the US, Germany, India. The real market is wider thanks to the international remote segment. Time to close a Senior / Principal Software Architect — 8-16 weeks (longer than regular roles due to seniority + extensive interview process — system design rounds + architecture deep-dives + leadership assessment).

Un Senior / Principal Software Architect es responsable del ciclo completo de diseño de sistemas + liderazgo técnico. Base técnica profunda: dominio de nivel Senior Engineer en al menos un stack (no puedes diseñar lo que no entiendes a nivel de código: antipatrón «arquitecto en torre de marfil»). Conocimiento de lectura de varios stacks para elegir tecnologías. Dominio de estilos de arquitectura: monolito / monolito modular / microservicios / event-driven / CQRS / event sourcing / serverless: conocer los compromisos de cada uno + cuándo aplicarlo y cuándo no. Dominio de Domain-Driven Design: DDD estratégico (bounded contexts + context mapping + identificación de subdominios) + DDD táctico (aggregates + entities + value objects + domain events). Sistemas distribuidos a fondo: teorema CAP, modelos de consistencia (linealizabilidad / eventual / causal), nociones de algoritmos de consenso, idempotencia, patrón saga, patrón outbox, manejo de transacciones distribuidas, tolerancia a particiones, modos de fallo. Arquitectura de datos: compromisos entre SQL y NoSQL, persistencia políglota, estrategias de particionado / sharding de datos, modelos de lectura CQRS, event streaming (Kafka), implicaciones de una base de datos por servicio. Dominio del diseño de APIs: REST + GraphQL + gRPC + AsyncAPI, estrategias de versionado, patrones de API gateway, diseño contract-first. Análisis de compromisos entre atributos de calidad: escalabilidad frente a simplicidad, rendimiento frente a mantenibilidad, consistencia frente a disponibilidad; expresar los compromisos de forma explícita (no existe la «mejor» arquitectura, existen compromisos en contexto). Modelo C4 + documentación: diagramas C4 (Context / Container / Component / Code), diagramas como código con Structurizr / PlantUML, documentación arc42, disciplina de ADR (documentar cada decisión significativa + contexto + alternativas + consecuencias). Evaluación de arquitectura: metodología ATAM, fitness functions (arquitectura evolutiva), gobierno de la arquitectura sin burocracia. Arquitectura cloud: los frameworks Well-Architected de AWS / GCP / Azure, patrones cloud-native, compromisos entre coste y arquitectura. Diseño de sistemas a escala: diseñar en pizarra sistemas para 100M+ usuarios, planificación de capacidad, presupuestos de rendimiento, consideraciones multirregión. Gestión de la deuda técnica: identificación + cuantificación + priorización + estrategia de pago + comunicar el coste de la deuda al negocio. Experiencia en migraciones: modernización de sistemas legacy (patrón strangler fig), extracción de monolito → microservicios bien hecha (incremental, no big-bang). Liderazgo técnico / soft skills (críticas para un arquitecto): comunicación técnica para distintas audiencias (desarrolladores junior → nivel C), influencia sin autoridad, facilitación de revisiones de diseño, mentoría a Senior Engineers, expresión de compromisos, resolución de conflictos, gestión de stakeholders, «architect elevator» (Gregor Hohpe: conectar la estrategia de negocio del ático con la realidad técnica de la sala de máquinas). Documentación: documentación de arquitectura clara, registros de decisiones, propuestas de diseño. Inglés para Senior+ IMPRESCINDIBLE: la arquitectura es un rol de mucha comunicación, con documentación + revisiones de diseño + alineación con stakeholders en inglés en un contexto internacional. Extra opcional: charlas en conferencias (QCon / GOTO / conferencias de arquitectura), textos de arquitectura publicados (blog / libro), contribuciones de arquitectura al open source, profundidad en un dominio (fintech / salud / alta carga): aumentan notablemente el valor de mercado para roles de Principal / Distinguished Engineer / Chief Architect.