Una arquitectura puede ser elegante, segura, escalable y técnicamente defendible y, aun así, ser una mala decisión para la organización que tendrá que operarla.
Eso ocurre porque correcto técnicamente y adecuado para el negocio no son exactamente la misma pregunta.
La primera mira diseño, controles, rendimiento, integración y buenas prácticas.
La segunda también necesita mirar restricciones, personas, presupuesto, continuidad, tiempo, dependencia y capacidad de cambio.
La mejor arquitectura no es necesariamente la más sofisticada. Es la que la organización puede operar, gobernar, recuperar y evolucionar de forma sostenible.
Una arquitectura siempre existe dentro de restricciones
En un diagrama es fácil diseñar componentes ideales.
En la realidad aparecen preguntas como:
- ¿quién va a operarlos?;
- ¿qué conocimiento requiere la solución?;
- ¿qué pasa fuera del horario normal?;
- ¿cuánto cuesta mantenerla además de comprarla?;
- ¿qué dependencias crea?;
- ¿cómo se integra con lo que ya existe?;
- ¿qué ocurre cuando falla?;
- ¿cómo se recupera?;
- ¿qué tan difícil será reemplazarla?;
- ¿la organización tiene capacidad real para absorber el cambio?
Ignorar esas restricciones no las elimina.
Solo las desplaza hacia la operación futura.
La complejidad también es una deuda
Cada componente adicional puede aportar redundancia, control o flexibilidad.
También puede añadir:
- configuración;
- monitoreo;
- actualización;
- dependencia;
- superficies de falla;
- conocimiento especializado;
- pruebas;
- documentación;
- recuperación;
- coordinación entre equipos.
Por eso una arquitectura con más capas no es automáticamente una arquitectura mejor.
La pregunta es si el valor adicional justifica la complejidad adicional.
En ciberseguridad esta discusión es especialmente importante porque muchas arquitecturas terminan acumulando controles que nadie quiere retirar, aun cuando la operación ya no puede mantenerlos con la profundidad esperada.
El costo real aparece después de la compra
Una decisión tecnológica suele evaluarse con cifras visibles:
- licencia;
- infraestructura;
- implementación;
- servicios profesionales.
Pero el costo operativo puede incluir además:
- capacitación;
- administración diaria;
- integraciones;
- almacenamiento;
- atención de alertas;
- investigación de errores;
- actualizaciones;
- pruebas de compatibilidad;
- respuesta ante fallas;
- renovación o migración futura.
Una arquitectura puede ser económicamente viable en adquisición y demasiado costosa en operación.
Por eso el costo debería evaluarse durante el ciclo de vida, no solo durante el proyecto.
Las habilidades disponibles forman parte de la arquitectura
Un diseño que depende de conocimiento que la organización no posee necesita responder cómo obtendrá y conservará ese conocimiento.
Las opciones pueden ser distintas:
- desarrollar capacidad interna;
- contratar especialistas;
- operar con un tercero;
- simplificar el diseño;
- automatizar ciertas tareas;
- aceptar una dependencia controlada.
Ninguna es universalmente correcta.
Lo que no funciona es asumir que la habilidad aparecerá después porque la arquitectura la necesita.
Seguridad también significa poder recuperarse
Una solución puede mejorar prevención o detección y, al mismo tiempo, crear una nueva dependencia crítica.
Por eso me interesa preguntar:
- ¿qué pasa si este componente deja de estar disponible?;
- ¿cuánto depende el proceso de él?;
- ¿existe una forma degradada de operar?;
- ¿cómo se reconstruye?;
- ¿qué datos o configuraciones deben protegerse?;
- ¿hemos probado la recuperación?;
Una arquitectura que no contempla su propio fallo está incompleta desde una perspectiva de resiliencia.
La reversibilidad importa
No todas las decisiones necesitan ser permanentes.
Cuando existe incertidumbre, una arquitectura puede ganar valor si permite:
- probar en una escala limitada;
- separar componentes;
- cambiar proveedores;
- exportar datos;
- retirar una integración;
- volver a una condición anterior;
- evolucionar por etapas.
La reversibilidad reduce el costo de aprender.
También evita convertir una decisión tecnológica razonable hoy en una dependencia difícil de cuestionar mañana.
Una buena decisión tecnológica responde primero al problema
Antes de discutir productos o componentes, intento precisar:
¿Qué problema estamos resolviendo?
No qué tecnología queremos desplegar, sino qué limitación, riesgo o necesidad debe cambiar.
¿Qué resultado esperamos?
Más visibilidad, menor exposición, mejor recuperación, una decisión más rápida, menos trabajo manual, mayor confiabilidad.
¿Qué restricciones son reales?
Presupuesto, personal, tiempo, regulación, legado tecnológico, ventanas de cambio, proveedores o conocimiento.
¿Qué operación requiere?
Quién administra, quién responde, quién valida, qué ocurre cuando falla y qué evidencia necesitamos conservar.
¿Qué alternativas existen?
Incluida la posibilidad de simplificar, integrar mejor lo actual o no incorporar una nueva plataforma todavía.
El diagrama no es el resultado
Una arquitectura puede verse impecable y producir muy poco valor si no se traduce en capacidad operativa.
Por eso prefiero evaluar una decisión tecnológica en varias dimensiones simultáneas:
ajuste al problema → reducción de riesgo → operabilidad → integración → costo total → resiliencia → gobierno → capacidad de evolución
Una debilidad en cualquiera de ellas puede cambiar la decisión.
Esto también aplica a la ciberseguridad
En seguridad existe una presión natural por incorporar más controles.
A veces es necesario.
Pero cada control debería poder responder:
- qué escenario modifica;
- quién lo opera;
- qué dependencia introduce;
- cómo se integra;
- cómo se valida;
- qué pasa cuando falla;
- cómo sabremos si sigue siendo necesario.
Ese análisis ayuda a evitar dos extremos:
subproteger por simplicidad y sobrearquitectar por acumulación.
Una conclusión práctica
La arquitectura técnica importa.
Pero la estrategia tecnológica aparece cuando esa arquitectura se evalúa también desde la organización que tendrá que vivir con ella.
Por eso una solución puede ser técnicamente correcta y seguir siendo una mala decisión si:
- nadie puede operarla bien;
- su complejidad supera el valor que aporta;
- crea dependencias difíciles de gestionar;
- no puede recuperarse de forma confiable;
- consume capacidad que debería estar dedicada a prioridades mayores;
- o no existe una ruta razonable para evolucionarla.
La pregunta final no es solamente:
¿Está bien diseñada?
También es:
¿Es una decisión que esta organización puede sostener y defender?
Trabajo relacionado
De herramientas a capacidades: diseño de un modelo de decisión para estructurar ciberseguridad