¿Cómo y por qué la industria tecnológica comenzó a utilizar el arquitecto del título?

Comparar el diseño de computadoras y software con el diseño de edificios es probablemente tan antiguo como lo es la programación.

Refiriéndose a la “arquitectura” de una CPU es probablemente el uso más temprano de ese término, lo que probablemente condujo al uso posterior del término “arquitectura de software” y, eventualmente, a principios o mediados de la década de 1990, el título del trabajo “Arquitecto de software “.

Tengo un vago recuerdo de que “arquitecto” se aplicó inicialmente más popularmente a las preocupaciones de toda la empresa. Tecnologías de redes, tecnologías de mensajería, opciones estratégicas sobre inversiones en plataformas, sistemas operativos, bases de datos, servidores de aplicaciones, en lugar de estar dentro de los límites de un solo proyecto de software. Pero la aplicación de la función y el título a la arquitectura de un proyecto de software complejo se hizo popular a fines de la década de 1990 y dejó de existir en 1999.

La popularidad del título probablemente provino de una combinación del boom de las puntocom y el deseo de todos de ser una startup moderna y moderna, además de la creciente popularidad (y complejidad) de las aplicaciones de n niveles. Saltando sobre varios párrafos que acabo de escribir sobre la evolución del cliente / servidor a 3 niveles a n niveles a la nube, los proyectos se hicieron grandes y complejos. La naturaleza de los proyectos cambió y, por supuesto, la naturaleza del trabajo cambió.

Todos los proyectos grandes y complejos tienen una tensión natural (o al menos predecible) entre una visión unificadora y el trabajo en equipo. Podría decirse que el software tiende a tener los proyectos más complejos (y antes de comenzar a arrojarme contraejemplos, asegúrese de que esos contraejemplos no incorporen o dependan del software …). Uno de los factores más importantes en el éxito de proyectos complejos es una visión unificada. La forma más fácil de tener una visión unificada es tener un solo programador, o más tarde el modelo de “Programador jefe” de Brook.

Pero cada vez más y más grandes organizaciones (que a menudo contratan a desarrolladores más y menos talentosos) estaban luchando por crear aplicaciones públicas utilizando tecnologías cada vez más complejas. La idea de tener un papel técnico que solo abordara este aspecto se volvió atractiva. A medida que los proyectos empresariales crecieron en complejidad por varias razones (incluida la interconexión más profunda con otros proyectos empresariales dentro de la empresa), surgió un papel similar en un nivel estratégico diferente.

Esto sucedió en un momento en que la arquitectura Cliente-Servidor se estaba volviendo popular en la industria. Condujo al advenimiento de la arquitectura de varios niveles. El riesgo de que un proyecto de desarrollo de software pueda terminar creando un “nuevo” producto final que ya existía ha crecido rápidamente.

Para evitar tales riesgos, era necesario el papel de un “Arquitecto” , que transformaría el lenguaje empresarial y crearía un prototipo en el que los desarrolladores y evaluadores puedan trabajar. Las decisiones de los arquitectos son después de consultar después de consultar a las partes interesadas y los equipos de gestión en tierra y en alta mar.

Espero que esto haya ayudado.