Suponga que se encuentra solo en una sala en la que dispone para su entero goce de 2 sillas en las que reposar sus extenuadas pompas. Toma una de ellas y al sentarse experimenta una vergonzosa caída al piso debido a la imprevista “descomposición” de la silla. Sin mediar pausa junta las partes esparcidas y logra recomponer la silla a su forma original… al menos ahora ha vuelto a parecer una silla. Dejando de lado sus pensamientos espurios, es de esperar que si alguien entra a la sala y necesita sentarse seguramente usted le ofrezca gentilmente tan solo una de las sillas, la sana. Quizás no lo ha notado, pero algo interesante acaba de ocurrir: dispone de un elemento que tiene forma de silla pero que no sirve para sentarse, como si esa silla no existiera. Pero ahí está, con sus 4 patas, sentadera y respaldo, se puede tocar, mover. Pero nadie se puede sentar en ella, no cumple el propósito para el cual fue diseñada y construida.
La lectura entre líneas es que toda cosa tiene un “ser” y un “parecer”, y ambos aspectos se derivan de un propósito, de una razón de existir. Una segunda lectura entre líneas revela que el “ser” es algo que sucede y el “parecer” hace a las formas.
Esa cosa parece una silla (porque tiene 4 patas, sentadera y respaldo) y es una silla porque me siento en ella. Y esto es posible (o sea, es real) porque fue diseñado intencionalmente para que así sea. Hablando en criollo, le llamamos “arquitectura” a la forma, estructura y comportamiento que determinan que las cosas sean lo que parecen. O dicho de otra forma, las cosas son lo que parecen porque tienen una arquitectura que lo determina.
Trasladando la analogía de la silla al desarrollo de software, podemos improvisar algunas notas ayuda-memoria:
Si logré evitar confundirlo lo suficiente con el entendido sobre la arquitectura de las cosas, permítame colaborar en el goce del ejercicio de su trabajo de arquitecto de software con algunas recomendaciones: