Preguntas de entrevista para Arquitecto de Sistemas

Respuesta modelo

La decisión de la que más he aprendido fue no trocear un monolito. En una aseguradora teníamos la plataforma de siniestros en una sola aplicación con nueve personas trabajando sobre ella, y la presión interna era convertirla en microservicios porque era lo que se hacía en el resto del sector. Evalué tres opciones: mantenerla como estaba, modularizarla con fronteras explícitas y base de datos separada por esquema, o extraer seis servicios independientes. Descarté la tercera por dos motivos medibles: el dominio de siniestros cambiaba cada trimestre por normativa, de modo que las fronteras que dibujáramos ese año iban a estar mal al siguiente, y no teníamos capacidad de operación para seis despliegues con sus guardias. Elegí la modularización. Lo que perdí lo tengo claro: seguimos escalando el conjunto en lugar de la parte que lo necesita, y un despliegue sigue afectando a todo el módulo. Lo que gané fue que el plazo medio de entrega de un cambio pasó de once a tres días en dieciocho meses y que, cuando peritaciones sí necesitó escalar por su cuenta, lo extrajimos en cinco semanas porque la frontera ya estaba definida y sin dependencias cruzadas de datos.

Respuesta modelo

Lo convierto en escenarios de calidad con números y con dueño. Empiezo preguntando por el momento concreto: qué operación, en qué franja horaria, con qué volumen y qué pasa si no se cumple, porque rápida en el alta de una póliza y rápida en un informe mensual no son el mismo problema. En el último caso, salieron cuatro objetivos: p95 por debajo de 400 ms y p99 por debajo de 1,2 segundos en el alta, disponibilidad del 99,9 % entre las siete y las once de la noche, y capacidad de 3.500 altas por hora en campaña. A continuación pongo precio a cada uno: el p99 solo era alcanzable si dejábamos de consultar a la Dirección General de Tráfico de forma síncrona, así que llevé a negocio la elección entre mantener la validación inmediata o cumplir la latencia, y decidieron pasarla a proceso diferido con notificación. Por último, cada objetivo se instrumenta y se comprueba de forma automática: pruebas de carga nocturnas contra los umbrales y un panel que se revisa en el comité mensual. Un requisito no funcional que no se mide se convierte en opinión en seis semanas.

Respuesta modelo

Uso registros de decisión de arquitectura, en formato corto y guardados en el mismo repositorio que el código, no en una carpeta de la que nadie se acuerda. Cada registro tiene cinco apartados: contexto y restricción, opciones consideradas, decisión, consecuencias asumidas y estado. En la compañía anterior llegamos a 94 registros en tres años. Además de escribirlos, hago dos cosas que importan tanto como el documento. La primera es pasar las decisiones estructurales por un comité de arquitectura con representación de las áreas afectadas, con acta y con fecha, para que quede claro quién estuvo de acuerdo y quién no. La segunda es un procedimiento de excepción con caducidad obligatoria: cuando un equipo necesita saltarse un principio por una entrega urgente, se aprueba con fecha de vencimiento y se revisa. Cuando llegué había diecinueve excepciones vivas sin fecha; al cabo de un año quedaban seis, todas con plazo. Para diagramas uso el modelo C4 con tres niveles, versionados junto al código, porque un diagrama que no se actualiza engaña más que la ausencia de diagrama.

Respuesta modelo

La trato como una cartera de inversiones, no como un problema de calidad, porque en ese lenguaje sí se aprueba presupuesto. Mantengo un registro donde cada elemento lleva tres cifras: cuánto cuesta resolverlo, cuánto cuesta al año convivir con él en incidencias, horas de soporte y retrasos de entrega, y qué riesgo se asume si no se toca. Con eso construyo paquetes priorizados por relación entre coste de convivencia y coste de resolución. En la última compañía presenté al comité de dirección tres paquetes con su retorno estimado y se aprobó reservar el 18 % de la capacidad trimestral, sin campañas especiales ni proyectos de calidad aparte. En dos años cerramos los nueve elementos de mayor interés, entre ellos una versión de Java sin soporte y la duplicidad del maestro de clientes, y las incidencias graves bajaron de veintisiete a ocho al año. Igual de importante es la otra mitad: veinticinco elementos siguen abiertos con la decisión explícita de no acometerlos, revisada cada trimestre. Cuando la dirección ve que usted también sabe no gastar, se fía de las veces que pide dinero.

