Funciones principales de un arquitecto de software:

Arquitectura: Definicin de arquitectura de los sistemas, vista fsica, vista lgica, principios de arquitectura, seguridad, etc. Seleccin de Software: Pilas de aplicaciones, bases de datos, libreras, frameworks, estndares tecnolgicos, etc. Seleccin de Infraestructura: Sistemas Operativos, hardware, redes, sistemas de recuperacin, etc. Requisitos no Funcionales: Rendimiento, escalabilidad, seguridad, etc. Liderazgo: Liderazgo Tcnico, responsabilidad y autoridad, direccin de equipos, etc. Coaching y Mentoring: Ayuda sobre problemas tcnicos, ayuda en la evolucin profesional, etc. Metodologa de Proyectos: Estructura de Proyectos, Metodologas (Waterfall, Scrum, RUP, XP...). Procesos de Desarrollo: Control de versiones de cdigo fuente, procesos de construccin, integracin continua, automatizacin de pruebas y otros procesos y herramientas de desarrollo. Prcticas y Estndares: Estndares de codificacin y libros blancos, seleccin de herramientas, etc. Diseo, Desarrollo y Pruebas: Diagramas UML, codificacin, pruebas unitarias, etc. Experiencia: Conocimiento sobre tecnologas y arquitecturas. Estar al da en cuanto a tendencias tecnolgicas: Agile, Web 2.0, SOA, Lightweight Java EE, etc.

http://geeks.ms/blogs/oalvarez/archive/2009/07/02/funciones-principales-de-un-arquitecto-desoftware.aspx

Definicin de la arquitectura del software

El proceso de definicin de la arquitectura parece bastante simple. Todo lo que tienes que hacer es identificar cules son los requerimientos y disear un sistema que los satisfaga. Pero en realidad no es tan simple y el papel de arquitectura de software puede varia ampliamente dependiendo de que tan comprometido estas y que tan seriamente visualizas tu papel. Como el siguiente diagrama muestra, la parte de la definicin de la arquitectura puede ser dividida en un nmero de elementos diferentes.

1. Manejo de requerimientos no-funcionales: Los proyectos de software a menudo quedan atrapados con los usuarios que preguntan sobre las caractersticas que desean, pero rara vez se les pregunta que requerimientos no-funcionales (o cualidades del sistema) necesitan. Algunas veces los actores dirn que "el sistema debe ser rpido", pero eso es muy subjetivo. Los requerimientos no-funcionales necesitan ser especficos, medibles, alcanzables y capaces de ser probados si vamos a cumplirlos. La mayora de los requerimientos no-funcionales son tcnicos por naturaleza y a menudo tienen una alta influencia sobre la arquitectura del sofware. Entender los requerimientos no-funcionales es una parte crucial, pero hay una diferencia entre asumir cules son los requerimeintos y llevarlos a cabo. Despus de todo, Cuntos sistemas has visto que genuinamente necesiten ser operacionales 24x7?

2. Definicin de la arquitectura: Con los requerimientos no-funcionales capturados, el siguiente paso es empezar a pensar sobre como vas a solucionar los problemas indicados por los actores y definir la arquitectura. Se puede decir que cada sistema tiene una arquitectura, pero no que cada sistema tiene una arquitectura definida. Y ese realmente es el punto aqu. El proceso de la definicin de la arquitectura te permite pensar sobre como vas a tomar los requerimientos junto con las restricciones impuestas y resolver el problema. La definicin de la arquitectura es sobre introducir estructura, directrices, principios y ligerazgo a los aspectos tcnicos del proyecto de sofware. Definir la arquitectura es tu trabajo como arquitecto pero hay una gran diferencia entre disear un sistema desde cero y extender uno ya existente.

3. Seleccin de la tecnologa: La seleccin de la tecnologa es tpicamente un ejercicio divertido pero tiene su lista justa de retos cuando te fijas en el costo, licenciamiento, relacin con proveedores, estrategia de tecnologa, compatibilidad, interoperabilidad, soporte, desarrollo, politicas de actualizacin, entornos de usuario final y an mas. La suma de estos factores puede a menudo hacer una tarea simple y convertirla en una completa pesadilla. Y ah est la pregunta de si las tecnologas en realidad funcionan. La seleccion de tecnologas es todo sobre manejar riesgos; reducir riesgos donde existe alta complejidad o incertidumbre e introducir riesgos donde hay beneficios que obtener. Las decisiones de tecnologa se necesitan hacer tomando en cuenta todos los factores, y todas las decisiones deben ser revisadas y vueltas a evaluar. Esto incluye los principales bloques de construccin para un proyecto de software hasta las librerias y frameworks que estn siendo introducidos durante el desarrollo. Si ests definiendo una arquitectura, tambin necesitas estar seguro que las elecciones que estan siendo tomadas son las correctas. Otra vez hay una gran diferencia entre evaluar una tecnologa para un nuevo sistema y agregar una tecnologa a un sistema que ya existe.

