Un enterprise architect es un perfil de gobierno técnico que alinea procesos de negocio, datos y tecnología con la estrategia de la empresa. No es lo mismo que la herramienta de modelado UML de Sparx Systems llamada Enterprise Architect.
Si estás revisando una oferta, un organigrama o una contratación y notas que el término aparece en sitios distintos con significados distintos, no te estás confundiendo tú. El problema es real, y en España se mezcla todavía más porque muchas descripciones hablan del rol, pero otras venden el software con el mismo nombre. En empresas con varios equipos, ese matiz cambia por completo qué contratas, qué esperas del candidato y qué problema quieres resolver.
Qué es enterprise architect y por qué el término confunde
Un CTO o un founder suele llegar a este punto por una razón muy concreta, la empresa ya creció, los sistemas ya no caben en la cabeza de una sola persona y alguien propone “meter un enterprise architect”. La pregunta correcta no es si suena bien, la pregunta es si necesitas una función de gobierno arquitectónico o solo una persona senior que ordene un área concreta.
En la administración digital del Reino Unido, el perfil se define como un liderazgo transversal que traduce la estrategia del negocio en cambio organizativo y entrega técnica, trabajando en varios niveles para conectar estrategia, cambio de negocio y ejecución técnica, no como un simple puesto de TI. Esa visión encaja con la arquitectura empresarial como disciplina de planificación, diseño y gobierno que alinea procesos, información y tecnología con los objetivos estratégicos de la empresa. Perfil oficial de enterprise architect en el Government Digital and Data Profession
En España, la definición operativa de ServiceNow en español lo describe como el marco que pone en consonancia procesos de negocio, sistemas de información e infraestructuras tecnológicas con la estrategia empresarial. Esa es la versión útil para negocio, porque explica por qué el rol no se limita a dibujar diagramas, sino a ordenar el portfolio tecnológico y a servir de puente entre negocio y TI. Definición de arquitectura empresarial en ServiceNow España
La confusión no es teórica
La mayoría de artículos introductorios fallan aquí porque no separan el rol profesional de la herramienta. Enterprise Architect también es el software de Sparx Systems para visualizar, analizar, modelar, probar y mantener sistemas, software, procesos y arquitecturas, así que una búsqueda en español puede llevarte a dos cosas distintas si no acotas bien el contexto. Enterprise Architect de Sparx Systems
Regla práctica: si el problema es organizativo, de gobierno o de alineación entre dominios, estás buscando la profesión. Si el problema es modelado UML, documentación o diseño de sistemas en una herramienta, estás buscando el software.
Ese matiz importa mucho en entornos con administración pública, proveedores legacy o equipos de producto que trabajan con documentación formal. También importa en selección, porque una oferta puede pedir “Enterprise Architect” y estar pensando en estrategia y governance, mientras el candidato cree que le piden experiencia de modelado. Cuando eso pasa, el proceso ya nace mal.
Si quieres comparar este perfil con el de arquitecto de software, te conviene leer también arquitecto de software, porque no resuelven el mismo problema ni responden al mismo horizonte de decisión.
Responsabilidades clave que nadie te cuenta en la teoría
En papel, el rol parece limpio. En una empresa real, un enterprise architect pasa gran parte del tiempo tomando decisiones que no se ven en un diagrama, pero que cambian cómo trabaja toda la organización. Ahí es donde el puesto gana valor, o se convierte en puro papeleo si nadie le deja tocar la realidad.
Qué hace de verdad durante la semana
Su trabajo suele empezar por definir roadmaps técnicos , ordenar el portfolio de aplicaciones y decidir qué se estandariza y qué se integra. Esa tensión entre estandarización e integración es el eje del rol, porque una empresa puede reducir heterogeneidad, pero si mata la integración acaba creando silos nuevos. La arquitectura empresarial existe justo para equilibrar esos dos extremos y conectar decisiones de tecnología con el modelo operativo.
También suele intervenir cuando producto, infraestructura y seguridad no están alineados. No llega para “aprobar” por deporte, llega para evitar que cada equipo tome decisiones aisladas que luego obligan a reescribir medio sistema. En organizaciones grandes o muy fragmentadas, esa capa de gobierno evita que la estrategia se convierta en una suma de proyectos sueltos.
Si un EA solo produce documentación y nadie usa sus entregables para decidir, no tienes arquitectura empresarial, tienes un archivo bonito.
Qué artefactos sí tienen sentido
Los artefactos útiles no son los más vistosos, son los que se convierten en decisiones. Un EA serio suele producir mapas de capacidades , principios arquitectónicos, decisiones registradas y roadmaps técnicos que sirven para priorizar.
- Mapas de capacidades: ayudan a ver qué hace realmente el negocio y qué parte de la tecnología lo soporta.
- Principios arquitectónicos: fijan límites, por ejemplo, cuándo no se introduce otra plataforma más.
- Decisiones arquitectónicas registradas: evitan que el equipo repita discusiones ya cerradas.
- Roadmaps técnicos: conectan deuda, dependencias y objetivos de negocio en un plan ejecutable.
Si esos artefactos no cambian nada en producto, operaciones o seguridad, el rol está sobredimensionado o mal encajado. El problema no es la teoría, el problema es convertirla en exceso de burocracia.
Para una visión más cercana al diseño de soluciones y a cómo se aterriza la arquitectura en producto, puedes cruzarlo con event-driven architecture, porque muchas decisiones de un EA acaban condicionando ese tipo de evolución técnica.
Enterprise architect frente a otros roles arquitectónicos
La confusión con otros roles pasa en casi todas las búsquedas de hiring. En una scaleup española, no puedes tratar igual a alguien que define principios para toda la empresa que a quien diseña una integración puntual entre dos sistemas. Si los mezclas, acabas contratando seniority sin alcance real.
Dónde termina cada perfil
Un enterprise architect mira el conjunto, decide principios, fija prioridades transversales y marca la dirección de largo plazo. Un solution architect baja a un caso concreto, normalmente una integración, una solución o un dominio funcional. Un software architect se centra en la estructura técnica del software. Un data architect gobierna el modelo de datos. Un platform architect se ocupa de una plataforma interna o compartida.
En una scaleup, eso se traduce en preguntas distintas. El EA decide cómo encaja una nueva capacidad en el portfolio y qué deuda se puede tolerar. El solution architect diseña cómo se conecta el CRM con el ERP o con un servicio externo. El platform architect asegura que la plataforma interna siga siendo operable. El data architect evita que cada equipo invente su propio criterio de datos.
| Rol | Foco principal | Horizonte | Entregable típico |
|---|---|---|---|
| Enterprise architect | Gobierno transversal de negocio, datos y tecnología | Largo | Principios, roadmap, portfolio |
| Solution architect | Solución concreta o integración específica | Medio | Diseño de solución |
| Software architect | Estructura técnica del software | Medio | Diseño técnico del sistema |
| Data architect | Modelo y gobierno de datos | Medio y largo | Modelo de datos, estándares |
| Platform architect | Plataforma interna compartida | Medio | Arquitectura de plataforma |
La diferencia que más se paga mal en hiring
El error típico es cubrir gobierno técnico con un software architect muy senior y esperar que resuelva problemas de negocio, portfolio y priorización. A medio plazo falla, porque ese perfil suele ser fuerte en diseño, pero no siempre tiene la autoridad o el foco para coordinar dominios distintos. Ahí es donde el enterprise architect aporta valor de verdad, o sobra si la empresa todavía no tiene esa complejidad.
Si el candidato habla solo de patrones, diagramas y herramientas, pero no de decisiones, trade-offs y negociación con negocio, no estás delante del perfil correcto. Y si el proceso de selección no distingue entre estos roles, tampoco estás contratando bien.
Frameworks y artefactos que de verdad se usan en España
Muchos artículos convierten TOGAF, ArchiMate o Zachman en una lista de siglas. Eso no ayuda a nadie. La pregunta útil es otra, qué framework va a mantener vivo tu equipo dentro de seis meses y cuál solo va a llenar una presentación.
Cuándo usar cada cosa
TOGAF aporta estructura cuando la organización ya tiene varias capas, varios equipos y bastante coordinación que formalizar. En una scaleup pequeña, puede ser demasiado peso si nadie tiene tiempo para sostenerlo. ArchiMate funciona bien como lenguaje común para hablar de negocio, aplicaciones y tecnología sin pelearse por vocabulario. Zachman sirve más como marco de clasificación que como método de trabajo diario. BIZBOK encaja cuando el foco está en capacidades y procesos de negocio.
En equipos españoles que he visto funcionar bien, el patrón suele ser más ligero de lo que vende el mercado. Usan modelos claros, algo de ArchiMate cuando necesitan lenguaje compartido, y combinan eso con ADRs y mapas de capacidades para no convertir la arquitectura en ceremonia.
Mi recomendación: compra el framework que tu equipo va a sostener sin drama operativo. Si necesita una consultora para vivir, no te sirve.
Herramientas y enfoque práctico
Para modelar y documentar, el mercado usa herramientas como Sparx Systems Enterprise Architect, y también plataformas modernas de EA que conectan información viva con el modelo. El punto no es casarte con una herramienta, es evitar el modelo muerto que nadie actualiza. El valor aparece cuando el artefacto ayuda a decidir, no cuando impresiona en una demo.
La mayoría de equipos no necesita construir una catedral metodológica. Necesita una base que permita entender dependencias, priorizar deuda y explicar cambios a negocio sin traducciones interminables. Si el framework no ayuda a tomar decisiones más rápido, sobra.
Cuándo una startup o scaleup española necesita un EA de verdad
La respuesta corta es que el tamaño por sí solo no decide nada. En España, lo que suele disparar la necesidad de un enterprise architect es la complejidad operativa, no el organigrama. Cuando ya hay varios equipos tocando la misma base tecnológica, más integraciones de las que alguien puede mantener en la cabeza y decisiones que se pisan entre sí, el rol empieza a tener sentido. La confusión del término tampoco ayuda, porque muchos artículos introductorios hablan de arquitectura empresarial como si fuera solo una idea abstracta o como si estuvieran describiendo la herramienta de Sparx Systems, y no la función real dentro de una empresa. La propia percepción de adopción digital en compañías españolas hace visible esa presión, porque el punto de ruptura llega antes que la madurez organizativa. Datos del INE sobre uso de IA en empresas en 2024
Tres escenarios que veo en el mercado
En una scaleup SaaS B2B , el EA empieza a aportar valor cuando ya hay varios dominios, demasiadas integraciones y una deuda de coordinación que frena entregas. Ahí no necesitas un arquitecto encerrado en una torre de gobierno. Necesitas a alguien pegado a producto y a plataforma, capaz de ordenar decisiones y de evitar que cada equipo construya su propio miniimperio técnico.
En una fintech o healthtech regulada , el rol entra antes porque seguridad, trazabilidad y compliance no se dejan para después. Si el negocio vive bajo presión regulatoria, el EA ayuda a que la evolución técnica no dependa de parchear incidencias según van apareciendo. También baja el ruido entre ingeniería, riesgo y negocio, que en este tipo de compañías suele ser donde se rompe todo.
En una startup temprana , normalmente sobra. Si el equipo sigue buscando product market fit, meter un EA suele añadir peso donde todavía hace falta velocidad y foco. Primero tiene que existir una responsabilidad técnica clara, una dirección de producto mínimamente estable y problemas reales de coordinación. Sin eso, el rol queda demasiado grande para lo que la empresa necesita.
Mi postura sobre el orden de contratación
En la mayoría de scaleups españolas de 40-120 personas , el primer movimiento suele ser un staff engineer o un platform lead. El enterprise architect llega cuando se multiplican dominios y equipos, y cuando ya no basta con buena ingeniería local para sostener las decisiones transversales. No antes. Si lo contratas demasiado pronto, acabarás pagando a alguien para que haga de coordinador elegante sin palancas reales.
Si el CEO está actuando como arquitecto de facto y ya no da abasto, el problema no es académico. Falta gobierno técnico real.
Eso no significa que el EA tenga que entrar siempre como contratación interna. A veces conviene externalizar parte de ese trabajo hasta que la empresa tenga suficientes frentes abiertos como para sostenerlo con sentido. La clave es no confundir madurez técnica con tamaño de plantilla. Hay compañías pequeñas con demasiada complejidad y compañías grandes con una arquitectura todavía bastante simple.
Cómo contratar un enterprise architect en España
La oferta tiene que decir algo más que “perfil estratégico”. Si no, vas a atraer candidatos que saben hablar de arquitectura, pero no necesariamente gobernarla. Yo separaría la job description en tres bloques, responsabilidades, seniority real y señales de encaje.
Qué debería pedir la oferta
El candidato debe poder definir roadmaps técnicos , ordenar portfolios complejos, escribir decisiones arquitectónicas y negociar con producto, seguridad e infraestructura. En seniority alto, también debe simplificar legado sin romper la operación.
Para filtrar bien, no me obsesionaría con certificaciones. Me importa más si ha participado en migraciones reales, si sabe decir no con argumentos y si ha trabajado con equipos que no pensaban igual.
Preguntas que sí discriminan
- Junior o mid: cómo documentaría un cambio de arquitectura para que lo entienda producto, ingeniería y operaciones.
- Mid: qué haría para reducir duplicidades en un portfolio con sistemas solapados.
- Senior: cómo prioriza entre estandarizar y permitir excepciones cuando el negocio aprieta.
Red flags claras
Cuidado con el candidato que solo dibuja diagramas. Cuidado con quien se esconde detrás del framework. Cuidado con quien nunca ha vivido una migración complicada ni ha tenido que cargar con las consecuencias.
Filtro útil: si en la conversación no aparece ninguna decisión incómoda que haya tomado, probablemente no ha ejercido el rol de verdad.
En proceso de selección, yo pediría siempre un ejemplo de conflicto entre negocio y tecnología, y cómo lo resolvió. Si no puede contar eso, no estás contratando un enterprise architect, estás entrevistando a un buen presentador.
Salario y mercado del enterprise architect en España
Los rangos cambian mucho según empresa, sector y si el rol es más de gobierno o más de ejecución. Como referencia orientativa para seniority senior+ , el mercado español suele moverse así: startup en crecimiento, 45.000 a 55.000 € , scaleup SaaS, 55.000 a 70.000 € , gran empresa, 70.000 a 90.000 € y consultora Big 4, 80.000 a 100.000+ €. Referencia de bandas salariales en España
| Tipo de empresa | Banda anual bruta orientativa | Lectura de mercado |
|---|---|---|
| Startup en crecimiento | 45.000 a 55.000 € | Rol híbrido, a veces demasiado amplio |
| Scaleup SaaS | 55.000 a 70.000 € | Más encaje para gobierno transversal |
| Gran empresa | 70.000 a 90.000 € | Más formalización y alcance |
| Consultora Big 4 | 80.000 a 100.000+ € | Más exposición, más estructura |
Cómo leer esos números sin engañarte
En empresas extranjeras con remoto desde España, las bandas pueden subir porque compiten con mercados más caros. También pesan los variables, bonus, equity y, en algunos casos, bonus por certificación. Aun así, no me quedaría solo con la cifra bruta. El coste real cambia mucho con la ciudad y con los gastos que debes calcular al vivir en España, así que conviene mirar el neto y el contexto antes de cerrar banda. gastos que debes calcular al vivir en
La decisión entre contratar o externalizar también importa. Si el problema es puntual o la madurez aún no justifica una capa permanente, un partner fractional puede tener más sentido que una contratación fija. Si el portfolio ya es grande y las decisiones se repiten cada semana, la contratación interna deja de ser opcional.
Tu próximo paso como CTO o founder
Mira tus dominios, tus sistemas y tus decisiones bloqueadas. Si detectas duplicidades, dependencias mal resueltas o discusiones recurrentes entre producto, ingeniería y seguridad, ya tienes un caso claro para gobierno arquitectónico. Luego decide si lo que necesitas es un enterprise architect, un staff engineer o un platform lead, no mezcles los tres.
En las próximas 24 a 72 horas, prepara un brief corto con tres cosas, qué está bloqueado, quién decide hoy y qué decisiones no pueden seguir dependiendo del CEO. Con eso ya puedes abrir una búsqueda, hablar con tu equipo o testar si conviene externalizar primero.
Si quieres aterrizar este tipo de contratación sin perder semanas en descripciones genéricas, en Kulturo trabajamos justo con startups y scaleups que necesitan perfiles técnicos bien definidos y procesos de selección serios. Si estás decidiendo entre EA, staff engineer o platform lead, te ayudamos a separar el ruido del rol que de verdad te falta.