Respuesta modelo

Parto de tres preguntas de negocio, no de tecnología. La primera es si quien llama necesita la respuesta para continuar: si el usuario está esperando delante de una pantalla y no puede seguir sin el resultado, hay una razón fuerte para lo síncrono. La segunda es qué pasa si el sistema de destino no está disponible: si la operación de origen debe seguir funcionando igualmente, el acoplamiento síncrono es un riesgo inaceptable. La tercera es cuánto retraso tolera el negocio en la consistencia, y esa cifra la doy siempre por escrito. En el caso de contratación y facturación, la respuesta era clara: el usuario no necesitaba la factura para terminar el alta, pero cada caída de facturación bloqueaba la toma de pedidos. Pasé a mensajería con reintentos exponenciales, cola de mensajes fallidos, idempotencia por clave de negocio y outbox transaccional para no perder eventos entre la base de datos y el bus. Acepté una consistencia eventual de hasta noventa segundos en el estado del expediente, acordada con operaciones y visible en la interfaz. El resultado fue que la disponibilidad percibida del canal pasó del 99,3 % al 99,95 % y las incidencias por acoplamiento cayeron de catorce a dos al año. Lo que hay que decir en voz alta es lo que costó: ahora hay que operar un bus, vigilar la cola de fallidos y explicar a atención al cliente por qué durante un minuto el estado puede parecer atrasado.

Respuesta modelo

Introduje event sourcing en el módulo de movimientos de póliza convencido de que la auditabilidad completa lo justificaba. La decisión era defendible sobre el papel: teníamos requisitos de trazabilidad y un histórico difícil de reconstruir. Lo que subestimé fue el coste de aprendizaje del equipo y la dificultad de evolucionar el esquema de eventos con datos ya en producción. A los ocho meses el módulo tenía tres formas distintas de proyectar el estado y cada cambio funcional costaba el doble que en el resto de la plataforma. Hice tres cosas. Primero, medí en lugar de discutir: comparé el plazo de entrega de ese módulo con los demás durante dos trimestres. Segundo, llevé la marcha atrás al comité con la misma estructura que había usado para proponerlo, reconociendo que la premisa de partida era mía. Tercero, conservamos el registro de eventos únicamente como pista de auditoría, en modo de solo escritura, y volvimos a un modelo de estado con histórico versionado, con una migración de once semanas. El plazo de entrega se igualó con el del resto en un trimestre. Desde entonces aplico una regla: si una decisión no es reversible en menos de tres meses, la pruebo antes en un contexto acotado y con criterios de éxito escritos de antemano.

No empiezo por el corte técnico, empiezo por medir dónde duele. Durante dos o tres semanas recojo tres datos: qué partes del código cambian juntas y con qué frecuencia, qué equipos se bloquean en qué módulos y dónde se concentran las incidencias. Ese análisis de acoplamiento histórico suele contradecir el diagrama oficial y evita cortar por donde no toca. Con eso dibujo un mapa de contextos con negocio, no con el equipo técnico solo, porque las fronteras buenas siguen el lenguaje y la responsabilidad del dominio, no la estructura de la base de datos. Después separo dos horizontes. Para el canal nuevo, que tiene fecha, monto una fachada delante del monolito y construyo el canal contra contratos publicados y una capa anticorrupción, de modo que no herede el modelo antiguo aunque por dentro siga llamando al sistema existente. Para el problema estructural, propongo modularizar primero dentro del propio monolito: fronteras explícitas, prohibición de acceso cruzado a tablas comprobada automáticamente en el pipeline y separación de esquemas. Solo extraigo un módulo cuando cumple tres condiciones: frontera estable durante al menos dos trimestres, datos propios sin consultas cruzadas y un equipo capaz de operarlo. Y le pongo cifra al objetivo: reducir a la mitad el número de despliegues que requieren coordinación entre equipos en doce meses.

