Architectural Drivers

Qué son

Architectural Drivers son las necesidades, restricciones y preocupaciones que orientan de manera significativa el diseño de una arquitectura. Explican por qué ciertas alternativas son razonables, insuficientes o inviables para un sistema concreto.

essential-complexity permite distinguir obligaciones del problema elegido de los mecanismos para satisfacerlas; accidental-complexity examina trabajo introducido por representaciones y respuestas de solución. Un driver real puede justificar complejidad adicional, mientras una preferencia tecnológica por sí sola no demuestra esa necesidad.

El SEI presenta como entradas de Attribute-Driven Design la funcionalidad conocida, los requisitos de atributos de calidad y las restricciones. La identificación de drivers guía decisiones que deben satisfacer esas influencias. Attribute-Driven Design Method Collection.

No constituyen una copia del backlog. Se seleccionan y priorizan por su influencia sobre decisiones y estructuras. Tampoco son una lista de tecnologías preferidas: nombrar Kubernetes, una base de datos o un framework no explica qué necesidad obliga a utilizarlos.

Del propósito a las decisiones

El Atlas usa la siguiente cadena como framing conceptual:

Business Goal
→ Requirements
→ Architecturally Significant Requirements
→ Architectural Drivers
→ Quality Attributes
→ Trade-offs
→ Architecture Decisions

La cadena conecta propósito, selección de requisitos relevantes y consecuencias de diseño. No representa etapas cerradas ni exige descubrir todos los requisitos antes de decidir. Los atributos de calidad ya pueden aparecer entre los requisitos y drivers; volver a examinarlos permite comparar alternativas y explicitar trade-offs.

El SEI relaciona objetivos de negocio con requisitos de calidad y advierte que estos suelen quedar peor expresados que la funcionalidad. Relating Business Goals to Architecturally Significant Requirements for Software Systems, Clements y Bass. El objetivo es conservar una justificación rastreable, no traducir cada meta comercial directamente a una tecnología.

Una decisión revela restricciones nuevas; una prueba invalida una hipótesis; un cambio comercial modifica prioridades. Ese feedback puede obligar a revisar toda la cadena. systems-thinking ayuda a identificar efectos fuera del alcance inicialmente observado.

Qué influencias considerar

Familia	Ejemplo de influencia arquitectónica
Business goals	Abrir un canal comercial sin depender de una única integración.
Funcionalidad significativa	Confirmar una operación que cruza responsabilidades distintas.
Quality attributes	Recuperar un flujo crítico dentro de un plazo acordado.
Constraints	Mantener compatibilidad con un contrato externo existente.
Contexto técnico	Integrarse con sistemas cuya modificación no controlamos.
Organización	Equipos con responsabilidades y horarios de operación diferentes.
Regulación	Restringir acceso, residencia o retención de ciertos datos.
Cost y time	Entregar una capacidad antes de una fecha con presupuesto limitado.
Existing systems	Conservar información y comportamiento durante una transición; legacy-systems examina valor y restricciones heredadas.
Team capabilities	Operar el diseño con habilidades y soporte disponibles.

Estas familias se superponen. Un objetivo comercial puede generar necesidades de disponibilidad, integración y costo. Una restricción regulatoria puede limitar despliegue y administración. Es importante conocer origen, responsable y vigencia para no perpetuar una condición que ya cambió.

Requirements y drivers

Un requisito describe una necesidad o condición que el sistema debe satisfacer. Un driver es un requisito seleccionado u otra influencia relevante por su capacidad de orientar decisiones arquitectónicas. La priorización expresa su peso frente a otros drivers. No son sinónimos ni categorías mutuamente excluyentes.

«Mostrar el nombre del cliente» puede implementarse localmente bajo un contrato ya acordado. «Permitir integrar clientes de organizaciones externas sin acceso directo a sus datos» puede modificar fronteras de confianza, identidad y responsabilidad. Ambos son requisitos; su influencia arquitectónica depende del contexto.

architectural-significance ayuda a seleccionar lo que merece atención. La selección necesita explicar consecuencias de ignorar cada driver y conflictos entre ellos. Priorización no elimina obligaciones: una condición legal puede ser no negociable aunque otras necesidades permitan compromisos.

También conviene distinguir necesidad de respuesta propuesta. «Los equipos requieren entregas independientes» abre alternativas; «cada equipo tendrá diez servicios» prescribe una solución que todavía necesita justificación.

Expresar un driver utilizable

Un driver útil identifica quién necesita qué resultado, en qué condiciones y cómo reconocer cumplimiento. «Rápido» y «fácil de cambiar» dejan demasiado margen a interpretaciones incompatibles. quality-attributes-overview distingue esas preocupaciones de restricciones y respuestas técnicas propuestas.

