El Rol de un buen Arquitecto de Software


Resumen—Llegar a ser arquitecto de software no es algo que se consiga de la noche a la mañana o por el resultado de un ascenso laboral. Es un rol, no un rango. Es un proceso de evolución donde gradualmente se gana la experiencia y la confianza necesaria para apoderarse del rol. Mientras que el término “desarrollador de software” está ampliamente divulgado y su definición es clara, este no esel mismo caso de el “arquitecto de software”. Este ensayo habla acerca del rol que un buen arquitecto debe desempeñar dentro de un proceso de desarrollo de software.


Palabras clave— Arquitectura de software, Arquitecto de software, Desarrollo de software

I. Introducción

En términos generales, la arquitectura de software en la mayoría de los proyectos se puede dividir en dos fases: sudefinición y su entrega. Un arquitecto común está involucrado en ambas fases y las tareas en cada una se pueden resumir como se muestra en las figuras 1 y 2.



II. Administración de los requerimientos no funcionales
La primera responsabilidad del rol es la administración de los requerimientos no funcionales. En los proyectos de software siempre existe la necesidad de preguntarle al usuario lasfuncionalidades que quieren, pero rara vez se les pregunta por los requerimientos no funcionales. Algunas veces los stackeholders nos van a decir “El sistema debe ser muy rápido”, pero esto es algo muy subjetivo. Los requerimientos no funcionales deben ser específicos, medibles, logrables y susceptibles a pruebas, además de que el arquitecto se debe asegurar de que todos los qualities delsistema son considerados. Esto incluye las características comunes de ejecución del sistema tales como: rendimiento, escalabilidad, disponibilidad, seguridad y también las que no se consideran de ejecución como: auditoría, extensibilidad, internacionalización y localización.
Cómo los stackeholders no tienen conciencia de los requerimientos no funcionales, alguien los tiene que ayudar a definirlos.Después de todo, cuantos sistemas vemos que en la realidad operen 24x7?, y dado que la mayoría de requerimientos no funcionales son técnicos por naturaleza, tienen un impacto importante en la arquitectura del sistema y deben ser tenidos en cuenta por el arquitecto a la hora de diseñar.
III. Definición de la arquitectura
Con un paquete de requerimientos no funcionales definidos, el siguiente paso esempezar a pensar en como abordar los problemas presentados por los stackeholders y definir la arquitectura. Es adecuado afirmar que cualquier proyecto de software tiene su arquitectura, pero no todos los proyectos de software tienen una arquitectura definida y ese es el punto más importante en este ámbito. El proceso de definición de arquitectura de software te pone a pensar como vas a manejar losrequerimientos además de cualquier restricción impuesta por el cliente o los recursos disponibles que te haga analizar cómo resolver el problema. Entonces se necesita tiempo para pensar explícitamente en como la arquitectura va a resolver los problemas planeados por el cliente y desafortunadamente la arquitectura no va a evolucionar por si sola, alguien tiene que apropiarse del proceso dedefinición de arquitectura y esta responsabilidad obviamente reposa sobre el mencionado y bien ponderado arquitecto de software.
IV. Selección de la tecnología
La selección de la tecnología es típicamente un proceso divertido para el arquitecto pero con ciertos retos que también debe afrontar. Por ejemplo, algunas organizaciones tienen una lista de tecnologías predefinidas que sesgan la elección,mientras que otras empresas están negadas a las tecnologías open source. Además de esto, existen otros factores como el costo, el licenciamiento, las relaciones con proveedores, estrategias de tecnología, compatibilidad, interoperabilidad, soporte técnico, políticas de actualización, ambiente de trabajo del usuario final, etc. La suma de estos factores a menudo puede conducir a realizar una...