Las corporaciones necesitan de arquitectos más que el software

Desde que entré a esta clase y, en general, desde que tengo la noción de que existe una rama del desarrollo de software titulado Arquitecto de software, me he preguntado sobre el por qué dicho término existe y, más importante aún, ¿Qué es lo que hacen y por qué sus conocimientos son tan requeridos pero tan subestimados? En mi última publicación, mencionaba que un término como el que nos reúne semana a semana en este blog es difícil de definir y hasta de comprender en su totalidad debido a que, como sucede en cualquier disciplina, requiere de mucho esfuerzo, trabajo y recursos el lograr estandarizar términos cuando dichos conceptos se están construyendo y hasta siendo utilizados sobre la marcha. 

La historia del software, como hemos visto durante nuestra carrera, es única en cuánto a su documentación y normalización se refiere pues, dado a su amplia diversidad de contextos de uso, los empleos que se han creado se han pensado que pueden y deben ser entendidos y aplicados por todos los desarrolladores. No obstante, como Martin Fowler redacta en su texto Who Needs an Architect? así como no todos los doctores son capaces de realizar ciertas cirugías, no todos los computólogos pueden abstraer y transmitir el propósito y jerarquía de un sistema. Es decir, con esto en mente, el autor nos permite intuir que un arquitecto de software cobra valor no por su desempeño -entendiendo a este término como las tareas que realiza cotidianamente- sino por el impacto que dichas actividades tienen dentro del presente y futuro de un producto y hasta de una compañía. Y es que, aunque parezca contra-intuitivo, son precisamente las necesidades de negocio las que le dan sentido al buen diseño de software, ya que son realmente éstas las que, junto con un buen arquitecto, las que dictan cuáles y cómo es que interactúan nuestros componentes. 

A modo de conclusión, puedo decir que es bastante interesante cómo es que uno de los roles más solicitados actualmente sea tan complicado de definir, aún hoy en día y que aún sea tan mal entendido y hasta subestimado en muchos casos -ya menos pero aún pasa-. A modo personal, creo que esta perspectiva, aunque suene negativa, da la importancia, así como validez a la necesidad de más y mejores arquitectos de software, pues es precisamente los retos que genere la administración actual la que generará una nueva y hasta más unificada visión de lo que qué es la Arquitectura de software.