¿Cómo traduces los requisitos de los stakeholders de negocio en una arquitectura técnica?

Empiezo separando lo que el stakeholder pide del problema que realmente intenta resolver, porque ambas cosas divergen más de lo que la gente espera. Realizo sesiones de discovery estructuradas con los usuarios reales del sistema, no solo con el sponsor, y capturo los requisitos según una plantilla simple: la capacidad de negocio necesaria, el punto de fricción actual, y el resultado medible que probaría el éxito. Después convierto todo esto en una matriz de trazabilidad que vincula cada necesidad de negocio con un componente arquitectónico concreto, para que nada se construya sin una justificación clara. Para los requisitos no funcionales, pido a los stakeholders números en vez de adjetivos: un tiempo de respuesta definido bajo una carga definida en lugar de 'rápido', un estándar de cumplimiento nombrado en lugar de 'seguro'. Documento los supuestos y restricciones en un architecture decision record antes de dibujar el primer diagrama, porque la mayoría de las disputas de arquitectura más adelante en el proyecto se remontan a un supuesto que nadie escribió. Y siempre reviso el borrador de la arquitectura con el equipo técnico y el stakeholder original antes de darlo por cerrado, porque un diseño que solo entienden los ingenieros ya ha fallado en el paso de traducción.

¿Cómo gestionas los requisitos no funcionales cuando entran en conflicto con el calendario de entrega?

Los requisitos no funcionales suelen ser la primera víctima de un plazo ajustado, así que mi trabajo es hacer visible ese compromiso en lugar de dejar que ocurra por defecto. Puntúo cada uno según su impacto de negocio y el coste de añadirlo más tarde: un control de seguridad caro de incorporar después del lanzamiento se protege incluso bajo presión de tiempo, mientras que un objetivo de rendimiento con margen para mejorar tras el lanzamiento puede razonablemente dividirse en fases. Presento esto como un menú a los stakeholders en lugar de un veto técnico, detallando el alcance completo, lo que podemos aplazar sin aumentar el riesgo de forma material, y lo que no puede moverse sin la aprobación explícita de alguien con autoridad para aceptar ese riesgo. He visto equipos abandonar en silencio el cifrado en reposo o el registro de auditoría bajo presión de plazo porque nadie lo planteó como una decisión que necesitaba aprobación, y eso aparece meses después como un hallazgo de cumplimiento mucho más caro de corregir retroactivamente que de construir bien desde el principio. También paso una checklist breve de NFR en cada revisión de diseño para que estos compromisos salgan pronto, no durante la primera auditoría de seguridad tras el lanzamiento.

¿Cómo decides entre construir a medida, comprar una plataforma de un proveedor, o integrar lo que ya existe?

Trato esto primero como una pregunta de coste total de propiedad, y la preferencia técnica queda en segundo lugar. Construir a medida se justifica cuando la capacidad está cerca de lo que realmente diferencia al negocio, y una opción estándar forzaría un compromiso que los clientes notarían. Comprar tiene sentido para capacidades commodity donde el mercado ya ofrece opciones maduras y bien soportadas: construirlo internamente suele reinventar un problema ya resuelto, y peor que un proveedor que no hace otra cosa en todo el día. Integrar lo que la organización ya posee suele ser el primer movimiento correcto cuando las licencias o la infraestructura existentes cubren la mayor parte del requisito y una plataforma nueva no se justifica frente al hueco marginal de capacidad. Uso un modelo de puntuación ponderada sobre coste, tiempo hasta el valor, riesgo de dependencia del proveedor y carga de mantenimiento, e incluyo siempre el coste de personas de operar lo que elijamos, porque una plataforma barata que necesita un equipo especializado para funcionar no es realmente barata. Presento los compromisos con números, no solo una recomendación, porque la decisión final suele recaer en quien controla el presupuesto, no en mí.

¿Cómo comunicas las decisiones de arquitectura tanto a stakeholders técnicos como no técnicos?