Los objetivos pueden refinarse en requirements / ASRs, drivers y quality-attribute-scenarios, para comparar quality-attribute-trade-offs y decisiones. El recorrido es iterativo: evidencia nueva puede revisar el escenario o la prioridad, sin exigir completar una cadena waterfall.

requirements-to-architecture desarrolla la práctica de aclarar esas entradas y seleccionar influencias significativas. design-process utiliza los drivers para explorar y contrastar candidatos. Interpretar una necesidad, seleccionar su peso y elegir una solución son trabajos relacionados; el recorrido no convierte cada requisito en driver ni cada driver en una tecnología inevitable.

Por ejemplo: nuevos proveedores de facturación deben incorporarse sin modificar los consumidores del contrato de ventas, dentro del plazo comercial acordado. La propuesta necesita revisar propiedad del contrato, adaptación e información disponible. La condición puede investigarse mediante una integración representativa, sin construir anticipadamente todos los proveedores.

Otra preocupación puede exigir que solo un grupo autorizado acceda a datos de clientes durante soporte. El análisis debe incluir permisos, evidencia y operación, además del código que consulta esos datos. La precisión suficiente depende de la decisión: no toda conversación necesita un modelo cuantitativo completo.

Tecnología, restricción y preferencia

«Queremos Kubernetes» puede expresar familiaridad, una política organizacional o una hipótesis sobre despliegue. Hay que preguntar qué objetivo cumple, qué restricciones son reales y qué alternativas existen.

Si una plataforma es obligatoria por un acuerdo vigente, constituye una restricción de diseño que debe hacerse explícita. Eso no demuestra que sea universalmente mejor. Si solo es una preferencia, conviene evaluar costos y efectos antes de adoptarla.

software-architecture distingue stack de responsabilidades y compromisos. Las capacidades tecnológicas importan cuando se relacionan con una necesidad comprobable: por ejemplo, soportar un contrato de integración existente o permitir una recuperación evaluada.

Ejemplo: confirmar pedidos

Un negocio quiere reducir pedidos que quedan sin procesar después de confirmarse. Los requisitos deben aclarar qué promete la confirmación y cuánto retraso posterior resulta aceptable.

Si la intención debe conservarse ante caídas entre guardar estado y notificar, dual-write-problem expone una preocupación significativa. Si el negocio acepta entrega posterior con responsabilidad durable, transactional-outbox puede ser una alternativa. No es una elección automática: requiere considerar duplicados, observabilidad y recuperación.

El driver no es «usar un broker». Es satisfacer una obligación de negocio bajo fallos y restricciones identificados. Otra frontera transaccional o un contrato diferente puede producir una solución válida con tecnologías similares o distintas.

Conflictos, evidencia y evolución

refactor-vs-rewrite necesita un resultado requerido para comparar transformación y reemplazo; un lenguaje nuevo no justifica por sí solo la elección. migration-strategy conecta ese resultado con estados y secuencia factibles bajo restricciones. Descubrir que el trayecto no conserva una obligación puede exigir revisar alcance o prioridad, no solamente cambiar el cronograma.

Las prioridades pueden entrar en tensión: confirmar tras persistencia durable aumenta trabajo en el camino crítico; agregar redundancia incrementa costo; aislamiento de recursos reduce aprovechamiento compartido. El análisis necesita definir qué resultado se protege y qué sacrificio se acepta.

trade-off-analysis utiliza esos drivers para seleccionar criterios y comparar alternativas creíbles, separando preferencias de condiciones obligatorias. estimation puede aclarar magnitudes decisivas como demanda o retención; sus supuestos necesitan validación y no se convierten en drivers por el solo hecho de tener una cifra.

Mantener drivers visibles ayuda a reevaluar decisiones. Si aumenta exposición regulatoria o cambia la capacidad del equipo, una arquitectura antes razonable puede requerir ajuste. No implica que la decisión original fuera incorrecta: cambió su contexto.

evolutionary-architecture conecta esa revisión con cambio guiado. fitness-functions puede contrastar expectativas seleccionadas; sus criterios deben revisarse cuando cambia intención. architecture-erosion pregunta por debilitamiento de compromisos vigentes, sin clasificar una evolución justificada como violación por contradecir decisiones antiguas.

Errores frecuentes son convertir cada ticket en driver, ocultar restricciones bajo preferencias, inventar requisitos para justificar una tecnología y conservar prioridades sin revisar evidencia. architecture-foundations organiza el recorrido; architecture-vs-design ayuda a distribuir atención entre decisiones sistémicas y diseño local.