Ideas clave#
- Una decisión técnica no empieza con una tecnología, sino con un problema que necesitamos entender.
- La misma solución puede ser correcta o incorrecta según el contexto, las restricciones y la capacidad del equipo.
- Comparar alternativas exige hacer visible qué ganamos y qué estamos aceptando perder.
- Una buena decisión no busca una respuesta perfecta; busca una respuesta razonable para una situación determinada.
- La ingeniería no consiste solamente en elegir herramientas, sino en comprender sus consecuencias.
Un equipo mantiene una aplicación que ha funcionado bien durante años. El negocio necesita una nueva capacidad, el dominio comienza a crecer y cada despliegue exige más coordinación. En una reunión aparece una propuesta conocida: separar un servicio, introducir eventos y mover la operación a una plataforma más sofisticada.
En pocos minutos la conversación deja de tratar sobre el problema y empieza a girar alrededor de herramientas. ¿Microservicios? ¿Kubernetes? ¿Un broker de eventos? Cada opción tiene argumentos sólidos y documentación suficiente para defenderla.
He visto esta escena repetirse en proyectos con necesidades muy distintas. El momento que más cambia la conversación no ocurre cuando alguien presenta otra tecnología, sino cuando el equipo hace una pregunta más incómoda:
¿Qué cambió en nuestro contexto para que la arquitectura actual dejara de ser suficiente?
A veces la respuesta conduce a un nuevo servicio. Otras veces basta con modularizar mejor, simplificar una integración o delegar parte de la operación. La lección es la misma: no existe una respuesta correcta sin contexto.
La conversación cambia cuando cambia la pregunta#
Las herramientas son fáciles de comparar porque tienen funcionalidades, métricas y casos de uso visibles. El problema real suele estar menos definido: quizá necesitamos reducir el tiempo de entrega, aislar fallos, cumplir una regulación o permitir que dos equipos trabajen con mayor autonomía.
Por eso intento que las revisiones de arquitectura comiencen con la situación y no con el producto. Antes de preguntar qué tecnología utilizar, necesito entender quién tiene el problema, qué resultado esperamos y bajo qué condiciones debe funcionar la solución. Una lista de herramientas no responde ninguna de esas preguntas.
Esto no significa ignorar la experiencia técnica. Significa utilizarla en el momento correcto. La tecnología aparece después de comprender el problema, no antes.
Las restricciones son parte del diseño#
Durante mucho tiempo interpreté las restricciones como algo que debía eliminarse para llegar a una arquitectura ideal. La práctica me enseñó lo contrario: tiempo, presupuesto, regulación, experiencia del equipo y capacidad operativa son información de diseño.
Un equipo pequeño puede preferir un servicio administrado para concentrarse en el producto. Otro, con requisitos estrictos de control y especialistas en plataforma, puede operar la misma capacidad internamente. Las dos decisiones pueden ser correctas porque responden a restricciones diferentes.
Cuando una propuesta solo funciona si ignoramos las condiciones reales del equipo, no tenemos una arquitectura; tenemos un supuesto.
Un ejemplo: procesar eventos de negocio#
Imaginemos que una operación necesita publicar eventos sin bloquear su flujo principal. El equipo puede operar un broker, utilizar un servicio administrado o mantener una integración síncrona mientras el volumen sea manejable. Ninguna alternativa es buena por definición.
flowchart TD
A[Problema: procesar eventos sin bloquear la operación] --> B{Opciones viables}
B --> C[Broker autogestionado]
B --> D[Servicio administrado]
B --> E[Procesamiento síncrono]
C --> C1[Control / carga operativa]
D --> D1[Menos operación / dependencia]
E --> E1[Simplicidad / menor desacoplamiento]
C1 --> F[Decisión según contexto y restricciones]
D1 --> F
E1 --> F
La decisión cambia al responder preguntas concretas:
- ¿Qué nivel de disponibilidad necesita la operación?
- ¿Podemos recuperar o reprocesar eventos?
- ¿Qué volumen esperamos durante los próximos meses?
- ¿Quién atenderá la plataforma cuando falle?
- ¿Cuánta complejidad podemos asumir hoy?
Si el equipo es pequeño y el tiempo de entrega es limitado, reducir la carga operativa puede ser más importante que conservar control total. Si existen requisitos particulares de seguridad, costo o rendimiento, el balance puede cambiar. La arquitectura aparece en esa conversación, no en el nombre del producto elegido.
Cuatro decisiones sin una respuesta universal#
La misma tensión aparece en decisiones comunes de ingeniería. Formularlas como una competencia entre tecnologías oculta las variables que realmente importan:
- Monolito o Microservicios. La respuesta depende de los límites del dominio, la autonomía de los equipos, la frecuencia de cambio y la madurez operativa.
- Integración síncrona vs integración asíncrona basada en eventos. Importan el acoplamiento temporal, la consistencia, la trazabilidad y la forma en que el negocio responde a fallos parciales.
- Máquinas Virtuales o Containers. La portabilidad y la velocidad de despliegue deben compararse con el aislamiento, la plataforma disponible y la experiencia del equipo.
- Managed o Self-Managed. Más control también significa asumir mantenimiento, actualizaciones, observabilidad y respuesta ante incidentes.
Estas preguntas no tienen una opción ganadora para todos los sistemas. Son útiles porque obligan a hacer explícito lo que cada alternativa resuelve y el costo que introduce.
Un marco práctico para pensar decisiones#
Con el tiempo he encontrado útil ordenar la conversación en seis pasos. No lo veo como una metodología rígida, sino como una forma de evitar que una preferencia técnica se convierta en una decisión sin haber sido examinada.
flowchart LR
P[Problema] --> A[Contexto]
A --> B[Restricciones]
B --> C[Alternativas]
C --> D[Trade-offs]
D --> E[Decisión]
E --> F[Consecuencias]
1. Contexto: ¿qué problema estamos resolviendo?#
El contexto describe la situación actual, las personas afectadas y el resultado que buscamos. Importa porque dos sistemas técnicamente parecidos pueden tener prioridades de negocio y operación completamente diferentes.
2. Restricciones: ¿dentro de qué límites debemos decidir?#
Aquí hacemos visibles el tiempo, el presupuesto, la regulación, la experiencia y la capacidad operativa. Una alternativa que no puede sostenerse bajo esos límites no es realmente una alternativa.
3. Alternativas: ¿qué caminos son viables?#
Comparar al menos dos opciones evita confundir una preferencia con una decisión. No necesitamos una lista extensa; necesitamos caminos que resuelvan el mismo problema y puedan evaluarse bajo las mismas condiciones.
4. Trade-offs: ¿qué ganamos y qué aceptamos perder?#
Más control suele traer más responsabilidad. Una entrega rápida puede limitar flexibilidad futura y una menor carga operativa puede aumentar la dependencia de un proveedor. Hacer visible ese intercambio permite discutir consecuencias en lugar de gustos.
5. Decisión: ¿por qué esta alternativa tiene sentido ahora?#
La decisión debe conectar la opción elegida con el contexto y sus restricciones. No afirma que será correcta para siempre; explica por qué es razonable con la información disponible hoy.
6. Consecuencias: ¿qué cambia después de elegir?#
Toda decisión crea trabajo, riesgos y nuevas condiciones. Conviene definir qué señales obligarían a revisarla: un aumento de costos, un cambio de volumen, nuevos requisitos o una capacidad operativa que antes no existía.
Registrar la decisión conserva el contexto#
He aprendido que la memoria de un equipo comprime las decisiones. Meses después recordamos qué tecnología elegimos, pero no siempre las restricciones que justificaron la elección. Un registro pequeño puede conservar esa información sin convertirse en un documento difícil de mantener:
id: ADR-001
status: accepted
context:
Procesar eventos de negocio sin bloquear la operación principal
decision:
Usar una solución administrada de mensajería
drivers:
- equipo pequeño
- tiempo limitado de entrega
- necesidad de recuperación de eventos
review_when:
- aumento significativo de costos
- cambio en requisitos
- nueva capacidad operativaEl valor no está solamente en registrar qué elegimos, sino en recordar por qué lo elegimos y cuándo deberíamos revisarlo.
Una buena decisión técnica también debe poder explicarse. Meses después alguien preguntará:
¿Por qué hicimos esto?
La respuesta más útil no es “porque era la tecnología recomendada”, sino una explicación que conecte el problema, las opciones consideradas y las consecuencias aceptadas. La arquitectura también es comunicación: si una decisión no puede explicarse, será difícil operarla, cuestionarla o evolucionarla en equipo.
Continuando la conversación#
Esta forma de analizar decisiones es la base de Decisiones de Ingeniería #001, un workshop técnico virtual en vivo donde aplicaremos este marco sobre diferentes escenarios y discutiremos los trade-offs detrás de cada alternativa.
Conclusión#
Las herramientas continuarán cambiando y conocerlas seguirá siendo parte del trabajo. Pero conocer una tecnología no es lo mismo que saber cuándo utilizarla.
La ingeniería no consiste solamente en elegir herramientas. Consiste en entender problemas, evaluar alternativas y asumir conscientemente las consecuencias de una decisión.
Una decisión técnica es más fuerte cuando puede explicarse, defenderse y revisarse. No porque sea perfecta, sino porque hace explícitos el problema que resuelve, los límites que reconoce y las consecuencias que el equipo decide asumir.