Mantengo dos versiones de cada artefacto de arquitectura: una vista técnica detallada para ingenieros, normalmente un diagrama estilo C4 hasta el nivel de contenedor o componente, y una vista narrativa simplificada para stakeholders de negocio que muestra el flujo de datos y los límites del sistema sin detalle de implementación. Para audiencias ejecutivas empiezo por el resultado de negocio y el riesgo que se gestiona, y solo saco un diagrama si alguien pregunta cómo, nunca como apertura. He aprendido a detectar la jerga que a mí me suena precisa pero que fuera de ingeniería no significa nada, así que antes de una presentación importante pruebo la explicación con un compañero de otra función. También mantengo architecture decision records para cada decisión significativa, escritos en lenguaje sencillo con el contexto, las opciones consideradas y el razonamiento, para que seis meses después nadie tenga que reconstruir una decisión a partir de un hilo de Slack. Cuando no estoy de acuerdo con la dirección preferida de un stakeholder, expongo los compromisos en una tabla comparativa en lugar de discutir, lo que mantiene la conversación centrada en la decisión y no en quién tiene razón.

Cuéntame sobre una vez que tuviste que rediseñar una arquitectura a mitad de proyecto por una restricción que no habías anticipado.

Estaba diseñando la capa de integración para un cliente retail, conectando una nueva plataforma de gestión de pedidos con su sistema de almacén existente. A mitad de la implementación descubrimos que la API del sistema de almacén tenía un límite de tasa no documentado que hacía inviable nuestro patrón de integración síncrona previsto durante los picos de pedidos, algo que no aparecía ni en la documentación del proveedor ni en nuestras llamadas iniciales de discovery técnico. En lugar de intentar negociar un aumento de ese límite que el proveedor no podía garantizar, rediseñé la integración hacia un patrón basado en eventos usando una cola de mensajes, almacenando los pedidos durante los picos y procesándolos de forma asíncrona con el sistema de almacén, con un callback de estado para mantener actualizada la plataforma de pedidos. Esto añadió unas dos semanas al calendario, que comuniqué de inmediato junto con la arquitectura revisada y el razonamiento, en lugar de intentar absorber el retraso en silencio. El cliente aceptó el retraso una vez entendió que la alternativa era un sistema poco fiable durante sus períodos de mayor volumen. La lección que me llevo: probar explícitamente los límites de tasa y los supuestos de rendimiento durante el discovery, en lugar de confiar en la documentación del proveedor tal cual.

Describe una situación en la que tuviste que oponerte a un stakeholder que quería una arquitectura técnicamente inviable.

Un director comercial ya le había dicho a un cliente que nuestra plataforma podía soportar una sincronización bidireccional en tiempo real con su ERP dentro de una ventana de implementación de seis semanas, basándose en una conversación en la que yo no había participado. El ERP del cliente era un sistema on-premise muy personalizado sin API moderna, y una sincronización bidireccional en tiempo real habría requerido un conector a medida con un riesgo de mantenimiento continuo importante, o una capa de middleware que no tenía ninguna posibilidad realista de construirse y probarse en seis semanas. Preparé un breve informe técnico para el director comercial mostrando las opciones reales de integración, el calendario realista de cada una, y la carga de mantenimiento de la opción más rápida, y propuse una alternativa por fases: sincronización por lotes dentro de la ventana de seis semanas como primera entrega, con el tiempo real como una segunda fase definida una vez validado el conector en producción. Lo planteé como una forma de proteger la relación con el cliente en lugar de bloquear la venta, porque una integración en tiempo real sobre-prometida que fallara en producción habría causado mucho más daño que un compromiso realista por fases. El director comercial llevó la propuesta por fases al cliente, que la aceptó sin objeciones.

Da un ejemplo de una arquitectura de solución que no entregó el valor esperado. ¿Qué aprendiste?

Diseñé una capa de API gateway pensada para que tres unidades de negocio compartieran un conjunto común de servicios backend en lugar de mantener cada una sus propias integraciones duplicadas. Técnicamente funcionaba tal como se especificó, pero dieciocho meses después la adopción era baja: dos de las tres unidades de negocio habían construido sus propias integraciones punto a punto de todos modos, porque el proceso de cambio de la gateway compartida pasaba por un comité de revisión que añadía, de media, tres semanas más de lo que los equipos estaban dispuestos a esperar. La arquitectura en sí era sólida, pero no había diseñado la gobernanza que la rodeaba, y el proceso de aprobación lento empujó a los equipos de vuelta hacia el patrón fragmentado que intentaba eliminar. Aprendí que una plataforma compartida vale lo que vale el modelo operativo que la rodea: quién puede pedir un cambio, con qué rapidez, y quién es dueño del backlog. En proyectos posteriores ahora diseño la gobernanza y el SLA de cualquier plataforma compartida junto con la arquitectura técnica, y trato un proceso de cambio lento como un defecto de diseño tan serio como un problema de escalabilidad, porque produce el mismo resultado: equipos que rodean el sistema que construiste.