4. Evaluacin de la arquitectura: Si estas diseando software, necesitas preguntarte a t mismo si tu arquitectura funcionar. Para m, una arquitectura funciona si esta satisface los requerimientos no funcionales, provee los fundamentos necesarios para el resto del codigo y provee una plataforma suficiente para resolver los problemas de negocio subyacentes. Uno de los ms grandes problemas con el software es que es complejo y abstracto, lo cual hace difcil visualizar las caractersticas en tiempo de ejecucin desde diagramas UML o el cdigo mismo. Tenemos un nmero diferente de pruebas de todo el ciclo de vida de desarrollo del software que nos da la confianza de que el sistema que estamos liberando funcionar cuando sea mostrado. Entonces por qu no hacemos lo mismo para nuestras arquitecturas? si puedes probar tu arquitectura, entonces puedes probar que esta funciona. Y si puedes hacer eso tan pronto como sea posible, puedes reducir el total de riesgos de que el proyecto falle mas que simplemente esperar por lo mejor.

5. Colaboracin de la arquitectua: Es inusual para un sistema que viva aislado y existe un par de personas que necesitan entender esto. Esto va desde el equipo de desarrollo inmediato que necesitan entender la arquitectura hasta los actores que tienen un interes como seguridad, base de datos, operaciones, mantenimineto, soporte y ms puntos de vista. Para que un proyecto de sofware sea exitoso, necesitan colaborar muy de cerca con los encargados de sistemas para asegurar que la arquitectura se integrara satisfactoriamente con su entorno. Desafortunadamente, la colaboracion en la arquitectura en el equipo de desarrollo rara vez ocurre, por no hablar de los actores externos.

Liberacin de la arquitectura del software

Tambin es la misma historia con la entrega de la arquitectura, donde el papel de la arquitectura del software puede variar dependiendo del nivel de compromiso a travs de los elementos que contribuyen a un proyecto exitoso.

1. Apropiarse del panorama completo: Con el fin de llevar la arquitectura hacia una conclusin exitosa, es importante que alguien tenga el panorama completo y que venda la visin a lo largo del ciclo de vida del desarrollo de software, que evolucione a lo largo del proyecto si es necesario y que tome la responsabilidad de asegurarse que ser entregado correctamente. Si has definido una arquitectura, hace sentido permanecer continuamente comprometido y evolucionarla ms que solamente dejarla en manos de un "equipo de implementacin".

2. Liderazgo: Apropiarse del panorama completo es un especto tcnico del liderazgo, pero hay otras cosas que necesitamos que esten hechas durante la fase de liberacin de un proyecto. Estas incluyen tomar responsabilidades, proveer orientacin tcnica, tomar decisiones tcnicas y tener la autoridad para tomarl dichas decisiones. Como el arquitecto, necesitas tener el liderazgo tcnico para asegurar que todo est caminando perfecto y que el equipo est siendo dirigido en la direccin correcta y continuamente. La posicin del arquitecto es inherentemente sobre liderazgo y aunque esto suene obvio, muchos equipos que realizan proyectos no tienen el liderazgo tcnico que necesitan, con arquitectos asumiendo que una liberacin exitosa no es necesariamente su problema.

3. Entrenar y guiar: El entrenamiento y la guianza es una actividad que se suele pasar por alto en la mayora de proyectos de desarrollo, con muchos miembros en el equipo sin el soporte que requieren. Mientras el lder tcnico intenta dirigir el proyecto como un todo, hay ocasiones en que ciertas personas necesitan asistencia. Adems de esto, entrenar y guiar provee una forma de mejorar las habilidades de la gente y ayudarlas a mejorar sus propias carreras profesionales. Esto es algo que recae directamente como un mandato para el arquitecto, pero claramente hay una gran diferencia entre entrenar a tu equipo en arquitectura/diseo y ayudarlos con sus problemas de codificacin.

