1
¿Cual es el rol de un arquitecto de software, en general?
Yo creo que es el encargado de Modelar la App, Aportar con nuevos tecnologías que permitan la esca-labilidad de la Aplicación y la fácil integración de nuevos cambios dentro del Software , sin la necesidad de refactoring costosos dentro de estas.
¿Cual es el rol de un arquitecto de software, en agilidad?
Yo creo que este rol se pierde dentro de la Agilidad, ya que el equipo completo debe estar integrado dentro de este proceso, aportando las ideas y mejoras en la App.
¿El arquitecto debe ser una persona, o pueden ser todo un equipo?
Para mi debiera ser todo el Equipo.
Ya que una sola persona implica mas un tema de dictadura de la decisiones dentro del Software y se pierde la BrainStorming que puede hacer el equipo para el Software.
En mi humilde opinión, el término de Arquitecto es un concepto muy arraigado al mundo no-ágil y tal vez sea válido plantearse un concepto diferente.
Sin embargo, aquí les dejo algunas características de Arquitecto en términos Generales que alguna vez tuve que investigar/definir.
1 Recibir, evaluar y estimar requerimientos de desarrollo a medida de clientes.
2 Definir los elementos y herramientas de software que se usarán en los desarrollos (librerías, frameworks, base de datos, sistemas operativos, etc.)
3 Asistir a los desarrolladores frente a algún problema específico, de manera que no tengan que invertir tiempo en investigar para bajar el riego en el desarrollo.
4 Diseñar y definir la arquitectura de soluciones, apoyando en proyectos con clientes, buscando ser un nexo entre el cliente y el equipo de desarrollo.
5 Participación en la elaboración de propuestas para un aporte técnico frente a las particularidades de lo solicitado.
6 Documentar a través de estándares (UML) los diseños de arquitectura para ser implementado por desarrolladores. Identificando los diferentes aspectos tales como: Estructura Estática, Casos de Uso, Diagramas de secuencia, Diagrama de colaboración, diagramas de estados, seguridad, etc.
7 Poner a dispocición información relativa a investigaciones de tecnología o trabajos especificos, idealmente con ejemplos.
8 Definición de requerimientos no funcionales tales como: escalabilidad, seguridad, rendimiento, etc.
9 Liderar técnicamente los desarrollos que están a su cargo.
10 Seguir e impulsar la metodología de desarrollo adoptada por la empresa o por el área donde esté apoyando.
11 Estar al día en cuanto a tendencias tecnológicas: Métodos ágiles, Web 2.0, SOA, Java EE, etc.
Hola, les voy a contar mi experiencia en un proyecto en el que trabaje en ibm. El arquitecto que nos toco era un tipo bastante inteligente y en temas de arquitectura nos superaba a todos pero aun asi el decidio que todos dieramos nuestras ideas en cuanto a la arquitectura de la aplicacion, en consecuencia el decidio adoptar algunas de las ideas que le planteamos porque considero que eran mejores que las que el mismo habia propuesto. Ademas de esto la ventaja fue que ya antes de empezar a crear la aplicacion teniamos una vision de la arquitectura de esta.
Obviamente debe existir el rol de arquitecto ya que debe existir un especialista quien pueda guiar a los demas. En eso concuerdo en que no todos deben saber todo, pero el poder participar y dar tu opinion en cuanto a la arquitectura de la aplicacion es una experiencia enriquecedora y ademas permite poder reconocer si una persona tiene talento como arquitecto, cosa que con el modelo tradicional es muy dificil saber.
Por otro lado tengo mi experiencia en synapsis donde existia un arquitecto y su palabra era absoluta. Como consecuencia generalmente teniamos problemas con el porque generalmente encontrabamos que la arquitectura no soportaba o simplemente fallaba a la hora de dar solucion a los requerimientos de la aplicacion. La unica solucion que encontramos con un compañero de trabajo fue decompilar el core (ya que ni al codigo teniamos acceso) y trabajar sobre una version modificada a la original y subir a la mala las modificaciones. Esta demas decir que tanto el problema como la solucion eran pesimas.
En conclusion creo que:
- El arquitecto debe existir. Debe existir alguien que tenga los conocimientos relevantes para guiar a los demas.
- Si estas en la etapa inicial el arquitecto deberia trabajar con el equipo en la construccion de la arquitectura de la aplicacion.
- Si ya estas en la etapa de desarrollo el arquitecto deberia tener la flexibilidad necesaria como para aceptar propuestas de cambio y/o mejoras ante problemas en la arquitectura.
Como se podria decir, “un equipo de cabezas piensa mas que una”.
Julio Oyarzun
Con respecto a la Arquitectura, es necesario que alguien con conocimiento oriente al equipo, no todos deben saber de todo. Creo que se toman muy a pecho lo de la agilidad, en mi experiencia 8 años app. dirigiendo proyectos con rup, scrum, xp y kanban, hemos podido llegar a la luz(nuestra luz): estas son metodologias, y puedes usar de ellas, la parte que necesites, de ehcho hoy ya usamos una hibrido, mezcla de scrum-kanban.
El rol principal del arquitecto es definir el diseño de software para aquellas piezas importantes de las aplicaciones que al ser cambiadas generan un enorme impacto en la aplicación. Quien ocupe este rol se debiera dedicar a analizar las necesidades del usuario y generar una arquitectura base lo suficientemente sólida como para que los desarrolladores puedan cambiar todos los componentes que se desarrollarán a su alrededor sin mayor impacto.
En la agilidad “ideal”, si bien la arquitectura es una actividad que se realiza igual, el rol de arquitecto se pierde, ya que todo el equipo debe hacerse parte del proceso entero de desarrollo desde entender las necesidades del cliente hasta implementar en producción, pasando obviamente por la arquitectura.
Dicho lo anterior, en la realidad los equipos de desarrollo no siempre tienen a disposición una cantidad de miembros suficiente con la experiencia necesaria para hacerse cargo de todas las etapas y por esto, vemos alguna segmentación de roles incluso en la agilidad. Sin embargo, si existe un arquitecto ágil, su rol debiera variar un poco a no solo el diseño de piezas de software clave, sino tambien a enseñar a todo el resto del equipo sobre arquitectura.
La arquitectura como actividad debiera ser parte de toda discusión de diseño de software que el equipo tenga y debiera ser una constante parte del trabajo diario y como tal, todo el equipo debiera realizarlo. Con esto, el rol explícito de arquitecto se va y solo queda como una actividad.
All Shapado.com content and data are available under the
¿Cual es el rol de un arquitecto de software, en general? ¿Cual es el rol de un arquitecto de software, en agilidad? ¿El arquitecto debe ser una persona, o pueden ser todo un equipo?