Imagen de: Arquitectodesoftware.com |
En el post describimos, las funciones del arquitecto de software, Diferencias entre el Arquitecto de Software del Líder de Desarrollo, Diferencia en las funciones según el tipo de arquitecto, Posibles candidatos, Herramientas que debe manejar, Aspectos positivos de ser un Arquitecto de Software y los Retos a enfrentar.
Pmoinformatica.com, "La Oficina de Proyectos de Informática" presenta: Descripción de cargo del Arquitecto de Software.
Las Funciones del Arquitecto de Software
- Elaborar la arquitectura y diseño de software a partir de los requerimientos del usuario. Haciendo uso de patrones de diseño previamente conocidos, por experiencia personal o manteniéndose actualizado con las últimas técnicas y patrones.
- Crear consenso y entendimiento de la arquitectura. Debe involucrar a cada miembro del equipo, y lograr acuerdos respecto a la arquitectura, la cual debe comunicar y vender.
- Entender los requerimientos no funcionales:
- La mayoría de los requerimientos no funcionales son de naturaleza técnica, y suelen tener mucha influencia en la arquitectura.
- El entendimiento adecuado de estos requerimientos es crucial para desempeñar este rol.
- No basta con asumir cuales son esos requerimientos, se necesita indagar sobre ellos y determinar las necesidades reales.
- Definir la Arquitectura:
- Incluir estructuras, lineamientos, principios y liderazgo sobre los aspectos técnicos del software.
- Esta responsabilidad varía mucho si se está trabajando con un sistema con arquitectura definida frente a diseñar un nuevo sistema.
- Seleccionar Tecnologías:
- Puede llegar a ser un reto, considerando todos los elementos a considerar: costo, licenciamiento, relaciones con proveedores, estrategia de tecnología, compatibilidad, interoperabilidad, soporte, instalación, políticas de actualización, ambientes de usuario final, etc.
- Seleccionar tecnologías se trata de evaluar los riesgos, reduciéndolos cuando existe alta complejidad e incertidumbre y aumentarlos cuando existen beneficios (oportunidades).
- Todos los componentes deben ser evaluados, incluyendo los bloques generales, hasta el detalle de librerías y frameworks.
- Toda decisión de tecnología debería ser revisada y aprobada.
- Evaluar Arquitecturas:
- Al diseñar el software, el arquitecto debe preguntarse si la arquitectura seleccionada podrá satisfacer los requerimientos funcionales y en especial los no funcionales.
- Las arquitecturas también se pueden probar, y si hacemos esto al principio, podemos evitar el fracaso del proyecto.
Diferencias entre el Arquitecto de Software del Líder de Desarrollo
- El líder de desarrollo se enfoca en conocimiento detallado de áreas específicas mientras que el arquitecto de software necesita ver los problemas de forma amplia, desde diferentes perspectivas, enfocándose en integrar las partes en una red que permita solucionar el problema global.
- El Arquitecto de Software maneja el problema y la solución a una mayor escala y nivel de abstracción.
- Sus decisiones tienen mayor impacto en la duración del proyecto y los riesgos.
- Hacer Arquitectura de Software es tener una visión holística, ver el panorama amplio, para entender como funcional el sistema como un todo.
Diferentes Funciones según el tipo de Arquitecto de Software
Según el arquitecto sea Empresarial, De Aplicación o de Solución, manejará distintos niveles de complejidad, como se muestra en la siguiente tabla que obtuvimos de Wikipedia.
Tipo
de Arquitecto
|
Pensamiento
Estratégico
|
Interacciones
entre Sistemas
|
Comunicaciones
|
Diseño
|
Empresarial
|
Entre
Proyectos.
|
Altamente
abstracto.
|
En
toda la organización.
|
Mínimo,
de Alto Nivel.
|
Soluciones
|
Enfocado
en una solución.
|
Muy
detallado.
|
Múltiples
equipos de Proyecto.
|
Detallado.
|
Aplicaciones
|
Reutilización
y mantenimiento de componentes.
|
Centrado
en una sola aplicación.
|
Un
solo equipo de proyecto.
|
Muy
detallado.
|
Posibles candidatos
Los posibles candidatos son Líderes de Desarrollo o Desarrolladores de nivel avanzado, que durante su evaluación puedan mostrar:
- Varios años de experiencia en la tecnología de desarrollo de software que se está buscando.
- Ejecución de forma consistente y continua de proyectos exitosos en la tecnología de software o soluciones que se está buscando.
- Invierten tiempo en el autoaprendizaje de las mejores prácticas de desarrollo y se mantienen actualizados en los patrones de diseño e ingeniería de software.
- Invierten tiempo en mantenerse actualizados en las últimas tecnologías de informática y desarrollo de software.
- Abordan la arquitectura de software con enfoque crítico y demuestran tener criterio propio.
- Muestran interés en que su propio desarrollo y el de sus pares se apegué a los patrones de diseño e ingeniería de software.
Los candidatos a Arquitectos de Software también pueden ser personas que desarrollaron pequeños proyectos en los cuales eran el único desarrollador (desempeñaban la función de Arquitecto y Desarrollador simultáneamente), por supuesto siempre tomando en cuenta la capacidad y tecnología.
Herramientas que debe manejar
- Lenguaje de documentación visual (ej. UML).
Aspectos positivos de ser un Arquitecto de Software
- Es un rol clave que tiene potencial de agregar mucho valor si se desempeña adecuadamente, lo cual implica por lo general mayor sueldo.
- Debe interactuar con personas clave en la organización, equipo de desarrollo y comunidad de usuarios, por lo que es un rol bastante visible. Esto implica mayores oportunidades de carrera.
Retos a enfrentar
- Uno de los principales problemas que enfrenta un arquitecto de software en el día a día, son los requerimientos funcionales con información incorrecta o incompleta. Requiere de mucha habilidad el poder identificar requerimientos mal documentados antes que sea demasiado tarde.
- Para ser un buen arquitecto de software, es necesario estar en constante estudio de las nuevas técnicas, patrones y herramientas. Para lograr esto se requiere esfuerzo, incluyendo sacrificios de tiempo personal y familiar para invertirlo en autoestudio, cursos, entre otros.
- El rol implica balancear tantos factores que “es muy fácil fracasar”, si esto ocurre, uno de los primeros que tendrá que rendir cuentas es el Arquitecto de Software, por lo que “el reto es no fracasar”.
- Con frecuencia, la complejidad del rol es subestimada, por lo que corresponde al Arquitecto ser un buen comunicador para demostrar el valor agregado del diseño y arquitectura en el proceso de desarrollo de software.
¿y qué opinas tu?
¿Cuál consideras que debe ser el rol del Arquitecto de Software?, ¿Cuál es el rol que se le da al Arquitecto de Software en tu organización?. Te invitamos a dejarnos comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) (puedes firmar tu comentario con la dirección de tu web si así lo deseas).
<< Artículo anterior: El Rol del Arquitecto de Software 1era Parte
¿Buscas más información sobre informática y gerencia de proyectos? suscríbete a nuestra lista de correos
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Referencias
IBM. Roles in the mobile application development lifecycle
Software Engineering Institute. Duties, Skills, & Knowledge of a Software Architect
Wikipedia. Software architect
Transact SQL-DML Funciones y Bases de datos Autor: Rocío Navarro Lacoba >> España (amazon.es) >> Latinoamérica (amazon.com) | Código Limpio Autor: Robert C. Martin >> España (amazon.es) >> Latinoamérica (amazon.com) | Métodos ágiles y Scrum Autor: Alonso Alvarez García y otros >> España (amazon.es) >> Latinoamérica (amazon.com) | Code Complete Autor: Steven C. McConnell >> España (amazon.es) >> Latinoámerica (amazon.com) |
Novedades Amazon
¿Interesado en otros productos Amazon sobre Gestión de Proyectos y Desarrollo de Software?.
>> Sección de Productos Amazon
Otros artículos en “La Oficina de Proyectos de Informática”
Desarrollo Profesional
>> Los 9 empleos en informática mejor pagados de 2013
>> Las 15 certificaciones mejor pagadas de 2013
>> Habilidades interpersonales cada vez más demandadas en los profesionales de Tecnologías de Información
Errores comunes en Desarrollo de Software (Antipatrones)
>> Errores comunes en el desarrollo de software: Base de datos como comunicador de procesos
Desarrollo de software
>> Introducción al mobile testing
>> Requerimientos No Funcionales: Porque son importantes
>> 5 Herramientas para la automatización de pruebas de software
Errores comunes en Desarrollo de Software (Antipatrones)
>> Errores comunes en el desarrollo de software: Base de datos como comunicador de procesos
>> Entrada de datos manejada inadecuadamente (Input Kludge)>> El botón mágico
>> El Objeto Todopoderoso
>> Errores comunes en el desarrollo de Bases de datos: Tercera Parte
>> Errores comunes en el desarrollo de Bases de datos: Segunda Parte
>> Errores comunes en el desarrollo de Bases de datos
>> Errores comunes de programación: Segunda Parte
>> 5 errores comunes de programación
>> El Objeto Todopoderoso
>> Errores comunes en el desarrollo de Bases de datos: Tercera Parte
>> Errores comunes en el desarrollo de Bases de datos: Segunda Parte
>> Errores comunes en el desarrollo de Bases de datos
>> Errores comunes de programación: Segunda Parte
>> 5 errores comunes de programación
Desarrollo de software
>> Introducción al mobile testing
>> Requerimientos No Funcionales: Porque son importantes
>> 5 Herramientas para la automatización de pruebas de software
Cual sería entonces la diferencia entre un arquitecto de software y un PMP (gerente de proyectos)?
ResponderEliminarHe buscado en varios lados y no me queda claro el rol del arquitecto, específicamente en metodología ágiles, en donde se aboga por conocimientos transversales y en donde los alcances son ciertamente desconocidos, se producen muchos cambios que obligan a d deshacer o a hacer refactoring, en fin, en donde todo cambia muy rápidamente. Según lo que he entendido, todos los integrantes deben velar por las ' labores ' que haría un arquitecto, documentar si es necesario en el transcurso de los sprint, etc.
ResponderEliminarHola, yo me hacia la misma pregunta, y encontre algunas respuestas en un curso que hice (Kleer, Argentina), donde se hizo mucho foco los atributos de calidad que una aplicacion debe poseer. El arquitecto es el que tiene que diseñar un plan de medicion de cada uno de ellos. Para que no se algo que ocurra por casualidad sino planificado en un sprint. Ej: Si decis que tiene Manageability, poder medir eso de alguna forma luego en su uso. Otro concepto interesante es la de manejar un portfolio de herramientas y tecnicas, con vision en el paso y en el futuro, con un ejemplo muy especifico como es el tech radar de thoughtworks. Todo esto lo podes meter en una metodologia agil.
Eliminar