Funciones Principales de Un Arquitecto de Software

Funciones principales de un arquitecto de software:            

Arquitectura: Definición de arquitectura de los sistemas, vista física, vista lógica, principios de arquitectura, seguridad, etc. Selección de Software: Pilas de aplicaciones, bases de datos, librerías, frameworks, estándares tecnológicos, etc. Selección de Infraestructura: Sistemas Operativos, hardware, redes, sistemas de recuperación, etc. Requisitos no Funcionales: Rendimiento, escalabilidad, seguridad, etc. Liderazgo: Liderazgo Técnico, responsabilidad y autoridad, dirección de equipos, etc. Coaching y Mentoring: Ayuda sobre problemas técnicos, ayuda en la evolución profesional, etc. Metodología de Proyectos: Estructura de Proyectos, Metodologías (Waterfall, Scrum, RUP, XP...). Procesos de Desarrollo: Control de versiones de código fuente, procesos de construcción, integración continua, automatización de pruebas y otros procesos y herramientas de desarrollo. Prácticas y Estándares: Estándares de codificación y libros blancos, selección de herramientas, etc. Diseño, Desarrollo y Pruebas: Diagramas UML, codificación, pruebas unitarias, etc. Experiencia: Conocimiento sobre tecnologías y arquitecturas. Estar al día en cuanto a tendencias tecnológicas: 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

Definición de la arquitectura del software El proceso de definición de la arquitectura parece bastante simple. Todo lo que tienes que hacer es identificar cuáles son los requerimientos y diseñar 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 definición de la arquitectura puede ser dividida en un número de elementos diferentes.

1. Manejo de requerimientos no-funcionales: Los proyectos de software a menudo quedan atrapados con los usuarios que preguntan sobre las características que desean, pero rara vez se les pregunta que requerimientos no-funcionales (o cualidades del sistema) necesitan. Algunas veces los actores dirán que "el sistema debe ser rápido", pero eso es muy subjetivo. Los requerimientos no-funcionales necesitan ser específicos, medibles, alcanzables y capaces de ser probados si vamos a cumplirlos. La mayoría de los requerimientos no-funcionales son técnicos 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 cuáles son los requerimeintos y llevarlos a cabo. Después de todo, ¿Cuántos sistemas has visto que genuinamente necesiten ser operacionales 24x7?

2. Definición 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 definición de la arquitectura te permite pensar sobre como vas a tomar los requerimientos junto con las restricciones impuestas y resolver el problema. La definición de la arquitectura es sobre introducir estructura, directrices, principios y ligerazgo a los aspectos técnicos del proyecto de sofware. Definir la arquitectura es tu trabajo como arquitecto pero hay una gran diferencia entre diseñar un sistema desde cero y extender uno ya existente.

3. Selección de la tecnología: La selección de la tecnología es típicamente un ejercicio divertido pero tiene su lista justa de retos cuando te fijas en el costo, licenciamiento, relación con proveedores, estrategia de tecnología, compatibilidad, interoperabilidad, soporte, desarrollo, politicas de actualización, entornos de usuario final y aún 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 tecnologías en realidad funcionan. La seleccion de tecnologías es todo sobre manejar riesgos; reducir riesgos donde existe alta complejidad o incertidumbre e introducir riesgos donde hay beneficios que obtener. Las decisiones de tecnología 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 construcción para un proyecto de software hasta las librerias y frameworks que están siendo introducidos durante el desarrollo. Si estás definiendo una arquitectura, también necesitas estar seguro que las elecciones que estan siendo tomadas son las correctas. Otra vez hay una gran diferencia entre evaluar una tecnología para un nuevo sistema y agregar una tecnología a un sistema que ya existe.

4. Evaluación de la arquitectura: Si estas diseñando 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 más grandes problemas con el software es que es complejo y abstracto, lo cual hace difícil visualizar las características en tiempo de ejecución desde diagramas UML o el código mismo. Tenemos un número 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. Colaboración 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 más 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.

Liberación de la arquitectura del software También 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 través de los elementos que contribuyen a un proyecto exitoso.

1. Apropiarse del panorama completo: Con el fin de llevar la arquitectura hacia una conclusión exitosa, es importante que alguien tenga el panorama completo y que venda la visión 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 más que solamente dejarla en manos de un "equipo de implementación".

