Todos somos arquitectos de software... en teoría.

Al terminar de leer el capítulo 14 (Software Architecture) del libro Code Craft escrito por Peter Goodliffe, me surgió el cuestionamiento: ¿Realmente conocemos de arquitectura de software? digo, todo el contenido descrito por el autor como: componentes, diseño, comunicación, interfaces, entre muchos otros, realmente son conocimientos que, de una u otra forma, hemos visto hasta el hartazgo en la carrera. Pero, aún así: ¿Por qué es necesario el repaso? regreso a mi pregunta inicial: ¿Realmente conocemos de arquitectura de software? 

Resulta increíble el pensar que muchas veces como estudiantes y, aún peor, como profesionales primerizos pequemos de subestimar la arquitectura de sistemas y englobarla en términos como: documentación, diagramas, requerimientos de negocio -como nota, he de admitir que estos conceptos no tienen nada que ver con lo que es la arquitectura de software si se piensan por separado, pero justo demuestra mi punto referente a nuestra, tal vez justificada, ignorancia respecto a lo que significa y conlleva diseñar software-. Porque sí, el desempeñarnos como tal requiere de dichos elementos en algún punto pero, al no darle la importancia necesaria e inclusive dejarla al último en un esquema de trabajo para un proyecto, resulta casi obvio el por qué muchos de nuestros trabajos académicos se caracterizan por ser poco reutilizable y por carecer de escalabilidad y que asociemos a estas herramientas como la definición y aplicación de una edificación tecnológica. Aunque, igualmente no es del todo nuestra culpa que sea así... de hecho, me atrevería a decir que estas fallas son esperadas aún después de nuestro final como estudiantes -he de ahí la razón por la que mencioné que sí puede estar justificada nuestra poca experiencia-, pues, como es mencionado en el capítulo: Llevamos mucho tiempo creando y diseñando edificios; software realmente llevamos poco y aún estamos aprendiendo sobre la marcha. Igualmente, y, complementando lo anterior dicho, es nuestro conocimiento en temas como Programación Orientada a Objetos y todos aquellos relacionados con la Ingeniería de Software que se logra digerir el contenido del capítulo de mejor manera. Es decir, resulta más sencillo corregir nuestra percepción de arquitectura una vez que ya se tienen nociones fuertes sobre sus dependencias, que partir de raíz con estas abstracciones. 

A modo de conclusión -y reconociendo que no se debatió mucho sobre la carnita del capítulo como las diferentes formas o estilos de arquitectura digital-, me gustaría cerrar con mi propia concepción sobre, lo que creo yo, fue el tema central del capítulo y con lo que inicié esta entrada: realmente, no conocemos de arquitectura, no porque no se nos haya enseñado, sino porque nosotros hacemos la arquitectura en el momento, aunque claro, esta percepción no justifica la mala práctica de no tener una visión planeada y estructurada de nuestros sistemas a desarrollar, pues justamente son estos dos motivos lo que nos motivan a seguir creando y mejorando nuestro concepto de arquitectura de software.