Arquitectura - ¿Que es y que hace el arquitecto'

Que es la arquitectura de software y cual es el papel del arquitecto?

He escuchado muchas veces frases como “Debes tener en cuenta que la arquitectura se hace al inicio, después simplemente desarrollamos”, “Eso fue una decisión de arquitectura y debe respetarse” o “Esperemos a que el arquitecto tenga tiempo para que tomemos una decisión y continuemos el desarrollo”. La verdad no estoy de acuerdo en absoluto con ninguna de ellas porque en mi opinión:

• La arquitectura no incluye solo el diseño de unos componentes en UML y la aplicación de 4+1 vistas o cualquier otra estrategia de documentación. Esta va mucho más allá e incluye, el análisis y entendimiento de la necesidad, el diseño arquitectónico de los componentes y sus relaciones satisfaciendo cada uno de los drivers arquitectónicos y la asesoría y direccionamiento en el desarrollo. En torno a este planteamiento no tiene sentido decir que se hizo un correcto diseño pero que el desarrollo no satisface los drivers arquitectónicos. Era responsabilidad del arquitecto brindar el acompañamiento y la asesoría al equipo de desarrollo para que se realizara la implementación adecuadamente dentro del contexto.

• Las decisiones de arquitectura no son palabra de Dios, de hecho es imposible en el inicio del proyecto tener todo el alcance claro y tomar decisiones completamente acertadas en torno a esto. La arquitectura es un plan más de aquellos que hacemos en el proyecto y como todo plan debe ser flexible y adaptarse  a las necesidades de este, no al contrario. De hecho en la medida de lo posible las decisiones deben tomarse en conjunto con el equipo, el Arquitecto debería actuar más como un asesor que orienta a las personas en torno al logro de un mejor diseño que satisfaga todos los drivers arquitectónicos. Esto es muy utópico porque normalmente la arquitectura se realiza cuando el equipo aún no está conformado o se hacen compromisos de diseño en etapa comercial, pero al menos debemos garantizar que ésta recibe la adecuada retroalimentación por parte del equipo previo a la implementación y que este se sienta conforme. Después de todo quien construye se debe sentir cómodo con las herramientas que usa y la arquitectura es una herramienta más. No una imposición.

• El arquitecto no debe ser el punto central de toma de decisiones de diseño (Al menos no de todas) porque lo más probable es que se convierta en un cuello de botella y frene muchos temas de implementación. Incluso lo más probable es que el equipo pueda tomar mejores decisiones porque tienen el conocimiento en detalle de la necesidad. Con esto no quiero decir que todos tomen decisiones que podrían incluso ir en contravía, me refiero al hecho de que las decisiones sean concertadas por todo el equipo y no solo por el arquitecto. Esto no quita la necesidad de que el arquitecto preste el servicio de revisiones a las decisiones ya tomadas o participe como un miembro más en el equipo que tomará la decisión.

En conclusión el arquitecto de software no realiza una serie de actividades, simplemente cumple un único objetivo “Garantizar que el software sea implementado de forma tal que satisfaga todos los Drivers arquitectónicos, lo que a su vez se traducirá en satisfacción de las necesidades del cliente”. 

Si esto no se logra podríamos considerar que la arquitectura fue todo un fracaso aún cuando haya sido muy bien definida en el papel. ¡El papel puede con todo!