Una de las particularidades del rol de Arquitecto de Software en sus muchas variantes (Enterprise, Solutions, Applications, Information, etc) es precisamente tener la visión completa de los sistemas, a lo largo de su ciclo de vida (no tan sólo en su definición o construcción) para asegurar que la calidad del producto es la esperada y poder plantear alternativas de evolución / remediación en caso de no serlo.
Esto sin embargo a veces parece entrar en colisión con la especialización y separación de roles en el desarrollo de aplicaciones corporativas.
Es habitual encontrar que los requerimientos funcionales del sistema, la vista de la arquitectura, el diseño de los diferentes componentes, el plan de pruebas y despliegue, la definición de las tareas de monitorización y operación, etc, sea definido por personas diferentes y lo que es mucho peor, sin comunicación directa con el resto de stakeholders.. la única comunicación es un workflow abstracto en el que cada uno entrega unos componentes o procedimientos y el workflow pasa al siguiente estado.
La separación de roles en la ejecución no implica que la información sobre el sistema se disperse, descontextualice o se oculte
Al menos el arquitecto debe poder contemplar el sistema en su conjunto para poder comunicar la información necesaria a cada uno de los roles ejecutivos u operativos