Explícame cómo diseñarías una arquitectura de integración que conecte un sistema legacy on-premise con una nueva plataforma SaaS en la nube.

Empiezo perfilando el sistema legacy: qué interfaces expone realmente, si tiene una API utilizable o solo acceso a nivel de base de datos o de archivos, y su rendimiento y disponibilidad reales bajo carga. Si solo expone una base de datos, evito conectar directamente a las tablas de producción desde el lado cloud y construyo en su lugar una capa anti-corrupción, normalmente un pequeño servicio que se encarga de la traducción entre el modelo de datos legacy y el esquema esperado por la plataforma SaaS, para que un cambio en un lado no se propague directamente al otro. Para el patrón de conectividad, uso por defecto una capa iPaaS como MuleSoft, Boomi o Azure Integration Services en lugar de código punto a punto a medida, porque ofrece monitorización centralizada, lógica de reintentos y gestión de errores de serie, y es mucho más fácil de mantener para el equipo interno del cliente tras la entrega. Prefiero la integración asíncrona y basada en eventos siempre que el proceso de negocio tolere consistencia eventual, usando una cola de mensajes para desacoplar los sistemas y absorber una caída de cualquiera de los dos sin perder datos. Y siempre incluyo un job de reconciliación que compara recuentos de registros y campos clave entre ambos sistemas según un calendario, porque los errores de integración que pierden o duplican registros son la clase de fallo más difícil de detectar solo con los logs de la aplicación.

¿Cómo abordas la definición y documentación de requisitos no funcionales para un sistema que estás arquitecturando?

Reviso una checklist estándar que cubre rendimiento, disponibilidad, seguridad, escalabilidad, mantenibilidad y cumplimiento, y para cada una insisto en un objetivo medible en lugar de una afirmación cualitativa. Para el rendimiento eso significa un tiempo de respuesta concreto en un percentil concreto bajo una carga concurrente concreta, no la promesa de que 'debería ser rápido'. Para la disponibilidad, un objetivo de uptime explícito ligado al coste de negocio del tiempo de inactividad, que a su vez determina si la arquitectura necesita redundancia activa-activa o un diseño más simple de una sola región con un tiempo de recuperación documentado. Documento todo esto en una matriz NFR junto con el origen de cada requisito, para que un objetivo que viene de una obligación regulatoria quede claramente distinguido de uno que es solo una preferencia interna, porque ambos reciben un trato muy distinto cuando surgen compromisos más adelante. También marco cuáles son restricciones firmes y cuáles son objetivos con margen negociable, porque tratar cada requisito como igualmente fijo es lo que causa una sobre-ingeniería innecesaria. Reviso la matriz en cada hito importante, porque los requisitos fijados al inicio de un proyecto sobre supuestos tempranos de escala o uso suelen necesitar revisión una vez que existen datos reales de uso.

¿Cómo evalúas y seleccionas un proveedor o plataforma de terceros dentro de una arquitectura de solución?

Llevo la evaluación de proveedores como un proceso estructurado, no un ejercicio de preferencia, empezando por una matriz de puntuación ponderada que cubre el ajuste funcional, el esfuerzo de integración, el coste total en un horizonte de tres años incluyendo implementación y soporte, la estabilidad del proveedor, y el coste de salida si algún día necesitamos migrar. Siempre pido una prueba de concepto contra nuestros requisitos reales de integración en lugar de fiarme de una demo del proveedor, porque las demos están construidas para esconder exactamente los puntos de fricción que nos importan. Reviso yo mismo la documentación de la API y los límites de tasa del proveedor en lugar de fiarme de la palabra de un ingeniero comercial, porque ahí es donde ya me he quemado antes con estimaciones de calendario. Para cualquier proveedor que maneje datos sensibles, reviso sus certificaciones de seguridad y sus opciones de residencia de datos frente a nuestros requisitos de cumplimiento antes incluso de hablar de condiciones comerciales, porque un proveedor que falla en cumplimiento queda descartado sin importar el precio. Y doy mucho peso al coste de salida: una plataforma barata de adoptar pero cara de abandonar, por formatos de datos propietarios o falta de herramientas de exportación, arrastra un coste oculto a largo plazo que rara vez aparece en el business case inicial pero que ha costado caro a todos los clientes con los que he trabajado que lo ignoraron.

