El Arquitecto de Soluciones como puente entre el negocio y la tecnología
La mayoría cree que un arquitecto elige tecnología. Ese es el error.
Hay un perfil que existe en casi todas las organizaciones de tecnología, aunque no siempre tiene ese nombre en la tarjeta de presentación.
Es el que se sienta con el área comercial a entender qué necesitan realmente. Luego se sienta con el equipo técnico a entender qué es viable. Y en el medio — en ese espacio incómodo donde el negocio habla un idioma y la tecnología habla otro — construye el puente.
A veces ese perfil se llama Tech Lead. A veces Analista Funcional Senior. A veces Project Manager con mucho criterio técnico. Y a veces, cuando la organización tiene el cargo formalizado, se llama Arquitecto de Soluciones.
Pero el título no lo define. Lo define la forma de pensar.
El error más común: confundir arquitectura con tecnología
Cuando alguien dice "vamos a necesitar un arquitecto para este proyecto", muchos equipos entienden: "alguien que elija qué tecnologías usar". AWS o Azure. Microservicios o monolito. Kafka o RabbitMQ.
Ese es exactamente el error.
Un Arquitecto de Soluciones no empieza eligiendo tecnologías. Empieza haciendo preguntas incómodas:
- ¿Qué problema de negocio estamos resolviendo realmente?
- ¿Qué pasa si no lo resolvemos?
- ¿Con qué sistemas existentes tiene que convivir esta solución?
- ¿Cuáles son las restricciones reales — regulatorias, presupuestarias, de tiempo?
- ¿Qué riesgos estamos asumiendo con cada decisión?
La tecnología viene al final. Siempre. Y esa secuencia — primero el negocio, luego la arquitectura, luego la tecnología — es la que separa una solución bien diseñada de una que genera deuda técnica, retrabajo y proyectos que nadie recuerda con orgullo.
El puente que nadie ve — hasta que se cae
En los proyectos tecnológicos existe una brecha que aparece una y otra vez, en banca, en telecomunicaciones, en gobierno, en salud. La brecha entre lo que el negocio quiere y lo que el equipo técnico entiende que debe construir.
El negocio habla de "mejorar la experiencia del cliente en el onboarding digital". El equipo técnico escucha "hay que cambiar el formulario de registro". Y así, sin que nadie lo note, el proyecto se construye sobre un malentendido.
Meses después, el producto entregado no resuelve el problema original. El negocio queda insatisfecho. El equipo técnico queda frustrado porque — desde su perspectiva — hicieron todo lo que les pidieron.
Los dos tienen razón. Y los dos perdieron.
El Arquitecto de Soluciones es el profesional cuyo trabajo es evitar exactamente eso. No solo una vez al inicio del proyecto — sino durante todo el ciclo de vida. Traduciendo, validando, cuestionando, facilitando. Asegurándose de que lo que se construye resuelve el problema que originó el proyecto, no el problema que alguien describió mal en una reunión de kick-off.
Los cuatro dominios que toda solución debe considerar
En organizaciones complejas — y la banca es el ejemplo más exigente — una solución bien diseñada debe navegar cuatro dimensiones que rara vez se alinean solas:
Negocio: ¿qué capacidad nueva o mejorada habilita esta solución? ¿Cómo se mide el éxito? ¿Quién es el dueño del proceso?
Datos: ¿qué información necesita fluir, entre qué sistemas, con qué frecuencia y con qué nivel de consistencia? ¿Dónde vive el dato maestro? ¿Quién es responsable de su calidad?
Aplicaciones: ¿qué sistemas están involucrados? ¿Cuáles se reutilizan, cuáles se modifican, cuáles son nuevos? ¿Cómo se integran entre sí?
Tecnología: ¿qué infraestructura, plataformas y herramientas soportan todo lo anterior de manera segura, escalable y sostenible?
Frameworks como TOGAF formalizan esta secuencia. BIAN, en el mundo bancario específicamente, va un paso más allá: define un lenguaje común de capacidades — Customer Onboarding, Payments, Risk & Compliance, Channels — que permite que equipos de distintas organizaciones, países y tecnologías hablen exactamente el mismo idioma.
Lo interesante de estos marcos no es la metodología en sí. Es la disciplina que imponen: no puedes diseñar la solución tecnológica si primero no entiendes el dominio de negocio. No puedes definir las integraciones si no tienes claro el modelo de datos. No puedes elegir la infraestructura si no sabes qué aplicaciones vas a correr.
El orden importa más de lo que parece.
Microservicios, EDA, API Gateway — cuándo importan y cuándo no
Hay un momento en casi toda conversación de arquitectura en que alguien dice "hagámoslo con microservicios" o "necesitamos event-driven". Y la pregunta correcta no es si esas son buenas ideas — generalmente lo son. La pregunta correcta es: ¿para qué problema específico?
Un monolito bien diseñado puede ser exactamente la solución correcta para un sistema interno de baja criticidad. Tiene menos complejidad operativa, es más fácil de desarrollar con equipos pequeños y más simple de debuggear. Elegir microservicios en ese contexto no es modernidad — es sobreingeniería.
En cambio, cuando una transferencia bancaria necesita disparar simultáneamente un registro contable, una notificación al cliente, un análisis antifraude y una actualización del historial crediticio — sin que el fallo de cualquiera de esos procesos detenga a los demás — una arquitectura orientada a eventos con un broker como Kafka no es un lujo. Es la única forma razonable de hacerlo.
La elección correcta siempre depende del contexto: el volumen de transacciones, la madurez del equipo, las restricciones regulatorias, el presupuesto disponible, los sistemas existentes con los que hay que integrarse.
Un arquitecto que llega a cada proyecto con la misma solución, independientemente del contexto, no está haciendo arquitectura — está aplicando una plantilla.
La pregunta que más revelan las entrevistas de arquitectura
"¿Cómo diseñarías una solución para X?"
Es la pregunta clásica. Y la respuesta incorrecta — la que más candidatos dan — es empezar a hablar de tecnologías. "Usaría AWS Lambda para el procesamiento, DynamoDB para el storage, API Gateway para la exposición..."
La respuesta que marca la diferencia empieza así: "¿Puedo hacerte algunas preguntas primero?"
¿Qué problema de negocio resuelve X? ¿Cuántos usuarios concurrentes esperamos? ¿Existen sistemas legados con los que debe integrarse? ¿Cuáles son los requisitos regulatorios? ¿Cuál es el presupuesto? ¿En qué plazo debe estar operativo?
Solo después de responder esas preguntas tiene sentido hablar de tecnologías. Y normalmente, la solución óptima no es la más sofisticada — es la que resuelve el problema real con la menor complejidad sostenible.
Eso es arquitectura.
El perfil que más escasea: quien habla los dos idiomas
Lo que hace al Arquitecto de Soluciones un rol genuinamente difícil de cubrir no es el conocimiento técnico — hay muchos profesionales con sólidos conocimientos en cloud, APIs, bases de datos, patrones de integración.
Lo difícil es encontrar a alguien que pueda sentarse con un gerente comercial y entender lo que realmente necesita. Que pueda luego sentarse con el equipo de desarrollo y traducir esa necesidad en especificaciones técnicas concretas. Que pueda presentar ante un comité ejecutivo las alternativas evaluadas con sus trade-offs, sin asumir que todos saben qué es un circuit breaker o un consumer group de Kafka. Y que pueda, al mismo tiempo, defender esas decisiones técnicamente ante un equipo de arquitectos.
Esa capacidad de navegar fluidamente entre el lenguaje del negocio y el lenguaje de la tecnología — sin perder precisión en ninguno de los dos — es lo que hace que este rol sea estratégico en cualquier organización que dependa de la tecnología para crecer.
Y en 2025, eso es prácticamente todas.
Reflexión final: el título no hace al arquitecto
Existen Arquitectos de Soluciones que en la práctica solo eligen tecnologías y diagraman en Lucidchart. Y existen Project Managers, Tech Leads y Analistas funcionales que hacen arquitectura todos los días sin ese título en su tarjeta.
Lo que define al Arquitecto de Soluciones no es el nombre del cargo. Es la forma de pensar: siempre empezando por el problema de negocio, siempre evaluando alternativas con sus trade-offs, siempre considerando el impacto en los sistemas existentes, siempre pensando en la sostenibilidad de la solución a largo plazo.
Si esa es tu forma de trabajar — si llevas tiempo siendo ese puente entre lo que el negocio necesita y lo que la tecnología puede hacer — entonces ya piensas como un arquitecto.
El título puede venir después.
¿Te identificas con este perfil aunque no tengas ese cargo? ¿O conoces organizaciones donde el arquitecto diseña en el vacío, sin conectar con el negocio? Me interesa leer tu perspectiva en los comentarios.
En próximos posts: qué significa liderar el contexto de un equipo de tecnología — y por qué puede ser más valioso que liderar el código. Y también: cuándo medir el trabajo empieza a competir con hacer el trabajo.
No hay comentarios:
Publicar un comentario