Con una saga y con honestidad sobre lo que eso implica para el negocio. Primero decido entre coreografía y orquestación: si son tres pasos con reglas simples, coreografía mediante eventos, que acopla menos; si el flujo tiene ramificaciones, plazos y necesidad de saber en todo momento en qué punto está cada operación, orquestación con una máquina de estados explícita, porque el coste de depurar una coreografía de siete pasos es altísimo. Después defino la compensación de cada paso con negocio, y esta es la parte que suele olvidarse: compensar no es deshacer. Si ya se ha emitido un recibo, la compensación es una nota de abono, no borrar el registro, y eso es una decisión funcional que tiene que aprobar el área correspondiente. Técnicamente me apoyo en tres mecanismos: patrón outbox transaccional para que el evento y el cambio de estado se publiquen de forma atómica, idempotencia por clave de negocio para que un reintento no duplique el efecto, y un identificador de correlación que atraviese todo el flujo para poder auditarlo. Añado siempre un plazo máximo por paso con alerta y un procedimiento manual de resolución, porque un porcentaje pequeño de operaciones acabará atascado y alguien de operaciones tendrá que cerrarlas.

Trato el sistema heredado como un recurso escaso y lo aíslo detrás de una única puerta. Primero, un servicio de fachada que sea el único autorizado a hablar con el core: nadie más se conecta, ni siquiera para consultas, porque en cuanto hay quince clientes directos se pierde el control de la carga. Dentro de esa fachada pongo una capa anticorrupción que traduce el modelo heredado, con sus códigos y sus campos de significado ambiguo, al modelo de dominio actual, de forma que la deuda semántica no se propague al resto de la plataforma. Sobre el límite de peticiones aplico tres medidas: limitación de caudal con cola y prioridades para que las operaciones críticas no compitan con procesos masivos, caché con caducidad negociada con negocio para lo que tolera desfase, y separación de lecturas mediante una réplica o una proyección alimentada por cambios, si el core permite extraerlos. Añado disyuntor con respuesta degradada definida por negocio, porque hay que decidir de antemano qué se responde cuando el core no está: en contratación, por ejemplo, acordamos permitir el alta con validación diferida y bloquear solo la emisión. Y documento la capacidad real en peticiones por segundo como una restricción de arquitectura visible, no como un detalle de operación, para que cualquier proyecto nuevo la tenga en cuenta desde el diseño.

Cinco criterios, y el precio de la licencia es el menos importante. El primero es si esa capacidad es diferencial para el negocio: lo que nos distingue de la competencia se construye, lo que es igual en todas las empresas del sector se compra. El segundo es el coste total a cinco años con todo dentro: licencias, implantación, integración, formación, mantenimiento, la persona o el equipo que lo cuidará y el coste de salida si hay que cambiarlo. El tercero es el encaje con nuestros requisitos no funcionales y regulatorios, que en seguros y banca españolas incluye dónde residen los datos, qué garantías ofrece el proveedor bajo el Reglamento DORA y si podemos auditarlo. El cuarto es la velocidad: cuánto tarda cada opción en dar el primer valor y cuánto en estar completa. El quinto es el riesgo de dependencia, medido en concreto por lo difícil que sería sustituirlo y por la salud del proveedor. En el caso del motor de reglas presenté las tres opciones al comité de dirección con esas cifras: mantener costaba 1,4 millones a cinco años, construir 1,1 millones con quince meses y riesgo alto de desviación, comprar 640.000 €. Se aprobó la compra, cerró con un 6 % de desviación y el equipo actuarial pasó de tres semanas a dos días para publicar una regla nueva, que era el indicador que de verdad importaba a negocio.

Automatizando las reglas que se pueden automatizar y reservando mi tiempo para las decisiones que no. Implanté ocho funciones de aptitud en el pipeline: control de dependencias prohibidas entre módulos con ArchUnit, verificación de que ningún servicio accede a la base de datos de otro, comprobación de compatibilidad de contratos con Pact antes de publicar, umbrales de latencia en pruebas de carga nocturnas, límite de tamaño del artefacto de despliegue y detección de dependencias cíclicas. En el primer trimestre bloquearon veintitrés cambios que rompían fronteras, y lo importante es que los bloqueó la máquina, no yo, lo que elimina la discusión personal. Para lo que no se automatiza uso tres niveles: los equipos deciden libremente dentro de su contexto, las decisiones que afectan a contratos compartidos pasan por una revisión de diseño de una hora, y solo las estructurales llegan al comité de arquitectura. También publiqué cinco principios de una línea cada uno, porque un documento de cuarenta páginas no lo lee nadie. Mi señal de que voy bien es cuántas decisiones se toman sin mí y siguen siendo coherentes.