4. Asegurar la calidad: Incluso con la mejor arquitectura y liderazgo en el mundo, una liberacin pobre puede causar que un proyecto de la vuelta del xito al fracaso. Asegurar la calidad es una parte amplia de la funcin de un arquitecto, pero esto es mas que solo hacer revisiones de cdigo. Por ejemplo, necesitas una linea de referencia como defensa para asegurarte, y esto significa la introduccin de estndares y prcticas de trabajo. Desde una persepectiva de desarrollo de software, estas pudieran incluir estndares de codificacin, principios de diseo y herramientas de anlisis de cdigo fuente a travs de una contnua integracin, pruebas unitarias automatizadas y herramientas de cobertura de cdigo. Se puede decir que la mayora de los proyectos no aseguran la calidad lo suficiente, por tanto necesitan imaginarse que es lo importante y garantizarlo suficientemente. Para m, las partes importantes de un proyecto son todas aquellas significativas arquitectnicamente, con lgica de negocios crtica, complejas y altamente visibles. Solo necesitas ser pragmtico y darte cuenta que no puedes necesariamente asegurar todo, de hacer algo ms que no hacer nada.

5. Diseo, desarrollo y pruebas: La ltima cosa que recae sobre la funcin de un arquitecto es el diseo, el desarrollo y las pruebas. Ser un arquitecto prctico no significa necesariamente que te tienes que involucrar en el da a da con las tareas de codificar, pero si implica que estes contnuamente involucrado en el proyecto, ayudando activamente a darle forma y a liberarlo. Dicho esto, porque las actividades diarias de codificar no son parte de la funcin del arquitecto? La mayora de los arquitectos tienen bastante experiencia, entonces tiene sentido mantener esas habilidades actualizadas. Adems, el arquitecto puede experimentar el mismo dolor que todos los dems en el equipo, que a su vez ayuda a entender mejor como es vista su arquitectura desde la perspectiva de los desarrolladores. Muchas compaas tienen polticas que previenen a los arquitectos de escribir cdigo porque sus arquitectos son "tan valiosos como para ejecutar este trabajo cmodo". Claramente es una actitud incorrecta ... por qu dejar que tus arquitectos pongan todo su esfuerzo en definir la arquitectura si no vas a dejar que contribuyan a su liberacin exitosa? Por su puesto que hay situaciones donde no es prctico que se involucren a nivel cdigo. Por ejemplo, un proyecto grande generalmente significa un panorama ms amplio que cuidar y puede haber ocasiones donde simplemente no tengas el tiempo. Pero generalmente hablando, un arquitecto que codifica es ms efectivo y ms feliz que un arquitecto que solo mira desde un extremo.

http://micro-howto.blogspot.mx/2010/02/eres-un-arquitecto-de-software.html
Funciones principales: Arquitectura: Definicin de arquitectura de los sistemas, vista fsica, vista lgica, principios de arquitectura, seguridad, etc. Seleccin de Software: Pilas de aplicaciones, bases de datos, libreras, frameworks, estndares tecnolgicos, etc. Seleccin de Infraestructura: Sistemas Operativos, hardware, redes, sistemas de recuperacin, etc. Requisitos no Funcionales: Rendimiento, escalabilidad, seguridad, etc. Liderazgo: Liderazgo Tcnico, responsabilidad y autoridad, direccin de equipos, etc. Coaching y Mentoring: Ayuda sobre problemas tcnicos, ayuda en la evolucin profesional, etc. Metodologa de Proyectos: Estructura de Proyectos, Metodologas (Waterfall, Scrum, RUP, XP). Procesos de Desarrollo: Control de versiones de cdigo fuente, procesos de construccin, integracin continua, automatizacin de pruebas y otros procesos y herramientas de desarrollo.

o o o o o o o o

o o o o

Prcticas y Estndares: Estndares de codificacin y libros blancos, seleccin de herramientas, etc. Diseo, Desarrollo y Pruebas: Diagramas UML, codificacin, pruebas unitarias, etc. Experiencia: Conocimiento sobre tecnologas y arquitecturas. Estar al da en cuanto a tendencias tecnolgicas: Agile, Web 2.0, SOA, Lightweight Java EE, etc.Web 2.0, SOA, Lightweight Java EE, etc.

http://robmv.com/arquitecto-de-software/