2. Liderazgo: Apropiarse del panorama completo es un especto técnico del liderazgo, pero hay otras cosas que necesitamos que esten hechas durante la fase de liberación de un proyecto. Estas incluyen tomar responsabilidades, proveer orientación técnica, tomar decisiones técnicas y tener la autoridad para tomarl dichas decisiones. Como el arquitecto, necesitas tener el liderazgo técnico para asegurar que todo esté caminando perfecto y que el equipo esté siendo dirigido en la dirección correcta y continuamente. La posición del arquitecto es inherentemente sobre liderazgo y aunque esto suene obvio, muchos equipos que realizan proyectos no tienen el liderazgo técnico que necesitan, con arquitectos asumiendo que una liberación 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 mayoría de proyectos de desarrollo, con muchos miembros en el equipo sin el soporte que requieren. Mientras el líder técnico intenta dirigir el proyecto como un todo, hay ocasiones en que ciertas personas necesitan asistencia. Además 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/diseño y ayudarlos con sus problemas de codificación.

4. Asegurar la calidad: Incluso con la mejor arquitectura y liderazgo en el mundo, una liberación pobre puede causar que un proyecto de la vuelta del éxito al fracaso. Asegurar la calidad es una parte amplia de la función de un arquitecto, pero esto es mas que solo hacer revisiones de código. Por ejemplo, necesitas una linea de referencia como defensa para asegurarte, y esto significa la introducción de estándares y prácticas de trabajo. Desde una persepectiva de desarrollo de software, estas pudieran incluir estándares de codificación, principios de diseño y herramientas de análisis de código fuente a través de una contínua integración, pruebas unitarias automatizadas y herramientas de cobertura de código. Se puede decir que la mayoría 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 arquitectónicamente, con lógica de negocios crítica, complejas y altamente visibles. Solo necesitas ser pragmático y darte cuenta que no puedes necesariamente asegurar todo, de hacer algo más que no hacer nada.

5. Diseño, desarrollo y pruebas: La última cosa que recae sobre la función de un arquitecto es el diseño, el desarrollo y las pruebas. Ser un arquitecto práctico no significa necesariamente que te tienes que involucrar en el día a día con las tareas de codificar, pero si implica que estes contínuamente 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 función del arquitecto? La mayoría de los arquitectos tienen bastante experiencia, entonces tiene sentido mantener esas habilidades actualizadas. Además, el arquitecto puede experimentar el mismo dolor que todos los demás en el equipo, que a su vez ayuda a entender mejor como es vista su arquitectura desde la perspectiva de los desarrolladores. Muchas compañías tienen políticas que previenen a los arquitectos de escribir código porque sus arquitectos son "tan valiosos como para ejecutar este trabajo cómodo". 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 liberación exitosa? Por su puesto que hay situaciones donde no es práctico que se involucren a nivel código. Por ejemplo, un proyecto grande generalmente significa un panorama más amplio que cuidar y puede haber ocasiones donde simplemente no tengas el tiempo. Pero generalmente hablando, un arquitecto que codifica es más efectivo y más feliz que un arquitecto que solo mira desde un extremo.

http://micro-howto.blogspot.mx/2010/02/eres-un-arquitecto-de-software.html

o o o o o o o o

Funciones principales: Arquitectura: Definición de arquitectura de los sistemas, vista física, vista lógica, principios de arquitectura, seguridad, etc. Selección de Software: Pilas de aplicaciones, bases de datos, librerías, frameworks, estándares tecnológicos, etc. Selección de Infraestructura: Sistemas Operativos, hardware, redes, sistemas de recuperación, etc. Requisitos no Funcionales: Rendimiento, escalabilidad, seguridad, etc. Liderazgo: Liderazgo Técnico, responsabilidad y autoridad, dirección de equipos, etc. Coaching y Mentoring: Ayuda sobre problemas técnicos, ayuda en la evolución profesional, etc. Metodología de Proyectos: Estructura de Proyectos, Metodologías (Waterfall, Scrum, RUP, XP…). Procesos de Desarrollo: Control de versiones de código fuente, procesos de construcción, integración continua, automatización de pruebas y otros procesos y herramientas de desarrollo.

o o o o

Prácticas y Estándares: Estándares de codificación y libros blancos, selección de herramientas, etc. Diseño, Desarrollo y Pruebas: Diagramas UML, codificación, pruebas unitarias, etc. Experiencia: Conocimiento sobre tecnologías y arquitecturas. Estar al día en cuanto a tendencias tecnológicas: Agile, Web 2.0, SOA, Lightweight Java EE, etc.Web 2.0, SOA, Lightweight Java EE, etc.

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