Primero busco el número real y su forma, porque diez veces repartido en un día y diez veces en dos horas son problemas distintos. Pido a negocio el perfil esperado: hora punta, duración, mezcla de operaciones y qué parte es lectura. Con eso hago una prueba de carga contra el sistema actual para encontrar el primer límite, que casi nunca está donde se supone: en el último caso era el número de conexiones a la base de datos y una consulta sin índice en el maestro de clientes, no el servidor de aplicaciones. A partir de ahí, la arquitectura se ordena en cuatro palancas por orden de coste creciente: separar lecturas y cachear lo que tolera desfase, que suele resolver la mayor parte; sacar del camino crítico todo lo que puede esperar, como facturación, notificaciones o antifraude no bloqueante; dimensionar de forma elástica lo que sí queda en el camino crítico; y, solo si hace falta, particionar los datos, que es la opción más cara y la última. En paralelo, defino con negocio la degradación aceptable: qué funcionalidades se apagan primero si llegamos al límite, por ejemplo recomendaciones e histórico ampliado, para no caer del todo. Y cierro con un ensayo con carga real replicada al menos tres semanas antes de la campaña, con criterios de salida escritos.

Con tres prácticas concretas. La primera es clasificar los datos al dibujar el mapa de contextos: qué información personal maneja cada contexto, qué categorías especiales del RGPD aparecen (salud en seguros, por ejemplo), cuál es la base jurídica y cuánto tiempo hay que conservarla. Esa clasificación condiciona el diseño de inmediato, porque determina qué se puede replicar a un entorno de pruebas, qué hay que seudonimizar y qué no puede salir de un entorno determinado. La segunda es el modelado de amenazas en las decisiones estructurales, no en todas: una sesión de dos horas con seguridad cuando se define una frontera nueva, un canal nuevo o una integración con un tercero, con las conclusiones registradas en el propio ADR. La tercera es convertir en automáticas las reglas repetitivas: cifrado obligatorio en tránsito y en reposo, prohibición de datos personales en registros de log comprobada en el pipeline, gestión centralizada de secretos y revisión de permisos mínimos. En entornos sujetos al Esquema Nacional de Seguridad añado la trazabilidad del registro de actividad y la separación estricta de entornos, porque son medidas exigidas y auditadas. La regla que aplico es sencilla: si un requisito de seguridad no está en el ADR de la decisión que lo provoca, terminará convertido en una incidencia seis meses después.

No respondo con un no y tampoco cedo en silencio: presento el coste. Lo primero es entender la fecha, porque no todas las urgencias son iguales; si responde a una campaña contratada o a una obligación normativa, la restricción es real. Después preparo dos o tres opciones con su precio: la solución limpia con su plazo verdadero, la solución que llega a la fecha rompiendo la frontera con el coste anual que eso añadirá, y si existe, una versión reducida del alcance que llegue a tiempo sin romper nada, que es la que más veces acaba aceptándose. Si se elige la vía rápida, la apruebo formalmente como excepción con tres condiciones escritas: fecha de vencimiento, quién asume el trabajo de corrección y en qué trimestre entra en el registro de deuda con su coste. Lo hago así porque el problema real no es la excepción puntual, es la excepción que nadie recuerda haber concedido. Y llevo la decisión al comité aunque ya esté tomada, para que quede constancia de quién asumió el riesgo. En mi experiencia, poner el coste anual encima de la mesa cambia la conversación más que cualquier argumento técnico: cuando el director comercial ve que ahorrar dos semanas cuesta cuarenta mil euros al año, muchas veces es él quien propone recortar alcance.

