Orion Protocol

El Camino del Arquitecto: Amplitud de Conocimiento y Toma de Decisiones

Este post explora el enfoque que un arquitecto de software debe adoptar para adquirir conocimiento. Analiza el concepto de amplitud técnica y cómo esta influye en la toma de decisiones, utilizando la matriz de Rumsfeld como marco de referencia para entender los diferentes niveles de conciencia sobre lo que se sabe y lo que se ignora. A través de este modelo, se resalta la importancia de un conocimiento amplio para la gestión de riesgos y la resolución de problemas en la arquitectura de software.

Amplitud vs. Profundidad: El Enfoque del Arquitecto

El rol del arquitecto de software difiere significativamente del rol de un desarrollador en cuanto al enfoque del conocimiento. Mientras que un desarrollador profundiza en un área específica, un arquitecto debe tener un amplio conocimiento en distintas áreas.

• Desarrollador: El desarrollador se mueve en el eje Y, buscando profundidad de conocimiento. Su meta es dominar un lenguaje, tecnología o tipo de implementación específico.
• Arquitecto: El arquitecto se desplaza en el eje X, priorizando la amplitud de conocimiento. Debe conocer diversas temáticas del desarrollo de software sin necesidad de ser un experto en cada una.

El aumento de la amplitud técnica y el conocimiento general permite a un arquitecto tomar mejores decisiones.

La Matriz de Rumsfeld: Un Modelo para la Toma de Decisiones

Para la toma de decisiones, podemos usar como ejemplo la matriz de Rumsfeld. Esta matriz, una herramienta de gestión de riesgos, clasifica el conocimiento en cuatro cuadrantes, lo que nos ayuda a graficar nuestra conciencia sobre lo que sabemos.

• Lo que sabemos que sabemos: Como arquitecto o desarrollador, somos conscientes de que podemos manejar y utilizar un lenguaje, framework o tecnología específica. Es nuestro dominio de especialización.
• Lo que sabemos que no sabemos: Conocemos la existencia de tecnologías o lenguajes que no dominamos o de los que no tenemos conocimiento profundo. Sabemos que necesitamos investigar o aprender más sobre ellos si son relevantes para un proyecto.
• Lo que no sabemos que sabemos: Este es un conocimiento tácito que adquirimos con la experiencia y que solemos dar por sentado. Un ejemplo es la experiencia en resolución de problemas comunes o la intuición para el diseño de sistemas.
• Lo que no sabemos que no sabemos: Todo lo que desconocemos por completo. Son las incógnitas desconocidas (unknown unknowns), las que representan el mayor riesgo en cualquier proyecto de software. Es lo que no hemos escuchado o de lo que no tenemos ninguna noción.

Cuantificando el Conocimiento

Para visualizar y cuantificar este conocimiento, se puede usar la pirámide que complementa la matriz de Rumsfeld.

Desarrollar una mentalidad de amplitud técnica es clave para un arquitecto de software que busca tomar decisiones informadas y mitigar riesgos. Entender los diferentes niveles de conocimiento, desde lo que dominamos hasta las incógnitas desconocidas, nos prepara mejor para enfrentar los desafíos de un proyecto.