Espacio de problema vs solución en arquitectura

Comunicar bien tu trabajo como arquitecto de software empieza por separar lo que el sistema debe resolver de cómo lo va a resolver. Esa distinción, sumada a una comunicación adaptada a tu organización, define si tu arquitectura se entiende, se aprueba y se construye sin fricción.

¿Qué diferencia el espacio del problema del espacio de solución?

La primera tarea de un arquitecto es guiar la conversación hacia dos territorios distintos. El espacio del problema reúne las ideas, intenciones y requerimientos que el sistema debería atender. El espacio de solución contiene las opciones técnicas disponibles para responder a esos requerimientos.

Mezclarlos es uno de los errores más comunes y casi siempre nace de un sesgo organizacional. Cuando alguien dice necesitamos un microservicio de detección de fraude, ya está empujando una solución antes de definir el problema. Un ingeniero sin experiencia se entusiasma con un modelo asistido por IA. Un arquitecto experimentado pregunta primero qué se considera fraude, porque esa respuesta cambia el nivel de tolerancia al error y, con él, toda la arquitectura.

¿Qué es el espacio del problema en arquitectura de software? Es la serie de retos y requisitos que descubres conversando con tu cliente. No incluye soluciones, solo lo que necesita resolverse y por qué importa.

¿Qué preguntas usar para explorar cada espacio?

Cada espacio se descubre con un tipo de pregunta diferente. En el espacio del problema dominan el por qué, el para qué y el qué. En el espacio de solución, el cómo.

• Qué problema queremos resolver, para fijar el alcance.
• Por qué se necesita una solución, para medir urgencia y prioridad.
• Por qué ocurre el problema, para encontrar causas y problemas de contexto que no se dicen explícitamente.
• Por qué con estas restricciones (más rápido, más eficiente, más fácil), para validar si vale la pena el esfuerzo.
• Qué aspectos desconocidos hay, como regulaciones que pueden cambiarlo todo.

Solo cuando esas respuestas están claras tiene sentido pasar al cómo.

¿Cómo influye la ley de Conway en tu arquitectura?

A mediados del siglo XX, Melvin Conway formuló un principio que sigue vigente: las organizaciones que construyen sistemas de información terminan replicando, en esos sistemas, su propia forma de comunicarse. Si tu equipo se comunica de forma fragmentada, tu sistema saldrá fragmentado.

Esto tiene un costo concreto: la carga cognitiva, que es la cantidad de ideas que una persona debe sostener en su cabeza para hablar de un contexto. Cuanta más carga cognitiva exija tu arquitectura, más difícil será mantenerla y comunicarla.

¿Qué dice la ley de Conway? Que el diseño de un sistema refleja la estructura de comunicación de la organización que lo construye. Si quieres cambiar la arquitectura, observa primero cómo conversa el equipo.

Cada organización se comunica distinto. Las distribuidas tienden a lo asíncrono y estandarizado. Las jerárquicas concentran decisiones. Y muchas combinan ambos modelos. Tu trabajo es detectar esos patrones, adaptarte a ellos y hacerte entender dentro de ellos.

¿Cómo comunicar efectivamente tu arquitectura?

El medio es el mensaje. Si entregas un PDF estático, recibirás silencio. Si entregas un documento vivo, recibirás decisiones. Para eso existen el hipertexto, que enlaza textos con otros recursos, y la hipermedia, que suma video, audio o diagramas interactivos.

Los documentos de arquitectura solo tienen sentido cuando incluyen tres cosas:

• Comentarios e interacciones entre lectores.
• Control de cambios para revisar cómo evolucionó la decisión.
• Una plantilla común que reduzca la fricción de lectura.

Pide feedback directo sobre secciones específicas, no sobre el documento entero. Y no aceptes el por mí está bien: esa respuesta es la versión educada del desinterés y deja decisiones sin validar.

¿Por qué establecer fechas de corte en la documentación?

La documentación sin fecha de cierre cae en parálisis por análisis. Nadie la lee, nadie opina, nadie decide. Establecer una fecha límite obliga a la conversación y convierte el documento en un instrumento de decisión, no en un archivo muerto.

¿Qué diagramas debe dominar un arquitecto de software?

Después de los documentos, los diagramas son el segundo medio más importante. Puedes crear estándares propios para tu organización o apoyarte en estándares ampliamente adoptados.

• C4 model, para comunicar abstracciones que se vuelven cada vez más concretas a medida que avanzas en el espacio del problema.
• Diagramas de secuencia, para visualizar la dinámica de mensajes entre los actores de un sistema.
• Estándares de proceso, para formalizar actividades, tareas y paralelizaciones de un proceso de negocio.
• UML, que cubre estructuras, estados, secuencias e incluso despliegues.

¿Qué es el C4 model? Es un estándar de diagramación que organiza la arquitectura en cuatro niveles de abstracción, de lo más general a lo más concreto, para que cada audiencia vea lo que necesita.

¿Cómo aplicar esto a tu propio problema?

Vuelve al problema que trabajaste en clases anteriores y reescríbelo separando con claridad el espacio del problema del espacio de solución. Dos técnicas te ayudan a profundizar:

• Los cinco why, para preguntar iterativamente por qué hasta llegar a la causa raíz.
• Los seis sombreros, para examinar el problema desde puntos de vista distintos: emocional, crítico, creativo, optimista, analítico y organizativo.

¿Cuál de estas técnicas crees que te dará más claridad en tu próximo proyecto? Cuéntalo en los comentarios.