Empiezo por entender por qué, sin público. Hablo primero con la persona responsable técnica del equipo y pregunto qué problema tenían y qué les llevó a esa solución. En bastantes ocasiones descubro que el principio que se saltaron era inadecuado para su caso o que el camino oficial era tan lento que resultaba impracticable, y entonces el que tiene que cambiar soy yo. Si el problema es real y su solución no lo resuelve bien, valoro el riesgo con datos: qué pasa si se queda como está durante seis meses, qué acopla, qué impide, qué coste tiene revertirlo. Con eso decido entre tres caminos: aceptarlo y modificar el principio, aceptarlo temporalmente como excepción con fecha, o revertirlo si el riesgo lo justifica, cosa que reservo para los casos que afectan a seguridad, a datos personales o a contratos que otros equipos ya consumen. Lo que no hago nunca es convertirlo en un asunto de autoridad ni sacarlo en un comité sin haber hablado antes con el equipo: quemar la relación con los equipos es el error más caro que puede cometer un arquitecto, porque a partir de ahí las decisiones se toman sin avisarle.

Presento tres bloques ordenados por plazo y por riesgo, con cifras y con lo que se pierde en cada uno. En el bloque inmediato, sin impacto funcional, entran las licencias y contratos que ya no se justifican: en la última compañía, retirar tres de los cuatro nodos del ESB tras sustituir las integraciones punto a punto liberó 96.000 € anuales, y consolidar dos herramientas que hacían lo mismo, otros 30.000 €. En el bloque de medio plazo entra la reducción de coste estructural: retirar antes el sistema heredado acelerando la migración por familias de expediente, que ahorra 170.000 € anuales de mantenimiento pero exige inversión previa, y simplificar integraciones que obligan a mantener equipos duplicados. En el tercer bloque pongo explícitamente lo que no recomiendo recortar y por qué, con su consecuencia: reducir la capacidad reservada para deuda técnica ahorra este trimestre y devuelve las incidencias graves al nivel de hace dos años, que costaba en horas de soporte más de lo que se ahorra. Presento cada línea con su ahorro anual, el esfuerzo necesario y el riesgo, y dejo claro cuál es reversible y cuál no. La conversación acaba siendo mucho mejor cuando la dirección ve que usted no defiende su presupuesto por instinto, sino que también señala dónde sobra.

Saco la discusión del terreno de las preferencias y la llevo al de los escenarios. Convoco una sesión con ambas partes y con negocio, y en lugar de debatir las soluciones defino primero los tres o cuatro escenarios de calidad que el sistema tiene que soportar, redactados con números: este volumen en esta franja, esta latencia, este comportamiento cuando el sistema de destino no responde, este plazo de incorporación de un consumidor nuevo. Luego pido a cada equipo que explique cómo se comporta su propuesta en cada escenario y qué coste operativo tiene. Casi siempre ocurre una de dos cosas: aparece una diferencia objetiva que decide sola, o se ve que ambas cumplen y entonces la discusión era estética, y en ese caso decido por criterios secundarios y lo digo abiertamente, por ejemplo la que el equipo que va a mantenerla conoce mejor. Si el desacuerdo persiste y hay tiempo, propongo una prueba acotada de dos semanas con criterios de éxito escritos de antemano. Y si no hay tiempo, decido yo, lo registro con las alternativas y las razones, y me aseguro de decírselo en persona al equipo cuya propuesta no salió, porque una decisión comunicada por acta genera resentimiento durante meses.

Divido los noventa días en tres tramos. En el primer mes escucho y observo, sin proponer nada: hablo con las personas desarrolladoras veteranas, con operaciones, con soporte y con dos o tres responsables de negocio, y reconstruyo el mapa real a partir de tres fuentes objetivas que no mienten: el control de versiones, que muestra qué cambia junto y con qué frecuencia; el registro de incidencias del último año, que muestra dónde duele; y la configuración de red y despliegue, que muestra quién habla con quién de verdad. En el segundo mes documento lo mínimo útil, no un inventario exhaustivo: un diagrama de contexto y otro de contenedores en formato C4, la lista de integraciones con su tipo y su volumen, y las cinco restricciones que condicionan cualquier decisión futura, como los límites del core o las ventanas de proceso nocturno. Ese material lo valido en sesiones con los equipos, que además es la mejor manera de ganarme su confianza. En el tercer mes propongo, y propongo poco: dos o tres decisiones con impacto claro y una forma de trabajar (registro de decisiones, revisiones de diseño, un par de reglas automáticas en el pipeline). Lo que evito a toda costa es llegar con una arquitectura objetivo dibujada en la segunda semana; es el error que más rápido consume el crédito de un arquitecto recién incorporado.