¿Cuáles son las cualidades requeridas para un arquitecto de software?

1. Existe la llamada Gang of Four, un equipo de escritores que ha escrito un libro muy famoso sobre el patrón de diseño SW. Personalmente, creo que todo diseñador y arquitecto de SW tiene que conocer y comprender los patrones mencionados en este libro . También hay otros patrones que debe tener en cuenta, pero este es obligatorio.
2. Un criterio importante para un buen diseño de software es que es una prueba futura . Como la tecnología cambia rápidamente, la separación de la tecnología y la lógica de la aplicación es importante. Es una especialización de la separación de preocupación principal. Durante la descomposición, debe vigilar las dependencias de las tecnologías. Si un componente depende de una tecnología en particular, debe encapsularse de una manera que le permita definir componentes lógicos de aplicación pura. Reemplazar una tecnología no debe cruzar los límites del paquete.
Por ejemplo, si almacenamos mensajes de registro en una base de datos, el servicio no debe llamarse “ILogDatabase”, ya que proporciona información sobre la tecnología utilizada. En su lugar, nombre el servicio “ILogRepository” o “ILogServer” y agregue un subpaquete “logDatabase” que implementa la conexión al DBMS. Puede verificar que su arquitectura cumple con este principio haciendo la pregunta “¿Qué necesito cambiar si almaceno los datos de registro en un archivo XML en el futuro?”. La respuesta debería ser “solo este paquete de tecnología en particular” y definitivamente ninguna interfaz pública.
3. Y finalmente, es importante que hagas el trabajo. Es decir, hacer el trabajo que debe hacer un arquitecto. Puede apoyar a otros equipos y a los miembros de su equipo con otras actividades, si ha terminado con su trabajo pero no antes de eso. Y para hacer esto más concreto, proporcionaré algunos ejemplos de los que es responsable un arquitecto:
a. Requisitos de ingeniería de soporte como consultor técnico.
si. Revisar los requisitos .
C. Proporcionar estimaciones .
re. Proporcionar diseño .
mi. Explique el diseño a los desarrolladores.
F. Identifique las necesidades de capacitación en su equipo y haga lo necesario para cerrar estas brechas. Preferiblemente eres tú quien los entrena.
sol. Verifique que la implementación siga su diseño .
h. Equipo de prueba de soporte . Asegure la capacidad de prueba de su diseño. Proporcionar herramientas si es necesario.
Por supuesto, está perfectamente bien si delegas estas actividades a los miembros del equipo si crees que pueden manejarlo. Pero al final del día, usted es responsable del resultado ya que es el arquitecto. Pero no eres responsable de todo. Aquí hay algunos ejemplos de los cuales usted no es responsable:
yo. No escribes requisitos.
j. No lo implementas.
k. No lo pruebas.
l. No planifica ni realiza un seguimiento de las actividades y tampoco dirige el equipo.
Por supuesto, ambas listas no están completas y puede adaptarlas según sus necesidades, pero no debe dejar espacios en blanco.