Solutions Architect

Las entrevistas para Solutions Architect evalúan tu capacidad para convertir un conjunto impreciso de requisitos de negocio en una arquitectura que realmente funcione, se conecte con lo que ya existe y sobreviva a un presupuesto real. Esa es una habilidad distinta del diseño técnico puro, y es donde los entrevistadores pasan la mayor parte del tiempo: quieren verte razonar sobre compromisos entre sistemas, no solo sobre infraestructura cloud aislada, y defender una decisión de diseño ante un lead de ingeniería y un director financiero en la misma reunión. Espera preguntas sobre patrones de integración, evaluación de proveedores, y el momento en que un stakeholder quería algo que la arquitectura no podía soportar limpiamente. Esta guía cubre las preguntas más frecuentes, con respuestas que muestran experiencia real diseñando soluciones, no teoría de nivel certificación.

Para consejos generales de preparación, consulta nuestra guía sobre las preguntas de entrevista más frecuentes.

Prepárate más

Dominar la entrevista conductual (método STAR)Cómo prepararse para una entrevista técnica

Preguntas de entrevista habituales para Solutions Architect

Preguntas conductuales para puestos de Solutions Architect

Preguntas técnicas para candidatos a Solutions Architect

Lo que buscan los reclutadores en las entrevistas para Solutions Architect

Lo que los responsables de contratación buscan realmente en los candidatos a Solutions Architect:

Fluidez para moverse entre la profundidad técnica y el lenguaje de negocio en la misma conversación. Los candidatos que solo saben operar a un nivel tienen dificultades en un rol que se sitúa entre ingeniería, ventas y el cliente.
Evidencia de pensamiento de gobernanza, no solo de diseño. Una arquitectura sólida que fracasa porque nadie definió cómo se aprueban los cambios es un fallo habitual y evitable.
Razonamiento honesto sobre los compromisos en lugar de una única 'respuesta correcta'. Los entrevistadores desconfían de los candidatos que presentan cada decisión de arquitectura como obvia sin reconocer las restricciones que la moldearon.
Experiencia real con proveedores e integraciones, no solo diseño cloud-native en terreno virgen. La mayor parte del trabajo de arquitectura de soluciones consiste en conectar con algo antiguo, sin documentar, o ambas cosas.
Disciplina de documentación. Los architecture decision records y los diagramas claros son lo que permite que un diseño sobreviva a que el candidato deje el proyecto, y su ausencia es una de las razones más comunes por las que fallan las entregas.

Preguntas que puedes hacer al entrevistador

→¿Cómo es el panorama de sistemas existente, y qué parte de este rol implica integrar plataformas legacy frente a diseñar desde cero?
→¿Cómo se gobiernan aquí las decisiones de arquitectura: existe un comité de revisión, y cuánto tarda normalmente una aprobación?
→¿Con qué frecuencia trabaja este rol con ventas o preventa durante el ciclo de la operación?
→¿Cuál ha sido el mayor fallo o arrepentimiento arquitectónico en un proyecto reciente, y qué cambió como resultado?
→¿Cómo se mide el éxito de este rol en los primeros seis meses?

Practica estas preguntas antes de tu entrevista

El simulador de entrevista prepara una sesión de práctica basada en una oferta de empleo concreta y tu perfil, para que repases las preguntas con más probabilidad de aparecer.

Empezar a practicar

Gratis en tu primer puesto guardado.

Puestos relacionados

Arquitecto cloud

Tech10 preguntas

Ingeniero de plataforma

Tech10 preguntas

Ingeniero de software

Tech10 preguntas

Ingeniero DevOps

Tech9 preguntas

Disponible en otros idiomas

English Français